Each year I attend a session of Kings College London's conflict simulation course as a guest to provide advice on how to design, develop and build a working conflict simulation.
The King's College London Conflict Simulation course, tasks participants with accurately modelling a historic conflict using a manual system (ie design a board game). The game must:
be playable within two hours;
have less than 100 counters; and
have a board no bigger than A3 (11.7 x 16.5 in)
All of which is relatively challenging for a particupants who have limited to no game design experience.
Conflict simulation design is a little different from pure game design; not only has the design to work as a mechanical construct, but it also has to accurately portray the conflict being modelled. This creates a whole new set of challenges that you just don’t have to worry about if you are creating a party game.
When we design games, we don't strive for a 100% accurate portrayal of the theme of the game, instead we aim to paint a faithful impression of what is going on. We endeavour to create systems in which players should still be able to gain an understanding of the dynamics, incentives and dilemmas relevant to the scenario being modelled.
So what are my top five tips for designing a good conflict simulation?
Understand the conflict being modelled. This can be quite a struggle as it involves a lot of research, but to make a good simulation you need to really understand your campaign or battle on a fundamental level. There is a crucial difference between knowing your conflict and really understanding it - a good simulation designer needs to achieve the latter.
There are no sacred cows. When designing a game or a system, there will be mechanics or concepts that, for whatever reason, you really love and are desperate to include. However all too often they just don't work within the overall mechanics of the game. Snipers are a good example of this; designers often seem to include rules for snipers in scenarios where they just aren't a critical factor or appropriate to the simulation/game. For example, when I designed 'Afghanistan 1980', I was fairly ruthless with the rules, however I failed to cull a mechanic around Soviet intelligence operations. Had I done so, I would have freed up additional counters from my allowance of 100, cut down the rules and ended up with a more streamlined system.
Playtest lots. You really need to playtest your game a lot, and do it with a range of people from a range of backgrounds. You don't need to do a full run through every time you playtest and you may decide that, for certain elements, you can test small parts of the game in isolation. Similarly some things you may be able to 'test' using a spreadsheet or other tool. In both Intervention and Manifesto, we did quite a lot of work using spreadsheets to test game balance - for example when designing the Intervention's rules for crossing a minefield we created a small spreadsheet to calculate the likely outcomes, given different input variables, and then experimented. While this limited or selective testing is encouraged to save time, you will still need to test the whole thing multiple times over. When testing it is also essential to experiment at the extremes. For instance, what happens if I mass all my forces in this one location? What happens if I pursue this resource goal exclusively? On average, how many of the worst troops does it take to knock out the best? A lot of early versions of games work well when players all play in a certain expected way - if someone does something odd then the whole thing can fall apart.
Edit Positively. When you go from the alpha version of the rules to the beta version of the rules, or do a really significant update, start a new document. Rewrite and/or copy/paste in the rules you want to keep, section by section. This 'positive editing' minimises the chance for unwanted artifacts from previous versions to sneak into the more mature version of the rules.
Finally: Have fun. While, according to the King's College design brief, it is not essential for your game/simulation to be 'fun', it helps if it is. Game design is an extended process, requiring hours of work, you will enjoy the design process and the playtesting much more if your game is fun and you are interested in the subject matter.