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