@2003 Troy Dunniway – All Rights Reserved.

Finishing the game design

By Troy Dunniway
troy_dunniway@hotmail.com

“Never put off till tomorrow what you can do today.”

- Anonymous.

In the last part of the development process, it’s time to wrap it all up and get it out the
project door. Hopefully you’ve managed to stay on track up until this point. If not, this
time might have to be spent finishing the design spec or other aspects of the design. This
time in the schedule is often a buffer, which is good to add into the design, which will
allow you some time to redesign certain aspects of the game if it is necessary or jus catch
up if you’ve gotten behind. It’s time to also make one last pass through the design and
look for anything you’re missing. It’s also good if you make sure to have the entire
team’s buyoff on the design at this point, so you’ll know what else you’ll need to do. If
everything is on track then the time is best spent starting to balance the game or polishing
the level designs.

The Polish Phase

Budget time at the end of a project to polish the game, bring all elements to a high
production value standard, and add the little touches. The goal of the polish phase is to
take the code and content complete game which is already fun and “polish” it. This may
include adding minor features and content, play balancing for fair game play and proper
difficulty, performance tuning and most importantly fixing any bugs found to make sure
the game is as error free as possible.

Test rigorously to insure balance (where appropriate), to insure there is no single optimal
winning strategy (or unit, or spell, etc.), and to eliminate any potentially fatal gameplay
flaws. When the game reaches the customer, we want them to feel that every aspect of the
game was well planned and executed. Polish tells our customers that we took the time
and made the effort to craft an extraordinary product.

Polishing a game increases customer satisfaction, enhances the reputation of the

developer and publisher, and builds fan loyalty. Lack of polish has a negative effect in all
of these areas, working against the goals of everyone involved in development. There is
no acceptable excuse for not polishing a game. If you cannot afford to polish, you are in
the wrong business or your team was inadequate (too small or unskilled). Nearly done is
not an acceptable standard for going gold.

Final Play tests

As a designer, during the polish phase, it’s your job to make sure that all of your design
ideas were correct. No matter how well we plot and plan, we just often have to guess on
some things. Make sure that you validate your ideas, test them, make sure people like

Do Not Distribute without permission. 1

 @2003 Troy Dunniway – All Rights Reserved.

them, make sure the game is fun, make sure the game is easy to use and play and above
all else is fun.

One of the most difficult things to do as a designer is admit that you were wrong. Even if
you’ve conducted play tests throughout the game development process, you will not until
now have had all of the pieces in place and fully working together, so it’s time to do one
final test to make sure that everything in the game works correctly, is properly balanced
and is actually fun.

Don’t allow your own familiarity with a game cloud your judgment as to what is good
and bad. Don’t think a game is good, that the controls are easy, that the interface is
simple or that the game is really fun. Know that the game is what you think it is, get
others opinions, validate your ideas and make sure that what you are doping is correct.
I’ve seen many many bad design decisions made out of arrogance and ignorance.

The Last of the Design Issues

There are plenty of other issues that plague us as game designers. Some of these issues
are specific to certain genres of games, while others are specific to particular problems
you may face. I wish I had time to cover every possible issue, but there is just too many
of them. Ultimately, you’re just going to have to figure each one out as it comes up.

Some problems may have possible solutions in other articles on the web or in books, but
you’ll probably find that most of the problems we face are seemingly always new and
different from anything we’ve seen before. I guess this is the Murphy’s law of game
design. I wish I could face the same problem twice, since it would make it so much
easier, but I rarely do. This is the main challenge we’ll face as designers – trying to solve
problems that haven’t existed before and have no apparent solution. If it was easy,
everyone would be a designer.

Adjusting the Design

One of the biggest mistakes designer make while in production is thinking they’re
finished. It doesn’t matter if you’ve created a design which is two pages or 2000 pages,
but if you don’t keep up on the reality of the design in relation to the schedule,
implemented features and all that, you’re going to be in trouble. As a designer, you create
the design spec to tell everyone what to design. In a perfect world, it would all be done on
time and to your exact specification. This never happens.

In reality, things never go as planned. If you’re not constantly aware of what the state and
reality of the project are and constantly making adjustments, you can get yourself into a
very bad position. What often happens is that certain aspects of the technology get
delayed, are unable to be completed, and can’t be done to spec or just fall behind. Art can
occasionally also have the problem as certain features you’re relying on just can’t be
done, or the team falls behind and can’t deliver what was expected. Many people tend to
put these features on the back burner, saving them for later and tell the designer they’ll
try and get them in. The designer then bides his time, hoping the feature will come in at
the last minute and save the game. Unfortunately, that feature should have just been cut.
This also happens with cut features however, and that features begin to get cut and the

Do Not Distribute without permission. 2

 @2003 Troy Dunniway – All Rights Reserved.

