Data File Author Feedback Request on AB3

[rob]

At 11:23 AM 6/1/2005 -0400, you wrote:

>Squads. I hate they way they are done internally. I would love to see some
>way of just adding a "blank" squad, that you can then drag units into.
>They are a handy feature, but either having them on for all units or off
>is a pain.

I need you to explain that last sentence for me in more detail. Can you
give me a concrete example of what you'd like to see, why it would be
really useful, and where the current mechanism is gumming things up for you?

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com

[deathlynx]

A feature request I mentioned in the bowels of another thread...
Would it be possible to set member scripts on a more global level? For example when using a certain ruleset all units with a certain tag are invalid...(in B5:CTA group.patrol is not a member of ruleset.war)...They could still be given through options but simply not chosen from the list...

[rob]

At 01:53 PM 6/1/2005 -0400, you wrote:
>5. Ability for a child item to remove an item/option of the parent - not
>sure if I have phrased this correctly tho' sorry

This requires some explanation, please. Can you give me a concrete example
of what you want to accomplish and how it would be utilized?

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com

[Warmonger]

Originally Posted by rob

At 11:23 AM 6/1/2005 -0400, you wrote:

>Squads. I hate they way they are done internally. I would love to see some
>way of just adding a "blank" squad, that you can then drag units into.
>They are a handy feature, but either having them on for all units or off
>is a pain.

I need you to explain that last sentence for me in more detail. Can you
give me a concrete example of what you'd like to see, why it would be
really useful, and where the current mechanism is gumming things up for you?

-Rob

Ok. Examples: Battlefleet Gothic. Capital ships can be squadroned together, but don't have to be. While the smaller escorts have to be in squadrons of two or more. Many people don't squadron their capital ships at all, so it's a lot of extra overhead in the roster view and printout. Of course you can make an "escort squadron" as a unit choice where you can add individual ships, but that makes it where you can't see the stats in front of you unless you either keep them in the overall list or right click for a detail of somekind. Either way, it's a lot of coding.

Warmachine: Squads = Battlegroups. While in lower point games only one Warcaster (squad leader type) is used, in larger games you can have 2-4 total. Each has his own allotment of units that he can take. Using the battlegroup for this second function is great, but not so great for the first, because once again you're viewing a lot of overhead that isn't needed. I DID create a sample setup for that, where I used an option list to add child units to the warcaster. But in my case and other peoples, I sometimes like to but units and see what kind of points I have left for a leader. Makes it hard to tweak the points, especially since it's a game where there isn't a whole lot of room for customizing.

So the point I was making, is that all I have seen of squads so far, is that in the DEF file, they are either turned off, so that they just don't exist. Or they are turned on so that every unit created has its own squad by default. Ick. I qould LOVE the ability as I stated before, of just being able to create a blank squad/battlegroup and drag units into it for organization.

[rob]

At 02:59 AM 6/5/2005 -0400, you wrote:

rob wrote:
At 11:23 AM 6/1/2005 -0400, you wrote:

>Squads. I hate they way they are done internally. I would love to see some
>way of just adding a "blank" squad, that you can then drag units into.
>They are a handy feature, but either having them on for all units or off
>is a pain.

I need you to explain that last sentence for me in more detail. Can you
give me a concrete example of what you'd like to see, why it would be
really useful, and where the current mechanism is gumming things up for you?

-Rob


Ok. Examples: Battlefleet Gothic. Capital ships can be squadroned together, but don't have to be. While the smaller escorts have to be in squadrons of two or more. Many people don't squadron their capital ships at all, so it's a lot of extra overhead in the roster view and printout. Of course you can make an "escort squadron" as a unit choice where you can add individual ships, but that makes it where you can't see the stats in front of you unless you either keep them in the overall list or right click for a detail of somekind. Either way, it's a lot of coding.

