Guest
Posts: n/a
|
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 ---------------------------------------------------------------------~-> |
#1 |
Guest
Posts: n/a
|
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 ---------------------------------------------------------------------~-> |
#2 |
Guest
Posts: n/a
|
--- 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 ---------------------------------------------------------------------~-> |
#3 |
Guest
Posts: n/a
|
--- 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 ---------------------------------------------------------------------~-> |
#4 |
Senior Member
Lone Wolf Staff
Join Date: May 2005
Posts: 8,232
|
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 ---------------------------------------------------------------------~-> |
#5 |
Guest
Posts: n/a
|
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 ---------------------------------------------------------------------~-> |
#6 |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Additions to the In Play tab | Harbinger | HL - d20 System | 7 | February 20th, 2007 04:02 PM |
needed additions/corrections | SeaOtter | HL - d20 System | 2 | January 12th, 2007 05:15 PM |
additions explanations | emperor799 at earthlink.n | Card Vault | 4 | March 4th, 2003 06:45 PM |
Mage Knight Additions/Fixes version 3 | emperor799 at earthlink.n | Card Vault | 1 | March 4th, 2003 04:12 PM |