A Primer for the Design Process, Part 1: Do

For every game that sets the high-water mark in design and/or game play, there are dozens of titles that don't. Why is that? I've discovered a number of possible reasons. Many games are made by people who shoot from the hip instead of taking a good and proper aim at success, many designers are relatively new to their jobs and aren't certain what's expected of them, and few development companies have established a formal design processes for creating and implementing a game.
Books and magazines are only now dedicating themselves to the craft of game design. Because it is an inherently creative task, everybody thinks they can do it. If that were true, there'd be more games out there with better control, better AI, more user-friendly front-ends, game mechanics that the average 12 year old can immediately pick up and play, and less games clogging the clearance bin at Software, Etc. A harsh reality story a friend of mine likes to tell regards a VP of development-type for a larger developer/publisher asking why he should invest 1.4 Million dollars in his project versus simply investing it in the stock market. The answer? The possibility of an astounding return on investment provided the game is well designed, on time, and fun to play.

This primer for the design process is broken into three separate sections: Do, Think, and Need. The first article explains what you need to do to get ready to make a game, the second looks at what you need to think about while you're making the game, and the final piece examines what you'll need to do the task.

What to Do:

The primary task of the Designer is to design the game. That sounds simple; it was meant to. More goes into designing a game than writing frilly paragraphs about just how cool you think your idea is, just more is required than writing a massive, hernia-inducing tome of endless and unnecessary detail that no one but the author can bring themselves to read.

Good design is about the implementation of ideas and details. To know what you need for your game, you need to know what's going on around you. You need to know what the market might support and what the market is sick and tired of seeing. You need to know what your company (or those funding your company) may or may not want to see. In short, you need to start by asking some questions.

1. Asking questions

This is as simple as it sounds, you need to ask questions before you begin to write your design doc. There are a lot of things to consider while you're cooking up ideas for your next platinum-selling title. By no means is this list all-inclusive. Some questions might be irrelevant to your respective situation -not all games need the same considerations- while some projects might require additional questioning. Determining which questions to ask is one of the most important parts of your job.

What are the current trends?

What are current trends in design? Scan the trade-mags and look at what and who are causing a buzz. As technology gives us the ability to push more polys, build and view larger worlds, light them in real-time, and maintain an acceptable frame-rate, we see that gamers are expecting more from their entertainment. One way that certain creative companies have kept the ongoing interest of gamers is to blur the lines between established genres. It helps us to challenge what's become "accepted" and push the veil of innovative design.

Trends can also exist in things like options and utilities-how the competition is empowering the player by giving them more control over their game play environment. One standard now being called for in the wrestling genera is the need/want to create custom wrestlers from the ground up. This became the most talked about feature on the US side with WWF Warzone, and now THQ and EA both incorporate more "player-empowering" concepts into their titles.

What is marketing looking for?

This could be restated as, "What are gamers looking for?" Look to the marketing experts, they should have a good idea about what people want. They do the focus-group testing, they should be compiling data from this feedback. Also, consider what the market can stand. "Me-too" products usually sell much less than the product they're emulating.

What current tools do we have access to?

For example, look at what motion capture did for animation. Don't get me wrong, I'm not advocating an "all motion capture, all the time" game world, but that kind of data is an excellent way to build a foundation that your well-paid and well-respected motion editors can start from, tweaking the motion to fit the design after the fact.

3D authoring and world-building tools are still probably the most prevalent example of things that can help or hinder the design process. Preexisting tools can also give you jump if you need to either prototype a concept in a hurry or if you need to race to make the Christmas buying season before you loose the license for your game.

Tools give you a way to either prototype a design to get an idea across. They also allow you to get a job done with less hassle. Recycling technology is not a bad thing, unless the only thing your company can hype is tech with no game play.

Some genre's lend themselves to certain kinds of music, often from professional named bands or individuals. Take a listen to what's good, what seems to be happening, then incorporate its style into your title. Some marketing folks will fork over a chunk of your development budget to sign bands or individuals to do the music for your title, but it's been my understanding that very seldom, if ever, will a person's decision to purchase a title be based on the fact that someone they may have heard on the radio once did the music for the game. In certain cases having a named talent do the music might add to the "cool" factor and help generate a little buzz on websites or the odd magazine, but it's not going to sway the consumer and it can also be a huge licensing hassle with no real guarantee that what gets written for the game will be delivered on time or be any good. If there's any question, a good solution is to try to get a synchronization license (Where you get the right to cover the song, but not to use the original recording by the original artist) for a piece of music you'd really like in your game.

Some companies have been known to waste a ton of cash trying to get a particular vocal talent or talents to act in their game as, unfortunately, a major marketing aspect of the title. Did it matter that Rob Schnider was the main vocal talent in A Fork in the Tail, or Christopher Lloyd was in Toon Struck? As above, more often than not most gamers won't buy a title simply because there's some celebrity voice actor that they button past in the first 2 seconds of hearing it in order to get back to the game play.
Get something (or someone) good that fits the attitude of the game, and it will increase the gaming experience for the player. That's all you need to be worried about.

What's been done and how was it done?

I talk about this later on in the "Think" section about Critical Evaluation, but this is a very important issue when you first start your design. There's absolutely no need for you to tell a story that's already been told, or develop a game that's already been done, or rehash a genre that's on the way out. Do your research and learn from that research. You should be playing games, plain and simple. You need to know what's out there, what's already been done, and how high the bar has been set so that you can clear it.

2. The Working Design Document

Once you've focused your ideas, its time to think about the design doc. The design doc acts as a script; it should be giving every other professional involved with the product a more than firm idea of what they need to know to implement their portion of the product.

