Lone Wolf Development Forums  

Go Back   Lone Wolf Development Forums > Army Builder Forums > Army Builder

Notices

Reply
 
Thread Tools Display Modes
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old May 31st, 2005, 05:05 PM
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
rob is offline   #1 Reply With Quote
TheDaR
Junior Member
 
Join Date: May 2005
Posts: 10

Old May 31st, 2005, 11:10 PM
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
TheDaR is offline   #2 Reply With Quote
shaggai
Senior Member
Volunteer Data File Author
 
Join Date: May 2005
Location: Matawan, NJ, USA
Posts: 158

Old May 31st, 2005, 11:51 PM
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
shaggai is offline   #3 Reply With Quote
Russell
Senior Member
Volunteer Data File Author
 
Join Date: Mar 2005
Location: Australia
Posts: 254

Old June 1st, 2005, 04:35 AM
Quote:
Originally Posted by 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
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: )
Russell is offline   #4 Reply With Quote
Warmonger
Member
Volunteer Data File Author
 
Join Date: Apr 2005
Location: North Western Arizona
Posts: 97

Old June 1st, 2005, 07:23 AM
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 is offline   #5 Reply With Quote
Warmonger
Member
Volunteer Data File Author
 
Join Date: Apr 2005
Location: North Western Arizona
Posts: 97

Old June 1st, 2005, 07:31 AM
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....
Warmonger is offline   #6 Reply With Quote
kuni_tetsu
Junior Member
Volunteer Data File Author
 
Join Date: May 2005
Location: Nashua, NH
Posts: 16
Send a message via Yahoo to kuni_tetsu Send a message via Skype™ to kuni_tetsu

Old June 1st, 2005, 07:47 AM
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
kuni_tetsu is offline   #7 Reply With Quote
harkan
Senior Member
Volunteer Data File Author
 
Join Date: Mar 2005
Posts: 345

Old June 1st, 2005, 09:53 AM
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 is offline   #8 Reply With Quote
harkan
Senior Member
Volunteer Data File Author
 
Join Date: Mar 2005
Posts: 345

Old June 1st, 2005, 09:44 PM
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?
harkan is offline   #9 Reply With Quote
rob
Senior Member
Lone Wolf Staff
 
Join Date: May 2005
Posts: 8,232

Old June 4th, 2005, 01:26 PM
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 is offline   #10 Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 08:01 AM.


Powered by vBulletin® - Copyright ©2000 - 2024, vBulletin Solutions, Inc.
wolflair.com copyright ©1998-2016 Lone Wolf Development, Inc. View our Privacy Policy here.