0% found this document useful (0 votes)
50 views

Developing Design Process

The document discusses developing an effective process for game design. It states that game design requires a vast array of skills and is challenging work. It then outlines typical stages in a game development cycle, including concept, pre-production, production, and post-production. It emphasizes that having an organized design process is important for managing a project, ensuring all aspects are considered, and aligning with schedules. The document also notes there is no single right process, but designers should find one that works well for their needs and style.
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
50 views

Developing Design Process

The document discusses developing an effective process for game design. It states that game design requires a vast array of skills and is challenging work. It then outlines typical stages in a game development cycle, including concept, pre-production, production, and post-production. It emphasizes that having an organized design process is important for managing a project, ensuring all aspects are considered, and aligning with schedules. The document also notes there is no single right process, but designers should find one that works well for their needs and style.
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 25

@2003 Troy Dunniway – All Rights Reserved.

Developing a Process for Design


By Troy Dunniway
[email protected]

"The person who knows 'how' will always have a job. The person who knows 'why' will always
be his boss." - Diane Ravitch

Designing games is an extremely challenging job. It requires a vast array of skills, knowledge and
experience in order to do it well, yet it is perceived by many as being easy to do. There are many
kinds of designers and design jobs out there, and they all often do very different things each day.

People often think that designing games is just about coming up with ideas. Ideas are a dime a dozen.
Taking an idea and making it work, making it fun and making it into a game is the hard part.
Execution of the idea is everything. In the end, you have to trust that you and the people on your team
will have plenty of great ideas along the way, so great ideas aren’t going to usually be a problem for
most teams, but making the idea is another story.

Some people think that great games are all about good game play or storytelling, artwork, cool
technology or some other aspect of the game. In fact, it’s about all of them and how they all fit and
work together. Designing games is a constant compromise, since everything must fit together and
work as a cohesive experience.

You often see a bad feature in a game and think that you could have done it so much better, and that
the designer of the game must have been an idiot to have done it that way. While there are some bad
designers out there, and a few people with bad ideas, the reality is that it is often out of our hands. If
the technology doesn’t come through for you, if a feature isn’t possible to make, if the artists can’t
make it look right and if a thousand other things that could happen do, you can get completely
messed up and have all your plans evaporate instantly.

When I was helping design the first 3D RTS to come out called “Armor Command”, we knew very
little about 3D. We were unable to figure out how to get the mouse to work in the 3D world and then
also function on the 2D interface, so we were forced to make the 2D interface completely keyboard
driven. While this was far from optimal, we made due and came up with an adequate solution. On
Munch’s Oddysee for the Xbox, a large amount of the planned features never were completed, so we
were forced to redesign most of the levels for the game at the last minute in order to take advantage
of the features which actually made it into the game.

As a designer, it can be a hopeless feeling to have all your hard work thrown out because something
else didn’t come together. While we can never remove risks like this, and it will always happen and
be the thorn in our side, there are things you can do to prevent many of these problems from
happening. Having a process that you follow when you make games will help you prevent many of
these problems and others which you might encounter.

Do Not Distribute without permission. 1


@2003 Troy Dunniway – All Rights Reserved.

The Game Development Cycle

All games must go through a development process. This means that they usually follow the same
order of events, or a similar order of events when they are developed. Most games follow a fairly
similar development cycle. Each company makes games a little different, but the overall development
cycle is very similar. So from a high concept level, the game development process is similar to the
development of other software and entertainment products.

The basic development cycle goes like this:

Concept - Pre Production - Production – Post Production

Later on we will refine this cycle a bit more however, to show how this process of making games is
slowly changing.

Like most everything else, all games must start with an idea. This idea must be thought about and
refined a little bit, until it can begin to form into a cohesive concept. This concept is usually then
developed into some kind of proposal. Occasionally this may just be you going to your boss with the
idea in your head and telling it to him to get approval to make it, but usually it involves putting it
down on paper in some kind of formal way which people can read, understand and get excited about.
The goal of this first step is about getting permission to develop your idea further.

Once you are given permission to develop the idea further or decided for yourself to refine the idea
more, you can then start what is called Pre-Production. Pre-Production is the time when you take
your early concept and evolve it into something which can show why the game should be made. The
goal of pre-production is to develop a game prototype which shows why the game is fun, how it looks
and that the technology necessary to build the game is feasible. Pre-Production is therefore the
planning and early building stage. For a designer, this is where a lot of your work is done.
Surprisingly, Pre-production is one of the most important stages of the development cycle, and is
often either overlooked or severely cut short by many developers and publishers. At the end of Pre-
Production, you generally will need to show your game prototype to someone again to get approval to
move into full production.

Once you have approval to start building the entire game, you move into Production. Production is
when most of the assets of the game are made, and when the bulk of the features are flushed out. This
is when the game is assembled. The goal of this phase is to create a version of the game which is
basically all together, done and ready to test.

Once a game hits a key point, called Alpha or Content Complete by many people, it should have all
of it’s features and programming code finished. The goal of this phase is to find all of the bugs with
the game, make sure it is stable, compatible and well balanced. At the end of this phase the game
should be finished and shipped to the public.

Keep in mind that every company has a different process and set of procedures when it comes to
making games. This can serve as a guideline to what is widely accepted by many companies.

This general overall process is logical and generally works pretty well to develop games. As a game
designer however, you will find that the overall game development cycle isn’t the same or in
alignment with the game design process you will need to follow to make a great game.

Do Not Distribute without permission. 2


@2003 Troy Dunniway – All Rights Reserved.

The Game Design Process

A game design process is similar to the game development cycle for most people. Most game
designers, yes even the working professionals, don’t have a formalized game design process.
Whether they realize it or not however, most game designers do have a process which they follow.

So what is a game design process? A design process is a series of steps that must be completed to
refine an idea for a game and bring it to completion. Whether the game is being designed by one
person or a group, every concept within the game must be thought of, refined, questioned, verified,
and solidified before it can be implemented.

As a designer, you control the content that goes into a project. You determine the number of features,
mechanics, moves, protagonists, antagonists, special effects, and so on. Being realistic about what is
going into your game is the first step in the design process. Making sure that everyone on the team
understands as clearly as possible what is in the game from the start is the best thing you can do.
Establishing a formal design process allows you to think about all aspects of the design and ensure
that you cover all your bases up front.

You can have great art, great technology, and a great design, but unless you have unlimited funds, a
proper schedule is the most important thing you can have on any project. Because games are often
one-of-a-kind propositions full of unproven content and technical hurdles, they are notoriously
difficult to schedule (which is one reason that so many games are late, late, late). Having a design
process is one of the checks and balances with the reality of your schedule and the game design you
are creating. With a good understanding of the process, you can not only schedule your own tasks,
but help the Producer on the project begin to schedule the rest of the game realistically.

Every idea must get from the designers head and then somehow into the game. Every aspect of the
game must be designed. Failing to design key aspects of the game could cause major problems late in
the development cycle. Therefore developing a formalized game design process can be a huge
advantage to you if you understand how to properly utilize it. Keep in mind that there is no right or
wrong design process, but there are better processes which will work better for you.

Different Processes

