Data File Author Feedback Request on AB3

[rob]

This thread is directed to data file authors ONLY. I've started a SEPARATE
thread that focuses on end-user features. Please post your comments on the
appropriate threads!!!

From a data file authoring standpoint, what areas do you find to be the
most confusing, frustrating, and/or limiting? I realize that the
documentation has been marginal thus far, and that situation is soon to
change. So this thread really boils down to two separate aspects.

The first aspect is what topics need to be given the most attention in the
documentation? What areas are most confusing and in greatest need of
detailed explanations?

The second aspect is functionality. What areas are the most problematic for
you? Where are things overly complex and/or too obtuse to get a good handle
on? And what things are true limitations?

NOTE! Please do NOT just say something "sucks", since that doesn't provide
us with anything useful. Tell us what isn't working and offer some
suggestions on how you think things could be done better.

Thanks, Rob

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

 

[TheDaR]

In no particular order:

I'd like to see a more practical orientation to the documentation. API references are fine, if you already fully understand the basics of operation and just want to know a particular attribute name or order of evaluation. However, if you're a first time data author, what you really want is a walk through of setting up a data file set, from start to finish. The template/minimal one is good, as far as it goes, but it's scattered all over the docs, and something with a bit more complicated features would be nice. An example of how to set up a semi-complicated exclusion/remainder, including all the various links and options, or how to do a unit like IG Sentinels from 40k, where child links are used to create sub-units which can have different options would go a long way to solidifying the concepts enough that you can then read the rest of the docs for the specifics.

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. A more detailed essay one what things should be units, what items, and what options without any child entity for example, and how to look at your game system and break it down appropriately. Like when it makes sense to create a "squad" unit versus using AB's squad mechanism.

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.

There's a lot of little functionality improvements you could make in the interfaces in general. For example, editing an exclusion list entry on a link requires that you double click, type a 1 or 0, and then click elsewhere to get it to take. That could easily be a checkbox for each one. Likewise, selecting tags can be somewhat laborious, having to select first the tag group out of a drop down, then doing another drop down to get the actual value. Making the link table on a unit so you can toggle the various fields like 'visible' and 'selected' without having to open the link detail page would be a nice speed up. None of these are killer, but all in all it adds up to a lot of pointing and clicking that you could probably get away without.

More as I think of them.

-DaR

 

[shaggai]

This is really my start with AB and XML. Don't have too much to ask for except I would like to have the AB3 program not "bomb" out entirely when opening a file that won't compile right. An automatic restart of AB3 would be nice. Either that, or something within the creator program that can open AB3. Really would help the "sledgehammer" approach I use

 

[Russell]

This is really my start with AB and XML. Don't have too much to ask for except I would like to have the AB3 program not "bomb" out entirely when opening a file that won't compile right. An automatic restart of AB3 would be nice. Either that, or something within the creator program that can open AB3. Really would help the "sledgehammer" approach I use

You can recompile data files within AB without risk of it bombing out using Ctrl-C (or "Tools-> Data File Debugging->Compile Data files" if you're particularly fond of menus).

(sorry for not adding any suggestions - I'll think of something later I promise :wink: )

 

[Warmonger]

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.

 

[Warmonger]

Heh. I'm likely going to create a bunch of little posts as I think of things.

Composition reports. Like calculated fields need to have the ability to be turned on and off with tags or rulesets etc. A perfect example was when I was working on the necron datafile for 40k. If I created a calculated field to print on the roster with the number of necron models and the phase out number, it would print for everyone....

 

[kuni_tetsu]

I like this concept, just grab a container first and then fill it with what you
want in the squad.

--- Warmonger <warmonger@pobox.com> 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.


---

Kuni Tetsu
Clan War rules guy
Moderator of ClanWar-l

"Rule #35: That which does not kill you has made a grave tactical error"
-- From: The Seven Habits of Highly Effective Pirates



__________________________________
Discover Yahoo!
Get on-the-go sports scores, stock quotes, news and more. Check it out!
http://discover.yahoo.com/mobile.html

 

[harkan]

1. Floating/fixed window for showing tags assigned to a unit, would make data file dev a lot easier if it can be tracked 'on the fly' without having to go through the menus

2. 'Locking' a stat - if using a random figure then some way of locking the stat etc so that after the initial generation it stays as it is instead of being recaluclated each time an option is added/removed

3. More customisation on the help file display and/or html options to allow more 'tweaking' of them

4. More keyboard shortcuts for the main keys such as new, delete, yes, no etc - this would speed things up and cut out a lot of 'mousing'.

5. Ability for a child item to remove an item/option of the parent - not sure if I have phrased this correctly tho' sorry

Two other annoyances have been addressed already about adding tags and setting exclusions

 

[harkan]

couple more ..

6. The ability to rename rosters so they are different from the race name, i.e. instead of having Chaos Space Marines when creating Thousand Sons army, selecting the ruleset ammends the roster name to Thousand Sons

*EDIT*
7. Abiity within a rule to ammend the display text dependant on rulesets, this should allow more flexibility without having to create the same rules with different message and summary or a very generic and unhelpful message and summary for the same situation in differing rulesets - maybe a small script option in the ABC to allow roster/unit based ammendments to the message/summary?

 

[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. :-(

>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.

>A more detailed essay one what things should be units, what items, and
>what options without any child entity for example, and how to look at your
>game system and break it down appropriately.

There is NO right answer to this stuff. For example, some of the methods
being used on the 40K files are the ways that I had envisioned things being
written. In some cases, I suggested some approaches to the authors and they
chose to go a different direction. What they have works quite well, so it's
NOT that they chose a "wrong" approach. The issue is that AB is extremely
versatile and there are numerous ways to approach a given situation. The
topics I'm covering definitely are intended to provide guidance in a lot of
these areas, but there are rarely clear "correct" ways of doing things. And
deciding what should be units/items/options has multiple "right" answers.
It's all a matter of style and preference.

>Like when it makes sense to create a "squad" unit versus using AB's squad
>mechanism.

I've written up this topic. It points out the comparative advantages and
disadvantages of the various approaches. But each author has to make the
call himself.

>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.

-Rob

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

 

[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]

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]

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.

>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.

>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