MATTHEW STIBBE outlines a few simple guidelines to the design of a wargame from initial scenario through to the finished article

THE ADVENT of computers has meant that wargames can now be enjoyed without recourse to rule books or dice. Games like Desert Rats and Annals of Rome have sold as well as arcade games, indicating a real interest in wargames. The spirit of the dedicated wargamer still lurks inside those games, however: as easy as they are to play, somewhere inside the computer there are as many sets of rules as any table top game. As a result, designing a computer wargame is not as straightforward as it seems, but with an eye for accuracy and an idea of what makes a game entertaining, almost anyone can design a reasonable strategy game. In this article I hope to show how a such a game emerges from a basic idea, to become a fully-fledged computer wargame.

The first stage is to decide which historical period is to be simulated. This does not mean that wargames must be set in some school-book past, though: they can just as easily be set in some imaginary future, such as the games that simulate a hypothetical war in Europe; although a wargame is [testing] the player against a simulated real life situation, that doesn’t necessarily mean it must have a definite anchor point in reality. However, as ‘What would have happened if Hitler had invaded England?’ is a good starting point, ‘What if Hitler had had 30,000,000 tanks?’ is not, mainly because the game would be unbalanced, and partly because it would not be a good test of the player’s abilities, since it has departed from an accepted reality level.

Among my favourite wargames are Eastern Front and Desert Rats, and although these are quite old now, they both provide a chance to replay history with the player in command. Perhaps the acid test of a wargame is whether the game unfolds exactly like the real historical situation if the player issues the same commands that were made at the time.

There are several ways of implementing a wargame, and the next task is to decide what scale to use. In my first game — based on the Vietnam war — the smallest units that are available to the player are battalions. These small units of about 800 men were the best compromise between reality and the limits of computer power, to work out their moves, and human memory, to remember where they all are! The war itself was a series of small scale actions, and to use larger units would have completely taken away any tactical control of the war, leaving only a strategic simulator. Even so, using battalions means that there will be about 200 units in play at any one time, and to get round the problems of human memory they can be given several orders at once to be executed sequentially.

In my latest game design of a tactical level set in modern Europe, I have opted for platoon-sized units (about 30 men, or 3 vehicles) as the smallest unit to which an order can be given. Eastern Front works at a divisional level, and Desert Rats at a more detailed brigade level.

A wargame is usually displayed on a a scrolling map, which shows the terrain over which a battle is being fought. Rainbird’s innovative UMS (Universal Military Simulator) uses a perspective map to display hills and terrain. This is excellent for small battles, but is a little limiting when trying to fit a continent on the screen; nevertheless I think it shows the way that wargames are going, I look forward to a sort of battle simulator in which the player will get a general’s eye view, instead of, or as well as a map display.

I always begin with a proposal, which is usually only a few sides. This has two purposes: firstly it helps me to think through what I would like to do with the game, and secondly it helps me sell the game by giving other people an idea of what the game is about. I then expand on the ideas that I have covered in the proposal in my design, which actually says how the things that I outlined in the game proposal work.

Along the way some things change, get added or dropped. For instance, my most recent game proposal for tactical combat suggested the use of tactical airpower. It was only when I had worked out that a turn should last only 15 minutes and therefore, a whole game no more than 3 hours (in game time), that I realised that it would take the length of an average game for the aeroplanes to arrive. This had the useful side effect that it allowed me to dispose of all the usual air defence equipment that modern armies have, so making the game less complex to play and program. On the other hand, with the Vietnam game, the use of tactical airpower evolved to the stage where the current design allows for airpower to be assigned to actual units, or specific missions (like bombing North Vietnam or the Ho Chi Minh trail), as opposed to simply being aerial artillery.

Once you have a general idea about what the game will look like, and what it will simulate, the next stage is to research the scenario. I usually get and read all the books on a subject that I can, and at the moment my shelves are filled with Vietnam books. General military reading is also useful, for instance Von Clauswitz’s On War is a fascinating study of military strategy. General books and magazines about military affairs are also useful reading, for instance Jane’s Defence Weekly. In addition, playing board and computer wargames gives a good idea of what can be done, and what can be improved upon.

