Wargames at War

Creating Wargames for the Troops

The military doesn't design wargames the same way commercial wargames are put together. There are a host of special situations and problems they must contend with. Since the late 1970s I have been called upon to give lectures, lasting from half an hour to several days, on how I feel it should be done. These lectures are quite popular and I get invited back to some venues year after year. More importantly, I constantly run into military wargamers who have been successfully using the guidelines presented in these lectures. What follows is the advice I have been giving to military wargames designers over the last fifteen years. This material has always been given in the form of a lecture, so it's about time to get it all into print. There are ideas here that even the designer (or player) of commercial wargame will find useful. There's no better way to understand the differences between military and commercial wargames than to compare what follows with the later chapter on designing commercial wargames. There are some interesting differences.

Some of the lectures last half an hour, some go on for several days. What follows is a recapitulation of all the items I try to cover. When I have more time, I go into more detail. Otherwise, I present a checklist format.

The Golden Rules

All situations can be easily modeled using a half dozen design rules and past experience with similar situations. The rules are:

1. Know what the user wants. It's difficult enough knowing what you want to do when you are doing a model for yourself. It's easy to start building a model with a vague idea of what you want. It's impossible to complete an adequate model unless you have developed a precise idea of what you want it to do. If the user is someone else, you have to help them figure out what they want it to do. This is not easy, and is often avoided because of the difficulty. Don't avoid it, be difficult if you have to. In the long run, this is the easy way out. To define the needs of the project, apply this checklist. It will get you started in defining the model users needs. If you can't define your project adequately, you'll waste a lot of time and effort. You probably won't complete your project either. The last thing you want to hear from the user is, "that's what I asked for, but it's not what I want."

1. Determine the Process to be modeled. Many different aspects of your model must be defined before you can proceed. Scale (Strategic, Operational, Tactical), Environment (Land, Air, Naval, Combined), Intensity (Low, Medium, High), Basic Aspects (Movement, Combat, Order of Battle), Special Aspects (C3I, Logistics, Doctrine & Tactics, Fog of War--Is the situation highly dependent on one, or both, sides being in the dark about what is going on? If so, you will have to model this aspect of the situation.)
2. What do you want it to do? There are several different tasks you can direct your modeling towards. These can include training, research, analysis, etc. For example:

Test a hypothesis. This can be historical, contemporary or future). It can be about weapons, tactics, organization or whatever. Be rigorous in defining your hypothesis. A model will eat you alive if you are sloppy.

Define a process. You may want to break down an existing system into its essential parts. A model building exercise is excellent for this.

Provide training. There is no better way, other than actually going into the field with the system.

2. Start with an existing model. For example, to create a wargame for contemporary ground combat operations, you can wander off to your local game or software store and see what the commercial designers are up to. There are also companies that deal in out of print games that may be of use. If there are any gamers in your area, buy them a beer and pump them shamelessly for leads. There's also a lot of previous work in the non-commercial sector waiting to be plundered. No sense reinventing the wheel, especially since that approach is sure to lead to exceeding your budget and missing deadlines. Don't endanger your career. Plagiarize. There's no copyright on ideas and most of the ones you need have already been thought of and thought out by more experienced designers. I know, I often steal from myself (as well as others, that's why I'm an expert).
3. Be sure you know what you know. Pick a subject you have a keen interest in, or have gained a perceptive knowledge of. This will eliminate a lot of time consuming research. You wouldn't be doing this if you weren't an expert in something.
4. Compile information. Once you have agreed upon what you want to do, you must gather information. Here is a sample checklist.

1. Area of Operations- Where, in time and geography, is the conflict to take place.
2. Scale- What is to be represented on the map, a few square miles or a continent.
3. Significant Terrain. For the Terrain Effects Chart, this is a winnowing process, in which you reduce all the terrain information you have gathered into a usable format.
4. Order of Battle. Units involved, their movement capability, combat capability and other characteristics.
5. Victory Conditions. This is a critical element, and often slighted or overlooked. What were the goals of the combatants?
6. Combat Results. Attrition rates in combat, with adjustments for other factors as needed and likely distribution of results for use with non-deterministic (unpredictability of combat) procedures.
7. Sequence of Play. Sequence that appears to work best in most situations is: 1-Planning and preparation operations, 2-Movement, 3-Combat, 4-Post operations checks (victory, morale, command control, etc).

5. Integration. The Big Moment, you create the prototype. This is where you assemble the first working version of the game. The Prototype is usually Quick and Dirty. Just get it working, quickly. Once that is done, Check the Switches. Whether the game is manual or computerized, you should have probability tables that can be easily changed to adjust the games outcomes in a controllable fashion. Finally, a note on "Pre-Dawn Madness & The Bleeding Edge of Technology." There is a bit of magic involved at this point. The model must be exercised, errors noted and the model modified and exercised again. Strange things will happen and you will often find yourself spending more hours working on this phase than you realize. This is the Pre-Dawn Madness most programmers are familiar with. Don't expect to understand everything that's going on in the prototype. If it works, leave it be and go on to the next item. Don't be any more inventive than you have to be. Beware the Bleeding Edge of Technology: stay with the simple and don't get cute.
6. Testing and User Acceptance. First there is Alpha Testing, where first you and then some typical users must be able to reproduce Historical Event, or defined hypothetical event. Then comes Blind (or Beta) Testing, where the game is handed to typical users without you hovering over them ("blind" to you). Lastly, there is testing ongoing after installation. No model is ever truly finished.

  Wargames and the 1991 Iraq War

  Differences Between Hobbyists and Professionals

  Table of Contents

  Chapter 9 Contents