Home Forums General Game Design Computerised Rules? Reply To: Computerised Rules?

#13200
Avatar photoJohn D Salt
Participant

Patient readers may perhaps already be familiar with my views on this subject, forcibly expressed on a number of occasions. Game assistance programs, or computer-assisted rules, are chimerical monsters, neither one thing nor the other. Either the representation of the world should be on the tabletop, or on the mapboard, or in the computer. Splitting it across more than one of these creates a whole bunch of unecessary translation tasks, explaining the state of the tabletop/mapboard world to the computer world, or the other way about. These are clearical tasks, not tactical decision-making tasks, and when I play with toy soldiers, I want to be a tactician, or in a big game a strategist, not a bloody clerk. If you have written rules that require operations so complex that they ca only conveniently be performaed with a computer, I strongly suspect that you have designed a wretchedly bad game, and, what’s more, all that “detail” you are so proud of is not based on any factual basis, but created using the POOMA method (“pulled out of mid air” is the polite gloss).

There may, marginally, be some benefit in using a computerised opponent to hide information and make tactical decisions for a solitaire game; I have never seen such a thing attempted, I suspect because no wargamer’s programming skills are equal to dealing with the AI problems entailed. All the GAPs I have seen in real life — which have been few — were wretched failures.

The real place the computer can help in rules-writing, IMHO, is for processing data for combat results tables. For example, my “Churchill Troop Commander” used attack values based on a hit probability algorithm and penetration formula that, while simple enough to be performed with a pocket calculator, would be tedious to do repeatedly. This is what computers were meant for — to relieve their human masters from clerical drudgery, not to create more of it.

All the best,

John.