Once I had an idea of how my Vietnam game should work, I began my research proper. I had three histories of the Vietnam war, from which I derived the strategic and political elements of the game, and a huge book called The Vietnam Order of Battle which cost a small fortune but which lists all the units that were present in the Vietnam war. Although this information is available in other sources it was invaluable to have all the information collated in one book. It is this sort of detailed information that is necessary when putting together a game.

Turning the available information into a working wargame requires the use of rules. These tell the computer what should happen in certain circumstances. For instance in my game, when the US raises its commitment to the war, the government’s popularity falls. The difficult thing is to work out by how much. I found that the best way of doing this is to make a mini simulation. In the case of the political elements of Vietnam I used a spreadsheet, with columns for each year of the war, and rows for each of the variables. When I had entered the figures, I could test out various strategies and see if they were realistic. From this testing I modified the rules until I felt that I had a realistic working model.

For the resolution of combat I wrote a simple ‘C’ program to test the effect of various units’ strengths in combat against each other. Another way is to make an actual board game out of the rules, and use it to playtest the game. This sort of experimentation is very important in making a good game; it is quite easy to do in BASIC, and even with only a few variables and formulae, quite complicated models can be developed, either for political simulation or for resolving combat.

Movement can be implemented in several ways, either using continuous movement, where a unit moves smoothly and continuously throughout the turn, or by using discrete steps, which correspond to grid squares on a map. The latter is closer to board wargames, and is in many ways easier to implement, because it is easier to calculate how fast a unit should move in terms of squares than in pixels. The former looks better, and is more realistic, but is harder to program.

In many games it is not how the unit moves but when. For instance, in a tactical wargame a unit might not receive its orders for several minutes, and with a scale of 15 minutes to a turn, this requires some mechanism for delaying the unit from carrying out its orders until it has ‘received’ them.

The most difficult area is that of artificial intelligence: it is very difficult to persuade a computer to think in terms of flanking and encirclement. Instead you need to give the computer a set of rules for moving that produce the same net effect. There are usually two levels in a computer’s play, the first being strategic; the second tactical. Crudely speaking, in the strategic phase the computer decides which units are going where, and in the tactical, how they are going to get there. This is done looking several turns in advance. With many units in play it is hard to consider each possible move in the light of possible countermoves, as is done with chess, so a mechanism needs to be built in to consider when to advance and when to cut losses by withdrawing. These decisions also affect the decisions the computer makes at a lower level: for instance, when on the assault a computer might attack enemy units, and move directly toward them. But when on the defensive, units will move away from and around enemy units wherever possible.

Another possibility is to pick a scenario where the player will always behave in certain ways and so preprogram a number of counter strategies into the computer. In Desert Rats the computer always plays very defensively with each unit moving in support of its neighbours. This successfully represents the British manoeuvres, but under computer control the Germans lack the vigour that nearly won them the Desert War. Yet another way is to respond to the player’s moves as they are made during a movement phase. This is a form of cheating, and allows the computer to respond to the player’s strategy rather than predict it. In a way, a human player is handicapped because the computer can always examine the exact state of his or her forces, but the player cannot examine the computer’s.

Once the game is written, it may still need some fine tuning. This is usually done by modifying the variables in a game, so that specific factors are altered in a realistic or sensible manner during play. Other areas which may need changing are the tables that work out who wins a battle, or the speeds at which different types of unit move over different types of terrain.

Often the biggest problem with wargames is deciding what to leave out. As an example, when Chris Crawford produced a version of Eastern Front for a larger Atari, he included a number of new options which he was unable to fit Into the smaller formats.

A simulation is, of necessity, a scaled-down version of reality. A simulation deals with general trends, not specific events; in my Vietnam game I have included a variable called ‘outrages’ to simulate all the different things that appalled the world: strategic bombing, defoliation, atrocities and the mining of Haiphong harbour. I would have liked to include a model of North Vietnamese diplomacy and a model of the American economy in the game, as these would have made it more realistic, in the end, however, I left them out, because I did not think that they would add anything to the gameplay while simply increasing its complexity.

If you think of a wargame as a game of rules like Monopoly, then all that is necessary is to make those rules as realistic as playability and the constraints of your hardware will allow.