The History of a Wargame Design

Guadalcanal Campaign by SSI has in the few weeks that it has been out proven to be a most popular program. The author of the game tells us in this article the history of his design from conception to royalty checks.

In board wargames the classic “trade-off” was always detail and realism vs. playability. In computer wargames the trade-off has changed; detail and realism vs. programmability. GUADALCANAL CAMPAIGN (GC) includes as much detail and realism as programmability would allow. Detail conscious gamers can and will site numerous examples of how realism was sacrificed in some areas. I am sure, however, that most gamers will agree that GC is the most detailed (by sheer volume) computer wargame on the market.

The intimidating length of GC (294 turns) made playability the number one design priority. The program tells the players what to do and when to do it so that they can concern themselves with strategy instead of mechanics. The ease of play allows even non-fanatical players to finish the full game in one or two weeks without being burned out.

GC has some obvious faults or “trade-offs” which should be explained. The low resolution graphics were a first for SSI and were accepted with considerable reluctance. A hi-res screen requires 8K of program memory and, with the mountainous data files and programming involved, there simply wasn’t 8K to spare. To accommodate a hi-res screen, the larger programs would have had to have been broken into many smaller programs and tied together with a tedious chaining system. The increased chaining would have meant a considerable increase in player waiting time (one minute of chaining per turn equals five hours of chaining per campaign).

Another “trade-off” was the language used to program the game. In the words of one programmer/author, “No great paintings were done with crayons — no great programs are written in BASIC.” Alas, my keyboard is crayon stained; GC was written in BASIC. However, it was not the author’s objective to design a “great” computer program. It was the author’s objective to design a “great” wargame using a well-organized and functional computer program.

HISTORY OF THE GAME

The idea for GC came from a board wargame. A friend and myself had struggled through several weeks of SPI’s SOLOMONS CAMPAIGN. I hated the confusing rules and tedious bookkeeping but the concept of a campaign level game with interaction of land, air, ship and sub units was fascinating. It was clear that the computer could allow much greater detail in describing the ships and planes involved, while solving all of the rules and bookkeeping hassles.

In computer programming there is a large amount of work between the initial idea and the finished product. The psychological momentum required to just get started can be the greatest problem. For six months I kept GC in my head; occasionally tinkering with the lists of variables and subprograms which would be required for the game. Finally, in December of 1981. these vague ideas jelled into a firm plan of action. It was time to take the plunge.

Completing the first version of GC required a month of total immersion in the project. It took roughly a week to write the program out on paper, a week to exhaustively research the forces involved. a week to punch the programs and data into the computer and a week to make it all (sort of) work.

Much of the credit for researching the game must go to Mr. Allyn Nevitt. Allyn, a close friend, is quite an authority on the Japanese Navy. He allowed me free use of his personal reference library which contained the information needed to rate the game’s 293 ships. He also compiled a list (using Japanese language sources) of each Japanese destroyer that participated in the campaign and included their date of arrival.

In the early weeks of January I weeded out the last of the “bit bugs” in the program and started to have fun with my new toy. The newly completed program consisted of one BASIC program (109 sectors long) and one data file (52 sectors long). As the month progressed, I added mini-games for the battles: Eastern Solomons, Santa Cruz and Guadalcanal. The additional programming required to control the mini-games also produced the games first OUT OF MEMORY error. Condensing the program solved the immediate problem but the memory limit brought further development of the game to a screeching halt.

Briefly, I turned my back on GC itself but not on the GC game system. In about two weeks of research and reprogramming I was able to adapt the Guadalcanal System to the Mediterranean theater of operations in a game I called MALTA CONVOY. At last my enthusiasm for programming was exhausted: after two months of living and breathing naval history I was ready to return to the real world.

FINDING A PUBLISHER

I bought my first computer in May 1979 with the specific intention of designing wargames. Since that time I have designed several computer wargames and as my programming confidence grew, so did the desire to share my games with the world (or even cash-in on them). Unfortunately, I had no idea who would be interested in buying or marketing such a product. I knew that SSI and Avalon Hill were doing similar work: but they were faceless corporations in faraway lands.

In February of 1982 SSI got a lot closer.

On the 9th, I took time off work for a dental appointment. Upon arriving at his office, I was relieved to learn that the dentist was out sick for the day. I spent the remaining hours of my sick leave browsing the local computer merchant where I splurged my dental money on SSI’s TORPEDO FIRE game. (Spending $60.00 for a game hurt almost as much as my root canal). That night I enjoyed several rousing submarine battles but was totally frustrated by an apparent malfunction in the save-game routine. When one pays $60.00 for a game, one expects near perfection. The next day I called SSI to complain of my misfortune. Joel Billings, calmly and patiently explained what I was probably doing wrong. When that problem was solved I changed the subject and asked: “…by the way, I design computer games, would you be interested…”