Warmachine: Squads = Battlegroups. While in lower point games only one Warcaster (squad leader type) is used, in larger games you can have 2-4 total. Each has his own allotment of units that he can take. Using the battlegroup for this second function is great, but not so great for the first, because once again you're viewing a lot of overhead that isn't needed. I DID create a sample setup for that, where I used an option list to add child units to the warcaster. But in my case and other peoples, I sometimes like to but units and see what kind of points I have left for a leader. Makes it hard to tweak the points, especially since it's a game where there isn't a whole lot of room for customizing.

So the point I was making, is that all I have seen of squads so far, is that in the DEF file, they are either turned off, so that they just don't exist. Or they are turned on so that every unit created has its own squad by default. Ick. I qould LOVE the ability as I stated before, of just being able to create a blank squad/battlegroup and drag units into it for organization.

Ah, now I understand. You want to be able to have some squads and some non-squads on an ad hoc, mix-and-match basis. I wasn't clear on that until the examples, so thanks for them. :-)

This is something that we originally had intended to include in V3.0. The big problem is that the UI becomes confusing. Now the user can drag/drop some units in with some others, but not for some. The whole goal for a good UI is consistency and predictability, so that the user knows what to expect and everything works as expected (sometimes, the user needs to learn the rules first, but they ought to be consistent once understood). The mix-and-match approach provides neither consistency nor predictability. That's why we opted to omit it in V3.0.

So I'd be quite interested in hearing everyone's ideas on how this could be handled. Having an empty squad that the user puts things into is completely separate from the mix/match approach. That's a useful technique, but it would currently only be available when squads are turned on for the game system. The main issue is how to achieve mix/match in a clear, consistent, and predictably fashion for the user.

Thoughts?

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com)******************************** (408) 927-9880
Lone Wolf Development************************************* www.wolflair.com

[deathlynx]

One possibility would be for squads to be turned on but be invisible until you add a second unit to it either through drag and drop or option selection...possibly have the ability to have an option which "turns on" squads for the unit...It wouldn't actually turn on the squads, merely makes it visable...Does that make sense?

[Russell]

Regarding squads... For Warlord where some units must be organised into squads and others must not be organised into squads, I'd like to see a squad created when I add models to the roster which require a squad, and no squad created when I add a model that can't be in a squad... There shouldn't be any confusion for the user since they know a Solo model is .... solo. :-)

I would see this implemented as a flag on each unit, (restricted by the current ruleset/roster tags perhaps) which makes the unit available to be dropped into an existing squad or create a new squad when added to the roster. If the flag isn't set (or isn't valid) then you can't do those things...

Reading that again, I don't know if it actually adds anything to this thread, but hey... It's typed now.

[rob]

This just exacerbates the problem for the user. Please stop thinking about
what you want as an AUTHOR and think about all those users out there who
can barely manage to install and launch a piece of software, let alone
figure out how to use it. [Note: There are LOTS of them out there.]

The issue is NOT about making all this work in the engine. The issue is
with the UI. If a squad is turned on and off for a unit, isn't that a bit
non-obvious (read: confusing)? And if the squad is turned off, how do you
use drag/drop to add a unit to it? If there is no squad, there is nothing
to add into. And then if you remove the second unit and the squad turns
off, the user gets even more confused.

Remember what I said in my previous post on this topic. The goal for a good
UI is consistency and predictability. Changing things constantly on the
user is counter to BOTH of these basic tenets.

So an appropriate solution needs to be found that is both consistent and
predictable for the user.

-Rob

At 09:54 AM 6/5/2005 -0400, you wrote:

>One possibility would be for squads to be turned on but be invisible until
>you add a second unit to it either through drag and drop or option
>selection...possibly have the ability to have an option which "turns on"
>squads for the unit...It wouldn't actually turn on the squads, merely
>makes it visable...Does that make sense?


---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com

[rob]

At 08:27 PM 6/5/2005 -0400, you wrote:

>Regarding squads... For Warlord where some units must be organised into
>squads and others must not be organised into squads, I'd like to see a
>squad created when I add models to the roster which require a squad, and
>no squad created when I add a model that can't be in a squad... There
>shouldn't be any confusion for the user since they know a Solo model is
>.... solo.
>
>I would see this implemented as a flag on each unit, (restricted by the
>current ruleset/roster tags perhaps) which makes the unit available to be
>dropped into an existing squad or create a new squad when added to the
>roster. If the flag isn't set (or isn't valid) then you can't do those
>things...

