|Sponsored by ||Are you looking for Wargames at discount prices?|
Visit our wargame store and check out our prices and selection.
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
Table of Contents