In the brief conversation that followed I learned that SSI obtained over 75% of their games from independent designers and that they would be glad to look at any of the games I cared to submit (business had been slow despite my $60.00 infusion). In the course of the conversation Joel mentioned: “We’re using a customized disk operating system (RDOS) that uses 4K less memory (Great!) and chains three times faster” (Chains?)

At the time. I really didn’t know what chaining was, but I could tell from the way Joel talked about it that it must be important. I found the answer on page 171 of the Apple DOS Manual “To run a series of Applesoft programs without erasing earlier values of variables and arrays use the following procedure…”. Chaining allowed me to break out of the 48K straight jacket that had cramped the development of my computer games. I could now write 100K or even 200K games. For two weeks I exchanged legal documents with SSI. At the same time I sent SSI a list describing four of my wargames. Having a strong feeling that GC would attract the greatest interest, I wasted no time in polishing the game for its first “showing”. By the time Joel called to give GC the green light. I was certain that GC was a finished product — Silly me!

FURTHER DEVELOPMENT

Joel’s first response after receiving the game was that it had lots of potential. I could tell from our discussion that he was enthusiastic about GC, but a couple of his suggested changes were real bomb shells. First, he said that I would probably have to switch over to hi-res graphics. Second, all SSI games must have “solitaire capability”.

From the start I had a bias against hi-res graphics. Functional lo-res graphics fit neatly into my program and were fairly easy for players to read and understand. Hi-res graphics would require breaking the large programs into many little programs with significantly increased chaining. I realized that if properly done, the hi-res map would look much nicer. However, as the graphics played a relatively small role in the game, I really hated to butcher the program. Luckily, after much analysis, SSI came to share my conclusion.

My only previous experience at programming artificial intelligence into a wargame was for a modern tactical submarine game. For this the logic was simple: point the sub at the target and fire the torpedo. With homing torpedoes, I didn’t even have to worry much about geometry (angles of intercept). For solitaire GC, the computer would have to: (1) decide how and when to form Task Forces (which ships to use & what mission to assign); (2) how and where to move each TF to best accomplish its mission; (3) which planes should be used for CAP or Search and which should be held back for air-strikes; (4) assign target priority to sighted enemy TFs and; (5) know when to launch non-suicidal land attacks.

The artificial intelligence for GC was easily the most fascinating challenge of my programming career.

Returning to my “total immersion” style of programming, I spent four sleepless nights and one lost weekend feverishly molding my new creation. In less than a week, GC was transformed from a fancy bookkeeping program into a living creature. Upon completing the artificial intelligence program GUADABRAIN, I no longer had any doubt that GC could be successfully marketed.

Writing the rules to GC was two weeks of sheer drudgery and the undisputed low point of the whole project. It is much easier to tell a computer how to do something than it is to tell a human how you told a computer how to do something. Describing the human requirements for playing the game would have needed only two pages. Describing what the computer was doing when the human player was just watching required an extra 18 pages.

With the completion of the rules, the game was shipped out to the independent playtesters. A few weeks later I started receiving the first playtester comments in the mail. These letters would inevitably start out:

“I think your game is great. but…”, and proceed to list four or five pages of suggested changes. Since I had been convinced the game was perfect the volume of criticism put a strain on my ego (especially since most of them were valid). In all, about 60% of the suggestions resulted in some change in program. Another 20% were valid criticisms that could not be answered due to programmability problems. The playtesters were, as a whole, extremely knowledgeable and their suggestions contributed much towards polishing the game for which I thank them.

The last major change came when Joel suggested that I add a “short” campaign scenario to the game (Oct. 1-Dec. 31. 1942). This would not have required any major effort, were it not for the fact that the disk was already full. The solution was a major reorganization of the data files which would allow Campaign I, Eastern Solomons. Santa Cruz and Guadalcanal to all share the same data. These changes came after the major playtest effort and, as a result, one minor bug survived after the game went on sale (CA-Quincy was sunk in the battle of Savo Island on 9 August 1942. however her ghost can be seen prowling the harbor at Espiritu Santo in the Santa Cruz scenario).

After several other frantic last minute changes. GC was finally declared to be completed just in time for its debut at Origins 82 (held in Baltimore last July). GUADALCANAL CAMPAIGN had been the center of my life for over eight months: and I was now ready for some R&R (Royalties and Reviews).