August 25, 2026: Since the 1970s, the American military, and the Army in particular, have been developing generations of wargames, combat simulations, and theater-wide systems that enable commanders to experiment with different tactics, strategies, and doctrines.

In the 21st century, military wargaming uses more automation, usually called AI or Artificial Intelligence. Interfaces are easier to use, and computing power is much cheaper and more powerful. Running What If? simulations takes seconds, and users get a short, succinct summary of the wargame results.

Plenty of information explains how a wargame works and how to design one. A primary source is The Complete Wargames Handbook, available online. One chapter covers Designing Manual Games, which is often done before creating a computerized version. Like modern games, these manual games are also available to play on a PC or laptop. You can also play on your phone if you can get used to the much smaller viewing area.

How to Do It Yourself: Game design is a lot like writing a book, term paper, or other nonfiction. In many respects it's actually easier. But in some respects, it's definitely different. In this section, I will explain the differences.

The main difference is the structure of the work. A nonfiction writing assignment is basically an act of communication. The writer collects, reorganizes, and presents data in a form that the reader can easily use. I call this type of communication linear. That is, we start at the beginning and proceed word by word, sentence by sentence, paragraph by paragraph, page by page along the line laid down by the author. A game, on the other hand, is nonlinear. To be sure, it starts at a beginning, but from there on it is primarily an exercise in choices and options, with different paths that the reader or gamer may follow. Designing a game is working with a much more structured piece of work than is writing nonfiction. For one thing, a game is much more graphic than a literary work. A game is much more precise. Even on a "literary" level, it is mainly a set of instructions. But minor mistakes or ambiguous passages that might not seriously harm a nonfiction work can cause grave problems in a game.

There are many rules to designing games. Above all, two game design rules control all others. First, and most important, is:

Keep it Simple.

The second rule is nearly as important but a bit more complex to use. The second rule is:

Plagiarize.

Plagiarism is a dramatic way of saying, "use available techniques." If you try to plow too much new ground, you're not going to get very far, and you will have an extremely difficult time in keeping your game sufficiently simple to be manageable.

Keeping a game design project simple is very difficult. Once you get going, you'll be tempted to add this and add that. A game design is a very dynamic activity. It soon acquires a life of its own, asking questions and offering parts of the answer. The game designer is sorely tempted to go deeper and deeper. Without some years of experience and a high degree of professional discipline, it is extremely difficult to do a simple game that is not a truly incomprehensible one. For a game is, in addition to being a source of information, also a form of communication. If the information cannot be communicated, the game does not work. You've got to keep it simple.

Using available techniques gives you a wide range of proven procedures for designing a game that gives you the most bang for the buck. I assume you only have limited time for designing a game, and I presume you would prefer to spend less of your time banging your head against a wall and more time refining a functioning game.

There are no iron-clad guaranteed ("follow these rules and you cannot fail") guidelines for designing a game. I do have, however, 10 steps which are generally followed in designing games successfully. The number of steps has actually changed over the many years that I have been designing games. But in essence, these 10 steps, albeit rearranged and occasionally renamed, have remained remarkably consistent.

1. The first, and most important step, is concept development. At the start, you must decide what you want to do.

2. Next comes research. You will have done a little of this during the concept development stage. At this point, you must fill in as many of the gaps in your knowledge as you can.

3. This is what I have dubbed integration. This is where you take all of the research material and your knowledge of game mechanics and integrate it into a prototype game.

4. Now you flesh out this prototype, coming up, in effect, with something that looks remarkably close to the finished game. In some cases, if you're lucky or the phases of the moon happen to be just right, your prototype will be exactly like your finished game.

5. Prepare a first draft of your rules. Many people skip this step, preferring to keep the rules in their heads a little longer. They usually come to regret this.

6. This is one of the more difficult steps: game development. This means playtesting, changing the game, rewriting the rules, and taking a lot of abuse from people who would rather play than design and don't appreciate how hard it is to get anything done.

7. I call this step blind testing (computer game designers call it beta testing). This is where you take your physical prototype and written rules and send them to somebody who can play the game without you. This is often very revealing.

8. Editing. This step occurs when all of your blind-testing results have come back and have been integrated into the manuscript. Somebody else should now take over and edit the manuscript. This also means playing the game with all your final corrections and changes and generally trying to smoke out as many gremlins as possible.

9. Production. If you are going to publish the game, this is the production step. This is where many things can go wrong. Rules have to be typeset, and things can get scrambled about. You have to prepare the artwork from your prototype, and things can change again. There is much potential danger in this phase of game design.

10. Feedback. This step is also critical if you plan to design more games. This is the feedback step, where you must systematically collect player feedback to see what you did right and what you did wrong.

These steps are used to publish historical games. Most people apply their game design skills to modifying existing games or designing games that will most likely never be published. For these unpublished games (I deliberately refrain from calling them amateur because I am consistently impressed by the quality of unpublished games compared to many that are published), the designer's effort should focus on producing a game the designer can easily and effectively use. This means all 10 steps are used, although blind testing, editing, and production tend to be folded back into development and prototype construction. But it would not be that difficult for a gamer to conduct a blind test, have another player edit it, and then go through some simple production procedures, which would let the gamer give out copies of his game without the expense of actually publishing it. I will explain these techniques further on.

There is a lot more to the 10 game-designing steps than I have briefly explained. The tricks of the trade make these steps work. The tricks uncovered in the last thirty years could fill a few books. In order to get across to you a good number of these tricks in a format that you can use, I will describe the actual design and development of a game that was prepared expressly for this book. Although it's a rather small game, it includes the same elements as much larger games and requires the designer to follow the same steps, encounter the same problems, and solve them.