First Draft Design
| In May of 1982, I started thinking about the possibility of making a new version of Legionnaire, but I moved forward very slowly because it was a home project. As an Atari employee, I dedicated most of my time and creative energy to my project for Atari Research, the Excalibur design. However, in odd moments on evenings and weekends, I would occasionally turn my thoughts to the Legionnaire problem. My earliest design document dates from June of 1982. Here is a neat version of that document; I have added line numbers to make subsequent discussion clearer:
I offer this document as a textbook version of a concept document for a game design. In 15 lines, it lays out all the basic concepts of the design. It specifies all three critical components of any interactive design: input, processing, and output. Moreover, it specifies those components in terms of the primary design constraints:
Note also the parameters that are not specified. The size of the map is one such parameter; it's not central to the design of the game, and it will ultimately be determined by the unit count, which is specified. I take a completely functional approach to the graphics, specifying them only in terms of what information they convey and how. I do not specify anything about the prettiness of the graphics; that's not a central problem in the design. Once I know how the graphics will function, I can approach the problem of making them pretty. Still, the document has its flaws. There really wasn't any need to specify the object of the game; that's obvious. It should have said more about the combat system or the mechanics of leadership. But the best indication of the quality of this design document is the fact that, except for lines 7 and 8, the game came out pretty much the way this document specifies and this was months before I began programming. In July and August, I wrote two more detailed documents specifying some of the design options in front of me. I considered but rejected the possibility of using the crude graphics of the original version so that the program would run on the Apple and the TRS-80. I was undecided on the fundamental question as to the scale of the game: Would it be a strategic game or a tactical game? And I fretted about getting the fog of war into the game without making it unplayable. In September of 1981, there was a big wargame convention in the Bay Area where I live. I attended, and so did Eric Dott, the CEO of Avalon-Hill. We were eating dinner one evening when he asked me about my plans for future work. I mentioned my speculations about a new version of Legionnaire. I also mentioned that I thought I would publish it through the Atari Program Exchange. "But you have a contract with us for it!" he protested. Greatly surprised, I asked him what he meant. It turned out that my contract with Avalon-Hill for Tanktics also granted them rights to Legionnaire as well. I was deeply embarrassed by my oversight, instantly apologized, and assured Eric that I would certainly honor our agreement.
Much had changed in the 30 months since I published the original Legionnaire. The Commodore PET was obsolete. Although Eric Dott had asked me for a version of Legionnaire that would work on the Apple II as well as the Atari, he had also expressed a strong desire to have the scrolling map technology that made Eastern Front (1941) so appealing. I told him flatly that he couldn't have it both ways; the Apple II could not scroll anywhere near as well as the Atari. We both dropped the subject, figuring that we'd cross that bridge later. The Atari 800 was my obvious target machine, so I went to work on the design with somewhat more determination. This time, I approached the design problem more intelligently. I spent plenty of time establishing my design goals before writing any code.
My primary concern lay with the problems of combining a real-time game with a scrolling map. Most of the map would be out of view; action taking place there would not be visible to the player. I considered a dual-view system with a grand overview and a main map for orders entry, but that idea collapsed when I realized that the grand overview map would use tiny colored squares for the military units. It simply couldn't communicate the essential information about the game. Eventually I realized that, with a low unit count, most of the battle would take place on a single screen. Nevertheless, one of the weaknesses of the final game lay in this problem. Occasionally, a few units would wander out of the field of view and be forgotten by the player. Much later the player would stumble upon the units. While this problem was not fatal, it was nevertheless a design mistake on my part. By early October, I had settled on several decisions: playability over realism, the use of disruption in combat, the importance of slope effects, and the maintenance of reserves. But I couldn't seem to pull the design together; my design notes from those days express much vacillation and pessimism about the design. Realizing this, I made one of the best design decisions I have ever made: I stopped working on the project. Game design is at its innermost core a creative act. Creativity cannot be forced. You can work on a problem as much as you want, but effort alone can never overcome a creative mental block. I turned my attention to other tasks and simply forgot about Legionnaire. In mid-December, I had cleared out my other tasks, so I turned my thoughts back to Legionnaire. Sure enough, the answers seemed clearer then. I wrote it all down on one page:
This document is not as complete as the first one, but it represents the decisions I had made over vexed issues, not the complete design. The reference to slopes and slope effects requires some explanation. I wanted to explore the role of slopes in this design. All of my previous terrain systems had presumed that the contents of each hex were essentially independent of the contents of its neighbors. Terrain was therefore a collection of different icons scattered about a map. But ancient combat took place at a much smaller spatial scale than modern combat. Battle was literally hand-to-hand, whereas modern combat always takes place at some distance. Under such circumstances, the macroscopic terrain has little effect on combat. A forest of trees cannot block your view of an enemy standing directly in front of you; and you can't take cover behind a tree under such circumstances. What does matter is any height advantage you might have. If the slope places you six inches higher than your enemy, you can smash your sword down on him with considerably greater force, and he is commensurately weakened in the same fashion. Moreover, much ancient combat involved simple shoving. Like an inverted form of Tug-of-War, the two sides locked shields and shoved until one side collapsed onto the ground, where they were easily killed. If you have the upper hand over your enemy, it's a lot easier to knock him down. But how to represent slopes on a computer screen? The angle of slanted or curved surfaces is particularly difficult to communicate; the human eye relies on fine differences of texture of the surface to detect its inclination and curvature. Such texture control requires pixel-by-pixel shading algorithms, which were beyond the reach of even the Atari. I needed something better. This is not a new problem; mapmakers have struggled with the representation of slopes for hundreds of years. There are several schemes: splash lines, watershed lines, and topographic lines. I settled on the last of these. I briefly considered designing an algorithm to generate the terrain for each game, but after a few fruitless attempts, I gave up. And so in January of 1982, I set to work on the programming of Legionnaire. With a clear design in my head and complete mastery of my hardware, I had a rough prototype up and running by the end of February. Here's a task list from March, presenting the tasks I had yet to tackle:
This is a good example of how I develop a game. As it comes together, I make a list of incomplete features, display problems, ideas for improvement, and so forth. As I resolve each problem, I check it off. All of the items on this list are checked except for items 2, 11, and 12, which have X's next to them, and items 7 and 13, which have dashes next to them. The X-ed items are features that I decided to reject after further reflection. The dashed items are ideas that I liked, but resolved to defer until later in the project, when I might have more time. This, by the way, is a healthy way to deal with feature creep. Instead of tossing in features as they occur to you, you should implement only those features that you are certain will cost little time and are unquestionably worth the effort. Anything that is questionable should be put on the list of desirable features. Later on, when the project is behind schedule, you can show the list of desirable features to the Powers That Be and suggest that these could be added to the game if only you were given more time.
I had difficulty getting the barbarian AI to work well against experienced players. This is a common problem in game design. The usual response is to simply grant the computer some special advantage that makes up for its stupidity. I could have used the standard solution in this case: set the pace of the game so fast that the greater intelligence of the player could not be brought to bear effectively. However, I decided against this and opted instead to give the computer twice as many units as the player. After all, I reasoned, the Romans were outnumbered in most of their battles against the barbarians. However, this was the lazy solution; had I taken more pride in my work, I would have dedicated some time to sharpening the AI. The playtesters, both those at Avalon-Hill and my own playtesters, got their first crack at the game on March 1. I was not surprised when they reported a number of problems; I was aware of these. The playtesters were all experienced, and so they were able to look past the obviously incomplete sections of the game and assess what was actually there. I continued to implement final features, correct bugs, and fine-tune the game all through March and April. By early May, all the bugs had been expunged and the gameplay was well tuned. I was getting tired of spending my nights and weekends on Legionnaire while I worked on Excalibur during the day. I was experiencing burnout. Nevertheless, I pressed on in that last surge of energy just before deadline day. On May 30, I shipped the final version of Legionnaire to Avalon-Hill. They published it six weeks later. Things went a lot faster back then.
|
EAN: 2147483647
Pages: 248
- Key #2: Improve Your Processes
- Beyond the Basics: The Five Laws of Lean Six Sigma
- Making Improvements That Last: An Illustrated Guide to DMAIC and the Lean Six Sigma Toolkit
- The Experience of Making Improvements: What Its Like to Work on Lean Six Sigma Projects
- Six Things Managers Must Do: How to Support Lean Six Sigma