wish list additions

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.



Tony


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8...SFAA/IMSolB/TM
---------------------------------------------------------------------~->

At 20:49 23/09/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.

I think it would be tremendously difficult to implement any change to this,
without breaking every single datafile in ever written in tremendously
damaging and irritating ways


--
Colen 'Skrillboy' McAlister, demandred@skrill.org
http://www.skrill.org/, http://www.incompetence-central.co.uk/
1 = 2, for large values of 1.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8...SFAA/IMSolB/TM
---------------------------------------------------------------------~->

--- In armybuilder@y..., Colen 'Skrillboy' McAlister <demandred@s...>
wrote:
> I think it would be tremendously difficult to implement any
> change to this, without breaking every single datafile in ever
> written in tremendously damaging and irritating ways


I realise this sort of suggestion is probably more appropriate
to be introduced in a major revision, like going from 2.x to a 3.x
version change when we are likely to see the older files invalidated
anyway.

It should not be difficult to provide a simple migration
tool (to automatically handle padding an extra character into
the older convention) so nothing gets damaged in irritating ways.
Annoying perhaps, but not overly irritating.



Tony


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7...SFAA/IMSolB/TM
---------------------------------------------------------------------~->

--- In armybuilder@y..., Colen 'Skrillboy' McAlister <demandred@s...>
wrote:
> I think it would be tremendously difficult to implement any
> change to this, without breaking every single datafile in ever
> written in tremendously damaging and irritating ways


I realise this sort of suggestion is probably more appropriate
to be introduced in a major revision, like going from 2.x to a 3.x
version change when we are likely to see the older files invalidated
anyway.

It should not be difficult to provide a simple migration
tool (to automatically handle padding an extra character into
the older convention) so nothing gets damaged in irritating ways.
Annoying perhaps, but not overly irritating.



Tony


------------------------ Yahoo! Groups Sponsor ---------------------~-->
FREE COLLEGE MONEY
CLICK HERE to search
600,000 scholarships!
http://us.click.yahoo.com/47cccB/4m7...SFAA/IMSolB/TM
---------------------------------------------------------------------~->

[rob]

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/4m7...SFAA/IMSolB/TM
---------------------------------------------------------------------~->

At 18:05 24/09/2001 +0000, you wrote:
>--- In armybuilder@y..., Colen 'Skrillboy' McAlister <demandred@s...>
>wrote:
> > I think it would be tremendously difficult to implement any
> > change to this, without breaking every single datafile in ever
> > written in tremendously damaging and irritating ways
>
>
>I realise this sort of suggestion is probably more appropriate
>to be introduced in a major revision, like going from 2.x to a 3.x
>version change when we are likely to see the older files invalidated
>anyway.
>
>It should not be difficult to provide a simple migration
>tool (to automatically handle padding an extra character into
>the older convention) so nothing gets damaged in irritating ways.
>Annoying perhaps, but not overly irritating.

I don't even think it would be acceptable to do it at that point. Even when
v1.x turned into v2.0, the old datafiles still worked. There might have
been the odd validation error every now and again, but they were still
functional. Doing this would wreck every single file that used the old
method, unless some sort of migration tool was included and did it
automatically (which is a fair point).

There's another issue with the unit IDs, though. The reason they're 8
characters long is because AB turns them into a 64-bit integer, which can
be compared and contrasted much faster than strings can. Increasing the
length of the unique ID beyond 8 would break this and, I assume, cause
tremendous slowdowns.

At least that's how it was explained to me some time ago



--
Colen 'Skrillboy' McAlister, demandred@skrill.org
http://www.skrill.org/, http://www.incompetence-central.co.uk/
1 = 2, for large values of 1.


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Get your FREE credit report with a FREE CreditCheck
Monitoring Service trial
http://us.click.yahoo.com/MDsVHB/bQ8...SFAA/IMSolB/TM
---------------------------------------------------------------------~->