Designing
Computer Games
Wargames on computer have had a mixed record. The
"media" (the computer) is substantially different than the paper and cardboard
used in manual games. What works on paper does not always work so well on the computer.
The computer has capabilities that are often not exploited in computerized wargames. Those
wargames that do tend to emphasize the computers strengths tend also to be situations like
vehicle simulations. This makes sense, as a computer can handily deal with the numerous
calculations needed to simulate aircraft, ship or AFV (Armored Fighting Vehicle, tanks and
the like) activity. Manual games have a lot of problems with vehicle simulation, so
computerized vehicle simulations have done very well while their manual counterparts
languish unplayed by gamers with increasingly less time for games.
Computerized versions of non-simulator military situations is still an evolving area.
Programmers have been designing computer wargames for over twenty years. Game designers
have not been working on computer wargames for nearly as long. This has always been a
major problem with a lot of computer wargames that were (and largely still are) designed
by programmers who are often new to game design. Game design and programming are two
different skills that do have some
conceptual overlap. A lot of manual wargamers are programmers. But few programmers
start out as game designers and few who began as game designers were programmers. This has
led to most computer wargames designed by people who are better programmers than game
designers. This has produced some awful computer wargames. While the cost to the player of
these wretched games has been high (more in terms of aggravation than money), the
experience has enabled those programmers with a talent for game design to rise above the
pack. Chris Crawford and Gary Grigsby are two of the most notable of this new generation
of designers. There are a dozen or so who are nearly as good as these two (I won't name
names, lest I inadvertently forget someone who deserves to be mentioned. You know who you
are, including the foreigners.) But there are still a lot of neophyte game designers who
may be great (or sometimes dreadful) programmers turning out painfully inadequate games.
Thus the first thing you must consider when creating a computer wargame is are you
going to do the designing and programming or only one of these chores. This is not a
trivial decision. A superb programmer many be a mediocre (or simply lackadaisical) game
designer and will produce, at best, a good looking game that has little useful play (or
historical) value. A good game designer who is an inadequate programmer won't get very
far. The third solution, to have a good game designer work with one or more good
programmers usually produces good results once the communications problems can be
overcome. This team approach is becoming increasingly common, particularly since current
computer wargames are so elaborate that many different specialists must be called in (for
programming, graphics, interface, sound and documentation) that adding a game designer to
the list is no burden and is usually a decided plus. The last solution, having a someone
that combines the talents of a programmer and game designer is rare because that
combination is extraordinary.
Before we get into the nuts and bolts of this, I ought to present my own credentials.
This will put what I say here in perspective.
I've designed five computer wargames. For three of them, I did the design, someone else
did the programming. The first one I programmed myself. It was an experiment, which was
just as well. It didn't turn out that badly, but it was far from publishable. It was
called "Rus" and was programmed in Microsoft BASIC (on a TRS80 Mod I) in 1981 so
that I could get an idea what programming computer wargames was all about. I had some
background in programming, having learned the rudiments of COBOL and RPG II in the 1970s,
in addition to the primitive language of HPs first series of programmable calculators.
COBOL and RPG II were dreadful languages and, although I had access to a minicomputer
running those two languages, I did little with my programming knowledge beyond reading
the program listings of the programmers that worked for me. I had done several business
applications in BASIC, a language I learned in 1978. The Rus game was about the Viking
invasion of Russia in the ninth and tenth centuries.
The Rus (as the Russians called the Vikings) advanced down Russian rivers, plundering
and settling as they went. So in my game you proceeded down one of the Russian rivers,
encountering (and dealing with) all sorts of situations as you went. It was a revealing
experience. I quickly learned that my game design ideas rapidly outstripped my programming
skills. I was comfortable in BASIC, and I knew what peeks and pokes could do within the
operating system. After finishing the game, I decided to leave programming to those with a
knack with it.
The second game I programmed was done on a dare. What brought that about was the
appearance of the 123 spreadsheet program in 1983. I had been using the earlier VisiCalc
spreadsheet to great effect since late 1980, but 123 was a supercharged VisiCalc with a
macro language. The macro language was, in essence, brain damaged BASIC. I did a lot with
macros, and still do. On a dare, I created a wargame on a spreadsheet. Actually, the first
spreadsheet wargame was done on the CP/M version of Microsofts MultiPlan spreadsheet. I
ended up doing versions of this wargame on SuperCalc, Symphony and Quattro. Someone else
got it going on the Excel spreadsheet program. I began giving it away in 1983 and that
"wargame" played a major role in getting the military to use spreadsheets for
combat modeling. This type of computer wargame is not slick enough to be a commercial
product, but it gets a lot of real wargaming work done.
My third computer wargame was more polished, and recognizable. In 1985 I was asked by
an old Army friend (Ray Macedonia, recently retired from running the Wargames Department
of the Army War College) to create a manual wargame on tactical armored warfare. He needed
it for the work he was doing with his new employer (AVCO, later part of Textron) on
anti-tank weapons. So I created the manual game in a few months. They liked it so much
that AVCO asked to have it turned into a computer wargame. They gave me a Symbolics
workstation, two programmers and a lot of money and three months later we had it up and
running. Neat game, full color graphics, AI and everything.
While I had never done a computer wargame like that before, I already knew how to spec
(writing out the specifications for the programmer) out a project for programmers, as I
had been doing that since the early 1970s and through the 1980s was usually supervising
one or more teams of programmers doing financial modeling programs. In 1989 I got involved
with the GEnie computer network and ended up agreeing to design a multi-player (over 300
players) game of the Hundred Years War. The programming was done on a mainframe computer
and all the players got together via their PC and a telephone call (through a modem).
That game went into alpha testing in 1991 and went online for paying customers in 1992.
In 1991 I was approached by 360 Pacific (publisher of many computer wargames, including
the best seller Harpoon) about doing a computer wargame on the naval war in the Pacific. I
agreed, and the spec was done by October, 1991 with programming to continue through 1992.
It is from the above perspective that I will describe how one should go about designing
a computer wargame. Some of the material presented here is from the lectures I have been
giving to military wargame designers for the past dozen years. That will just broaden your
knowledge of designing computer wargames a bit more.
Note that we are talking about designing, not programming, a computer wargame. Actually
writing the program code for a computer wargame is a whole different matter. The
programming techniques are not only very arcane (and largely understandable only by
programmers) but change substantially from year to year as computers and programming tools
become more powerful and, well, different. Designing computer wargames consists of
principles and techniques that are less subject to change.
Chapter 6 - Computer Wargames
The Spec
Table of Contents