This is an improvement, but it still falls short (IMHO). The issue is that
AB is intended for newbies to a game as well as veterans. Veterans would
absolutely know about the limitation on Solos. But newbies would not.
Granted, in Warlord, the name "Solo" is a big hint, but other games with a
similar structure but non-obvious names would remain confusing to users. "I
can do X with that unit, so why can't I do X with this other unit?"

More ideas???

-Rob

---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (408) 927-9880
Lone Wolf Development www.wolflair.com

[TheDaR]

Originally Posted by rob

At 03:10 AM 6/1/2005 -0400, you wrote:
>I'd like to see a more practical orientation to the documentation.

I'm writing all this up now. It's a VERY time-consuming process to think of
all the different situations, figure out a good way to present the topic,
and then actually write something that is clear. At this point, I've got a
list of about **100** topics that need to be covered, and many of them are
taking me an hour or two to write up clearly. :-(

Good to hear. It's a lot of work, but it'll save data file authors a lot of pain to be able to dive in straight away without asking dozens of questions or spending days tracing other data files just to figure out what the overall structure is like.

Originally Posted by rob

>Another thing I'd like to see is some "Best Practices" sections, which
>describe not the details necessarily of what to do, but why to do things
>certain ways, and when those ways won't work.

I've got some of these in my list. But I'd really love a list of topics
that YOU want to see addressed, since my list probably doesn't match your
list exactly. :-)

Off the top of my head:

• Naming conventions to make tracking options/entities easier
• When to use costs on options versus on entities
• Which scripts are best for calculating/testing various common things, when various ones can do the same thing (eval vs live, sizelimit vs postlink, etc)

Basically, some philisophical discussion of what the program's authors would do when confronted with various situations, knowing the program inside and out.

Originally Posted by rob

>On a functionality basis, the one thing I would most desire would be
>having ABCreator capable of following various links. I'd love to be able
>to start from the Unit list, click on an entry in the option list, follow
>it to the option section, where I can see there's a child item, and then
>click on that item and follow it back to the item screen.

Yikes! Nothing like asking for the moon. :-> This would require that ABC
load all the data files and maintain them at all times, bouncing between
data files as needed. While the loading and maintaining would just be a
hefty chunk of work, automatically bouncing between data files would be
miserable to handle. For example, what if you had dirty records in your
current file? And I assume you'd also want to "go back", just like you can
when browsing websites. Then there is the issue of performance. I think the
only way this would work well is if ABC used a single merged database
concept. But that undermines the ability of data files to be maintained by
a group of authors, each of whom operates only within his set of files.

If you're just looking to VIEW things in other files and NOT edit them,
then it might be feasible to do something like this, but it would be a
major can of worms. How about first identifying some "baby steps" for us to
tackle in this area? For example, would it still be useful to be able to
click on an entry in the option list and be able to VIEW that optoin? Or
click on a child entity reference within an option and VIEW the entity?
Those are initial steps that might be more manageable initially. And I'm
sure there are others that you've thought of. :-)

Well, you did ask for what we want.

Viewing (especially as a tool tip, something AB does very well overall) would be a very strong start.

I'd also be fine if following any unresolved links just popped up a dialog that said something like 'This link doesn't resolve in this file, would you like to (open another file) (create an option/entity in this file) (cancel)'. Those three options would pretty much solve 90% of the use cases I can think of; namely either wanting to switch to the link in the current datafile (most of the time), create a new option or entity as appropriate (most of the rest of the time), and on the very rare cases go to another file.

The other thing I've thought of is better error messages from the script compiler. 'Invalid use of reserved word in script' isn't a very helpful in terms of knowing what to fix. Even just adding the token which caused the error to that message would help a lot (Invalid use of reserved word "parent" in script) in narrowing down which context transition you messed up.

-DaR