At present, game systems like DBM have about 400 army lists. So a
formalized mechanism for defining race prefixes was established by the
authors of the DBM files. The race prefixes don't have any meaningful
relationship to the actual army lists, which is a minor nuisance. I
recommend you do the same for WAB.
The key reason that the race prefix is limited to 2 characters is that
there is an 8 character limitation on unique ids. Within a given race, that
leaves 6 characters to uniquely identify each unit. And it is MUCH more
critical to identify a unit clearly by its id than to identify the race.
Six characters is pushing it for the unit, so the race is limited to 2.
So now for the obvious question. Why only 8 characters? The answer is
performance. The reason AB uses 8 character unique ids is that 8 characters
can be quickly converted to a 64-bit integer. All of the 8 character ids
get converted to 64-bit integers and then AB uses INTEGERS throughout for
high speed lookups and access. This is VASTLY faster than using strings.
The moment AB goes past 8 characters, AB has to go back to strings - and
take the correspoding performance hit.
For you technoids out there, this last statement was true when I first
wrote AB, although it's no longer quite accurate. I have since figured out
a way to go to 10 character unique ids that can still be converted to
64-bit integers, but I hadn't done this yet when I first wrote AB. Also, I
need a mechanism that is two-way, so I have to be able to quickly convert
the 64-bit integer back to the string on demand. This last clarification
was for all of you algorithm experts who will tell me that I can squeeze a
lot of information down into 64-bits if it doesn't need to be reversible,
without collisions, or quick. However, if there are algorithm experts who
can offer a solution that achieves these three goals, I would very much
like to hear about it!!!
Yes, I could switch to something else for a V3.0 release (e.g. the
10-character limit). However, it's not likely to happen. As you pointed out
in your other post on this topic, the current limitation is a nuisance - it
doesn't preclude files from being written. The amount of effort required to
revise the mechanism within AB, write an automatic converter to the new
mechanism for existing data files, and then test it all, would be
significant. To do it just to eliminate a very minor nuisance for the data
file writer doesn't make any sense at all. That same amount of time could
be spent implementing additional features that end-users would find
compelling, which would have a direct impact to the bottom line (remember,
Army Builder is a full-time job and paying my mortgage).
Please don't take this as negativity on my part. I'm just trying to be
honest and put all my cards on the table. While the purist developer in me
would love to make this change to improve the product, I also have to put
the business hat on regularly. It's a nasty juggle, and I don't want to
raise false hopes for anyone. I hope you understand.
Thanks, Rob
At 08:49 PM 9/23/2001 +0000, you wrote:
>Is a 2 letter pneumonic for the race (in data files)
>enough? Granted it seems to work fine in WFB. But
>I am asking because WAB already has 40 distinct armies
>and the next few supplements will easily triple that
>number. Only having two digits per "race" is already
>losing the pneumonic value of the race prefix. I imagine
>some other games (historicals would be my first guess but
>fantasy or sci-fi might too) already have this problem
>or are not too far away from it.
---------------------------------------------------------------------------
Rob Bowes (rob@wolflair.com) (650) 726-9689
Lone Wolf Development
www.wolflair.com
------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7CAA/ySSFAA/IMSolB/TM
---------------------------------------------------------------------~->