While there is no right or wrong way to design a game, there are many different ways. This is both a
blessing and a curse. It gives us lots of freedom, but makes finding the right process very confusing.
This can also be made worse by the fact that many of the people who write articles and articles on
game design, and speak about it at conventions have very strong opinions about what works and
doesn’t work for them, but they tend to preach it as the only solution.

For some designers, the idea of a design process involves just sitting down and creating the game as
they see fit, in a vacuum. Others try to create the design by brainstorming with other members of the
team. Whichever way you generate your ideas, you need to agree upon the process by which new
ideas can be implemented. Although some designers can conceive and control their projects by
themselves, most need other people involved in the process to ensure that what they're doing is
realistic.

So, if you don't have a process in place that helps make your ideas happen, it's time to think about it a
little. You then want to make sure that the entire team understands the process and will adhere to it. It

Do Not Distribute without permission. 3


@2003 Troy Dunniway – All Rights Reserved.

seems a little strict at first, but ultimately having a process ensures that you're making the best
possible product.

It is a good exercise to read and hear about how other designers work and the processes that they use,
but you have to be careful. I would encourage you to use a lot of common sense and restraint in
throwing out your current process, if you have one, unless you’re sure that this new process that
someone else is using is right for you, your team, the type of game you’re making and the
environment you are trying to build.

Many different philosophies approach the best way to design a game. Every company, every team,
and every project have different strengths and weaknesses that will also make one method more
successful than another. This article shows you primarily one approach to game design, but it's not
the only way and it's perhaps not even always the best way for you and your particular project.

Some designers hate the way large publishers work and the way big business works, so they will
argue and rebel against my process until the bitter end. Some designers believe that game
development has to be a totally organic process that you can't schedule because the game needs to
evolve into its final form. Other designers believe that it's best to have a game designed by a single
visionary, while still others believe in design by committee. There are a lot of different ways to skin
the game design cat. Here's a glimpse at a few of the design processes which people use:

No Design

Some designers believe that it is impossible to design something and keep it creative. To put it
bluntly, they are wrong. Jumping into a game and just making it won’t get you very far, unless
you’ve done it before, the game is really simple, or it is some kind of a sequel. Even then, I still
wouldn’t recommend attempting to not design your game ahead of time.

Little Design

A bit more than not having a design, some people like to design as little as possible in the beginning.
They may write a paragraph to a few pages of details and then jump into making the game. This isn’t
much better.

Complete Up Front Design

On the other extreme side of the spectrum are the people who try and completely design the entire
game before they begin making it. They may write hundreds of pages of detailed documents and plan
out every detail, before they begin making the game.

Technology Design

A technology design is one which is one where a key feature(s) of the game are programmed first and
then a game is made out of the feature. While every game needs technology, and even it has to be
designed, a technology driven design is one where a programmer sits down and develops a cool
feature or set of technologies and then makes a game out of it. Bloodwake for the Xbox is an example
of a game where some incredible water technology was created, and then they figured out how to
make a game using really good water physics.

Do Not Distribute without permission. 4


@2003 Troy Dunniway – All Rights Reserved.

Another approach for technology driven design is taken by a game like Dungeon Siege. These games
were designed by designers with a strong programming background, and they first developed what
they call the “Sandbox” and then see what they can make with it. This is where the developer creates
a whole series of features, which all fit together, but they aren’t sure exactly how, and then once the
technology is finished they try and figure out exactly what kind of game to make with it.

Artistic Design

Visual design is the process used by many developers who work in what are primarily art houses.
Many game developers whose upper management come from the art or film industry also use it. This
process involves visually detailing the game for a very long time. In this process, there is a tendency
to forget about game mechanics. I've seen projects designed with this method drag on for a very long
time, only to produce impressive artwork without a real game underneath. One of the big problems
with art-driven design is that the visuals raise expectations that, in many cases, are not supported by
the underlying technology or game-play mechanics. In general, it is very easy to visualize a game in
static storyboards or paintings (or even pre-rendered game-play visualizations) and very difficult to
actually implement these visual ideas.

Munch’s Oddysee was highly driven by its need for a fantastic visual quality. These types of projects
are usually designed or run by someone with an art background, or because the art is a very important
aspect of the game. I have seen games which were close to a year into their Pre-Production phase,
and all that had been done was concept art. No code had been written and no real game design had
been done. While Art is a critical element to the game design, you need to make sure that it is kept in
balance with the rest of the game.

Collaborative Design

A collaborative design process is one in which the entire team works together to develop the design
of the game. Although in many cases every project is a team design, even if it has a lead designer, a
collaborative design goes out of its way to include everyone in the process. Valve is a prime example
of a company that uses a very collaborative design process called the Cabal. You can read all about it
at www.gamasutra.com/features/19991210/birdwell_01.htm.

The Valve process involves including the entire team or members of the team in regular
brainstorming and design meetings. The idea behind a collaborative design process is that everyone
on the team is smart and has great ideas, so it's good to utilize this to get the best game possible.
Unfortunately, everyone tends to have different ideas, so it can be hard to focus the project.

One of the biggest problems with a collaborative design process is that someone needs to be in charge
and able to make the hard decisions. This process can quickly devolve to a design by committee,
which doesn't work. Unfortunately, when you ask everyone's opinion, you're likely to get a variety of
different answers, or else one person will dominate the group and keep others from talking.
Whenever the entire group must decide specific issues, you can be in for trouble.

If the collaborative process isn't run well, you can run into a host of problems. In my opinion, even a
collaborative process should have a leader who can act as a "tie breaker" to keep the team focused.

Do Not Distribute without permission. 5


@2003 Troy Dunniway – All Rights Reserved.

Iterative Design

An iterative design is one where a feature, or maybe a few features are designed, implemented, tried,
tested and the refined, before you move on to the next set of features. This design process can be
similar to that of a balanced design, but tends to look at just a few features at a time and then make
them fun, before adding anything else. This process is often driven by programmers, and is often used
in strategy games where every new feature could possibly unbalance the game.

Iterative design can also be called Trial and Error Design or T&E design, as I call it, and it is most
often done by programmers. Although this isn't necessarily a bad idea for some games, it can mean
death for others. In a T&E design, you start with a small concept and then begin to program the
game. The goal is to get the game up and running and fully playable as soon as possible. When the
core of the game is working, you begin to add features and remove features as it makes sense. In
other words, add a feature and see if it is fun; if it isn't, take it out and add another. Keep this up until
the game seems fun overall. Designers who use this process typically do minimal, if any, formal
game design.

Most early games and many arcade games were designed this way because the games were simple
and easy to create. This was also often done because no formal design standards existed and because
the person programming the game was often also the person designing it and possibly even doing the
art for it. This made designing games back then a lot different than the way most games are now
designed.

This design philosophy was used by Chris Taylor when he created Total Annihilation. Because an
RTS is so data-driven, game-play balance is everything. Although this approach worked really well
in TA, it didn't work so well initially in Dungeon Siege, and Chris quickly learned that he needed to
do more up-front design work to design a good RPG. This shows that just because one technique
works well in one application doesn't mean that it can be applied to every game design you might do,
unless you're always doing the same type of game in the same genre.

Balanced Design

A balanced design is one where everything is done together. It lies somewhere in between no design
and a complete upfront design. It has components of artistic design, technology design and the other
design processes, while finding the right balance between them.

Similar Issues in Software Design

