Monday, November 2, 2009

First Draft Design



[ Team LiB ]









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:



New Legionnaire Specs




  1. Map:
    Rectgrid, scrolling.



  2. Terrain:
    Clear (brown), forest (green), slope (orange).



  3. Romans:
    Red military symbols alternating at 2Hz with background terrain.



  4. Barbarians:
    Blue symbols alternating at 2Hz with background terrain (if seen by player).



  5. Unit count:
    16/side.



  6. Object of game:
    Destroy enemy, especially leader.


  7. Romans start game in three encampments, each of different size.


  8. Barbarians start scattered about.


  9. Barbarian algorithm:



  10. Strategic:
    For each target, determine "projected strength" as


  11. PS = SumOfBarbarian(strength/distance)/SumRoman (strength/distance).



  12. Tactical:
    Determine confidence level from own strength, neighbor's strength, Roman proximate strength.



  13. Player-missile graphics:
    Cursor, eagle, barbarian leader.



  14. Roman units:
    Infantry, 10th Legion (elite), cavalry, light infantry.



  15. Input:
    Joystick has three modes: scroll, move cursor to select unit, specify unit orders. Change states with button (Roll).



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:



LESSON 31


Begin each project with a one-page specification of the gameplay.




  • The five basic colors permitted by the Atari display system are each specified in lines 2, 3, and 4.


  • The initial conditions of the game are laid out in lines 7 and 8 (probably too much detail in that).


  • The core algorithm for the barbarian AI is worked out in lines 10 and 11, while a subsidiary algorithm is presented in less detail in line 12.


  • The allocation of crucial player-missile graphic resources is presented in line 13, while the basic types of units are declared in line 14.


  • In line 15, the basic input structure is laid out.



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.



NOTE


At this point, the reader may wish to skip ahead to Chapter 18, "Eastern Front (1941)." The remainder of the story took place after I developed Eastern Front (1941), and some of the material in that chapter bears on this discussion. In a sense, the Avalon-Hill version of Legionnaire was almost a new game design. Nevertheless, I have placed its design history here so that the continuities with the earlier version will be clearer.



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.



LESSON 32


When you're creatively stumped, don't try to force it; do something else for a month or two.



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:




Legionnaire: Final Design


Tactical scale:
(Same as original Legionnaire).


Rectgrid with overlarge battlefield and scrolling map. Battle fought on a portion of the map.


Standard Eastern Front (1941) order entry. Real-time execution.


Unit types:
Infantry, cavalry, and Caesar.


Units are animated:
Alternate unit type icon with motion arrow icon.


Combat system:
Same as in original Legionnaire.


Unit count:
10/side.


Facing counts heavily!


Slopes and slope effects�yes.


Graphics scheme:
Background color is tan, contour lines black, trees green, Romans red, barbarians purple.


Character sets:
Contour lines: 48. trees: 8. special: 8. no character set DLI.


Player-missile graphics:
Cursor, objective, arrows, and attack animations.



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:



Task List



  1. Variable disruption response rates�better leaders rally the men faster.


  2. Caesar's legion rallies nearby legions.


  3. Must put in orders display arrows!


  4. Need strong indicator that a unit has been selected.


  5. Combat should be very similar to Eastern Front (1941), except make a clang sound instead of a machine gun.


  6. Add sound of marching feet. Put in half-character animation to show motion better.


  7. Need more complexity in gameplay.


  8. Make combat facing-dependent.


  9. Add variable number of barbarians?


  10. Variable number of Romans [real leadership challenge with more units].


  11. Player must scout for enemy�line of sight rules?


  12. Add barbarian leader who can rally barbarian units.



  13. Scenarios:
    Destroy barbarians, cross the board, breakout and escape, defend.


  14. Apply cursor wink to barbarians.


  15. Variable speed for different units.


  16. Recovery from disruption is too rapid.


  17. "Clang" sounds like "buzz."


  18. Barbarians don't retreat�they stand and die.



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.



LESSON 33


Defer unanticipated but desirable features until late in the project.



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.



LESSON 34


If you're not passionate about it, the best you can achieve is competence.







    [ Team LiB ]



    No comments: