Back in the years when developers were hippy wannabes, iterative prototyping was the only game in town. With Zen haikus such as Pacman and Asteroids, who needed to plan? The programmer sat down with a brainstorm, pumped out a few pages of code and then tweaked the game till it was fun. With some early development schedules on the order of weeks, chances were good that a playable version of the game was available almost immediately. Once you have something to play, its pretty easy to notice that "Oh, I die immediately because the enemy ships target my ship too quickly." A few lines of code later, the next version is ready for play testing. Repeat the 'prototype, critique, make changes' cycle until the game is perfect.

Here are some techniques that facilitate the merging of design and prototyping. Certain aspects bleed slightly into project management, but for the most part they deal with the nitty gritty creative decisions regarding what goes into the game.

• The Vision: Maintain a coherent vision throughout. Prototype driven games have an amazing tendency to wander. Check out Quake. Originally it was, what? Something to do with a fantasy world, a big hammer, and a liberal dose of adventure/action if my memory serves me correctly. A couple years later, they end up with an imminently playable clone of their previous game with a mangled plot, and confused atmosphere. The technology was great, and all the control tweaking paid off, but in many ways the game could have been much better. Many aspects of a game, including plot, setting, characters, and atmosphere can be envisioned by a reasonably creative person rather early on in a project's history.

• Use concept sketches, mockups, and heck, even text to get a good feeling for the game you are making. Then stick with it. A designer should be able to play the game in their head, and they should have rough documentation to prove they aren't winging their responses all the time.

• Set goals for the game, put them down in writing, and as the project evolves, keep referring back to the original plan. Not only do you prevent wandering, but all of a sudden some of those tough decisions become a lot easier to work your brain around. It is a big secret, but one of the largest benefits of a written design when you are dealing with incredibly creative people is something called 'focus.' As team members wander down various dimly lit side paths (which they will if they are competent), the designer and his documentation acts as the torch that helps everyone remember, "Hey! THIS is the way we are going."

• The Crap Filter: To state that pure prototyping does not require 'design' is a bit misleading. After all, there has to be someone, somewhere who makes the decisions about which problems are important and what new solutions to try. If you ignore the relatively modern emergence of the Design Document Creator, the traditional designer could also be described as the team's Inspired Crap Filter. (The term is a liberal paraphrase of a comment made by Paul Schuytema, Prey's lead designer, click Here to read.) This is the guy who sifts through all the suggestions that come out of the team, runs them through his internal vision, and spits out informed gameplay decisions. In this role, the designer writes up occasional guidelines, holds lots of chats, and fleshes out the final solutions during each phase of the project.

• Use Cases: Use cases driven prototyping. A standard software engineering methodology involves identifying what the final product needs to accomplish and then setting a rigorous version schedule to guide implementation. Key to the whole process is the concept of 'use cases' A use case is an identified action or problem that the program needs to solve. Note that a use case is *not* a specific implementation, but merely an identification of a need that must be met. In the design of a modeling application, a use case might describe the need for easy to use object rotation method. What exactly this method involves isn't mentioned. Use cases are used to define the scope of a project. Since they don't contain a huge amount of information, a use case document can be written up relatively quickly that describes the final capabilities of a program, if not exactly how the user accesses those capabilities. A rough schedule can be assembled from just a list of use cases. A few educated guesses are made about each use case's implementation and then they are divvied up among a series of versions. Version 0.1 might include the first version of the 3D engine to satisfy the "Needs to be able to display 3D objects" Larger sections are broken up into a main use case and lists of related use cases that are additions or modifications to the original use case. Once the first few versions are implemented, it should be easy to see how well the team managed completing everything within time. If a use case is not going to be completed in time for a given version milestone, it can be pushed off to later versions. Chances are good that if the team pushes off use cases several versions in a row then the whole schedule should be reworked to reflect their empirically validated performance rather than the previously overly optimistic projections. It is rare that a team suddenly becomes drastically more efficient, though you wouldn't know it talking to many game developers who have just missed a major deadline. "We'll just work harder and 'catch up' *wink* I wonder where those extra 80 hours a week going to come from. Use cases help guide the project while still leaving room for revision after each prototype phase. After all, a use case merely states the expected results, not what occurs. If you are aiming for intense cooperative action between two players with battles that tend to last 10 minutes, you have a great target to consider when testing your prototype. "Hey, this game play doesn't fit the use case." Revisions are added to the use case list in the form of additional use cases much as if you were simply dealing with a normal multiple use case section.

The Cycle:

1) Define use cases

2) Contemplate rough implementations for each use case.

3) Split use cases into versions that take an equivalent amount of effort.

4) Finish a version. If planned use cases don't make it into this implementation, push them back into future versions.

5) Critique version using use cases as guidelines

6) Create new use case revisions based on critique

7) Adjust schedule (Including fudge factors. :-)

8) Continue on with next version, repeating steps 4 - 7 until project is complete.

Use cases aren't perfect. They tend to work best when the use case is easily defined. With a tool such as a paint program or financial report generator, this isn't all that hard since the features end up having 'useful' results. With a game, the usefulness isn't nearly as apparent because you are dealing heavily with psychological factors. Instead of talking about whether or not a feature returns a form correctly, you need to consider whether a feature satisfies risk/reward constraints, learning curves, resource balancing, and an innumerable other fuzzy factors. A good designer tends to mentally model these rather abstract quantities so that a use case's implementation can be logically judged. However, if you have no idea why a feature should add to the 'fun' of the game, then you are going to have serious problems getting a grip on the whole use case process.

• Create technology resilient game designs: Not every design needs quad filtered NURB interpolated lens flares to be enjoyable. New technology always takes longer than expected, and the final implementation is often radically different than the original intent. Deal with it through smart design. Assume that much of what your programmer gushes about isn't going to work the first time. Create a design that works just as well in 2D as 3D (it is possible. ;-) Rely on the interactions of your game mechanics to produce an enjoyable product, not artwork, sexy coder hacks, or next generation machinery. If you end up losing your hotshot programmer, the game should be just as fun without that wup ass lensflare. A couple of companies use this to philosophy to good effect. Peter Molyneaux uses a primitive test bed to try out game ideas from the earliest possible moment. Sure, the graphics are ugly 2D blobs, but he ensures that the core game, without the fluff, is worth creating. The massive 3D engine programming and art production occur in parallel so that there is no delay. Imagine a game that has been play tested during it's entire development. If your design is tied into your technology you won't able to play the game until the technology is finished. Trust me when I say this can lead to horrendous delays. :-)

Many greats such as Sid Meier and Peter Molyneux come from the designer/coder tradition. However, times are changing. 3D engines are a dime a dozen, and with tools like Motivate or UnrealEd, the 'how' of a game is often not nearly as important as the fuzzier question 'why?' Players expect fully realized worlds in addition to a bullet list of impressive technical specs.

As word of caution, I've met very few pure programmers who have the background necessary to convey visions of beautiful fantasy landscapes, intricate plots, or the Machiavellian social dynamics of an online ecosystem. You need a good understanding of programming. I wouldn't question that in the least. At the same time, it pays to know a bit about art, music, and especially writing.

Oh, and it's not such a bad thing to be able to work with a team.

A designer without social skills is like a president with his pants on...not *nearly* as desirable.

So what does this suggest for a school? Yep, you guessed it, the good old liberal arts education. Concentrate on programming if you feel like it, but take that odd course on figure drawing or biology. Take every creative writing course you can find, and in your spare time start writing up a 10 page, then a 30 page, and finally a couple hundred page design documents.

While you are at it, become mind bogglingly good at something other than writing, with a nod given to dear old programming and art. Not only will this skill give you something to fall back on in the first dozen years it takes to build up your reputation, but you can also use it to supplement your design docs. A nice sketch or hacked together demo of a game concept can do more to sell a treatment than any quantity of text alone.