It can also be helpful to study general software development. I strongly believe that there is a strong
correlation between the game-design process and that of other software design. I believe you can
learn a lot from other software projects, whether they are applications or even updates of an existing
code base. The more I talk to people from other parts of the software industry, the more I realize that
game developers' problems aren't unique. Therefore, I highly recommend reading articles on general
software development, including Rapid Development, by Steve McConnel.

The process of game design is similar to normal software design in many ways. Many people think
that making a software application is totally different than designing a game. Although it's true that

Do Not Distribute without permission. 6


@2003 Troy Dunniway – All Rights Reserved.

games are creative and have their own set of difficult problems to overcome, a lot of similarities still
exist between most software-development processes. All software projects require code to be written,
involve deadlines, must create a product that is easy to use, includes a development and design
process, must consider what users want, and includes an entire team of skilled people working on the
project for years at a time. Designers can learn a lot from normal software development, which can
help improve the process of developing games.

As you can see, there are a lot of different ways to design a game, and all of these different
development processes will directly influence how you create your own design process. The entire
process of creating games is very difficult. Without some kind of plan, you're never going to make it
on time and on budget, unless you make severe compromises. It's important to adopt and understand
some kind of design process if you hope to be successful.

Creating a good game design is a very difficult thing. It's not something that you can just jump into,
but it's also something that is creative and that can't be overly analyzed. Having a process in place
and developing a deep understanding of how you should design games will go a long way toward
helping you design a better game.

What Does It Mean to Formalize a Document?

A formal design is one that follows a set of policies and procedures to help ensure that an adequate
design is created for the project. If you don't follow a more formalized approach to design, you might
waste a lot of time early in designing the wrong things or focusing so much on short-term issues that
you put off the long-term problems facing your game.

This formalization is set in place as a way for you to think about every aspect of the game early,
especially when it's time to set a budget and a schedule. People in the industry commonly do not
work on critical components until late in the project, assuming that they will be easy. More often than
not, this causes delays in the project. Never assume that anything is easy.

Formal design documentation is about planning your game. The better planned a game is up front, the
smoother the project will usually go and the better chance it will have of actually being manufactured
and distributed.

In an ideal situation, a designer should be able to work by himself for at least six months before
anyone else even joins the project. During this time, the designer roughs out the design. When the
designer has had time to solidify the basics of the game play, several other people should then come
on board and help with preproduction. By the time the design reaches the end of preproduction, it
should be fully formalized and fleshed out so that when the project moves into full production, a
blueprint of the entire game will be available to the team. Of course, some aspects of the game won't
be fleshed out yet, but the preproduction phase should answer as many questions as possible. Keep in
mind that this is an ideal situation that doesn't always happen. Often you will have to work on
projects that are already in full production and that have either no formal design or a really weak one
that needs to be fixed.

The most challenging part of creating a formal design documentation procedure is that it needs to
constantly change and adapt to every new project. It is impossible to create a set of rigid rules that are
equally appropriate for every project.

Do Not Distribute without permission. 7


@2003 Troy Dunniway – All Rights Reserved.

By formalizing your design process into documents, you create a blueprint from which others can
build the game. To communicate your intentions effectively, these documents must live up to certain
standards of completion. The bigger the team with which you work is, the greater the chance you
have of something going wrong with someone else's implementation of your design if it is not
properly formalized.

By creating this document and saying that it is complete, you're endorsing the design. If your name
and reputation are on the document, you're placing a lot on the line. You also want to make sure that
the design you endorse is done right. The worst fear of a designer is to work on a project for an
extended period of time with a large team and see the project cancelled because of bad game design.
A lot of fingers can (and will) point in your direction because, as the lead designer, the fault is yours.
I've been involved in helping a lot of projects that have come under fire late in the project's
development for bad or unfinished game design. This problem is very common in the industry, and
we must stop it by making sure that game designs are formalized and up to snuff.

So what separates a normal design document from a formalized one? A formalized design is one in
which a set process is applied to the document to ensure that it is written to a satisfactory level of
completeness. In some ways, every design is formalized, but if you're just writing down what comes
to mind and are not thinking about the process and the implications, you're failing to formalize the
document.

A formalized design is one that is planned out in advance. This requires that you have some prior
knowledge in game design and hopefully some experience in designing the same kind of game
because they are all slightly different. It also helps if you have a template of some kind. A formalized
design doc doesn't exactly have precise characteristics that can be listed because it's always different.
The process involved in the development of the document is more important than the specific
information within the document. A formalized design is one done to a level that is satisfactory
enough to allow you to easily and realistically develop a game based on the information.

The next two short examples show the difference between taking a loose approach and a more formal
approach to writing a paragraph description.

Short Informal Design Example

Well, you see, in my game there are these guys, and they run around using guns and killing people.
They have all kinds of cool weapons that shoot bullets, lasers, big flames, and missiles that explode.
The player is a big guy who is in the Army, and he's fighting aliens who have all kinds of strange
weapons.

Short Formal Design Example

Goal: This is a first-person shooter that has spectacular graphics and a bunch of great new features.

Game play: First-person shooter, similar to Quake.

Controls: Same as Quake. List here[el].

Weapons: Pistol, machine gun, laser pistol, laser rifle, bazooka, flame-thrower, grenades.

Story: Sci-fi story that pits the player against an alien invasion on a distant Earth colony on Mars.

Do Not Distribute without permission. 8


@2003 Troy Dunniway – All Rights Reserved.

The difference between these examples is that the formal example is often easier to read for the team,
because they can find the information they need and get all of the details. The formal example also
helps make sure that what you are writing is complete and precise. The informal example doesn’t
sound as professional, which you need to try and be. Overall, I’ve found for my main design
documents, it’s best to be quick and to the point, and as minimal as possible. You shouldn’t have to
sell your team on the idea.

Sometimes it is necessary however to create multiple versions of your documents. You may find that
people from marketing and management respond better to a more hyped up, cool sounding document,
than one which is better suited for the team.

Using the Design Process

Every idea must go through some form of process to become a reality in a game. Understanding the
path that an idea travels until it becomes a reality is important. You might start with an idea such as
"The game should have four-player split-screen multiplayer." As a lead designer, you might be fairly
sure that this is something you want to do, but you must also figure out all the specifics for it. You
might then need to check with all the other designers to make sure that there is not some other
ramification or pushback to doing it. When the entire design team thinks it's a good idea, you might
need to check with the programmers to see if they can do it. After the programmers have signed off
on the idea, you might need to check with the art department, to make sure that any changes required
by that group can be done.

For some games and ideas, this might be all that is required. However, for more complicated or risky
ideas, you might also need to have the marketing department, testers, and management signed off on
the idea. Each one of these sign-offs is a necessary step in the design process. Either way, you need to
understand that, as a designer, you can drive the vision of the game, but you can't control it: Other
factors need to be taken into account before your idea can become a reality inside the game.

Most ideas are put into some form of a design document and looked at in bulk by whoever needs to
sign off on them. Avoid trying to get buy-off on each and every individual idea from the entire team,
unless it's a really big change in the vision of the game. No matter how you turn an idea into a
feature, keep in mind that at some point you need to get others to buy off on the idea. Involving the
entire team in the buy-off process regularly helps the entire design process greatly.