Like other parts of the entertainment business, there are some basic rules and formats for how ideas are presented, as well as a few things that people no longer want to see. Publishing has its "double spaced 12-point Courier font" from the old Smith/Corona days, and film and TV have standard script formats for either television or the silver screen. These formats are not only expected, but also demanded.

Our business is a little different. It's not quite old enough for standards and guidelines to exist, but we're moving into the "broad spectrum formalization" for industry standards and practices. Simply stated, tradition has bred expectation. Certain questions should be answered before the thing is sent to production. This is your job, O Maintainer of the Creative Vision. You need to answer these questions and more, as everyone on the project will be coming to you or your people for information and the lo-down on what needs to happen and, more importantly, how it's supposed to happen.

Design documents tend to fall into one of two formats: they either loosely describe a game concept so upper-management can sign off on the idea, then get dropped into someone's filing cabinet never to be read again OR they are the size of your local Yellow Pages, filled with every imaginable detail that no-one but the person who wrote it cares about or is willing to read.
In an effort to maintain the working lines of communication between the design staff and the production team, we came up with the idea of a "feature-oriented" document that could keep everyone on the team up to date and informed whenever a design change was made or redesigned.

If you look a production movie script, you'll see that there are different colored pages at any given point throughout the entire script. These pages represent changes that have been made to the script since the start of filming. The colors allow the cast and crew to follow the changes and thus maintain continuity and keep everybody -pardon the unintentional pun-on the same page when updates occur.

Like a script, things in a design document will change due to circumstance, talent, or innovative problem solving on the part of management or the production team. These changes should not only be noted, but also sent out to the people whom they affect.

The Feature-Oriented Design Document

Our feature-oriented design document began as a basic form that could help keep the 6 people involved with the design document up to date. It was designed not only as a fluid guide for everyone on the team, but also as a living document that could carry us through the ongoing design of 3 different games.

We put the design document on our LAN, with the design team continually adding to or updating the document at the same time. Version control is a simple matter of the software (in this case MS Word) not allowing more than one person to work on an individual sub-document at any given time.

The document itself incorporates a couple of features that help with keeping things organized, including major headings calling out important items like what the engine needs to do to, AI requirements, game modes, motion requirements, and on and on. Under these heading are the particular sub-documents explaining the features or functions that individuals on the team have been tasked with designing. Whenever a new design feature is nailed down we can send out updates to the relevant team member through E-mail with a hyperlink attached to the virtual document for easy access by team members. We can do this because the document is being written with the whole team in mind.

The sub-documents themselves take the form of a numerated template with the heading numbers tied to the table of contents. This allows us to sort these documents by feature or project when we work on layers of design for separate products. The template helps push for a more detailed design for each feature and also helps the designer answer questions up front, allowing for a more thorough design when the project hits production.

This template also allows us to design for more than one version of the game. Some design features have been layered to appear over a series of releases and as such, you're always on the same page with whatever feature you're thinking to forward.

The master plan for the design document is to have it linked with both a Technical Design Document that's arranged in the same manner and some sort of scheduling software like MS Project. This has the added function of allowing us to asses any impact to milestones or budget new design features may have.

The Template:

The major reason most artists and programmers don't read the design document is that, if there are any practical design features contained within, they are usually buried in page after page of ongoing paragraphs. Simply stated, no one wants to weed through it to get to what they need to know. The template, in this form, serves the major function of being digestible in small relevant chunks.

Remember, this is a FEATURE-ORIENTED design document, which means that it is put together with certain goals in mind, and these goals are broken down into doable bits.

There must be "Tasks & Questions" sections for each arm of the development team. This allows the Designer, Artist, Programmer or Sound Designer in question to skip straight to the task relevant to them without having to filter through all the other text. This also lets the design team ask any questions they may have at a time when they might not have access to the person that could immediately answer it.

You'll also want some way to tag features that have been dropped or held back for whatever reason. You don't necessarily want to delete those features, as they may make their way back into the current design or appear in the sequel if you're doing one.
In our particular case, we're working on the design for several titles at one time. Each heading is further expanded into 3 sub headings-one for each version-and color coded to make reading and separating them on-screen a little easier.

E-mail and the Hyperlink:

With the design doc online, we're able to send intranet e-mail to all concerned parties when a feature is designed, changed, or dropped. In addition to the email saying, "This feature has been designed, changed, or dropped," we can also add a hyperlink which, when clicked upon, will take the concerned party directly to the page(s) they should be reading.

The e-mail has a secondary consideration in that the Project Manager will know when and if the Email is being read. This helps in maintaining team accountability for what each person's job should be, and how they need to implement it when the time comes. This kind of organization lends itself to a HTML-type document as well. We're currently setting up just this kind of accessible, online document using MS Frontpage. You could also use Dreamweaver if you were so inclined. This allows anyone with a web browser to access the design doc and very easily navigate their way to whatever piece of info they need. Even better, you can do things like create art bible's, complete with linked thumbnails and actual photo reference on the network, making sure all or your resource is available and protected.

The next section (THINK) will go deeper into asking questions about what you're supposed to be doing as a designer. This also includes my list of "Nevers," garnered over the years both from friends in the industry and from simply doing things the hard way.

Tim Huntsman has been with Acclaim Studios, SLC for over 4 years and is the Lead Designer for Acclaim's next-gen wrestling title. He has worked on the ECW wrestling franchise as well as the genre-defining WWF Attitude for PSX and N64, projects that taught him more about professional wrestling than he ever thought he'd know. When not working on games and their design, he's playing guitar in experimental projects, writing various forms of fiction, painting in the Sumi-E style, and fencing (with swords, not wooden planks.)