This essay will not be a chronological history of the Patton Strikes Back project. Instead, it will be an anecdotal history, flitting from point to point in the history of the project to make its points.
Lesson 1: Start with a clear mission statement
This was one of the best things I did with this project. From the very outset, I knew exactly what I wanted to accomplish with the design. Too many designers, I suspect, start off with fuzzy goals. The worst manifestation of this is the inane goal, "We’re gonna make this the greatest game of its type ever made!" That’s not a goal, that’s a fantasy. Sure, it’s good to have fantasies, but their pragmatic value is almost nil.
A clear mission statement is useful because it has direct pragmatic value during the course of a project. The essence of game design is decision-making; a designer makes thousands of decisions during the course of a project. These are never easy or simple decisions. You are not presented with choices between the beautiful, glorious, wonderful way to do the job and the ugly, scuzzy, nasty way to do it. Your choice is always between options with different merits. Option A has better graphics; Option B has better sound. Option A has better gameplay, while B offers a better user interface. "A" takes more RAM, but "B" guzzles more cycles. "A" will be harder to program, but "B" will require more expensive artwork. How then do you choose between the two options?
The nitwits among us will immediately pipe up with a seemingly simple answer: "I’ll just evaluate the merits of the two options, and I’ll pick the better option." Right -- and maybe you’ll get your game finished in time to take advantage of the new 80886 features. You don’t have time to carefully weigh all the factors. You need to make a decision NOW!
This is one advantage of the clear mission statement: it simplifies the decision-making process. Instead of asking, "Which option is better?" you need instead ask only, "Which option better fits my mission statement?" This latter question is more precise, more specific, and therefore easier to answer. More important, it is faster to answer. The bulk of a game designer’s important work is making decisions about what to include and what to pass up; anything that makes this difficult process faster and more reliable is worthwhile.
With Patton Strikes Back, I established a clear mission statement in the very first week of work: this was to be "a wargame for the rest of us." I believe that there are too many complex wargames, games designed for the hobbyists and wargame fanatics. I wanted to make a game that would show regular people just how interesting a wargame could be. This meant that I would have to risk the ire of the aficionados and design a game that would emphasize ease of use and accessibility over complexity, a game in which it is more important to be up and playing in ten minutes than to be still playing after 100 hours. The precise mission statement made the entire design process move more quickly.
Lesson #2: From Miss Goody Two-Shoes to Hairy Hacker
Programmers are always conflicted over the problem of hacking. We all know that we really shouldn’t hack our code, that it should be clean, well-designed code with good structure. But structure takes planning and time, and ofttimes we don’t know enough about our destination to plan our route that carefully, or we’re in too much of a rush to plan, so we hack. Yet we also know that hacked code is so brittle that, over the long run, it takes more time to debug and maintain than properly structured code. Hence the continuing dilemma: should we be Goodie Two-Shoes programmers or hackers?
This is one of those religious issues for which one man’s opinion is just as good as another’s, but I finally came up with an approach that seems clear to me. The value of Goody Two-Shoes code lies in the ease with which it can be modified and corrected after it has been written. Game projects tend to be fire-and-forget; once it’s out the door, we no longer have the option of modification or correction. This implies that our need for Goody Two-Shoes code diminishes late in the project, when we are pressed for time anyway. On the other hand, the early stages of a game project have us writing code that we know will change considerably later on. This suggests that we start the project writing Goody Two-Shoes code and gradually shift our emphasis to hacking as the deadline closes in on us.
However, there is another time scale to consider: the short-term time scale in which we write up a single feature. Most game programming is in some way experimental; any feature that is fully understood is probably obsolete in our fast-moving industry. Thus, we spend a lot of time inventing wheels. You can’t plan such code in advance; you just have to wade in and hack until you figure it out. The conclusion I came to is this: hack first, then recode it right.
So we get opposite recommendations for different time scales. For the long time scale, structure, then hack; for the short time scale, hack, then structure. If you think of this as a religious issue, I think you’ll find my solution very Eastern.
Lesson #3: Don’t be seduced by the cleverness of your own ideas.
This was the single biggest mistake I made with Patton Strikes Back. I came up with a truly clever idea: a large-scale scrolling tactical map in which unit sizes would be indicative of unit strengths. Now, this is indeed a damn good idea, and I was justifiably proud of it. But it caused too many problems. The IBM PC translation just couldn’t be done. The tactical map turned out to be clumsy to use. Most players eschewed it. I should have had the courage to dump a clever idea that, in the final analysis, created more problems than it solved. I didn’t, and the game suffered for it.
Lesson #4: Bake the cake first, then add the icing
Publishers sell games in the same way that bakers sell cake. The customer doesn’t taste the cake until he gets it home; all he sees in the store is the icing. So bakers don’t sell cake; they sell icing. In the same way, most publishers don’t give a damn about gameplay (cake); all they care about are the graphics and sound (icing). So when you show off your game to a prospective publisher, he won’t ask about the gameplay, he’ll want to know about the icing. Eager to make the sale, you’ll get sucked into a lengthy discussion of the finer points of icing, and end up making lots of promises to go home and improve the icing before the publisher makes a commitment to the product.
Of course, once you’ve got the contract, things don’t change; the publisher will continue to decry the many cosmetic deficiencies in the product, so you’ll spend all your time beefing up the icing, adding more curlicues and multicolor roses and three-color borders. You tell yourself that you’ll get to the gameplay sometime soon, but the demands from the publisher never stop, and you never get time to bake the cake. You’ll end up with a beautiful mound of icing with no cake inside -- which is in fact the way most games ship.
With Patton Strikes Back, I baked the cake before I even showed it to any publisher. I designed and developed the game first. I finished all the basic game structures, wrote and tuned the artificial intelligence, even got much of the play balance worked out. Only then did I show it to publishers. Guess what they wanted? More icing! At that point, it was easy. Having finished the cake, it was easy to pile the icing on. I added Multimedia Newsreels with Actual Combat Footage and Realistic Digitized Combat Sounds wowie-zowie! I added personal anecdotes with Actual Digitized Photographs. It was easy. It was mindless. And it made the publisher so happy.
It’s a lot easier to bake the cake and then add the icing than the other way around. Ever tried to slip a cake under a pile of icing?
Lesson #5: There ain’t no rest of us
The game was released to the world in December of 1991. It received excellent reviews. Indeed, I have yet to encounter a single negative or even lukewarm review. Unfortunately, it has not sold well. I have broken even on my out-of-pocket costs, not much more. It would seem that "the rest of us" aren’t buying computer wargames. The aficionados certainly hated it. "Too easy to beat," they sniffed. "Only good for a few dozen hours of play." Without the support of the aficionados, the game withered. It’s still on the shelves, largely because of continuing favorable reviews and a steep price reduction. But I will never make a significant income from the game. Lesson #5 is, I think, the most important lesson to learn from Patton Strikes Back.