A design process can also help you identify several main needs in your game production. First of all,
a process should help you keep track of all of your ideas. It can also help you track all of the features
in the game, and help ensure that you don’t forget any key features of the game. As you can see, a
design process is indirectly closely tied to scheduling. This is important to keep in mind since it’s
difficult to make games without keeping the reality of the schedule in mind.

Making games is a team effort. A design process can help your team work much better. Every idea
that must be made into a game has a process that it must go through in order to get made. This
process includes getting the team to buy off on each and every idea you come up with. Programmers
and artists must tell you that the idea is possible, while the Producer and others may need to tell you
if it is feasible.

A design process also helps to ensure that nobody on the team is implementing ideas without your
consent and buyoff. It also lets the other people on the team know that you're in charge of the design

Do Not Distribute without permission. 9


@2003 Troy Dunniway – All Rights Reserved.

and that it's not okay for them to simply start changing things as needed. In addition to the project
design process, each department should have its own development process, or "pipeline," for how
things are implemented in the game. This helps keep proper communication channels open between
team members and keeps time from leaking away from your schedule.

How you formalize your design process is up to you. Just knowing that you need to have a process
may be good enough for some people and projects, while creating some kind of chart may be better
for others. I like to create a spreadsheet that lists every feature in the game going down, with the
across columns listing the steps of the design process.

Here are the different categories I track across the top of the spreadsheet: Feature, Feature Priority,
Date Needed By, Stage feature is in: Idea, design buyoff, art Buyoff, Programmer Buyoff, Buyoff
from Others, final feature approval.

Going down on the chart I track the features like: Interface Design, level design, units, weapons, etc.
I then break down each of these features into as finite as detail as possible. Even if the features are
unknown, you still should have a rough idea of what the total features for the game should be. This
initial step can also help you try and help you figure out which features you should design first. This
helps you make good decisions about what you are doing early on, which is one of the toughest
challenges for a professional game designer.

I've found that creating a detailed design process spreadsheet serves several important functions.
First, the spreadsheet acts as a place where I can put every important design feature. This helps me
make sure that I don't forget an area. Second, by continually updating this spreadsheet, I can track the
progress of every design feature in the game. This also allows me to globally track the game's
progress against its ship date. In addition, the spreadsheet helps the rest of the team, which must buy
off on a particular feature, know where the game is in the design process. Last, the design process
marks the beginning of a schedule, which is really the most important part of the project.

How exactly you use the design process to improve your game is up to you. It may not be possible to
capture all of the information you need to track in a single design process document. It may also not
be necessary to even create these documents at all, but if you’re as anal and thorough as I am, it can’t
hurt.

The Changing Development Cycle

Earlier we talked about the standard development cycle.

Concept - Pre Production - Production – Post Production

Over time, we have begun to realize that this development cycle doesn’t work extremely well. Some
of this has to do with the way games need to be made, while other issues revolve around stickier
problems having to do with the way contracts are written and the current political scene of the
industry. What it boils down to however is that once we commit to fully developing a game, it can be
very difficult for some publishers to cancel a project.

One of the problems we are facing which is forcing this change is that the quality bar of games is
dramatically increasing every year. Many developers are still developing games using the processes

Do Not Distribute without permission. 10


@2003 Troy Dunniway – All Rights Reserved.

and standards of what was acceptable in years past, which is impractical in today’s much more
competitive environment and higher project costs.

There are two different schools of thought when it comes to creating features and showing quality in
a game. The first school of thought is what is called a “back-end development cycle” (see figure 4a)
and it says that developing games, programming features and making great quality art is extremely
difficult. Therefore it will take the developer most of the production cycle of the game in order to get
all of the features working in the game, which won’t allow them to show what the finished game will
look like until very late in the development cycle.

The back end development model is the most common model used in the production of games today.
Only a single prototype is built and then full production is started. Because the entire game is not
running early on, many problems are often not discovered until late in the development cycle. This
causes delays and lots of changes late in the project, when it is the most expensive to run. Also, if a
project is then discovered to not be viable until the end of production, millions of dollars have already
been spent and often years of time.

The second school of thought is called a “front end development cycle” (see figure 4b) and is where
you need to show the final quality of the game as early as possible in the development cycle. This can
be very difficult to impossible for a new developer with no existing technology to achieve. This
approach is now considered lower risk for a publisher and the developer. Because of the quality
problems we are having as an industry and because of the lower risk factor, there are more and more
people making a change to the front end development cycle and demanding to see what the final
game will look like as soon as possible.

Do Not Distribute without permission. 11


@2003 Troy Dunniway – All Rights Reserved.

The front end development cycle is safer for a publisher because it allows them to risk less money if
there is a problem and they need to get out of the project. The front end development cycle is used by
many successful companies like: Naughty Dog, Blizzard, Insomniac, Nintendo and Microsoft. It
allows them to spend more time at the beginning, in Pre-Production, making sure that we know what
we are going to make before we jump into making it. Under this model, several prototypes are built,
which prove all major concepts in the game, before the entire project is staffed up and becomes
expensive to run. If a prototype is found to need more work, it can be easily and more cheaply thrown
out and repeated or just completely thrown out with a lot less money being spent. With this model,
costs do not start going up until the risks are limited. Later in the article I will get into more detail
about what goes into a prototype, and how this process directly effects pre-production.

Finding the Process That Works for You

As you can see, there are many different ways to make games. Every company you work for will
have its own way of making games. You may not have a choice on the process you use to make
games initially. You may however be able to control how your team or small group works, so it will
help you a lot to see how different people design and the advantages and disadvantages of each
technique. Then, in the end, you can hopefully gain enough insight, experience and influence to build
your design process and development process which works best for you.

You should formalize your design for a lot of reasons, and you should avoid a few things along the
way. The biggest mistake I see all game companies making is not properly documenting their design
ideas. So, the first step of figuring out how to formalize your document is to think about what would
be best for you and the project.

None of my advice here will do you any good if it completely changes your project and it spirals out
of control. You might not be able to stop your game development for four months while you say, "I'd
really like to just think about this for a while do you guys mind taking a short vacation?" The advice
in this article is meant to help you improve your process in an idealized situation, so don't expect to
completely adopt a formalized document overnight. Some of my ideas will be immediately applicable
to you, while others are food for thought or something to implement in the next project.

Do Not Distribute without permission. 12


@2003 Troy Dunniway – All Rights Reserved.

Breaking down design

"Designing is not the abstract power exercised by genius. It is simply the arranging of how
work shall be done."

W. R. Lethaby

The different parts of the development cycle which we’ve been talking about can logically be broken
into phases. These Phases help identify key points in the game-development cycle. Within each Phase
of the development process, certain design and development work is usually done. These Phases
aren't always very well defined during some projects, however. The five Phases might also be too
granular for some production cycles, so don't be afraid to break this down into some smaller steps and
adjust your design process appropriately.

The main reason for separating the Phases of the design is that, at the end of each phases, there
usually comes a time when you are waiting for other members of the team to finish some work and
for some kind of approval from management to continue. This usually means that you are waiting for
some aspect of the game to actually be created and made playable so that people can look at or test it.
At the end of each of these Phases, there is a chance that the results won't be adequate and that you
will have to repeat the stage or iterate the stage until it is good enough to proceed. When you
understand the different stages a design goes through, you can begin to understand the phases for the
work that you need to do during each stage.

What is a Design Document?