designer just figures they’ll adapt. In the end, you end up in an impossible situation, with
features you were counting on and not having them, but the project is now totally behind
schedule and you have to move in to reactionary design.

What needs to happen is that you should constantly be aware of what features aren’t
going to be finished. As these features are cut, you should begin to implement backup
plans. Did I say Backup plans? Yes, it helps to have a backup plan, but if you don’t have
one, since it’s impossible to plan for everything, then you need to adjust all aspects of the
design which are affected by the change. If you wait until the very end to figure out how
to get away with not having the feature, it’s probably too late. You also need to be aware,
and especially make sure the programmers are aware, of key features which are necessary
for the game to work correctly. You need to make sure that key features don’t get cut
from the game, just because it was a bit hard to do and somebody didn’t think it was
important. So the best advice is to keep limber, and realize that even your completed
design spec will change.

Change can come from other places as well. As the game begins to reach a more
completed stage, it may enter testing. This may come from formal focus group testing, or
from informal play tests. Either way, people may begin to suggest changes. If these
changes are deemed important, it’s important to begin figuring out how to do them now
and not later.

So no matter what the source or cause for change is, just be aware that it can occur and
make sure you’re ready for it to happen. The best designed game can be ruined if half the
features are never implemented and you’re unable to build your vision. There is nothing
worse than trying to redesign the game at the last minute, once the technology is
completed, because you didn’t know or care that there was a problem.

Controlling Feature Creep

Change can also come from you. This is the hardest thing to curb. Is the change being
made because you thought of something else which would be cool, or because it’s
necessary to make the game fun.

Feature creep is usually something which happens at the end of a project, and refers to
last minute design changes which happen late in a project. One of the hardest things to do
is say no. We could all probably work on a game forever and never feel it was perfect. It
always boils down to making it as good as possible in the time we have. Unfortunately,
we always want more. We always no more at the end of a project about the game, than at
the beginning. So we start finding new things which are now possible, which we never
thought was possible, getting new ideas or need to make changes to make it better.
Feature creep is probably one of the biggest reason most game projects are late. We can’t
control problems with the technology, at or other things in the game, but we can try and
control feature creep. A good designer will know when to say if a feature is worth doing.
Many features seem really minor, and may only take a few hours or a day to do, the
problem is you’ll find yourself saying yes to a lot of those and still running late. Every
feature, no matter how small must be weighed by the impact it will have on the design,
with the impact it will have on the schedule and budget. Occasionally we’ll be fortunate

Do Not Distribute without permission. 3

 @2003 Troy Dunniway – All Rights Reserved.

enough to work on a project which can be finished when it’s done, but until that time, it’s
important to try and understand that early in a project it’s alright to add and change
features. You just need to understand that later in the project, each change you make can
have huge consequences.

There is no science to determine what features to not add and which are critical to add.
As a designer, you need to evaluate what each feature means to the design. The first
question you need to ask is “what will happen if we don’t have the feature?”. If the game
will be considered unplayable without the feature, then you need to seriously consider
implementing it. If the feature is just kinda cool, and doesn’t contribute to the overall
gameplay, then you should probably not do it if it is late in the project, or tag it as a
secondary feature, if it’s early in the project. Basically, all features should have a priority,
and you need to make sure that high priority features are finished and finalized before
you or anyone else start working on secondary features, or the flash.

Localization
Localization is the process in which your game is translated into another language.
Normally this is a fairly easy process which is handled by an outside group. They take
any text in the game, and any audio from the game and translate it for you, as well as
manuals and other printed material. Normally a designer doesn’t need to be involved in
this process at all.

However, sometimes a game requires changes to it in order to make it acceptable for sale
in a foreign country. Sometimes a game requires changes so that it will sell better in a
foreign country. There are a wide variety of reasons why you may need to changes things
in order to make a game better for a foreign country.

A good majority of the major changes that usually occur are between the US and
Japanese markets. The US market will generally accept many of the Japanese games as
they are, but the Japanese market won’t support many of the popular US titles, because
the Japanese have very specific tastes which are very different from those of Americans.
Very few other countries have a big enough market which can demand major localization
changes.

There are a series of problems you need to watch out for while shipping a game to
another country. There are a lot of images, icons, beliefs, and other things to watch out
for. Some cultures, like the Japanese, believe that having four fingers is an insult, so if
your character also does, then you may need to change this. Other cultures believe things
about other personal traits and other things that you need to watch out for, otherwise you
risk insulting them.

The most extreme cases of localization involve redesigning some or all of the artwork for
the game. Some games, like Wild 9, by Shiny Entertainment are an example of a game
which had created a more gritty set of characters for the US version of the game, and then
they redesigned all of the characters for the Japanese version. While this is an extreme
case, in goes to show that the tastes of Americans and other cultures do vary and

