The ideas for a game from anywhere, but at some point before production there should be a plan laid out for all involved to see. Throughout history, game creators have left valuable insights into their inspiration through these pieces that we collectively call ‘design documents’. From visualizations to project planning, from code to creativity, these paper and digital works are an art in and of themselves. Let’s take a look at how games were made through the decades via our scarce, but always fascinating remnants.
In my own experience, one of the most effective things in getting a game to come together quickly is to have a visualization for what the screen looks like. This identifies to all involved what the literal vision of the game is and how the user will be interacting with it. While games may have been largely one or two person affairs in the beginning, it was still helpful to lay out all the screen elements when possible. Such was the case with Darrell J Blendowski and his game Flying Fortress from 1976. Mr. Blendowski created an annotated diagram which described both gameplay and how the controls would work. He divided the screen into zones of point totals as well as making important notes such as “ACK-ACK doesn’t go all the way to the top of the screen” and “should go farther” to mark out his thought process. As one of the earliest known surviving game design documents, it’s a non-stratified and person look into problem solving which many engineers made fun for themselves.
While it’s fine and good to give a rough sketch of what you want on screen, it’s also necessary to actually mark out visuals in terms that computers understand. Graph paper has always been the tech-guru’s friend and it served a vital role in actually doing the work. Working things out on grids was not only helpful for getting things to the screen, but also incredibly useful for figuring out tricks like how to repeat identical lines or re-use sprites. Often these grids would be a guide for hexadecimal inputs as not quite every user had tools that they could use for sprite creation. Both Bill Blewett and Tomohiro Nishikado did have assisting programs, but their layout of design was still necessary before putting bits to pixels.
Time moves on, games become more complex. Companies feel it to be a necessity to properly organize game ideas and development into something that could be referenced and referred to regularly. Atari were of course the leaders of these efforts and one of the more unique collections we have are for Battlezone. Unique in that they show a half-formalized, half off-the-cuff approach to the method. There are a few jokes “The method is by making a good shot (unlikely)” as well as a very crude representation of the game at the bottom. You can see by this early sketch that while the idea for Battlezone was present, the actual form of the game was not. This “beta” version of the game was far more similar to Tank than anything else. Eventually they did make a formalized visualization which fit much more closely to the final game, but with an optimistic view of information that could be displayed before being scaled back.
Atari took the road of the bullet point method, a way to quickly distribute understanding between a large group that needed to be on the same page. Documents though could be directed at particular people, like a film pitch, and that’s the approach John Newcomer took when he wrote up the proposal for Joust. Headed by the main features which production would have to take into account, the first order of business is to describe what the ultimate goal of the game is and why it’s fun. In this way Newcomer is getting inside of the player’s head rather than leaving the design to become fun later. In his magnificent cursive script he sums up the game thusly, “The strategic play is a combination of piggyback chicken fighting and demolition derby.” The age of the elevator pitch begins here.
Development however is not mostly planning, it’s mostly active. When a game is first presentable, you show it to as many people as possible to gather feedback. Gaining useful information from that feedback is a mind-numbingly difficult process, especially with contradictory accounts. Jerry Momoda at Nintendo devised a system of rating based on player feedback and location testing that meant more than raw numbers. This evaluation of the competition’s games, in this case Atari Games’ Paperboy, no doubt influenced the process of development on the corporate or creative end of others when presented in such a readable format. Being mostly positive it probably wasn’t much other than to signal that the game would be a big hit, which it was.
Nintendo rigidly formalized their game creation process with planning sheets. These sheets were immensely useful because they were fitted to the specifications of the Famicom, down to the hexadecimal screen position of every 8×8 tile. The main purpose of these sheets seems to have been discovering clever ways to reuse blocks as well as strictly define color resources. On the right side you can see each object’s color pallet being defined in color and code for a standard scene in Super Mario Bros. These sheets are well organized, if a bit cramped, with spaces for time and date, comments, values, and other organizational trappings. From a technical standpoint these are extremely useful, but most of the creative work was likely done on separate paper first. They even devised a neat way of overlaying these sheets with translucent paper to make edits.
Pushing the boundaries of creativity can get you looking like Ron Gilbert in his Maniac Mansion flowchart. This is an example of some of the limitations of single page paper, unable to describe the nuances of a non-linear game especially as ideas are added and removed through development. This attempt to organize the titular mansion therefore is completely unsuccessful in accurately describing anything other than the maniac: Ron Gilbert. These first passes are rare to find still extant though and show the usefulness in reevaluating your plans. The game likely would have been a whole lot more messy with all these extra rooms.
As we move towards the 90s, there starts to be a greater understanding that game design could be explained through language. Rather than attempting to describe movement on an emotional level, how it should feel, Jordan Mechner counts out the in-game distance it takes for the Prince of Persia to cross a particular gap. All of the game’s challenges can therefore by codified and impossible leaps can be removed before playtesting. The meticulous Mechner has two whole books documenting his design process which go from cutscene arrangement to memory addresses to puzzles like the Mirror Prince. Highly recommended.
By the time of Street Fighter 2, large teams were now expected to put together proposals which were fleshed out visions of the game that anybody could read. Not only did they describe the premise, the production, the story, and all that they also had to go into detail about how the game worked functionally. Frames of animation, jump arcs, controls, and stats needed to be presented in an accessible format. Game documentation was becoming an art in itself, a formal part of the production process. This meant both that executives had to become familiar with how games worked and designers had to become aware of what success was expected of them.
As we’re still in the era of 2D games, I couldn’t not bring up the brilliant method of Gregg Mayles, designer of Donkey Kong Country. To get a feel for a scrolling game, far too big to fit on paper, he would create a series of arranged Post-It Notes to map out a game’s flow. You can see here a pretty damn accurate portrayal of the first level of DKC with splinterings off to the bonus rooms to allow for some non-linearity. Personally I think this method is genius and it’s a miracle that these boards have survived through the years for Mayles to show us. The method is clean, testable, and perfectly fitting a fast-paced game like DKC which feels fairly big despite the small levels.
For 3D games though, it was going to be harder to plan on paper without a rethinking of the methodology. The folks at iD Software became more like architects, defining the landscapes of Quake with traditionally drawn layouts from a bird’s eye view. They defined height through texture, using dotted lines and arrows to imply passageways beneath what was immediately viewable. This left a lot of room for changing angles and adding walls within the editor, but gave those doing the gruntwork an idea of what sort of level they wanted to create. With tools like Quake had, it was easy to build something and test it quickly to see if the idea held any water.
Now, a level in Quake is one thing, but how the hell do you define the Water Temple from Ocarina of Time? I’m not sure Eiji Aonuma even knows, but his two maps here appear to be an attempt to work it out. Aonuma defines each room through the Water Temple with a number, starting as “Spot 00”. He labels each door with two corresponding numbers which represent the steps needed to enter those areas, corresponding to another number within the room. It’s pretty clear that he conceptualized the Water Temple as a very rigid set of puzzles to be solved in a particular order, not quite understanding the tedium of getting misdirected on the solution. This document also hosts some early computer-based visualization to help wrap one’s head around what actually happens in the puzzles.
Sometime’s it’s more than enough to just set the mood. This drawing for Shenmue doesn’t say much about the game (or at least, me not being able to read the text) save for the setting. It’s clear that the game is meant to be lavishly detailed, decorated in largely meaningless objects which still have to be modeled and textured. The distinct Japanese flavor with market stalls and paper lanterns immediately invokes that Shenmue feeling. And of course, that bit at the top, “VF RPG” AKA “Virtua Fighter Role-playing Game”. That was the way they were thinking about it.
For our last item, let’s look at the oft-forgotten role of the writer in the development process. In most games the writer is entirely secondary, writing around a somewhat developed setting, but in Half-Life 2 the role was reciprocal. Marc Laidlaw wrote this piece to inspire the aimless development team all the way back in 2000. It was definitely not a piece that was going to go into the game, instead simply a way to quickly display ideas without needing to resort to a document that would be quickly scrapped.
From the most technical to the most abstract, these pieces have hopefully given you some worthwhile insight into the process of making games. All studios do it differently, and should continue to in an effort to reflect their priorities and personalities. Always look out for more