Everyone has a different idea about what design documentation should look like. I've seen designs for
games as short as 3 pages and as long as 1000 pages. What matters is not how long your documents
are, of course, but how clear and thorough they are. Every type of product and team requires a
different level of documentation, so the best approach is to offer guidelines and let the game dictate
the standards.

The most important thing to remember while creating your design documents is that they are what we
call "living" documents. This can mean several things. First, the documents are always changing and
are always being updated, refined, and polished. Second, many people tend to contribute to the
document in some way, providing feedback and additional information through the life of the project.
Finally, a living design document isn't just a collection of words and diagrams set in stone, but it is a
flexible map representing every aspect of the design as it changes over time, acting as a warehouse of
useful information for the entire team.

Creating a game is not a black-and-white process, so your design documents also cannot be rigid and
inflexible. Game creation is an art applied to a science. When creating your documents, you might
have to use your instinct, intuition, and gut feelings to come up with the initial answers to your
problems. Sometimes you might come up with several ways that a problem can be solved. Because a
design document is living, feel free to insert all of your ideas. In case one idea doesn't work, you'll
immediately know what to try next. Also, by including your ideas and thoughts in your document, the
rest of the team can read them early and might contribute to a healthy debate about the relative merits
of your ideas, allowing you to solve problems on paper well before implementation. Letting your
programming team see your ideas early also enables them to evaluate them from a technical
perspective based on the way the core technology functions. Sometimes even the slightest game

Do Not Distribute without permission. 13


@2003 Troy Dunniway – All Rights Reserved.

design change, that seems easy to do, can affect the entire core of the game. If the programmers know
that there is a possibility for two different features to exist, they can make their technology flexible
from the start, to implement your new idea later with less work.

For example, if you ask the question in your game: “Can the NPC’s in the game pickup and use
different weapons?” Whether or not NPC’s use the weapon they are given or have the ability to
change weapons is a huge architectural change. If a character just uses one weapon all the time, like a
sword, then the actual model of the character can just have a sword as default. The game doesn’t
really need to know the sword exists. Plus the animations can account for the character always having
a sword. If you decide on this, and then later on decide that it would be cool if the character can
pickup and use a gun, this will cause all kinds of problems. An in between solution may be that there
are classes of weapons, stick (swords, clubs, etc), pistols, rifles, etc. Then, a character might be able
to use a class of weapons, but not all weapons. Making this single choice will determine how the
programmers design the architecture of the animation system and AI, how the models are built, how
the characters are animated and how the game is balanced. Before you decide on any key feature, try
and think about any possible changes you can foresee, what systems of the game will be affected and
who it affects. Get the signoff of anyone who the design feature affects, so that you and they know it
will work.

One of the biggest problems with trying to also keep track of all these other things arises in the way
documents are formatted. Later I'll get into how to properly format game design documents that will
make ideas in your document clear and easy to understand.

Another critical reason to properly design your game on paper is to allow you to create realistic
schedules. We live in a time in which it seems to be acceptable to be late sometimes very late.
Publishers and developers wonder why they can't make any money from a project that was a year late
and doubled its expected production budget. There is no reason why projects should be late, and there
is no reason for designers to live in perpetual crunch mode. If projects are properly designed and a set
of good design documents is created, you should know exactly what you need to do up front and
should be able to detail out a proper schedule. If you fail to design, you're failing to plan, and you
know what can happen there.

You'll face many unknown questions when designing a game. Even with a formal design process,
you might not be able to answer them. Get help early! Turn to other members of the team or outside
resources to solve as many problems as you can.

Can You Over-Design?

There comes a point in every paper design in which the answers will just be unknown. If you design
too much of the game before it is playable, you run the risk of designing so many features early on
that aren't fun, and then you end up spending time implementing features and losing the soul of your
game. It is very important to strike a balance between documentation and implementation. Some
games beg for a completed design early. Adventure games and other very linear games are examples
of games that have simple play mechanics but complex interactions between them.

One thing you will learn is that you usually can't just design a game from start to finish. This begs the
question of whether you can over-design. I can say that it's important to design a game as much as
possible, but a lot has to do with when you design.

Do Not Distribute without permission. 14


@2003 Troy Dunniway – All Rights Reserved.

Think of designing a game as a military operation. You don't want to just gather all your troops
together, cram them in a plane, and tell them to attack. Although this does happen a lot and is
sometimes necessary to win the war, it's not the safest thing to do. This is especially true if your
troops are green. A good military operation requires proper training, practice, intelligence, and
preparation before execution.

The military can do some practice before a battle, but until it knows exactly what the terrain and the
opposition are like, it's impossible to plan the specifics of the battle. Game design is similar: You
have to design a lot of general things early, which means making broad design strokes. Then when
you learn what kind of war you're getting into, you will know more about how to refine your ideas
and what tactics you will need to employee to crush your enemy. At this point, you might have the
vision of the game pinned down and can start getting ready to go into battle. When you find out
where exactly the battle will take place, you can practice it in other words, you can build the
prototype before committing to battle. While drilling for the final battle, however, you might find out
that a different plan is better than the initial one you created. This might require a totally different or
even slightly different battle plan before attacking. Attacking the enemy or committing to the battle is
the point at which you move into full production in the game.

Although this analogy might seem strange, it shows you that no matter how well you plan or how
much you design, you still need to test things, try new things, look for problems, and evaluate the
game design before committing to it. A bad game design will result in you losing the war or getting
the project canceled. However, sometimes victory is bittersweet at the end of the war or project if
there are too many casualties along the way. A poorly run or designed project might get out the door,
but that doesn't mean that everyone will be happy at the end, when the game doesn't sell and
everyone on the project is burned out and quits from frustration. You have to find a balance in your
game designs. Designing too little or too much can both lead to problems.

Every game has some level of design documentation; the question is how much is right for you and
this project. As a general rule of thumb, I expect that when laying out my design over the course of
months, I will write a minimum of 100 pages. However, if you find your document hitting 500 pages,
it's probably time to seriously re-evaluate what you're doing and the state your project is in. This
doesn't mean that always writing 500 pages is bad, but if you've written 500 pages of design and still
haven't started creating the game, you are probably in for trouble. If a lot of what you're writing is
back story, character development, and other details that will help serve as a guideline for the game,
maybe you're just working on a very grand and epic storyline within an RPG.

Because there is no hard-and-fast rule, it's just good to get into the habit of occasionally evaluating
your design for the content that it holds. As soon as you find yourself writing text because you feel
like you need to add more pages to the document, stop! It's time to figure out what information is
relevant and what is just filler.

An Overview of the Design Process

So now that you understand that's it's important to have a good design process, you should first be
sure you understand the entire game-development and design process. I want to take the development
cycle we’ve been talking about and expand on it some more. This expansion fits well into the front-
end development cycle I’ve been talking about, and helps refine it even further.

Do Not Distribute without permission. 15


@2003 Troy Dunniway – All Rights Reserved.

This elaboration of the development cycle may not be helpful for everyone on the team, but as a
designer I think it is critical. As you read more of the article and begin to understand the big picture
of game development, you will hopefully start to understand why this refined process is helpful.