Do Not Distribute without permission. 4

 @2003 Troy Dunniway – All Rights Reserved.

sometimes warrant being redone if you wish your game to be highly successful overseas.
I do warn you however, that generally this extreme step is not worth the amount of work.

Different cultures do like different kinds of games. You don’t see American’s necessarily
running out and buying dating simulators and horse racing games, which are popular in
Japan, as you also don’t see the Japanese buying a lot of realtime strategy games and
simulators. Each culture likes different kinds of games. You need to make sure that your
idea for a game would be popular in the country you choose to localize it in.

In the case of some games, like RPG’s, which are popular in both the US and Japan, you
also need to be aware that the style of the genre is very different in both countries.
Compare a game like Final Fantasy, to a game like Baldur’s Gate. Both games are
considered RPG’s, yet both are considerably different. While many games in the same
genre are different, you’ll notice that through sales patterns that the same types of games
are typically always successful in one country or another. A few types of the games are
popular in both places, but just because Final Fantasy is popular in the US doesn’t mean
that Baldur’s Gate would be popular in Japan.

No matter how you design the game, it’s just good to be aware of issues pertaining to
localization. Even if you don’t redesign it entirely or redo anything, you need to know
what in your game is potentially offensive or will be poorly accepted, so that you can
analyze the risk up front and understand whether you should make changes early in your
design or not to accommodate the world.

Fixing Design Bugs

As you move into the later stages of the development process and the testing team begins
to fully test the game, there is potential for conflict between the design team and the
testing team. What is a bug? This is a tough question. There are many kinds of bugs,
some of which are readily identifiable and obvious because the feature doesn’t work,
crashes, or is broke in some way, while other bugs are subjective and based on an
opinion.

You will possibly find a lot of bugs being entered by the testers, which you will contest.
Early on, you need to establish what design bugs are really bugs and what is by design.
The end of the project can become frustrating for a designer, as more people look at the
project and express an opinion. It’s impossible to make everyone happy. I’ve seen a lot of
projects make many last minute changes to the design of the project, in an attempt to
make everyone happy. Unfortunately, this isn’t always possible, and you may end up
ruining the game at the last minute, by making quick reactionary design decisions instead
of well thought out design decisions.

You need to also watch what criteria test sets for fixing bugs. I’ve seen testers get a
vendetta on a certain kind of problem they’re able to reproduce, but one which takes
place throughout the game, but it is so hard to reproduce that they are the only ones
capable of doing it. Then, you spend tons of time trying to fix this problem.

Do Not Distribute without permission. 5

 @2003 Troy Dunniway – All Rights Reserved.

Be aware of problems which happen all over the game and need a global solution, instead
of fixing it in individual places across the game. An example of this might be where you
suddenly find that a really good player is able to jump in the air and around walls. Do you
try and fix every wall in the game, or change the way the player can jump? This is a
tough question. Both solutions have far reaching ramifications. As a designer, you must
make these kinds of decisions. However, you also need to weigh the severity of the
problem. Is the problem so severe that it breaks the game? There are a lot of different
ways to tackle a problem like this, and ultimately there is no right or wrong way, just the
best for your situation.

No matter how you approach bugs and game design, you need to be aware that there is a
lot of potential for conflict between design and test in the resolution of bugs. Laying the
groundwork and guidelines early on will help you a lot. Finding design bugs through
your own testing, team testing and playtests will also go a long way towards helping you
find as many design problems early on as possible and fix them when you still have time
to fix them properly.

Postmortems
Postmortems aren’t only good to read. It’s also good to write a postmortem for your
project, whether your project ships or not, you need to evaluate what went right, what
went wrong, what needs to change, what needs to be improved and what you should do
again.

This document needs to be written by every senior lead of the team. It’s also beneficial to
have the rest of the team write anonymous postmortems, so that you can get a sense of
what others felt the project was like, but without fear of repercussion. Once everyone has
written their reports, a meeting needs to be held and it needs to be discussed. Then a full
report should be written by one of the top people, probably the project producer, and
published out to the entire company.

Whether you share the information with people outside the company, is up to you. I find
it good to try and let others learn from my mistakes. I’d encourage you to write a more
generalized postmortem, that possibly hides some of the dirt and washes some of the
laundry ahead of time, and get it published with Game Developer Magazine,
gamasutra.com or some other website which can distribute it.

No matter what you do, it’s important that you learn from your mistakes. You also need
to make sure that others at your company learn from your mistakes as well. So no matter
what, analyze what you’ve done and see if you can improve your design process, so that
next time you can do it better. Remember that design is a constantly evolving process,
which is constantly changing and adapting to the changing industry.

Do Not Distribute without permission. 6