ON GAME DESIGN ============== 1991 by Mike Markowitz Designing a historical simulation game is simple; all you have to do is read until your eyes hurt and then playtest until your hands ache. My particular period of interest is ancient history, so sources are a problem. For designers of modern period games, there is usually a wealth of excellent source data: orders of battle, unit histories and eyewitness accounts, accurate maps, etc. The good stuff may only exist on fuzzy microfilm, in a government library on the other side of the continent, but at least it exists. Alexander the Great's campaign diary, on the other hand, went up in smoke when the great library of Alexandria was torched, and nobody else had a copy. For almost any period of military history, except perhaps the American Civil War, it's a big advantage if the designer can read some German or French. I think we design a lot of games that reflect the nationalistic biases of British historians, simply because we can't read the primary sources from the other side of the hill. I have only some rusty high-school Latin, and not being able to read Greek has been a big handicap in my work. This all assumes you have access to a good university library with an efficient inter-library loan service. You also need access to a good military hobby shop for the sort of obscure wargaming publications that no library would ever acquire. The best sources are always primary sources -- written by the guy who was there. For the ancient period we have very few examples of the good stuff: Xenophon's Anabasis (c. 400 BC) and Caesar's Commentaries (c. 50 BC). Next best are the secondary sources written by guys who talked to the guys who were there -- for example Herodotus on the Persian Wars, or Polybius on the Punic Wars. Even worse are the books written by guys who only had access to other books. Worst of all are previous games on the same subject, although you must study them and analyze them critically. Even a bad game represents a tremendous amount of work and thought. For the ancient period, another kind of primary source is archaeology. In fact, military archaeology can answer important questions right down into modern history, as recent excavations at the Custer battlefield have shown. Unlike a writer, an artifact cannot lie. It can be mis-dated or mis-interpreted, but it's as close as we can ever get to primary truth. Unfortunately, outside the English-speaking world, and the Middle East, the archaeological literature is rarely accessible in English. A game designer has to read widely. He should know a lot about the history of technology. He should be thoroughly familiar with the geography and climate of the area. One of the greatest pitfalls for a designer is the tendency to put everything that turned up in the research into the game. After all, it was hard work to track down the names and locations of all those officers, it would be a waste not to have a leader counter for each one... I was so lucky to find the weather reports for the period of the campaign -- just one extra little rule on hailstorms and tornadoes won't hurt... It seems as though every design needs to pass through two phases: 1. Proliferation of Complexity 2. Ruthless Simplification Phase 2 should be a bargaining process between the designer and the developer, balancing the desire to create an accurate simulation against the need to deliver a playable game. One reason that complexity proliferates is the temptation to drive every game function with a random process. My first thought in the design of SPARTACUS, for example, was to make regional recovery from supply depletion depend on a die roll. With die roll modifications for the number of troops in each area this could have grown into quite a nasty little table. Fortunately, I realized this was all unnecessary -- every depleted region automatically recovers at the start of the Autumn harvest. One of the hardest things for a designer to learn is the importance of tearing things up and throwing them away. I have torn up and thrown away lots of charts and tables because they didn't give results that felt right historically. You have to be prepared to tear up and throw away whole counter sets, maps and sections of rules, right up until the point where you "freeze" the design to begin serious playtesting. One of the hardest things for a designer is to avoid feeling defensive when the waves of criticism start rolling in from the playtesters. Playtesters are usually much sharper than the average gamer, so if they are baffled by a rule, a procedure, or a result, the odds are pretty good that something needs fixing. Your aim is not to defend your design decisions, but to make the logic behind them transparently self-evident in every rule, chart and table. Support your playtesters by providing prompt and complete answers to their questions. Allow enough playtesting time to incorporate feedback in the final revision of the rules. I failed to do this in ALEXANDROS, my first published game, and as a result, some errors slipped though the cracks. Many of us are good writers, living in a world of poor writers, and we've picked up the habit of handing in first drafts, because they're "good enough." In game design, first drafts are never good enough. Fifth drafts are never good enough. Stamp the date on everything, so you don't lose track of the latest corrected version. A set of game rules is almost like a Constitution for a little artificial world. As soon as it hits the street, legions of sharp-eyed rules-lawyers are going to be searching for every loophole and ambiguity. There is no chance that you will ever notice all the loopholes in your own work. Only good playtesters can do that.