I’ve talked a little bit about how scheduling is so important to game designers. This is actually a fairly
controversial subject, since creative people hate to work on a schedule and would prefer to just do it
the best that they can, no longer how long it takes. Publishers are often the ones to establish the
Milestones and deliverables for a project. Most publishers don’t usually request design deliverables
early on however, and leave this area very vague. It is very important that a designer stay on track
and on time, since more often than not, any changes and slow downs the designer encounters will be
amplified out to the entire team and project.

This more refined design and development process was the first step for me in trying to define what
needs to be delivered and at what point in the project for the designers. Later on in the article we will
get more heavily into how to more accurately and realistically schedule the design. For now just keep
in mind that there are some reasons why this breakdown will be helpful to you.

I've identified 10 main stages of the game-design process for this article. These stages fit into the
different phases of the overall game-development process. Because there can be different stages to a
game design, and because stages are often repeated, it is important to separate the different stages and
phases of the game design for this discussion. Keep in mind that there are key deliverables which will
need to be created for each of these stages, which I’ll go over in a bit. Not every project will need to
create every one of these documents or deliverables however.

I find it best that when you’re trying to establish a development process, that you create a set of
standards so high that it’s almost impossible to reach them all. I’ve seen process documents from
large companies that were meant to make everyone happy. In order for them to make a process
document that outlined a process which was acceptable for every kind of game out there, they
basically had to say “Do it however you want”. It’s impossible to create a process which will work on
all games and at all companies. My goal is to always set a bar that is really high, define documents
that may never need to be written, and to breakdown the process in as much detail as possible so that
I have a goal to strive for. I would much rather have someone say that this document is unnecessary
for their project for these reasons, than have someone never create the document because they never
even realized that they should have created it. Some people will say that this approach is excessive,
but if it gets you to think about the game development process and what really needs to go into it,
then I have succeeded.

This breakdown is the best way for you to start thinking about the game development cycle as you’re
getting into it, but this isn’t necessarily a formalized breakdown which the entire industry uses or
goes by.

Figure 4C. The Phases of Game Design

Phase 1: Concept

Stage 1: Concept

Phase 2: Preproduction

Do Not Distribute without permission. 16


@2003 Troy Dunniway – All Rights Reserved.

Stage 2: Vision

Stage 3: Definition

Stage 4: Creation

Phase 3: Prototype

Stage 5: Play

Stage 6: Refinement

Phase 4: Production

Stage 7: Expansion

Stage 8: Completion

Stage 9: Balance

Phase 5: Post-production

Stage 10: Conclusion

Of course, the Stage are similar to the Phases of the game-development process because they take
place within the Phases. However, because they make up important substages of the overall design
process, it's important to discuss them separately. Typically, each of the game-design phases is also a
key milestone, with a specific design item that must be delivered.

This is an important point to understand. These phases aren't just random or arbitrary; they are
designed so that you create your game in the right order and at the right time. Later in the article, I
talk more about what it means to formalize your design and why you need to do it. These phases
directly speak to this. You need to realize that each of these phases must be tied to a schedule and that
you must hold to this schedule as much as possible. These phases also take into account that
designing games is a creative process, so even if this seems rigid, you should hopefully understand at
the end that this phase schedule is actually a very creative and flexible process.

Some phases include starting or finishing a major document, completing a series of smaller
documents, and completing a proof of concept. I’ll briefly talk about all of the various documents you
may need to create at these stages here, and then later on throughout the article I will talk in more
depth about how to develop all of them. The design process is organized in layers, with each layer
building on the one before it. As you'll see, creating a game is a bit like baking a cake.

Proposal Phase

Do Not Distribute without permission. 17


@2003 Troy Dunniway – All Rights Reserved.

The Proposal Phase of the project is the most informal phase of the project, when the initial ideas are
coalescing into a game idea. Concepts are created, examined, and then thrown out. This is the stage in
which all the seedlings of a game first take tentative root. At some point, the ideas become strong
enough to write down and detail them. During this stage, a basic concept or "pitch" is created. Think
of a pitch as a short summary of your game that you can use to get someone interested in your game
idea.

Concept Stage
Similar to the first stage of the game-development process, the initial phase of the design process is
all about ideas. This phase doesn't have a great deal of formal process to it, but instead it requires a
lot of brainstorming. The main point of the concept phase is to sift through a lot of ideas in search of
a central "tentpole" concept that will become the basis of your game. To keep beating the cake
analogy to death, this is equivalent to perusing the recipe article and picking your main ingredients.
You might not know what kind of frosting or filling you want, but you had better figure out what
kind of batter you're going to use.

Pitch Doc

The pitch doc is often one of the first documents you formally write. This doesn’t mean that it is the
first thing you write, but once you have a good idea of what you want to make, you can start to create
this document. This doc is more of a marketing or hype-doc as I call them. It’s meant to give people a
high level view of your game idea, get them excited about it, and then ultimately fund or approve the
next stage of the project. This document is often a short one or two pages. Keep it simple, and make it
sound fantastic.

Concept Document

The concept doc is the first pass of the design document. It is where you start to write down your key
concepts of the game. This document is for the design team to gain a better understanding of what the
game is all about. It focuses on core gameplay, mechanics and what makes the game fun.

Pre-Production Phase

During this stage, the pitch is developed more thoroughly into a set of documents that describe the
game in enough detail to create a prototype. This means that you are confident enough about your
ideas that you can describe them in terms that enable programmers and artists to build a prototype
and be fairly confident that it will work. The preproduction phase is often the shortest phase of the
design process for many developers because there are always a million reasons why it is important to
build the game now. This is usually the wrong approach to creating a good game, so I encourage you
to fight for an adequate preproduction stage to allow you to properly design your game. The bulk of
the game design should be done during this stage because good preproduction should lay a
foundation that will make the rest of the project much, much smoother. By the end of the
preproduction stage, you need to know exactly what you are going to build in your prototype.

Vision Stage

Do Not Distribute without permission. 18


@2003 Troy Dunniway – All Rights Reserved.

In the vision phase, ideas are first put down on paper. You've picked out your main ingredient; now
you have to create a recipe. Here's where your vision gets tested: Is there enough of a central concept
to attract other great ideas, or is your idea of a role-playing game set in downtown Manhattan at rush
hour just not cutting it? Throughout this phase, you will find yourself throwing out ideas and starting
over many times. Eventually, concepts will start falling into place and you will actually write down a
few recipes, asking people what they think of each one and what might make the cake taste better. I
cover creating the vision for the game and the corresponding documents and steps involved in part
10, "Creating the Vision."

Vision Statement

The vision statement is a tool that helps the entire team keep one central focus throughout the life of
the project. A good vision statement will help the team clearly understand what it is that you are
making, help focus the team members on a common problem, build cohesion among team members,
and make it easier to make decisions about the project. A good vision statement helps clarify and
prioritize the goals of the project.

Essence Statement

A proper essence statement should tell anyone who is unfamiliar with your product exactly what it is
in a very short period of time. This statement should include your vision and goals for the product.

Definition Stage

During the second phase of the design process, most of the important details of the game are figured
out, including the core concepts, game play, and general mechanics for the game. During this phase,
you need to get your recipe down on paper and make it as complete as you canand that's not so easy
when you can't actually taste-test anything yet. During the definition phase, you work on developing
the creative vision of the game, which I cover in Article 10, "Creating the Vision."

Creative Spec

The Creative Spec is the document where we start to get to the bare-bones of the game concept. This
will be a working test model for the game. It may be redeveloped time and time again, but the
Creative Spec. is the vision that will keep the game focused on its Essence Statement.

Proof Stage

During the Proof stage of the project, it is time to show that your ideas will work. A lot of times this
work is done by someone in marketing, but as a designer you need to help. This is the point where
you need to thoroughly analyze the market and show why your game will succeed.

Competitive Analysis Doc

Doing research on your competition can take a lot of forms. You can analyze sales numbers, market
trends, feature sets, reviews and a host of different information. Creating this document helps you
thoroughly understand the competition.

Do Not Distribute without permission. 19


@2003 Troy Dunniway – All Rights Reserved.

Proof of Concept Phase

The proof of concept phase (POC) is the point where you’re ready to prove and show that your game
idea is solid. This often includes building a partially working version. In the front end development
model, this is the point where you iterate your game design several times if necessary, until you know
if it is going to be fun and compelling to play. In the past, we’ve traditionally called this the prototype
phase, but recently we have found that a “pre-prototype” phase is extremely helpful in refining ideas
earlier on. A lot of projects get thrown from prototype into full production very quickly, so the more
time you have to iterate early on the better.

Creation Stage

The creation stage is the point where you’re ready to dive in and start writing the main design
document for the game. So, now you’re ready to buy the ingredients for your project. This stage is
where you take all the ideas you’ve created up until now and coalesce them into a nice cohesive
design document which a game could be created with. This recipe has all the ingredients (characters,
mechanics, storylines, and so on) described in detail. In Phase 2, you know the ingredients of your
recipe, but you're not sure of the quantities of each one or how long they need to be cooked. In fact,
to really make your cake, you're going to have to bake a few and adjust the recipe accordingly.
During the creation phase, you must create the design for the game's prototype, which I cover in
detail in Article 11, "Designing the Prototype."

Prototype Design Document

Any information that needs to be implemented in the prototype must be thoroughly defined now, so
that the programmers and artists can actually start building the prototype.

Technical Design Document

There are two kinds of technical design documents. The first pass I like to do myself, working with
the lead programmer on the project. Not every designer is technical enough to write this document.
This document is meant to give the programmers an idea, often in non-technical terms, what the
different systems of the game will function like.

Prototype Phase

The preproduction stage and the prototype stage are often combined. I like to separate them, though,
because, without proper preproduction, it is very difficult to know what aspects of the game to
actually implement. Skipping over preproduction is like building a house without plans. During the
prototype stage, you build the first playable version of the game, including all the primary features
and as many high-risk design elements that you can implement technically. The higher the risk is, the
earlier features need to be tested. Because most of this work is being done by other people on the
development team, a designer should spend his time during the prototype phase fleshing out the
remainder of the design as much as possible.

At the end of the prototype stage, there needs to be time to test and iterate the prototype. I often add a
short sixth stage (Stage 3b) between Stages 3 and 4. When you are happy with the design of the
prototype, you need to bring the design documents into alignment with any changes that you had to
make during the prototyping stage. Spending an extra month or so here can help a lot. The rest of the

Do Not Distribute without permission. 20


@2003 Troy Dunniway – All Rights Reserved.

team can spend time bring any code that was hacked to make the prototype up to full production
standards, and the rest of the team can begin hiring and ramping up for full production.

Play Stage
This is the point at which you bake your first little muffins, most of which will taste either
undercooked or overcooked. Your carefully constructed design document has now been interpreted
by engineers and artists to build a prototype. The game must be up and running to see how it plays.
Now the ingredients get adjusted: Did you think that a drunken half-elf was a good idea? Whoops,
controlling a drunkard is just not that much fun, scratch one gin-soaked main character. By
continuing to bake muffin after muffin and adjusting the recipe, the batter improves quickly. This
way, in case your terrific recipe produces shoe leather[nd]flavored muffins, you can fix it before
ruining the whole cake. During this phase, you begin to flesh out the details of the game, which I
cover in Article 12, "The Design Bible."

Feature Analysis

Any features that are implemented in the game need to be evaluated. This short document is a way
for me to basically analyze the game one last time before we move into full production. This is the
last point where changes can be made in the design without some kind of potential impact on the
project or loss of work. I like to identify all of the key features, make sure they are all necessary, and
fun. This is also a good point to possibly run a focus group or usability test which will let you more
formally analyze your features.

Refinement Stage
This is the phase during which you put all the final pieces together and flesh out the various design
documents. It's time to butter the pan, make last-minute adjustments to the batter, set your timer, and
preheat the oven. During this phase, you bring all your documentation into alignment with your final
findings of the prototype design.

Design Spec

The design spec is the final design document. You take the prototype design document and begin to
flush out all of the features. Every feature in the game should now be built into the document.

Design Bible

The design bible is the place I store everything in the game. This includes reference material, and
anything not appropriate to put into the design spec. This can serve as a reference to other people as
they work on different aspects of the product. Also, by putting stuff into the design bible, instead of
the design document which only a few people will need, it can help keep the design document more
focused and simpler.

Story Bible

The Story bible is where all the details of the story are kept. Many games often have a super complex
story that includes many details which are unimportant to anyone but the lead designer and a few
others. I often detail out parts of the universe or world which aren’t really necessary, but may play an
important role to a sequel or for some consistency reason which I feel I need to understand. Don’t

Do Not Distribute without permission. 21


@2003 Troy Dunniway – All Rights Reserved.

bore your whole team with all the details of the story in the main design document, but make sure
they get enough of it so that they understand it.

AI Spec

The AI for the game needs to be designed. Similar to the technical design document, this is a task for
a designer and a programmer. The programmers need to understand how the AI needs to work. AI in
games is still rarely done well, and I think some of this has to do with the fact that designers rarely
get heavily involved with defining the AI, and just end up using what the programmers create.

Production Phase

When you reach the production stage, you should know exactly what game you are going to build
(although this rarely happens!). This is the longest part of the development process. The bulk of the
actual work laying out and testing the game play is done during this phase, and this is the stage in
which all the final aspects of the design are fleshed out. All of the final code and art is created during
this stage.

Expansion Stage

In the expansion phase, a variety of other documents and secondary design tasks can be tackled,
depending on the type of game you are creating. It's now time to start baking the cake. During this
phase, you finish the last details of the design, finish creating the final design spec, and begin heavily
testing the game for good game play. I cover most of these issues in Article 14, "Additional Issues
and Elements"; Article 15, "Usability"; and Article 16, "The Design Spec."

Level Design Doc

The level design doc is the place where all of the levels are detailed out. This can include concept art,
level layouts and other supporting material. It also isn’t necessary to put all of this information into
the main design spec, since not everyone needs to know every detail about each level. This document
should include information on how the levels are going to be built, the geography and architecture or
layout of the level, the story and events of the level, locations of enemies, NPC’s and anything else
that is in the world. There are a lot of details you usually need to know about a level before you run
off and build it.

Complete Stage

In this phase, you completely wrap up every aspect of the design and lock it down. It's now time to
trim the edges of the cake and spread the frosting. Any remaining issues are now finalized. I cover
the last few issues in Article 17, "Finishing the Design."

Balance Stage

In this phase, your main goal is to make sure that the game is fun to play, while not being too hard or
too easy. Now that the cake is fully baked, trimmed, and frosted, you need to put the candles on it to
make sure that it's perfect. You shouldn't actually be creating any documents anymore, but you
should be working to make the game fun and trying to get it out the door.

Post Production Phase

Do Not Distribute without permission. 22


@2003 Troy Dunniway – All Rights Reserved.

This is the final stage of the project that occurs when the game can be played end to end and is
"content complete." During this stage, the game is tested for bugs and polished for release. By now,
the designer's role is mostly over. Some projects might require a bit of play balancing or last-minute
tweaking, but hopefully you have moved on to the next project by now.

Polish Stage

This stage is the point of the project where you are usually code complete or finished with the game.
What is important now is that you balance the game and find any bugs in it. Designers are usually
involved with determining if design bugs should be fixed, making sure all the units in the game are
properly balanced and that the game is playable from start to finish without ever stopping the player,
stumping the player, or ruining the play experience. This is also where the pacing of the game can be
adjusted.

Conclusion Stage

In the final phase, an analysis and postmortem of the project should be completed so that you can
move on to the next project, having learned some lessons. It's time to serve up the cake and see who
comes back for seconds (or who gets sick to their stomach!). Do the people you work for ask for the
recipe?

These 10 phases of the design process are important to understand. This is the concept about which
most of this article is built around. Understanding the theory of how to create games is important, but
understanding how to actually create the games is often more important. Designing games is an
organic process, and understanding the different stages and phases of the design process and how
they relate is very important. It's not good to just sit down and design a game without taking the idea
on a journey to help define and refine it properly.

As you read through the rest of this article you will see how everything about game design will
indirectly lead back to this process and you’ll learn that how you make games will become as
important as what you design. You’ll then begin to see how everything fits together, and how the
process of making games relates to all aspects of game design.

Determining When to Design a feature

Hopefully by now the shear immensity of what you have to accomplish as a designer has started to
set in. Hopefully this article will help you better understand the entire process and allow you to go
into game development with your eyes wide open to the realities it poses. If you’re already in the
industry, there is still a good chance that you don’t fully understand the entire process, which this
article I hope will help clarify.

One of the biggest things that separates a good designer from a bad designer, or an experienced
designer from an inexperienced designer is their ability to do the right things at the right times.
Determining when to design a key feature, how detailed to make the design and how much time to
spend designing the feature is truly a difficult task. There is no right or wrong answer to this problem.
Each game will need different things done at different times and in a different order.
Do Not Distribute without permission. 23
@2003 Troy Dunniway – All Rights Reserved.

Since making games is also a creative process, sometimes it is necessary to follow your heart, your
inspirations and your gut instinct. Sometimes you also just need to put ideas down when they come.
If ideas are flowing freely and quickly, sometimes it is good to capture them before you loose them.
However, if you find yourself struggling for ideas and hitting a wall on things you know you really
shouldn’t be, then it is definitely time to move on.

When should you design a feature?

While there is no precise time to design a feature, there are some general rules and guidelines which
you can use. If you follow the design process which I outline throughout this article, you will see that
a lot of it is about designing certain sets of features. This can be important to follow, since it is an
attempt to define which features need to be worked on first.

The biggest thing you need to realize is that you need to have a vision for what you want to make.
This means that you need to understand what it is you want to make. You need to understand what it
is you are making, what makes it special and different. You need to initial think in broad strokes, and
the progressively refine your ideas and concepts into more exact specifics. Be careful to avoid
defining exact specifications early on. If you find yourself figuring out exactly how fast a unit moves,
how strong it is, and details like that in the beginning, this is unnecessary.

I have seen design documents from seasoned developers which were 50-100 pages in length. They
outlined every unit in the game, every detail and number associated with the unit, every piece of
equipment, weapon and such that was found. Every detail of the story was detailed out, the back-
story and every important event was detailed. Yet, they didn’t know what kind of game they were
making, why it was fun, or why people would play it. They didn’t understand or define the interface
or controls for the game, which was a major problem in the kind of game they were trying to make.
In short, they dove right in to the features, without knowing why they were doing what they were
doing.

Overall, you need to figure out what is important to the project and focus on it first. A very story
driven game like an RPG will typically need a lot more story work up front than your typical action
game. Also, just because you are doing a game like a FPS or RTS which is very derivative (similar to
another game) or a sequel doesn’t mean that you can ignore defining what the core of the game is and
how it is going to play.

Spending Your Time Wisely

It’s very easy for a designer to do “research” for a very long time. Early on in the development of a
game it is very easy for us to get wrapped up in checking out the competitors (hey, it’s a good excuse
to play games for awhile, and is necessary). It’s also very easy to just get lost in thought for long
periods of time. When you combine this with everything else which happens at the start of a project,
it can be very easy to not get a lot done for a few months. While this can be nice, it doesn’t help your
schedule.

It’s incredibly difficult to get started on a new project. Ideas have to come from somewhere. We often
need to come up with ideas, which can be very difficult for all of us at certain times. It’s important to
balance out this need, with the need to get the game designed on time or at least in a reasonable time
frame.

Do Not Distribute without permission. 24


@2003 Troy Dunniway – All Rights Reserved.

You must also spend your time wisely during the day. Find ways to make your design process more
efficient. It does nobody any good to be inefficient in what you do. Make sure you look at how you
are designing, the tools you are using, how levels are being built and the steps that you must go
through in order to get the job done properly. It is very easy to work very inefficiently and waste a lot
of your precious time. It is good to always evaluate your methods and see if the time you are
spending is well spent.

Wrapping It All Up

The game development cycle is an incredible complex thing. There are many different ways which
you can make games. While the vast number of possibilities can be thoroughly confusing, there are
really just a few viable paths with a few different variables in each.

An analogy I like to use is that the paths to game development are like a battlefield. There are
actually two parallels here. Each possible path you choose can either lead to victory or defeat. If
you’ve studied military tactics you will see that at first, when you look at the entire battlefield, it
would seem like there is an infinite number of options ands paths. However, you only have a fixed
number of highly specialized resources. So if you look at the battlefield, the resources you have and
the dangers ahead, it becomes apparent that there are usually only one or two paths that will work.
Some paths will work, while others will dead end or get you killed.

The point is, you must study, practice, train, plot and plan if you want to win the war. Once you
understand the battlefield, the correct path to victory will become clear and obvious. The trick is in
making sure you either don’t just jump into battle, and just run into an unknown situation guns
blazing, loose the war by preparing too much or get so confused you never know what to do and you
get killed without even realizing it.

The more you know about the various fields in game development the better off you will be. You are
the General of the battle (well, hopefully at least a Major), and you must be able to know how to use
your troops effectively. A general must understand his: army, airforce, armor, artillery, special forces,
support and all different kinds of specialties. All of these must work together as a team to win. The
better the General can see the big picture, the better he can truly understand exactly what his troops
are capable of, the better he is. Also, If you only know the theory of battle, but never understood the
current health of your troops, weather, enemy positions or morale, you also can’t be an effective
commander. Likewise, a good designer must not just understand basically what the other members of
his team do, but strive to constantly understand the condition in which they are in. This is mostly just
common sense, and part of being a good manager or teammate, but it’s surprising how often it is
really done well. SO, understand your team and the process, and you’ll be off to a running start when
it comes to your next project.

Do Not Distribute without permission. 25

You might also like