Game Design Documents

Game Design Documents Page 1
Disclaimer
The Game Design Documents is a collection of articles found on
various sites on the internet. All the content is property of it's authors and no
comercial exploitation is intended.
Disclaimer
Game Design Documents Page
This page is intentionally left blank.
Disclaimer
Game Design Documents Page !
Ta"le of #ontents
Disclaimer.........................................................................................................1
Ta"le of #ontents..............................................................................................!
Pedersen Principles of Game Design and Production.........................................$
Principle 1% &nderstand The 'ole of the Designer and Producer..................$
Principle % (o Designer or Producer )s an )sland........................................*
Principle !% +et Professionals do Their ,o"s.................................................-
Principle .% /)00 1/eep )t 0imple 0tupid2......................................................-
Principle $% 0chedules Are +i3e +a4s..........................................................15
Principle 6% The 7ardstic3% 8ne Day9s Pay for a :ee39s :orth of ;un.........15
Principle *% ) (ever <et a Genre That ) Didn9t +i3e.....................................11
Principle =% >e True to 7our +icense...........................................................11
Principle -% 0hare 7our Toys?......................................................................1
Principle 15% There9s (o <agic ;ormula for 0uccess...................................1!
#reating A Great Design Document.................................................................1$
@o4 the 0ystem :or3s..............................................................................1$
The #hallenge............................................................................................16
Ten Points for a 0uccessful Design Document............................................1*
)n 0um #hec3...........................................................................................
Documentation Guidelines for the Game #oncept and Proposal.....................$
The Purpose of Documentation..................................................................$
The >enefits of Guidelines..........................................................................6
Guidelines for the Game #oncept...............................................................*
#ommon <ista3es......................................................................................!1
Guidelines for the Game Proposal.............................................................!
#ommon <ista3es......................................................................................!-
Documentation Guidelines for the ;unctional and Technical 0pecifications.....1
;unctional vs Technical 0pecifications........................................................1
Guidelines for the ;unctional 0pecification.................................................
#ommon <ista3es......................................................................................$1
Guidelines for the Technical 0pecification..................................................$!
#ommon <ista3es......................................................................................$-
Guidelines for Paper +evel Designs............................................................65
0tep $% Play Test........................................................................................6
Documentation <ilestones and the Development 0chedule......................6!
Dealing 4ith #hange.................................................................................6.
Ta"le of #ontents
Game Design Documents Page .
Artists and Game Design Documents% ;rom )nterpretation to )mplementation
.......................................................................................................................6$
Designers% <any Are AutisticA (ot Artistic..................................................6$
Designs% +oo3ing At the >ig Picture............................................................6$
>lue 03y <eetings......................................................................................66
0pea3 (o4 or ;orever ;eel BictimiCed.......................................................66
#ommunicate Bia )magery.........................................................................6*
Get AheadA Thin3 Ahead............................................................................6*
The Design Document................................................................................6=
Ta"le of #ontents
Game Design Documents Page $
Pedersen Principles of Game Design and
Production
"y 'oger Pedersen
'ecentlyA ) intervie4ed for a num"er of positions 1specifically executive
producerA producer and game designer2 at various game companies.
Throughout each intervie4A many principles learned from my 16D years of
industry experience 4ere recalled. )n 3eeping 4ith my philosophy that game
developers should share and exchange information relevant to our industryA )
present ten principles of game design and production that everyone in the
industry should "e acEuainted 4ith.
Principle 1% &nderstand The 'ole of the Designer
and Producer
)t9s vital to 3no4 4hat lines of responsi"ility are dra4n 4ithin game
development organiCations. This 3no4ledge gives you an understanding of
4hich people are responsi"le for 4hich game componentsA 4ho ma3es design
and production decisionsA and so on.
The game designer. The game designer is the visionaryA some4hat li3e a
"oo39s author. This person has outlined the scope and description of the
product 4ith sufficient detail so that others can understand and develop the
product. ,ust as a "oo3 author sees his creation develop differently 4hen
made into a filmA the game designer needs to accept and solicit modifications
from the team mem"ersA the pu"lisher and the pu"lic during the development
process. 8ften A one of the game designer9s tas3s is to create the proFect >i"le
G the game9s lengthy technical specification. This document details the
gameplayA descri"es characters and settings 1possi"ly including diagrams or
dra4ings2A includes level descriptions and possi"ly maps of areas to exploreA
positions and actions for each character or class of characterA and so on.
The producer. The producer is the proFect9s managerA its champion. The
producer must 3eep the entire team productive and the lines of
communication open. This person is a diplomatA a politicianA a trou"leH
shooterA a force needed to produce the product. The producer must 3eep
mar3etingA advertising and pu"lic relations teams up to date 4ith the
progress of the gameA and honest a"out its featuresA performanceA and other
claims that 4ill "e made to consumers. These teams must understand the
Pedersen Principles of Game Design and Production
gameplayA its features and story line to generate great adsA media hypeA
magaCine previe4sA and so on. )n returnA these nonHtechnical team mem"ersA
"y virtue of their continuous contact 4ith the pu"licA provide the game
developers 4ith feed"ac3 from the pu"licA magaCines and retail channel
a"out 4hat features are currently hot in games.
The producer needs to facilitate communicate "et4een the 4hole teamA
and provide timely support for each developerA 4hich includes ensuring that%
Artists and animators provide art4or3A animationsA temporary
placeholders to the programmers on timeA until the final art4or3 is
availa"le.
Programmers provide the artists 4ith current versions as to see their
art4or3 in a real time gameplay mode. The producer must also ma3e
sure that the programmers provide a current version of the game to
the salesA pu"lic relations and mar3eting teamsA along 4ith various
reports a"out the latest version of the game. These reports descri"e
gameplayA special featuresA hard4are reEuirements and supported
hard4are and peripheralsA screen shots that "est portray the product
for adsA promotional sheetsA previe4s and revie4s for magaCines. The
producer also needs to ma3e sure that programmers 4or3 4ith the
Euality assurance 1IA2 testers and provide them 4ith the play
instructionsA special 3ey com"inationsA hintsA undocumented features
and actions.
Audio and sound engineers provide voiceA "ac3ground and
atmosphere sounds and music. These engineers also need to vie4
and play the current version to chec3 and validate the timingA usage
and clarity of their 4or3.
The designer 1if not a mem"er of the dayHtoHday team2 sees the
current version to confirm that the product is in line 4ith the
technical specifications and design originally set forth.
The IA testers report pro"lems to the producer. The pro"lems must
"e categoriCed as maFor 1crashA function or action not 4or3ing2A minor
1text misspellingA character movement to fast or slo4A response time
feels 4rong2A glitches 1sound or graphic pro"lem2A improvements 1add
a ne4 featureA improve the character9s interaction or "ehaviorA clarify
a confusing aspect of the design or gameplay2A a videogame
standards issue 1the triangle "utton does not perform as the
standard function definition2A and multiHplatform inconsistency 1P#
Game Design Documents Page *
version vs. videogame version2.
:hether one person assumes the role of "oth producer and designerA or
several people handle these tas3sA there must only "e one producer 4hose
4ord is finalA 4hose decisions are follo4ed and 4hose leadership is trusted
and motivating.
Principle % (o Designer or Producer )s an )sland
Gathering information throughout the product development cycle and
3no4ing 4hat to do 4ith it is the trait of a great designer and producer.
Designers should research their su"Fect matter and evaluate outside
suggestions and opinions. The audience demands and expects films and "oo3s
to seem realistic and accurate. The computer and videogame audience should
accept nothing less.
:hen underta3ing the development of a sports game 1e.g.A >ase"all2A a
designer may feel that he 3no4s the sport from playing it as a child and
vie4ing it on TB. @o4everA much more research must "e underta3en to create
an immersive experience for consumers. :hether the game genre is sportsA
'PGA adventure or simulationA the first step is to research similar titles in that
game genre. 7ou can do this "y surfing the )nternetA visiting the local store
and purchasing competitive gamesA reading revie4s of similar genre titlesA
collecting mar3eting materials and advertisements from other pu"lishers9
4e"sitesA and so on. This information is invalua"le 4hen you are designing a
ne4 product.
)f you are the producer of an upcoming "ase"all gameA you ought to
3no4 the common elements found in other >ase"all titlesA as 4ell as special
features that differentiate each product from its competitors. 7ou should read
revie4s of similar titles and the competing titles9 list of features. ;rom this
freely collected informationA a designer can understand 4hich features and
game play customers expectA special features that the competition offersA and
the criteria upon 4hich the revie4ers 4ill "ase their critiEues.
As the designer andJor producerA you must as3 yourself%
Does your game suffer the same poor or a434ard design fla4 as a
previously released title or similar genre titlesK The design of the
game needs to address ho4 to "e "etter than its competitors. The
design must "e a"le to handle fla4sA difficulties and pro"lems that
Game Design Documents Page =
revie4ers and customers have complained a"out in previous versions
of this product or in other similar genre titles. As the decision ma3erA
you must listen to your development teamA your mar3eting and sales
teamA retailersA and your game playing audience.
Do the ideas of the game designer and the team out4eigh those of
the revie4er1s2K The ideas that are made must have a good
foundation. All revie4ers try to accurately explain and criticiCe the
product to the pu"lic. There9s a real difference "et4een discarding a
revie4er9s opinion and listing the pro"lems and ho4 your design
addresses each one.
Does the design consideration include comments from previous or
potential customersK #ustomers enFoy great products. <y experience
1in producing sportsA gam"ling and triviaJpuCCle titles2 indicates that
customers 1fans2 4ill "uy any product in the genre they enFoy. Their
expectations are that your product 4ill teach the something ne4
a"out the activityA they 4ill gain experience and "e a"le to "rag to
their friends and associatesA andJor that they9ll "e a"le to someday
"eat the game. )9ve received a great deal of fan mail in 4hich
consumers have cited the aspects of my games that they enFoyed.
These letters also tell me 4hat additions to the game that they
4ould li3e to see in future releases. <agaCines pu"lish reader9s
letters that praise and criticiCe the products. <ar3et research and
"eta test groups consisting of potential and previous customers can
"e 4orth4hile in the final design stages to t4ea3 the product "efore
its release.
Are the team9s ideas and opinions seriously evaluated in the design of
the productK 0ee Principle L! for more information a"out this.
#an the addition of a feature expand the customer "ase and get more
pu"licityK
)n Billa #respo 0oft4are9s ;lic3sA a product that revie4ed !5A555 filmsA
a field for McloseHcaptionM 4as added during the developmentA instantly
adding four million hearingHimpaired and nonHNnglish spea3ing audiences to
the product9s customer "ase. (e4sletters reaching that consumer sector gave
the product freeA positive revie4s "ecause the product included information
vital to their readership.
The producer should collect information from team mem"ers a"out
improvements that can "e made to the productA and relay this information to
Game Design Documents Page -
the designer. The producer must "e a"le to recogniCe a good idea 4hen he
hears itA and implement that idea in the game to ma3e it a "etter product.
Designers should "e adapta"le and open minded to ideas that can
ma3e their games "etter. Producers need to "e managersA leadersA and
diplomats 4ho can ta3e information and in getting good suggestions
understood "y all involved 4ith the final decisions.
Principle !% +et Professionals do Their ,o"s
<ost proFects have a team of talented professionals 4or3ing on themA
made up of designersA programmersA graphic artistsA audio techniciansA
testersA mar3eting coordinatorsA and so on. Nach of these team mem"ers
"rings their o4n uniEueA important talents to "ear on the proFect. A producer
and designer must rely on these professionals and their particular points of
vie4 to improve and facilitate the development process. 'egardless of the
product9s genreA each mem"er can ma3e a product "etter.
;or instanceA the Euality assurance 1IA2 and testing people can suggest
gameplay improvements "efore the product is shipped. (o mem"er of the
team plays the game for hours at a time li3e a IA person doesA therefore
hisJher suggestions are similar to that of the potential customer. )n factA
mem"ers of the IA team have pro"a"ly played more games in a particular
genre than the rest of the team com"ined.
The producer must not only trust his team mem"ersA "ut also rely on
them for input to create the "est product.
Principle .% /)00 1/eep )t 0imple 0tupid2
Nvery aspect of a product should "e o"vious and easy to understand.
;or instanceA allo4ing players to access every option 4ithin t4o "utton
clic3s may "e simpler than having thirtyHseven uniEue 3eys to press. ;orcing a
player to press AltH#trlH0hift A to get his character to 3ic3 an opponent 4ould
"e ridiculous. +i3e4iseA having to press MAAM M>AM M#M and MDM to control the
movements of a plane in a flight simulator 4ould drive the average player
craCy. )f a player has to repeatedly press four 3eys to perform a tas3A the
game design should include a super 3ey or a oneH3ey macro to simplify the
operation.
/eep design interfaces simple. ) once designed games for an arcade
manufacturerA and the president of this company taught me a valua"le lesson
a"out design. @e said if a player doesn9t grasp the interface of a computer
game or videogameA that player 4ill read the manual since O$5 1or so2 4as
invested in the game. :ith arcade games ho4everA the player has only
invested a Euarter or t4oA so if the game isn9t understanda"leA addictive and
compellingA the player moves on to the next machine. :ho cares a"out
4asting poc3et changeK :hile this is especially critical for arcade gamesA )
thin3 it9s important to remem"er 4hen designing games for any platform.
Principle $% 0chedules Are +i3e +a4s
0chedule are li3e la4sP they are created "y legislative "odies and
meant to "e o"eyedA "ut they are also designed to allo4 exceptions if
evidence 4arrants special circumstances.
+i3e4iseA milestones are created at the "eginning of the proFect may
need to "e changed "ased on pro"lems that occur during development. ;or
instanceA the decision to change the original game specification 1e.g.A to
support a ne4 computerA a ne4 !D cardA alter preHplanned art4or3 or audio
clips2 in order to ma3e a "etter product is a situation 4hich may 4arrant
M"rea3ing the la4M that schedule spells out.
)f another month of development time 4ould greatly improve the
gameplayA remove nonHsho4Hstopping "ugs or allo4 for "etter visuals or
audio effectsA then circumstances Fustify deviating the schedule. To ship a
game on a target dayA monthA or year regardless of the state of the product
at that time can spell disaster for that product 1not too mention the harm it
does to the pu"lisher9s reputation2. <issing seasonal dates li3e #hristmas is
"adA "ut shipping "uggy or a poorly made product is 4orse.
7ou should only modify a proFect schedule if there are valid reasons.
The team and pu"lisher must agree that the additional time 4ill su"stantially
"enefit the product.
Principle 6% The 7ardstic3% 8ne Day9s Pay for a
:ee39s :orth of ;un
)f a customer pays O$5 1plus tax2 for a game that )9ve 4or3ed onA that
amounts to the average person9s one day net pay. 1A person earning O1/ a
year "rings home O1./ 4hich is O$. a day.2 )f the player reports enFoying the
game that ) 4or3ed on for at least one 4ee3A then ) am happy. )f the player
feels ripped off due to poor game designA numerous "ugsA o"stacles in playing
the game 1e.g.A multiH#D s4apsA memoriCing numerous 3eystro3esA and so
on2A poor audioA or some other pro"lemA then the game designer and any
team mem"ers 4ho 3ne4 of these pro"lems "eforehand are to "lame.
Nvery mem"er of the team should "e proud of their product. They
should consider the praise from consumersA revie4ers and the industry as
their re4ard for they time and 4or3 they spent on the game.
Principle *% ) (ever <et a Genre That ) Didn9t +i3e
A student 4ho doesn9t enFoy math can study hard and still earn an MAM
in class. 0imilarlyA a designer or producer does not have to have experience
4or3ing on a particular genre to create a good game 4ithin that genre. )n
factA a designer or producer doesn9t have to even "e an enthusiast of that
genre in order to get good results. Putting together a team in 4hich at least
one mem"er enFoys the genre 1or studying competing products of the genre2 is
4hat is critical.
8ften Fust one enthusiastic team mem"er can sho4 similar games that
heJshe has enFoyedA and there"y turn every team mem"er into a
3no4ledgea"le player of the genre. #om"ining fanatical genre loyalists along
4ith nonHgenre players on the development team can result in "enefits you
may not have considered. ;or instanceA a nonHgenre player can suggest
modifications to a game9s design "y pointing out aspects of the genre he finds
unappealingA 4hereas a fanatic of the genre can lend his expertise and advice
to 3eep a game faithful to the genre.
A 3no4ledgea"le developer or producer may as3 the entire team to
play similar games in that genre and as3 each team mem"er to critiEue the
products. This techniEue can help the development of your productA and it9s
time 4ell spent.
Principle =% >e True to 7our +icense
Games "ased on licensed products often cause players to ma3e certain
assumptions a"out those titles. There are preconceptions a"out the
gameplayA contentA and target audience. )n storesA it9s the licensed titles that
get noticed firstA regardless of their mar3eting and advertising. Game
designers must understand this customer mentality. The designer must
understand everything a"out that license in order to provide the 3ind of
entertainment that the target consumers have anticipated.
;or instanceA a "ase"all game that uses a particular "ase"all team9s
manager in its title suggests a strategy sports game. Players 4ould pro"a"ly
assume that they 4ould "e responsi"le for ma3ing decisions a"out the
players and "atting order. 8n the other handA a licensed product lin3ed to a
professional "ase"all player 4ould suggest an emphasis on sports actionA
such as pitching and "atting.
There9s a reason 4hy licenses cost "ig "uc3s. Designers and producers
must use the licenseA its charactersA and leverage consumer preconceptions to
title9s "enefit.
Principle -% 0hare 7our Toys?
Throughout the yearsA many game developers have "ounced ideas off
meA as3ed me EuestionsA and so on. ) haveA and 4ill al4aysA 4elcome these
inEuiries "ecause ) "elieve it9s for the greater good of the industry. 0ince ) have
al4ays "een interested in creating and exploring ideasA ) feel that 4hen
someone 4ants informationA )9ll gladly help. Three occasions in particular are
4orth relating%
)n 1-=$A an auto mechanic 4ho o4ned an Atari $50T called me and
to pic3 my "rain a"out game design and various game proFects he
4as 4or3ing on. ;or several months 4e tal3edA and often he sent me
samples of his art4or3 as 4ell as demos of the concepts 4e9d
discuss. 0ometime around 1-=*A he had an intervie4 4ith a maFor
pu"lisher and discussed ta3ing the demos and art4or3 4ith him. )
encouraged him and 4ish him success. A fe4 4ee3s laterA he
announced that he 4as hired as Mplatform levelM designer. :ithin
monthsA he "ecame the top Mplatform levelM game designer for this
companyA and he 4or3ed on the most 4ellH3no4n titles in the
industry. @e eventually left this pu"lisher to Foin another eEually
large pu"lisher as the head of game design. @e appeared in several
magaCines displaying his platform level designs. To this dayA )9ve
never met him and have only seen him in the magaCine articles that
he sent meA "ut ) feel very happy that ) 4as a small influence in his
life and in the industry.
:hen ) 4as 4or3ing on All Dogs Go To @eavenA a game for the P#
and Amiga "ased on the Don >luth filmA ) met a young man 4ho
4or3ed at an arcade. 8n several occasionsA ) gave him O15 in to3ens
Game Design Documents Page 1!
to sho4 me the latest video games. As he playedA ) o"served him and
as3ed Euestions li3eA M@o4 did you 3no4 to do thatKM. After 4e got to
3no4 each other "etterA he sho4ed me several comic "oo3 s3etches
that he had dra4nA 4hich 4ere great. :hen ) 4as contracted to
produce and develop All Dogs Go To @eavenA ) as3ed him to do all the
art4or3. 0ince he 4as ne4 to computer graphics and animationA )
taught him the mechanics of using a 0ummagraphics Ta"let and the
functions and features of various graphics pac3ages. @e learned
Euic3ly and produced some of the finest art4or3 that #GA and NGA
4ould allo4. After the release of this titleA he 4ent to 4or3 for a
;lorida pu"lisher as a computer and videogame graphic artist. :hen
the company moved to #aliforniaA he moved 4ith them. The last )
heardA he 4as moving on into one of the "ig pu"lishers as a senior
graphics person.
A high school student sent me a concept for a game sho4. The
description read 4ellA "ut the demo he sent me 4as terri"le. 8ver
several months on the phoneA 4e fixed many of the game9s rules and
aspects of the gameplay 4hich greatly improve the game sho4. )
programmed the gameA and hired an artist to provide the graphics.
:hen ) 4ent to Billa #respo 0oft4are outside of #hicagoA 4e
pu"lished this game sho4A 4hich 4e called #om"ination +oc3. The
game 4as fun to play and it 4as the first product to feature onH
screen players of all races. The high school student and ) shared in
the profits for several years.
The reason that ) relate these stories is that ) 4ant to emphasiCe the
"enefit to those 4ho help "udding game developers. :hen the opportunity to
help someone comes 3noc3ing on the doorA offer that person hospitality and
3indness. The results 4ill "enefit the Msee3er of 3no4ledgeAM 4ill honor you
Mthe masterMA and 4ill "enefit the industry as more creative thin3ers Foin in.
Principle 15% There9s (o <agic ;ormula for
0uccess.
/eep in mind that no one individual or company of any siCe has
discovered the formula for M4hat ma3es a successful product.M +i3e filmA art
and musicA games appeal to a variety of consumer tastesA and of course taste
is su"Fective.
0ome developers of past hits have credited their success to the
Game Design Documents Page 1.
underlying technology that their game used. 8ther developers claim that their
game transported the player into a surreal and immersive universe. 7et others
feel that their game9s success 4as due to the 4ay it engrossed the player in a
realistic simulationA challenged them 4ith its compelling design A or simply
made a great game accidentally. >ehind each successful title is a uniEue list
of traits that made it popular 4ith consumers.
The "ottom line is simple. A 4ellHdesigned product "ased on a team
effort 4ith an userHfriendly interface developed 4ithin a reasona"le time
frame 4ill "e successful.
Game Design Documents Page 1$
#reating A Great Design Document
"y TCvi ;reeman
)'ve got to get product out. )n the panic and diCCinessA my head
smashes against the #'T and next thing ) 3no4 this genie 4hiffs up out of a
virtual "ronCeHtextureHmapped lamp and offers me three 4ishes. :ithout
missing a "eatA ) ans4erA M) need...
A great team of talentedA s3illedA and dedicated engineers and artists
1including a very understanding 4ife2 4ith strong interpersonal s3ills.
Nnough time and money to allo4 for a messHup or t4o.
A first class design document.
8nce upon a timeA 4hen coding a game involved one programmer 1and
may"e an artist2 4ith a ta3eHitHasHyouHgo "udget and a loose deadlineA
documentation didn't need to "e ta3en so seriously. 7ou 3ne4 4hat you
4anted to ma3e and you made it. )f there 4ere a fe4 maFor changes along
the 4ayA the only one to complain 4as you. (o4adaysA a thorough and
reada"le document can mean the difference "et4een a s4ift descent to
"udgetless @ell and a smooth ride to shrin3edH4rapped (irvana.
@o4 the 0ystem :or3s
<ost games go through three development stagesA from concept to
design to production. Thin3 of them as MflashAM MpaperAM and Mgrind.M
)n the first stageA the concept paper acts "oth as a letter to yourself H
setting out your goals clearly so you 4on't lose sight of them H and as a sales
tool for 4homever ta3es the product to mar3et do4n the road. 0ometimesA
this stage involves a 4or3ing miniHprototype as 4ellA 4hich gives you a
chance to experiment and revise your ideas.
The intermediate stage of design involves a lot of discussions 4ith
artistsA animatorsA musiciansA and engineers H trying things outA and finding
4ays to organiCe and set do4n your ideas.
)n the final stageA production management is often left up to some
expert in moving trains and trac3s 4ithout maFor collisions. The original
designer may "e an integral part of the teamA "ut in many cases H especially
in large companies H the designer ends up as a 3ind of outside consultant.
:ithout EuestionA the design document is 4here the original parent of
the proFect exercises the most influence on ho4 this little "a"y is going to
gro4 up. Nven if youA the designerA have decided to dou"le as proFect managerA
don't delude yourself into thin3ing that you hold all the reins. A complex
proFect involves many talented people. 03illed programmers and artists tend
to have minds of their o4n. :hile you intend to create a horseA the artist may
"e envisioning a unicorn and the programmer a highly efficient camel. A good
document ensures that you are all planning to ma3e the same thing. A great
document ensures you all have the same feel for the inner soul of this thing.
Thin3 of it as a "ig "and FaCC score H it puts every"ody's mind in the same
placeA even 4hen there's still plenty of room for the stars to improvise.
7our document is a sort of intermediary "et4een your mind and the
real 4orld. )t ensures that 4hat you have in mind is something that the real
4orld is a"le to handleA and that 4hat you end up 4ith 4ill "e 4hat you
originally had in mind.
;inallyA remem"er the adage to 4hich any salty gamer 4ill attest%
MGreat art is in the details.M >rilliant details flo4 naturally from the general
gestalt as though they 4ere present in that first flash of inspiration. >ut once
you get into the handsHon implementationA it's easy to lose that spar3.
The #hallenge
Prototyping parts of the proFect yourself is definitely a good idea H
ma3e 4hatever rough s3etches you can. >ut againA it's those details that
count. The more details your imagination can holdA the greater a masterpiece
your 4or3 4ill "e.
:or3ing from a document has a flip sideA as 4ell. Developing an
exciting game has to "e exciting. 0ome of the "est parts of many proFects
4ere discovered in the heat of lastHminute deadline panic. TrueA the pressures
of time and cost "udgeting don't allo4 for perpetual reiteration of conceptA
"ut you simply cannot expect a 3iller game to come out of dryA predicta"le
4or3. The challenge is to create a design document that 4ill allo4 your
proFect to tolerate surprise adaptations 4ithout losing the integrity of its
original direction and scope.
Game Design Documents Page 1*
#ontents Purpose
1. #oncept
Paper
GenreP target audienceP
descriptionP most
compelling featuresP mar3et
informationP cost and time
to develop.
)t defines the conceptA scopeA
4orthiness and feasi"ilityP
sells the idea to your clientA
pu"lisherA employerA and
venture capitalist.
. Design
Document
Description of the "ody and
soul of the entire proFectA
4ith all the detailsA and the
method "y 4hich each
element 4ill "e
implemented.
)t ensures that 4hat is
produced is 4hat you 4ant to
produce.
!. Production
Documents
TimeHmanagement charts
1GanttA PN'TA and so on2P
tas3 data"aseP "udget
spreadsheetP technical
specificationsP IJA
data"ase.
)t implements the design
document on time and 4ithin
"udget.
Ten Points for a 0uccessful Design Document
1. Descri"e (ot ,ust the >odyA >ut the 0oul
)f game development 4as Fust an automated inputJoutput issue H
something li3e 4riting code and "eing a"le to predict ho4 it's going to 4or3 H
you could get "y 4ith a dryA descriptive document. The reality is that
development is done "y peopleA many of them creative peopleA 4ho have their
o4n mindsP most 4ill 4ant to leave a stamp of that mind on everything they
do.
)t 4or3s li3e this% 7ou provide specs to the artists and discuss 4ith them
4hat to do. 7ou then visit the programmers and go over their specs. >oth
groups nod to everything you say.
That nightA around A<A Fust as the constellation of #DD is rising in the
4estA the programmer reaches a midHlife crisis and "egins to thin3A M:hatA a
gee3 programmer the rest of my lifeK )s this 4hat my mother expected from
meK :hyA ) can design a game Fust as 4ell as any"ody else?M And the hands
3eep typing code.
Game Design Documents Page 1=
Around the same timeA the artist has Fust 4o3en up "efore his machineA
having fallen into a deep stupor 4hile 4aiting for a complex !D rendering to
finish. &nsure and not really caring 4hether he's dreaming or is actually
getting paid for all thisA immersed in that 4ild 4orld of artistic genius 4here
fantasy and reality "lend as oneA the phosphors come together in 4ays
previously unimagined H certainly not "y you.
>y the next morningA your horse has "ecome a unicorn 4ith t4o
humps. :ith creative peopleA instructing is not good enough. 7ou need to
inspire.
)n your design documentA don't satisfy yourself 4ith a detailed
description of every article and nuance. Ta3e time to descri"e the feel that the
game should haveA the purpose "ehind each elementA the experience each
user 4ill haveA and any other aspects of the game's soul you can envision and
descri"e.
;or exampleA say you're designing a shooter. 7ou 4ant to train your
players to deal 4ith certain challenges "efore they actually meet themA so
you place less lethal miniHchallenges a fe4 steps in advance. 7ou're going to
have to explain that to every"ody on the development teamA so they'll
understand 4hy certain things are 4here they are and 4hy they 4or3 the 4ay
they do. That 4ayA even if 1read% 4hen2 your team toys 4ith and mangles your
ideas as they exist on paperA you can still har"or hopes that the outcome 4ill
have the same or similar overall effect. 8r may"e even "etter.
. <a3e )t 'eada"le
Go aheadA provide your people 4ith full pages of 15HpointA sans serifA
=5HcharactersHperHline textA and demand that they read it. 7ou may 4ant to
"undle Advil in the pac3age H for those 4ho actually ta3e the pains to o"ey
orders.
) try to follo4 at least some of the guidelines of good page layout%
Plenty of 4hite space
0erif font for "ody text
>old headers
0paces "et4een paragraphs
0hort lines of text
Game Design Documents Page 1-
Direct the eye to4ards important material
<any instances call for a ta"leA spreadsheetA or chart. &se them and
ma3e them sensi"ly attractive.
!. PrioritiCe
(o4 that you realiCe that you're 4or3ing 4ith other conscious egosA
you'll appreciate the urgency of tagging certain game elements as sacred.
TrueA there are no guaranteesA "ut if you use the tag sparsely enoughA it may
get some respect. >ut don't stop there. As long as you're tagging ideasA you'll
also 4ant to distinguish "et4een things that you intend to do and things that
you'd li3e to do if timeA "udgetA s3ill setsA and technicalities permit.
Then there's the trash "in H things that sounded greatA "ut 4ere
trashed for good reason. 'efer to them explicitly and explain the reason that
they 4ere trashed. )f you don'tA ) can almost guarantee that they 4ill "e
resurrected. @ere's your list of tags%
)ndispensa"le
)mportant
)f Possi"le
'eFected
7ou may 4ish to use visual sym"ols to represent these. Don't rely on
colorA since documents aren't al4ays printed in color.
.. Get )nto the Details
A document 4ithout details is useless. Generalities can "e interpreted
"y any"ody in any 4ay that they li3e. MThou 0halt (ot /illM meant one thing to
<oses and another to a 0panish conEuistador. Detailing 4hom you shouldn't
3ill and under 4hich circumstances 4ould have "een more helpful. The same
holds true for your document% 8nce you've descri"ed some practical details
and given some examplesA your idea "ecomes more concrete H and harder to
shove around.
;or exampleA don't Fust sayA M>ronCe "ird is invinci"le.M Descri"e exactly
4hat happens to this creature in each possi"le instance of its "eing hitA and
ho4 it recovers after4ard. TrueA if the animator has any spun3 and artistic
dignityA you can rest assured that he 4on't follo4 your specifications. >ut at
least he'll have a clear idea of 4hat you 4ant to achieveA and his
modifications 4on't seriously alter the related portions of the game.
Don't Fust sayA MAt this pointA users 4ill have to press the Fump 3ey 4ith
the arro4 3ey to clim" the 4all.M Descri"e 4hat 4ill happen if a player tries
anything else. Nxplain 4hy you thin3 users 4ill "e a"le to figure out the
com"ination that you've provided. Nxplain 4hat a"out the environment
suggests that it's possi"le to clim" this 4all.
AgainA your artist 4ill come up 4ith something elseA perhaps
something even more suita"le than 4hat you originally conceived. That's real
success% :hen your developers' results come out even closer to your original
flash of conception than 4hat you 4ere a"le to descri"e on paper. >ut this
4on't happen unless you first lucidly descri"e your concept.
Don't Fust sayA M>ongo <an is stronger than >ongo >oyA "ut >oy has
faster reflexes.M &se ta"lesA spreadsheetsA and charts to assign real values to
the character's speed of movementA ho4 many hits the character can ta3eA
ho4 much damage the character's hits doA ho4 many cels it ta3es to animate
a hitA and so on. This sort of spreadsheet is invalua"le in the IJA and
t4ea3ing stages of production.
Don't Fust sayA M<ost people 4ill figure out the 4hole game in a fe4
days.M <a3e a chart of predicted product life in different householdsA indicating
at 4hich points in time you expect various features to "e discovered. &ser
testing 4ill later provide valua"le feed"ac3 for designing your next game.
$. 0ome Things <ust >e Demonstrated
0ometimes a fe4 rough s3etches are enoughA "ut if the idea is truly
important to your concept of the proFectA you may 4ant to ma3e a rough
animation yourself. :hen "ehaviors of elements "ecome too complex and
am"iguous to descri"e on paperA you'll 4ant to ma3e a prototype. A side
"enefit of prototyping is that this practice often leads to a simplerA more
elegant solution.
Nven 4hen you provide animations and prototypesA put the concept in
4ords as 4ell. TrueA an animation is 4orth a giga"yte of 4ordsA "ut 4ords
can communicate in 4ays that animations can't. :ords also clearly spell out
the vital nuances that may "e missed 4hen 4atching the animation.
6. (ot ,ust :hat >ut @o4
)n the real 4orldA the Mho4M determines the M4hat.M ;or exampleA
suppose you've opted for claymation. :or3 out the process of ho4 the images
4ill "e captured and document everything. :hat material and 4hat color
should the "ac3drop "eK :hat camera should "e used and 4hyK :hat are the
steps for processing the captured framesK And on and on. )f you've tried itA
you'll 3no4 that any one of these factors can have a serious impact on the
end result.
8r suppose you're 4or3ing on a motorcycle racing game. 7ou state that
the motor"i3es must "e "alanced "y their differing pros and cons. 7ou even
provide a chart that sho4s ho4 "alanced they are. Then you state that
t4ea3ing 4ill "e necessary. 0tate ho4 you plan to t4ea3 H 4hat is the
processK 0uppose the main character in your game is the Phantom of the
8pera. Descri"e ho4 the player's 3ey"oard is mapped as a pipe organ. Provide
a map of each 3ey. 0pecify ho4 many channels of sound 4ill "e availa"le.
Tal3 it over 4ith your programmer and 4or3 out every detail of ho4. Then
document it. T4o different Mho4sM can mean t4o very different results.
*. Provide Alternatives
ProFect managers spend a lot of time 4ith their Gantts and PN'Ts.
PersonallyA ) can't really say that this stuff is effective for game development H
principally "ecause there are Fust so many un3no4a"les. The more radical
and pioneering your game technologyA the less predicta"le the development
stream is going to "e. The "est thing you can do to ensure that your team
reaches your milestones on schedule is to provide more than one 4ay of doing
things.
+ets go "ac3 to the 3ey"oard as pipe organ example. 7our engineer
descri"es to you the ultimate method of getting a4esome and fun3y results
4ith tremendous po4er and depth to the user H at a cost of a"out $5 personH
hours to implement. As 4ith everything else 4e've discussedA you document
the 4hole thing.
7ou can't stop there. 7ou've got to as3A M:hat 4ould it ta3e if 4e Fust
4anted a trimmedHdo4nA eightHchannel pipeHorganK And 4hat 4ill 4e need
to achieve the "are minimumK And 4hat if 4e Fust had some assistant doing
thisKM And then you document all that as 4ell. :hen the ;edNx truc3 is on its
4ay over for the final daily pic3upA you'll "e a"le to save your s3in 4ith a
Game Design Documents Page
simpleA M8/A do Plan #.M
8ne of the "iggest mista3es )'ve made in product design is as3ing
engineersA M#an it "e doneKM &nless you're as3ing a firstHclass programmerA the
Euestion is useless. <ore specificallyA responses fall into one of three
categories%
+ousy programmer% M0ureA that's no pro"lem.M
<ediocre programmer% M(ope. #an't "e done.M
;irstHclass programmer% M) could do it li3e this and it'll ta3e t4o
4ee3s. 8r ) could ma3e a slight modification li3e this and it'll ta3e five
hours.M
Al4ays as3 for more than one alternative and an estimate of ho4 long
each 4ill ta3e. Then indicate your preference H do this is if 4e have timeA or
this if 4e don't.
=. Give )t +ife
)'ve already 4arned you against strangling the inspiration and
spontaneous creativity that comes 4ith the excitement and fun of seeing
ideas "ecome living o"Fects in your hands. 7ou've got to allo4 your document
to tolerate change H "y you or "y 1hopefully intelligent2 others.
) first learned this lesson as a music composition maFor at the
&niversity of >ritish #olum"ia. :ith much toilA ) had 4ritten a neoHrenaissance
"rass Euintet of 4hich ) 4as Euite proud. <y professor li3ed itA too. :hen 4e
"rought it to the college's star "rass Euintet for rehearsalA ho4everA ) passed
through several stages of horrorA dis"eliefA indignationA and clinical depression
4ithin ten seconds. The Euintet "egan to playA then stopped on signal from
the tu"a player. The fello4 too3 out his pencil and "egan to change a fe4
notesA and then everyone continued. )t happened more than once.
<y professorA noting my sudden faint state of healthA turned to me and
commentedA MDon't 4orryA they did that to <oCart as 4ell. And they're usually
right.M
The fact isA no matter ho4 good something loo3s on paperA the greatest
expert still modifies things 4hen it enters the concrete 4orld of o"Fective
perception. (everthelessA you don't 4ant to 4itness the ruthless rape of your
design and dreams. 'atherA you're hoping for a 3ind of organic gro4th H ideas
gro4ing naturally out of the seeds you've planted 4ithout needing foreign
lim"s and "odies grafted onto them.
@ere are some tips for creating a document that can tolerate change
4ithout corrupting the original idea or sa"otaging the development process%
<a3e certain to engrave in stone those aspects that are so essential
to the game concept that they must not "e changed.
<a3e certain every"ody understands the feel that the game is
supposed to have and the purpose of each of its details.
)f information is repeatedA it must "e crossHreferenced. 8ther4iseA if
there are changesA you can end up 4ith contradictory instructions.
And here are some tips for the actual implementation stage%
:hen a change is suggestedA chec3 "ac3 in your design document and
see if it is in concordance 4ith the MsoulM of your game.
#hec3 4hether this is Fust an isolated changeA or it's of maFor glo"al
ecological impact 1see MThe Ncology of )mprovementM2. )f it's the latterA
save it for your next proFect.
&pdate the design document and include the reasons for the change.
8r if you didn't ma3e the changeA say so and explain 4hy it 4as
reFected.
#hangesA deletionsA and reFected ideas should "e retained in a master
document to avoid discussing the same thing t4ice.
Nveryone must "e 4or3ing from the same version. Past versions
should "e destroyed.
#rucialA BitalA and &rgent% The design document must "e maintained
under one person's supervision only.
-. (o"ody 0hould >e A"le to 0ayA ) Did )t That :ay
>ecause ) #ouldn' t ;ind Any 'eference to )t )n the
Document
)'ve seen documents that didn't even have the pages num"ered. And
then they complain that people didn't follo4 instructions. Nvery good 4ord
processor 4ill autoHnum"er pages and print the date and title in the header
or footer of every page. 0ome 4ill even allo4 you to change the header at
ne4 chapters. &se "old text to direct attention to important material. 'epeat
yourself in different parts of the document as much as you li3eA as long as
you crossHreference so you can update everything together as 4ell. <a3e a
thorough Ta"le of #ontents.
7ou may 4ish to 4rite your document using @T<+ and provide hot
lin3s. 0ome progressive 4ord processors provide hot lin3 capa"ilities 4ithout
@T<+. >ut remem"er that more often than notA people prefer to 4or3 from a
hard copy. 1That 4ay there's something to read 4hile re"ooting after the
hourly system crash.2
15. Deliver )t )n Good #ondition
After all thisA you need to do 4hatever you can to facilitate everyone
actually reading and using the thing. A pile of papers doesn't get read H it
doesn't loo3 important enough. 8nly things 4ith hard covers loo3 important.
#reate a list of everyone 4ho is supposed to have a copy. /eep the list.
Print out the 4hole thing 4ith the date in the header of each page. @ave
holes made and put it in "inders. +a"el the spine and cover of each "inder.
:hen there are updatesA provide everyone 4ith the revised pages. At some
pointsA you may need to provide ne4 "oo3s and thro4 out the old ones.
)n 0um #hec3
<ovie ma3ers use move scripts. Architects use "lueprints. <usicians use
a score. According to ancient hearsay evidenceA even the #osmic #reator
created a design document H 4hich @e later let a fe4 prophets ta3e a pee3 at
H "efore the primal M+et there "e light?M 0o game developersA follo4ing their
0upernal 'ole <odelA can certainly do the same. Do it right and it's smooth
sailing the rest of the 4ay.
Documentation Guidelines for the Game
#oncept and Proposal
"y Tim 'yan
The purpose of design documentation is to express the vision for the
gameA descri"e the contentsA and present a plan for implementation. A design
document is a "i"le from 4hich the producer preaches the goalA through
4hich the designers champion their ideasA and from 4hich the artists and
programmers get their instructions and express their expertise. &nfortunatelyA
design documents are sometimes ignored or fall short of their purposeA failing
the producersA designersA artistsA or programmers in one 4ay or another. This
article 4ill help you ma3e sure that your design document meets the needs of
the proFect and the team. )t presents guidelines for creating the various parts
of a design document. These guidelines 4ill also serve to instill procedures in
your development proFect for ensuring the timely completion of a Euality
game.
The intended audience is persons charged 4ith 4riting or revie4ing
design documentation 4ho are not ne4 to game development "ut may "e
4riting documents for the first time or are loo3ing to improve them.
Design documents come in stages that follo4 the steps in the
development process. )n this first of a t4oHpart series of articlesA )'ll descri"e
the purpose of documentation and the "enefits of guidelines and provide
documentation guidelines for the first t4o steps in the process H 4riting a
concept document and su"mitting a game proposal. )n the next partA )'ll
provide guidelines for the functional specificationA technical specification and
level designs.
The Purpose of Documentation
)n "road termsA the purpose of documentation is to communicate the
vision in sufficient detail to implement it. )t removes the a434ardness of
programmersA designers and artists coming to the producers and designers
and as3ing 4hat they should "e doing. )t 3eeps them from programming or
animating in a "oxA 4ith no 3no4ledge of ho4 or if their 4or3 is applica"le or
integrates 4ith the 4or3 of others. Thus it reduces 4asted efforts and
confusion.
Documentation Guidelines for the Game #oncept and Proposal
Documentation means different things to different mem"ers of the
team. To a producerA it's a "i"le from 4hich he should preach. )f the producer
doesn't "less the design documents or ma3e his team read themA then they
are next to 4orthless. To a designer they are a 4ay of fleshing out the
producer's vision and providing specific details on ho4 the game 4ill function.
The lead designer is the principle author of all the documentation 4ith the
exception of the technical specificationA 4hich is 4ritten "y the senior
programmer or technical director. To a programmer and artistA they are
instructions for implementationP yet also a 4ay to express their expertise in
formaliCing the design and list of art and coding tas3s. Design documentation
should "e a team effortA "ecause almost everyone on the team plays games
and can ma3e great contri"utions to the design.
Documentation does not remove the need for design meetings or
electronic discussions. Getting people into a room or similarly getting
everyone's opinion on an idea or a plan "efore it's fully documented is often a
faster 4ay of reaching a consensus on 4hat's right for the game. Design
documents merely express the consensusA flesh out the ideasA and eliminate
the vagueness. They themselves are discussion pieces. Though they strive to
cement ideas and plansA they are not carved in stone. >y commenting on
them and editing themA people can exchange ideas more clearly.
The >enefits of Guidelines
Adhering to specific guidelines 4ill strongly "enefit all of your proFects.
They eliminate the hypeA increase clarityA ensure that certain procedures are
follo4edA and ma3e it easier to draft schedules and test plans.
Nlimination of @ype
Guidelines eliminate hype "y forcing the designers to define the
su"stantial elements of the game and scale "ac3 their etherealA farHreaching
pipe dreams to something doa"le.
#larity and #ertainty
Guidelines promote clarity and certainty in the design process. They
create uniformityA ma3ing documents easier to read. They also ma3e
documents easier to 4riteA as the 4riters 3no4 4hat's expected of them.
Guidelines ensure that certain processes or procedures are follo4ed in
the development of the documentation H processes such as mar3et researchA
a technical evaluationA and a deep and thorough exploration and
dissemination of the vision.
Nase of Drafting 0chedules and Test Plans
Design documents that follo4 specific guidelines are easy to translate
to tas3s on a schedule. The document lists the art and sound reEuirements for
the artists and composers. )t "rea3s up the story into distinct levels for the
level designers and lists game o"Fects that reEuire data entry and scripting. )t
identifies the distinct program areas and procedures for the programmers.
+astlyA it identifies game elementsA featuresA and functions that the Euality
assurance team should add to its test plan.
Barying from the Guidelines
The uniEueness of your proFect may dictate that you a"andon certain
guidelines and strictly adhere to others. A porting proFect is often a noH
"rainer and may not reEuire any documentation "eyond a technical
specification if no changes to the design are involved. 0eEuels 1such as :ing
#ommander ))A )))A and so on2 and other 3no4n designs 1such as <onopoly or
po3er2 may not reEuire a thorough explanation of the game mechanicsA "ut
may instead refer the readers to the existing games or design documents.
8nly the specifics of the particular implementation need to "e documented.
Guidelines for the Game #oncept
A gameHconcept document expresses the core idea of the game. )t's a
oneH to t4oHpage document that's necessarily "rief and simple in order to
encourage a flo4 of ideas. The target audience for the game concept is all
those to 4hom you 4ant to descri"e your gameA "ut particularly those
responsi"le for advancing the idea to the next step% a formal game proposal.
TypicallyA all concepts are presented to the director of product
development 1or executive producer2 "efore they get outside of the product
development department. The director 4ill determine 4hether or not the idea
has merit and 4ill either toss it or dedicate some resources to developing the
game proposal.
Game Design Documents Page =
The director might li3e the concept "ut still reEuest some changes. @e
or she may toss the concept around among the design staff and producers or
open it up to the 4hole department or company. The concept can "ecome
considera"ly more compelling 4ith the imagination and exu"erance of a 4ide
group of talented people.
A game concept should include the follo4ing features%
)ntroduction
>ac3ground 1optional2
Description
/ey features
Genre
Platform1s2
#oncept art 1optional2
)ntroduction
The introduction to your game concept contains 4hat are pro"a"ly the
most important 4ords in the document H these 4ords 4ill sell the document
to the reader. )n one sentenceA try to descri"e the game in an excited manner.
)nclude the titleA genreA directionA settingA edgeA platformA and any other
meaningful "its of information that cannot 4ait until the next sentence. The
edge is 4hat's going to set this game apart from the other games in the
genre. ;or example%
"Man or Machine is a first-person shooter for the PC that uses the
proven Quake II engine to thrust players into the role of an android space
marine caught up in the epic saga of the interstellar techno-ars of the
thirty-seventh century."
>rea3ing the introduction up into several sentences for the sa3e of
clarity is accepta"le. ,ust 3no4 that the longer your introductionA the more
diluted your vision 4ill seem.
>ac3ground
The "ac3ground section of your game concept simply expands upon
Game Design Documents Page -
other productsA proFectsA licensesA or other properties that may "e mentioned
in the introductionP so it's optional. The "ac3ground section is physically
separated from the introduction so that readers can s3ip it if they already
have the information presented. >ut the "ac3ground section is important for
licensed properties and seEuels and concepts 4ith strong influences from
previously released titles in the same genre. )f you intend to use an existing
set of code or tools or to license a game engineA then descri"e these items
and their success stories here.
Description
)n a fe4 paragraphs or a pageA descri"e the game to the readers as if
they are the players. &se the secondHperson perspective HH Myou.M Try to ma3e
this section an exciting narrative of the player's experience. Nncompass all the
3ey elements that define the core game play "y descri"ing exactly 4hat the
player does and sees. Avoid specifics such as mouseHclic3s and 3eystro3esA
"ut don't "e too vague. 7ou 4ant the readers to "ecome the player's
character. @over your detail level right a"ove the G&) interaction. 7ou 4ould
say something such asA M7ou scan your tactical radar and pic3 up t4o more
"ogies coming up the rearAM instead of M7ou clic3 on your tactical radar "utton
and the 4indo4 pops up revealing t4o "ogies coming up the rear.M The
description section should ma3e the content and entertainment value of the
game o"vious and convincing.
/ey ;eatures
7our game concept's 3ey features section is a "ullet point list of items
that 4ill set this game apart from others and provide goals to 4hich the
su"seEuent documentation and implementation should aspire. )t's a summary
of the features alluded to in the description. These "ullet points are 4hat
4ould appear on the "ac3 of the game "ox or on a sell sheetA "ut include
some supporting details. ;or example%
"!dvanced !rtificial Intelligence "!I#$ Man or Machine ill recreate and
advance the challenging and realistic !I that made %alf-&ife game of the year."
Determining ho4 many features to list is a delicate "alancing act.
+isting only one or t4o 3ey features is a "ad idea if you're doing anything
more complex than a puCCle gameP listing more than a page of features
implies that the proFect 4ould "e a @erculean tas3 and may scare off the
"ean counters. +isting too fe4 features might sell your concept shortP listing
Game Design Documents Page !5
too many 4aters do4n the concepts' strongest features.
/eep in mind that you need not list features that are givenA such as
Mgreat graphicsM and Mcompelling musicAM unless you really thin3 such features
are going to "e far superior to those of the competition. Great graphicsA
compelling musicA and the li3e are the understood goals of every game
proFect. 8n the other handA if the particular flavor of graphics and music
provides your game 4ith an edge in the mar3etA then you should spell that
out.
Genre
)n a fe4 4ordsA define the game genre and flavor. &se existing games'
classifications from magaCines and a4ards as a guide. ;or exampleA you
could choose one of the follo4ing% sportsA realHtime strategyA firstHperson
shooterA puCCleA racing simulationA adventureA roleHplaying gameA flight
simulationA racing shooterA god simulationA strategyA actionHstrategyA turnH
"ased strategyA sideHscrolling shooterA edutainmentA or flight shooter. Then
you can refine your game's niche genre 4ith these or other 4ords for flavor%
modernA ::))A alternate realityA postHapocalypticA futuristicA sciHfiA fantasyA
medievalA ancientA spaceA cy"erpun3A and so on.
Platform1s2
)n a fe4 4ordsA list the target platform1s2. )f you thin3 the game
concept is applica"le to multiple platformsA you should also indicate 4hich
platform is preferred or initial. )f you intend multiplayer support on the
)nternetA indicate that as 4ell.
#oncept Art
A little "it of art helps sell the idea and puts the readers in the right
frame of mind. &se art to convey uniEue or complex ideas. 0creen moc3Hups
go a long 4ay to express your vision. Art for the game concept may "e
"eyond most employees' capa"ilitiesA so reEuiring it 4ould limit the num"er of
su"missionsP thusA it is optional. )f a concept has meritA the art can come later
from a s3illed resource. 8ften art from previous proFects or off of the )nternet
4ill FaCC up a document. ,ust "e careful 4ith any copyrighted material.
#ommon <ista3es
@ere are some common mista3es that developers ma3e in creating a
game concept%
The #oncept )s Totally 8ff >ase or )napplica"le to the
#ompany's #urrent Plans
)f you don't 4ant to 4aste your time 4riting up concepts that get
tossedA find out 4hat the company in Euestion is loo3ing for and 3eep an ear
to the ground for opportunities 4ith 4hich your idea may "e a good fit.
)n Terms of 'esourcesA the Document As3s for the <oon
Try to 3eep your concept 4ithin the realm of possi"ility. /eeping the
"udgets do4n "y suggesting existing tools or properties to reuse is helpful.
+imit your ideas to that 4hich can "e accomplished in a timely fashion and
4ith a reasona"le "udget. +imit experimental technologies to one area. Don't
suggest revolutionary A) as 4ell as a ne4A stateHofHtheHart !D engine. )f you
are "eing solicited to produce the game conceptA find out 4hat the time frame
and "udget expectations are first.
The Document +ac3s #ontent
0imply sayingA M)t's #ommand Q #onEuer meets <ech:arrior 4here you
order your '<echs in tactical com"atAM is insufficient. 7our description has to
explain the actions that the player 4ill perform and ma3e them seem fun. A
good description might readA for exampleA M7ou order your '<ech to fire at
pointH"lan3 range on the exposed right torso of the #lan <ad#at 8mni<ech.M
This 3ind of descriptive content 4ill help mitigate misinterpretations of the
core game play that you envision.
The Game )sn' t ;un
A useful exercise is to "rea3 do4n all of the player ver"s 1such as
shootA commandA runA purchaseA "uildA and loo32 and envision ho4 player
performs each. ThenA for each ver"A as3 yourself if it's fun. Then as3 yourself if
the target mar3et 4ould find it fun. >e o"Fective. )f the action that the player
ta3es isn't funA figure out another action for the player to ta3e that is fun or
drop the ver" entirely.
The GameH#oncept Document Nmploys Poor +anguage and
Grammar
Don't ma3e yourself loo3 li3e an ass or an idiot. #hec3 your grammar
and spelling and avoid fourHletter 4ords and sexual innuendo. 7ou don't
3no4 4ho 4ill ultimately read your document or 4hom you might offend 4ith
some particularly expressive 4ords. Nven the machoA politically incorrectA
culturally insensitiveA slangHusing manager 4ith 4hom you exchange dirty
Fo3es over a "eer at lunchtime can get Euite sensitive 4ith documented
ver"iage.
The Designer Gives &p
Don't give up su"mitting ideas. 7ou never 3no4 4hen one of them 4ill
ta3e off. Persistence pays offA "elieve me.
Guidelines for the Game Proposal
A game proposal is a formal proFect proposal used to secure funding
and resources for a game development proFect. As a game proposal ta3es
time 1and thereforeA money2 to do correctlyA it should only "e developed for
promising game concepts.
The proposal is an expansion upon the game concept. :riting a
proposal may involve gathering feed"ac3 and information from other
departmentsA especially the mar3eting department 1if it exists2. 7ou may need
your mar3eting department to perform some mar3et research and analysis on
the concept. )f the game reEuires licensingA you may need your finance and
legal departments to investigate the availa"ility and costs involved in
securing the license.
The programming staffA typically senior programmers or the technical
directorA should perform an initial technical evaluation of the concept. They
should comment on the technical feasi"ility of the concept and the
programming areas that may reEuire research. They should assess the ris3s
and maFor tas3s in the proFect and suggest solutions and alternatives. They
should give a rough estimate as to the reEuired research and development
time and resources.
Game Design Documents Page !!
The game proposal should include a revised version of the game
concept. TechnicalA mar3etingA and finance feed"ac3 to the concept document
might force you to scale "ac3 the concept. )t might also suggest modifying or
adding features. These changes should not ta3e anyone "y surpriseA as this is
the first time that the concept has "een su"Fected to maFor criticism and the
colla"orative process. Giving copies of the feed"ac3 and analysis to the
director of development 1or 4hoever as3ed for the game proposal2 "efore they
are folded into the game proposal or effect changes in the concept is a good
idea. This process not only provides 4ritten confirmation that the concept has
"een revie4ed "y certain people or departmentsA "ut it arms the director 4ith
the 3no4ledge to vetoA alterA or other4ise approve any proposed changes.
The game proposal includes the follo4ing features%
'evised game concept 1preceding2
<ar3et analysis
Technical analysis
+egal analysis 1if applica"le2
#ost and revenue proFections
Art
<ar3et Analysis
The mar3eting department andJor a mar3et research firmA assuming
your company can afford itA should compile this information. )f you are
compiling this information yourselfA you should try to avoid pure guesses on
num"ers. +oo3 for info on the )nternet 1444.gamestats.com is a good source2
and use existing hits in the same genre as indicators for mar3et performance.
Target mar3et% The target mar3et is defined "y the genre and the
platformA issues that have "een already addressed in the concept
document. 7ou can Eualify this definition "y mentioning specific titles
that epitomiCe this mar3et. The most successful of these titles 4ill
indicate the via"ility and siCe of the mar3et. Also mention the typical
age rangeA genderA and any other 3ey characteristics. )f this game
involves a licensed property or is a seEuelA descri"e the existing
mar3et.
Top performers% +ist the top performers in the mar3et. Nxpress their
Game Design Documents Page !.
sales num"ers in terms of unitsA "rea3ing out any nota"le dataHdis3
num"ers and any successful seEuels. )nclude their ship date. 7ou can
"e vague HH I1 1--= or spring 1--=. This research can go 4ay "ac3A
so present your data in chronological order.
+ist their platforms if they vary from the platform for the proposed
game. @o4everA "ecause the mar3ets change depending on the
platformA you should al4ays present some title of the same genre on
the target platformA even if it didn't perform as 4ell as the others.
0uch data may indicate a sluggishness for that particular genre of
games on the platform. ;or exampleA turnH"ased strategy games
may have great sales on the P# platformA "ut have terri"le num"ers
on the 0ony Play0tation. This list of top performers should indicate
this discrepancy if you're doing a turnH"ased strategy game.
;eature comparison% >rea3 do4n the selling features of these top
performers. #ompare and contrast them to the 3ey features descri"ed
in the concept document. Try to provide some specifics. ;or example%
Tactical #om"at% )n #ommand Q #onEuerA Dar3 'eignA and <ythA you
order your units to attac3 specific targets and move to specific places
or ranges for an advantage. <ost units have a uniEue strength and
4ea3ness that "ecome apparent during playA thus encouraging you to
develop superior tactics. Tan3tics has a 4ider variety of orders to
allo4 you to apply superior tacticsA such as captureA ramA and hitH
andHrun. &nit position and target selection "ecome even more
important due to terrainA movementA and range "onusesP firing arcsP
and soft spots in rearH and sideHhit locations. All of the units have
distinct 4eaponryA armorA and speed to differentiate their strengths
and 4ea3nesses and encourage tactics. (ot only do you learn to
master these tactics over timeA "ut you can also script these tactics
into custom orders.
Technical Analysis
The technical analysis should "e 4ritten "y a seasoned programmerA
prefera"ly the technical director or a lead programmerA and then edited and
compiled into the proposal. 'evie4ers of this proposal 4ill use this technical
analysis to help them ma3e their decisions. >e honestP it 4ill save you a lot of
grief in the end. 8verallA this analysis should ma3e the revie4ers optimistic
a"out the game's chance of succeeding.
Game Design Documents Page !$
Nxperimental features% )dentify the features in the design that seem
experimental in natureA such as untried or unproven technologiesA
techniEuesA perspectivesA or other uniEue ideas. Do not include
features that have "een proven "y existing gamesA even if they are
ne4 to the development team. ;or exampleA if the team has never
developed a !D engineA don't list it as experimental. 'atherA list it in
one or more of the other categories in the technical analysis section.
8n the other handA if your development team is 4or3ing on a !D
engine using the theoretical system of EuadsA then this effort should
"e listed as experimental. 8f courseA "y the time you read this articleA
Euads could "e in common use.
)nclude an estimate of the time that it 4ill ta3e to "ring the
experimental feature to an evaluation stateA as 4ell as an overall
time estimate for completing the feature. Nxperimental areas
generally need more time in the scheduleA so the more experimental
features you listA the longer the schedule 4ill "e. :hile some
companies shy a4ay from such 1=H to .Hmonth proFectsA many see
these experiments as 4orth4hile investments in creating leadingH
edge titles. 0o tell it li3e it isA "ut don't forget to tell them 4hat they
4ill get out of it. <a3e them feel comforta"le that the experiments
4ill 4or3 out 4ell.
<aFor development tas3s% )n a paragraph or a fe4 "ullet pointsA
ma3e clear the maFor development tas3s. &se language that nonH
technical people can understand. <aFor means months of
development. Give a time estimate that assumes that you have all of
the resources that you'll need to accomplish the tas3. 7ou could also
give an estimate of the resources that you'll need. ;or example%
"!rtificial Intelligence 'cript Parser$ Three to four months ith to
programmers. The parser reads and compiles the !I scripts into
loer-level logic and instructions that are e(ecuted at run-time."
'is3s% +ist any technical ris3s. )f you don't foresee any technical ris3sA
"y all means say so. 'is3s are any aspect of research and
development that 4ill cause a maFor set "ac3 14ee3s or months2 if
they fail. +ist technologies thatA though they've "een proven to 4or3
"y competitorsA your company has never developed or 4ith 4hich
your company has little experience. +istA for exampleA realHtime
strategy if your team has never developed a realHtime strategy game
"eforeP or !D rendering if this is your first foray into !D. +ist any of the
maFor development tas3s mentioned previously if you perceive any
ris3. All untried offHtheHshelf solutions 1!D enginesA editorsA code
li"raries and AP)sA driversA and so on2 should "e listed as ris3s
"ecause they may end up not fulfilling your particular needs. Any
development done "y an outside contractor should also "e listedA as
that's al4ays a "ig ris3. :hen assessing ris3sA you should also
indicate the li3ely impact that fixing or replacing the technology 4ill
have on the schedule. )ndicate the time in 4ee3s or months that the
ship date 4ill slip. +ist the time impact on specific resources. +ist any
ne4 resources 1peopleA soft4areA hard4areA and so on2 that 4ould "e
reEuired to fix it. This section may seem pessimisticA "ut it creates a
comfort level for your document's revie4ers H they 4ill come a4ay
4ith the impression that the game implementation is under controlA
especially if they can perceive these ris3s themselves. Plus you'll have
the opportunity to sayA M7ou can't say ) didn't 4arn you.M
Alternatives 1if any2% Alternatives are suggestions for 4or3ing around
some of these experimental or ris3y features and maFor development
tas3s. >y presenting alternativesA you give the revie4ers options and
let them ma3e the choices. +ist anything that might cost more money
or time than desired "ut might have "etter resultsA or vice versa 1it
may cost less money and time "ut it may have less desira"le results2.
:hatever you doA "e sure to spell out the pros and cons.
Nstimated resources% +ist the estimated resources% employeesA
contractorsA soft4areA hard4areA and so on. &se genericA industryH
standard titles for people outside of the company% for instanceA the
pu"lisher or investor 4ho might read your document. +ist their time
estimates in 4or3 months or 4ee3s. )gnore actual costs 1dollars2A as
that comes later.
Nstimated 0chedule% The schedule is an overall duration of the
development cycle follo4ed "y milestone estimatesA starting 4ith the
earliest possi"le start dateA then alphaA "etaA and gold master.
+egal Analysis
)f this game involves copyrightsA trademar3sA licensing agreementsA or
other contracts that could incur some feesA litigation costsA ac3no4ledgmentsA
or restrictionsA then list them here. Don't "other mentioning the necessity of
copyrighting the game's title or logoA as these are par for the course and li3ely
Game Design Documents Page !*
to change any4ay.
#ost and 'evenue ProFections
The cost and revenue proFections can "e done in conFunction 4ith the
finance and purchasing departments. This data should give the reader a
rough estimate of resource costs "ased on the technical analysis's estimated
resources.
'esource cost% 'esource cost is "ased on the estimated resources
4ithin the technical analysis. Nmployee costs should "e "ased on
salaries and overheadA 4hich the finance or payroll department
should provide. 7ou can list these as average "y title or level. Any
hard4are or soft4are that you purchase should "e listed as 4ellA
even if it 4ill ultimately "e shared "y other proFects or folded into the
overhead "udget. &se a ta"le or em"edded spreadsheet as it is easier
to read and edit. ;or example%
Nmployee #ost Per <onth :or3 <onths Total
D Artists O.A555 !$ O1.5A555
+ead Artist *A555 1. -=A555
+evel Designers !A555 !$ 15$A555
Total% !.!A555
@ard4areJ0oft4are Price Ity. Total
Graphics :or3stations
1P))) $55<@CJ$6<>J-G>JBoodoo2
O.A55 ! O1A655
!D 0tudio <ax Nxtended 0ite +icense !A555 1 !A555
Total% 1$A655
Additional costs 1if any2% This section is an assessment of additional
costs incurred from licensingA contractingA outHsource testingA and so
on.
0uggested 'etail Price 10'P2% 7ou should recommend a target retail
price "efore your game goes in the "argain "in H pray that it does
Game Design Documents Page !=
not. The price should "e "ased on the price of existing games and an
assessment of the overall value "eing "uilt into the product and the
money "eing spent to develop and manufacture it. 8f courseA your
distri"utors 4ill li3ely push for a lo4er stic3er price or 4or3 some
deals to use your game in a promotion that 4ill cut the price even
furtherA "ut that 4ill all "e ironed out later. /eep in mind that the
higher the stic3er priceA the lo4er your salesA especially in a
competitive genre 4here there's not as much demand as supply.
'evenue proFection% The revenue proFection should sho4 pessimisticA
expectedA and optimistic sales figures using the costs that you've
already outlined and the suggested retail price. 8ther factorsA such
as mar3eting dollars and company overheadA should "e left out of
the picture as these are su"Fect to changeP if a minimum mar3eting
"udget is 3no4nA ho4everA then you should certainly factor it in.
8ften the revenue proFection is "est represented 4ith a pie chart or a
"ar chart. >e sure to indicate 4ith an additional 4edge or "ar the
costs incurred from any of the ris3s descri"ed in the technical
evaluation and sho4 totals 4ith and 4ithout the ris3 assessment.
Art
)f your game concept did not include any artA then the game proposal
certainly should. The art should "e created "y s3illed artists. Dispose of or
replace any of the art in the concept document that 4as not created "y the
artists. The art 4ill set the tone for the game. Assume that the readers may
only loo3 at the art to evaluate the proposalA so "e sure that it expresses the
feel and purpose of the game. )nclude a num"er of characterA unitA "uildingA
and 4eapon s3etchesA in "oth color and "lac3 and 4hite. Action shots are
great. )nclude a G&) moc3Hup if your game is a coc3pit simulation. >e sure to
have good cover art. Paste some of the art into the pages of the documentsA
as it helps get your points across and ma3es the documents loo3 impressive.
Presentation
The 4hole proposalA including the revised concept documentA should "e
printed on sturdy stoc3 and "ound in a fancy report "inder along 4ith copies
of the art. This document is to "e presented to "usiness people H you 3no4A
those people 4ho 4al3 around your office 4earing fine suits to contrast 4ith
the tHshirts and cutHoffs that you normally 4ear. Don't forget that you're
Game Design Documents Page !-
proposing a maFor investmentA so ma3e the proposal loo3 good and dress
4ell if you're going to handle the presentation. Preparing a slide sho4 in a
program such as <icrosoft Persuasion is helpful for pitching your 3ey points
and art.
#ommon <ista3es
0ome common mista3es in preparing a game proposal include%
The Analysis )s >ased 8n <agic (um"ers
Try to "ac3 up your num"ers "y listing your sources or explaining ho4
you came up 4ith them. :atching a producer pull some num"ers from thin
air and thro4 them in the document is almost laugha"le.
The Proposal )s >oring
This is a selling document. Don't "ore the readers. Give them factsA "ut
ma3e these facts excitingA conciseA and convincing.
The Proposal ;ails to Anticipate #ommonH0ense )ssues and
#oncerns
7ou should find out 4hat this proposal is up against HH other
proposalsA competitive productsA financing concernsA cost and time
expectationsA game preFudicesA and historical mishaps. 7our proposal 4ill
stand a much "etter chance of "eing approved if it addresses these issues
preemptively rather than getting "esieged "y them during the revie4 process.
The Proposal :riter )s 8verly 0ensitive to #riticism
<y experience might "e uniEueA "ut don't "e surprised if the maFor
promoter for your game proposal decides to play devil's advocate. <a3e sure
your proposal is solid. >elieve in it and remain confidentA and you'll 4eather
the criticism and ma3e "elievers out of those revie4ing your proposal.
The Proposal :riter )s )nflexi"le to #hanges to the Game
8ften during the process of gathering research or receiving criticism
Game Design Documents Page .5
from the revie4 committeeA some reasona"le suggestions 4ill arise for
changing or scaling "ac3 the design. Game development is a colla"orative
process. Ta3e the feed"ac3 and change the designA or the game could die right
there. The 3ey 4ord hereA as tattooed on the arm of my "uddy 4ho served in
the Bietnam :arA is transmute. @e had to transmute to stay alive and 3eep
goingA and your game idea may have to do the same.
Documentation Guidelines for the
;unctional and Technical 0pecifications
"y Tim 'yan
Did you ever loo3 at one of those huge design documents that "arely fit
into a fourHinch thic3A threeHring "inderK 7ou assume that "y its page count
that it must "e good. :ellA having read some of those design volumes from
cover to coverA ) can tell you that siCe does not matter. They are often so full
of am"iguous and vague fluff that it 4as difficult finding the pertinent
information. 0o 4hy does this happenK >ecause the authors didn9t follo4
guidelines.
This article is part t4o of a t4o part series that provides guidelines
that 4hen follo4ed 4ill ensure that your design documents 4ill "e pertinent
and to the point. &nli3e the authors of those prodigious design volumesA )
"elieve in "rea3ing up the design document into the portions appropriate to
the various steps in the development process G from concept and proposal to
design and implementation. ) covered the first t4o steps in part one of the
articleA providing guidelines for the game concept and game proposal. This
part 4ill provide guidelines for the t4o heaviest underta3ings G the functional
specification and technical specificationA as 4ell as some guidelines for the
paper portion of level design.
;unctional vs Technical 0pecifications
Traditionally in the game industryA there 4as only one spec. @o4
technical it 4as depended on 4ho 4rote it. Any documentation the
programmers 4rote after4ards to really plan ho4 they 4ere going to
implement it 4as informal and often remained on 4hiteH"oards or notepads.
7et in order to ensure the proFect 4ould proceed 4ithout haCard and on time
and on "udgetA the documentation needed to "e more technical. 0uch
detailed technical specifications too3 time G time 4asted if the goals and
function of the product should change or fail to gain approval.
This pro"lem 4as tac3led as more and more seasoned programmers
and managers of "usiness soft4are development moved into games. They
"rought 4ith them ne4 standards for documentation that helped ensure
more accurate plans and less technical pro"lems. They introduced a division
in the design document "et4een goals and method and "et4een function and
Documentation Guidelines for the ;unctional and Technical 0pecifications
techniEue. They separated the design document into the functional
specification and technical specification. This 4ayA the clientsA users or
principal designers of the product could revie4 the functional specification
and approve the goals and functions of the proposed soft4are G leaving the
determination and documentation of the methods and techniEue up to the
technical staff of programmers.
ThereforeA the technical staff 4aited until the functional specification
4as approved and signedHoff "efore starting on the technical specification.
They 4or3ed from the functional specification aloneA ignoring any design
changes that occurred after signHoff unless the spec 4as updated and a ne4
schedule agreed to. Thus the division saved time for the programmers and
gave them more control of the scheduleA 4hile still ensuring they had a
complete plan for the methods and techniEue for implementation.
<any companies still refer to the functional specification as the Mdesign
documentM and yet also produce a technical specification. The term
MfunctionalM is a clearer term adapted "y "usinesses and these guidelines to
clarify 4hat is expected in the document.
)n shortA 4hat goes into the game and 4hat it does is documented in
the functional specification. This is often 4ritten from the perspective of the
user. @o4 it is implemented and ho4 it performs the function is documented
in the technical specification. This is often 4ritten from the system
perspective. >oth form important delivera"le milestones in the design stage of
the game development process.
Guidelines for the ;unctional 0pecification
The functional specification 1or spec for short2 outlines the features and
functions of the product. The target audience is the team doing the 4or3 and
those responsi"le for approving the game design. The functional spec is a
culmination of the ideasA criticisms and discussions to this point. )t fleshes out
the s3eleton of the vision as expressed in the game concept and game
proposal. )t is a spring"oard from 4hich the technical specification and
schedule is derived and the implementation "egins.
)t9s important that it is all 4ritten from the user perspective. )n other
4ordsA 4hat is seenA experienced or interacted 4ith should "e the focus of the
document. )t9s often very tempting 1especially to programmers2 to create
something that9s very system oriented. This often leads to distraction and
hardHtoHfathom documents. 'eaders are really Fust loo3ing to this document
Game Design Documents Page .!
to visualiCe 4hat9s in the gameA not ho4 it 4or3s.
The length can vary from ten pages to a fe4 hundredA depending on
the complexity of the game. 7ou really should not aim for a page count. )9ve
seen and 4ritten really G88D design documents that 4ere less than fifty
pages and some that 4ere much more. )t is Fust important that each section
under these guidelines "e addressed. This 4ill eliminate the vagaries and
guess4or3 that comes 4ith insufficient documentation and the apparent need
to ram"leHon that comes 4ith aiming for a high page count.
The time involved in 4riting the functional spec is any4here from a fe4
days for say a puCCle gameA a month for a shooterA to a fe4 months for a
complex game such as an 'PG or strategy game. The amount of time spent
may not "e congruent to the resulting length. The discrepancy comes 4ith
deli"eration timeA especially if the game has any uniEueA unexplored Eualities
or if the game play is particularly deep. 8f courseA ho4 efficient the principal
designers are in ma3ing their decisions is of enormous impact as 4ellA
especially if everyone is particularly imaginative and passionate a"out the
game.
;or manyA this functional specification is 4here the documentation
"egins. They s3ip the important research and revie4 phase of the concept
document and game proposalA 4hich 4ould other4ise help it anchor the
vision and target mar3et firmly in place. >y s3ipping the first stepsA they also
put off the inevita"le criticism from mar3etingA finance and technical staffA
4hich leads to 4asted efforts.
The game9s lead designer usually produces the functional specification.
)t may "e a compilation of other9s 4or3 and hence a cooperative effort or it
could simply "e a matter of putting the vision of the producer on paper.
0ometimes the producer 4ill produce the document himJherselfP 4hich is
ideal for assuring that the vision expressed is indeed 4hat the producer
desires. +i3e the game of telephoneA sometimes the message gets altered
4hen it goes from the lead visionary to the author. :hatever the process and
4hoever the authorA it9s important that the producer and lead designer totally
agree 4ith everything expressed in this document. They cannot "e preaching
one thing and documenting another or the documents 4ill "e ignored and
serve no purpose.
)9ve never seen a design that didn9t undergo some changes during
implementationA "ut the process of communication has to "e expressed
through the specificationA even if it reEuires updates or an addendum. 0ome
Game Design Documents Page ..
changes need to "e fast and furious due to time constraints so the
documentation may "e light. 0oA even if it9s an electronic memorandum or
notes on a piece of paperA "e sure to distri"ute these and attach them to all
future copies of the specification. )f the vision of the game changesA ho4everA
it9s "est to start from the "eginning 4ith a ne4 concept document and
proposal. The clarity the updated documentation "rings 4ill save time in the
long run.
&nli3e the game concept and proposalA the functional specification is
not a selling document. )t merely "rea3s do4n and ela"orates on the vision in
very clear terms understanda"le "y every reader. )t can "e a little "oring or
dry as the necessary details are filled in. )9d recommend putting in summary
level paragraphs at the start of every sectionA so that readers can get the gist
4ithout s3ipping any sections or losing any confidence in the thoroughness of
the specification. :hy do ) recommend thisK :ellA the Euestion should really
"e M:hy do some people never find the time to thoroughly read the proFect
specificationsKM :hile your company9s managers and team mem"ers might
not fail in this regardA there9s al4ays a third partyA li3e the pu"lisher or
contractor.
8n the other handA this document cannot "e technically explicitA as its
readers are mostly nonHprogrammers. )f you find yourself getting technicalA
stop. That9s 4hat the su"seEuent technical specification is for. >esidesA getting
technical 4ith a "unch of nonHtechnical readers can ma3e their eyes glaCe
over or open up a canHofH4orms. 7ou don9t 4ant to give them an invitation
to stic3 their nose into something they don9t necessarily understand and really
shouldn9t care a"out. +i3e4iseA you or the other authors may "e nonH
technicalA and you shouldn9t "e dictating to the programmers ho4 they
accomplish 4hat you 4ant them to do. +et them determine that 4hen they
4rite the technical specification. This document is purely for the
communication and approval of 4hat goes into the product as opposed to
ho4 to accomplish it. +imit descriptions of ho4 something should "e
accomplished to those areas that are you "elieve are really important that it
4or3 a certain 4ay. ;or exampleA you 4ould not indicate 4hat varia"les to
use and ho4 to use them to simulate a la4 of physicsP ho4everA you might
4ant to indicate the factors involved in the physics eEuation. 0imilarlyA telling
a programmer ho4 to define his data structures and o"Fects is a "ad ideaA "ut
proposing the interface for data entry and the delineation of data is certainly
4ithin the confines of function.
The functional specification can "e "ro3en do4n into a fe4 maFor
Game Design Documents Page .$
sections%
Game <echanics
&ser )nterface
Art and Bideo
0ound and <usic
0tory 1if applica"le2
+evel 'eEuirements
Game <echanics
The game mechanics descri"e the game play in detailed termsA starting
4ith the vision of the core game playA follo4ed "y the game flo4A 4hich
traces the player activity in a typical game. The rest is all the infinite details.
#ore Game Play% )n a fe4 paragraphs descri"e the essence of the
game. These fe4 4ords are the seeds from 4hich the design should gro4.
Planted in the fertile soil of a 3no4n mar3etA they should esta"lish roots that
anchor the vision firmly in place and help ensure a successful game. This is
similar to the description section in the game conceptA except that it9s nonH
narrativeA and usually expressed clearest in "ullet pointsA though this could
vary depending on the type of game.
Game ;lo4% Trace the typical flo4 of game play 4ith a detailed
description of player activityA paying close attention to the progression of
challenge and entertainment. )f the core game play is the root of a treeA the
game flo4 is the trun3 and the "ranches. All activity should actualiCe and
extend from the core game play. >e specific a"out 4hat the player doesA
though try to use terms li3e MshootMA McommandMA MselectM and MmoveM rather
than Mclic3MA MpressM and MdragM. This 3eeps the description distinct from ho4 the
actual G&) 4ill 4or3A 4hich is li3ely to change. 'efer readers to specific pages
in the &ser )nterface section 4hen you first mention a G&) element such as a
screen or 4indo4 or command "ar.
#haracters J &nits 1if applica"le2% These are the actors in the game
controlled "y the players or the A). This should include a "rief description and
any applica"le statistics. 0tatistics should "e on a rating scale i.e. A to R or
+o4 to @ighA so that it9s clear 4here units stand in relation to each other in
"road terms. )t9s a 4aste of time plugging in the actual num"ers until the
programmers have 4ritten the technical specification and created an
environment for you to experiment 4ith the num"ers. 0pecial talents or
a"ilities "eyond the statistics should "e listed and "riefly descri"edA "ut if
they are complexA they should "e expanded upon in the game play Nlements
section.
Game Play Nlements% This is a functional description of all elements
that the player 1or charactersJunits2 can engageA acEuire or other4ise
interactive 4ith. These are such things as 4eaponsA "uildingsA s4itchesA
elevatorsA trapsA itemsA spellsA po4erHupsA and special talents. :rite a
paragraph at the start of each category descri"ing ho4 these elements are
introduced and interacted 4ith.
Game Physics and 0tatistics% >rea3 out ho4 the physics of the game
should functionA i.e. movementA collisionA com"at etc.A separating each into
su"sections. Descri"e the loo3 and feel and ho4 they might vary "ased on
statistics assigna"le to the charactersA units and game play elements. )ndicate
the statistics reEuired to ma3e them 4or3. Get feed"ac3 from the
programmers as you 4rite thisA as ho4 the game handles the physics and the
Euantity of the statistics 4ill severely impact performance issues.
This can get a little dryA "ut avoid getting too technical. Avoid using
actual num"ers or programming terms. These 4ill come later in the technical
specificationA 4ritten "y the programmers 4ho 4ill 4ant to do things their
4ay 1usually the right 4ay2. ,ust tell them 4hat you 4ant to accomplish. ;or
example% MThe units should slo4 do4n 4hen going up hill and speed up 4hen
going do4nA unless they are a hover or flying vehicle. @o4 much they are
affected should "e a factor of their clim"ing and acceleration statistic as 4ell
as the angle of the incline.M 7ou 4ould not tell the programmers 4hat math to
use to adFust the speed. Assuming you are not a programmer yourselfA they9re
Fust "etter at that than you.
Artificial )ntelligence 1if applica"le2% Descri"e the desired "ehavior
and accessi"ility of the A) in the game. This includes movement 1path finding2A
reactions and triggersA target selection and other com"at decisions such as
range and positioningA and interaction 4ith game play elements. Descri"e the
avenue through 4hich the A) should "e controlled "y the level designersA i.e.
using .)() filesA Linclude files of game stats or #HcodeA proprietary A) scriptsA
etc.
<ultiplayer 1if applica"le2% )ndicate the methods of multiHplayer play
1i.e. headHtoHheadA cooperative vs. A)A teamsA every man for himselfA hotseat2
Game Design Documents Page .*
and ho4 many players it 4ill support on the various net4or3ing methods.
Descri"e ho4 multiHplayer differs from soloHplay in game flo4A
charactersJunitsA game play elements and A).
&ser )nterface
The interface changes so very often that it almost seems pointless to
document itP ho4everA it9s got to start some4here. )t9s structured here to
minimiCe the impact of changes. )t9s starts 4ith a flo4chart of the screen and
4indo4 navigationA then "rea3s do4n the functional reEuirements of all the
screens and 4indo4s. That doneA the G&) artist is free to do 4hat he or she
feels is right as long as it meets the reEuirements. To get him or her started
you should provide moc3Hups. This often is to the designer9s "enefit to thin3
everything through. Then follo4 up 4ith a description of all the G&) o"Fects
that need to "e programmed to ma3e all the screens 4or3.
;lo4chart% This charts the navigation through the various screens and
4indo4s. &se B)0)8 or similar flo4charting tool to connect la"eled and
num"ered "oxes togetherA representing screensA 4indo4sA menusA etc. 8n the
corner of each sheetA put a num"ered list of all the items for easy referencing
and ease of defining tas3s for the programmers.
;unctional 'eEuirements% This functional "rea3do4n of every screenA
4indo4 and menu lists the user actions and the desired results and may
include diagrams and moc3Hups. :hile the specific interaction 1"uttonsA
hotspotsA clic3sA drags and resulting animations2 can "e listedA it9s often "est
to 3eep this separate from the list of functional reEuirements as these can
evolve during implementation. 8f course if it9s Fust easier to thin3 in terms of
clic3ing a "utton or it9s really important that something 4or3 a certain 4ayA
then "y all means get specific a"out the method of interaction.
<oc3ups% #reate a moc3Hup for all the screensA 4indo4s and menus.
This may end up getting ignoredA "ut it9s a good starting point for the artists if
they have no idea 4hat else they may 4ant to do. Don9t 4aste your time
creating anything really pretty. ,ust create simple line dra4ings 4ith text
la"els. #olor can "e very distracting if it9s "adA "ut if it9s importantA go ahead.
0ome dra4ing programs have templates that ma3e creating moc3Hups very
Euic3 and easy.
G&) 8"Fects% These are the "asic "uilding "loc3s used to create all the
screensA 4indo4s and menus. This should not include the items seen in the
main vie4 portalA as these are covered in the art list in the next section. The
Game Design Documents Page .=
G&) o"Fects are primarily listed here for the programmers to 3no4 4hat pieces
they9ll need to code and have for putting together the screens. 7ou should
explain in detail ho4 each is interacted 4ith and ho4 they "ehave. )t may
seem a "it o"vious and not 4orth documentingA "ut it really helps 4hen
drafting together the technical spec and schedule to 3no4 exactly everything
the game 4ill need.
;or some gamesA this can "e a very Euic3 list to put together G "uttonsA
iconsA pointersA slidersA @&D displays etc. >ut it9s much more complicated in
games 4here the interface is at all different. @o4everA 3eep in mind that the
methods of interaction are not all that different. A "utton is still a "uttonA
even if it9s clic3ing on a gorgon9s head instead of a gray rectangle.
Art and Bideo
This should "e the definitive list for all the art and video in the game.
:e all 3no4 ho4 things creep upA thoughA so add a couple of placeholder
references for art to "e named laterA li3e mission specific art and art for
mar3eting materialsA demosA 4e" pagesA manual and pac3aging.
8verall Goals% This is 4here you should spell out the motifsA
characteristicsA styleA moodA colors etc. that ma3e up the goals for the art.
Gather consensus 4ith the lead artists and art director and ma3e sure they
see eye to eye 4ith the proFect9s director or producer. Doing so no4 4ill save a
lot of time later if they end up redoing everything "ecause the goals 4ere
never clearly defined.
D Art Q Animation% This is really Fust a huge list that can "e thro4n
into the art schedule. )t can also include descriptions if needed. 0ome art isn9t
selfHexplanatoryA and other may involve specific needs from a design
standpoint. >e sure to explain it all. >rea3 your art do4n into sections. The
lead artist may have some particular 4ay he or she 4ould li3e you to do that.
)9ll list the typical section and their contents. 'ead them all to "e sure you
don9t forget anything.
G&)% 0creensA 4indo4sA pointersA mar3ersA iconsA "uttonsA menusA shell
etc.
<ar3eting and Pac3aging Art% 7ou might as 4ell list it here and the
scheduleA "ecause they9ll as3 for it. This includes 4e" page artA sell
sheet designA demo splash screensA magaCine addsA press artA the "ox
and manual.
Game Design Documents Page .-
Terrain% Nnvironment art li3e tilesA texturesA terrain o"FectsA
"ac3grounds.
Game Play Nlements% Player and enemy animations 1sprites or
models2A game play structures and interactive o"FectsA 4eaponsA
po4erHupsA etc. Don9t forget damage states.
0pecial Nffects% 0alvoA explosionsA spar3sA footprintsA "lood spotsA
de"risA 4rec3age.
!D Art Q Animation% This serves the same purpose and has the same
reEuirement of the D Art list a"ove. The difference may "e in ho4 the 4or3
may "e divided. Art teams li3e to divide !D art tas3 lists into modelsA
texturesA animations and special effectsA as they usually divide the tas3s this
4ay to maximiCe talent and s3ill and maintain consistency.
#inematics% These are the D or !D scenes often sho4n as an introA
"et4een missionsA and at the end of the game. These should "e scripted li3e a
film script as separate documents. ThisA ho4everA is production 4or3. ;or the
purposes of the functional specA Fust list them here 4ith the general purposeA
content and target length. )f any video is involvedA list it in the follo4ing
su"section.
Bideo% &nless you are doing an ;<B 1full motion video2 gameA this
su"section is pretty light. )f you have any video in your G&) for say pilot
messagesA "rea3 it do4n here. All video tas3s 4ill reEuire scriptingA "ut that is
production 4or3. +ist the general purposeA expected lengthA and general
content li3e num"er of actors and set designA even if it ends up "eing "lueH
screened into a !D rendered "ac3ground.
0ound and <usic
8verall Goals% 0tress the aesthetic and technical goals for the sound
and music. Descri"e the themes or moods you 4ant. (ame existing games or
films as examples to aspire to. )ssue technical edicts and editing o"FectivesA
such as sampling ratesA dis3 spaceA music formatsA and transition methods.
0ound ;S% +ist all the sound ;S reEuired in the game and 4here they
4ill "e used. )nclude the intended filenamesA "ut "e sure to consult 4ith the
sound programmer and sound technician 1or composer2 on the file naming
convention. This ma3es it easier for people to find the sound ;S and fold them
into the game.
Game Design Documents Page $5
Don9t forget a"out all the areas that sound ;S may "e used. 7ou don9t
4ant to overloo3 anything and thro4 off the schedule. Go through all the
game elements and your art lists to see if there should "e some sound
associated 4ith them. @ere are some to consider%
G&)% >utton clic3sA 4indo4 openingA command ac3no4ledgments.
0pecial Nffects% :eapons fireA explosionsA radar "eeping.
&nitsJ#haracters% Boice recordingsA radio chatterA stompingA collisions.
Game Play Nlements% Pic3Hup FingleA alertsA am"ient sounds.
Terrain 1Nnvironment2% >irdsA Fungle soundsA cric3etsA crea3s.
<otion% :indA footfallsA crea3ing floorsA 4adingA puddle stepping.
<usic% +ist all the music reEuired in the game and 4here it 4ill "e
used. Descri"e the mood and other su"tleties. <usic 4ill often reuse the same
themes and melodies. <ention 4here these themes should "e reused. #onsult
the composer on this.
Nvent ,ingles% 0uccessJfailureJdeathJvictoryJdiscovery etc.
0hell 0creen% <ood setting for title screensA creditsA end game
+evel Theme% +evel specific music 1designers choose the theme2
0ituations% 0ets the mood for situations 1lur3ing dangerA com"atA
discovery2
#inematic 0oundtrac3s
0tory
:rite the synopsis of the story told "y the game. )nclude the "ac3H
story and detailed character descriptions if it helps. )ndicate the game text
and dialogue reEuirements so they can "e added to the schedule. 0ome game
designs focus so much on this that they overloo3 everything else that should
"e in the spec. Telling a story is not the focus of most games. 8f courseA if you
are doing an adventure gameA it is extremely important. Nxpand and organiCe
this section as is necessary to tell the story.
+evel 'eEuirements
+evel Diagram% :hether this is a linear campaignA a "ranching mission
treeA or a 4orldHhopping freeHforHallA this diagram should "e the "ac3"one
upon 4hich all the levels are "uilt. A diagram isn9t necessary if the structure
is so simple that a list 4ould suffice. The follo4ing is an example of a typical
successJfail "ranching mission tree. 8f course this 4ill vary greatly for each
game. The important thing is that it Fust presents a road map for the level
designers and for the readers.
Asset 'evelation 0chedule% This should "e a ta"le or spreadsheet of
4hat level the game9s assets are to "e revealed to the player for the first
time. There should "e a ro4 for each level and a column for each general
type of asset. Assets include po4erHupsA 4eaponsA enemy typesA tric3sA trapsA
o"Fective typesA challengesA "uildings and all the other game play elements.
The asset revelation schedule ensures that assetsA the things that 3eep the
players loo3ing for4ard to the next levelA are properly spaced and not over or
under used.
)f it9s important to the game that certain assets stop "eing usedA then
the schedule might "e "etter dra4n as a Gannt chart 4ith lines indicating the
availa"ility of assets. This gives the level designers a guide to 4hat assets
they have to 4or3 4ith so they don9t ruin their level or anyone else9s.
+evel Design 0eeds% These are the seeds for the detailed paper
designs to follo4. Detailed paper designs at this point are less legitimate and
unli3ely to survive intact. Designs created after the designers have had time to
experiment 4ith the tools and develop the first playa"le level are much more
li3ely to succeed. )t9s "est to Fust plant the seeds for each level 4ith a
description of the goals and game play and 4here it ties into the story 1if
applica"le2. A thum"nail s3etch is optionalA "ut very helpful if the designer
already has a clear idea of 4hat he or she 4ants. >e sure to list any specific
reEuirements for the levelA such as terrainA o"FectivesA the revelation of ne4
assetsA and target difficulty level.
#ommon <ista3es
@ere are some common mista3es to loo3 out for%
)nsufficient Details
The descriptions need to "e specific enough to convey intent and
function. Avoid using vague terms unless you follo4 up 4ith specifics.
PatroniCing <aterial
7ou 4ouldn9t give a chef a recipe that told him ho4 to ma3e a
marinara sauceA so you don9t tell artists ho4 to manage their $6 color
palette or programmers ho4 to define a particular data structure. ,ust list
the facts important to the vision. (ot only does it 4aste their time 1and annoy
them2A "ut it 4astes the 4riters9 time. 0uch details are more appropriate for
the technical specification any4ayA 4hich is 4ritten "y the programmers.
Am"iguous or #ontradictory <aterial
:atch for this. )t clouds the visionA creates misunderstandingsA and
invalidates the functional specification.
The Design Document from @ell
(othing stupidA nothing am"iguousA nothing lac3ing G it Fust is too
damn much. Try to 3eep a mental total of ho4 long the design is going to
ta3e to implement 4hen fleshing out the specification. #ut extraneousA nonH
essential features and save them for the seEuelP or "e prepared to argue the
merits of 3eeping the features and extending the ship date.
Getting Too Personal 4ith the Design
7ou are not your 4or3. 7our personal "oundaries should not include
the design. As ) have stressed throughout this documentA game design is a
colla"orative process. :hile you 4ant people to ta3e o4nership and
responsi"ility for their 4or3A the functional specification should have Foint
o4nership. This 3eeps people from feeling isolated and more a part of the
processA and it ma3es the documents feel less li3e marching orders and more
li3e a plan. The team mem"ers are also much more li3ely to read something
that they helped put together. #riticism is then aimed at the design not the
documentors 4ho put is all togetherP thus ma3ing the team more comforta"le
and productive in offering their criticism.
Game Design Documents Page $!
:andering Bision
This may happen as you 4rite the functional spec. Nven 4ith a good
concept document and proposal championing the visionA there9s still some
room for interpretation. #reative fol3s have a 4andering imagination and may
"e influenced strongly "y 4hatever game they may "e playing at the moment.
Guidelines for the Technical 0pecification
:hile the functional specification explains 4hat is going into the
productA the technical specification explains ho4. The technical specification
1or tech spec2 is a 4or3ing "lueprint for the game. )t turns conFecture into
reality "y forcing the programmers to thin3 through ho4 the game 4ill "e
implementedA "y reducing implementationJintegration headachesA and "y
delineating the program areas and tas3s for the schedule.
<any companies 4ill s3ip this stepA as it is time consuming and
seemingly "enefits only the programmers. @o4everA time spent 4or3ing on a
tech spec is less than the time lost from pitfalls that come 4ith not 4riting
one. The primary author is the lead programmer or technical directorA though
it is often more timely and useful if the programmers responsi"le for
implementing the various program areas "e responsi"le for documenting
them. )n its compiled formA it should present a plan that any programmer can
understand and 4or3 from.
The target audience is the lead programmer on the proFect and the
technical director of the company. Therefore it 4ill generally "e 4ritten from
the system perspective as opposed to the user perspective. )t 4ill "e "oring
and Gree3 to the producer and any other nonHtechnical readers. >y as3ing for
oneA the producer is Fust ma3ing sure the technical staff thin3s everything
throughA even if he or she doesn9t understand it. To the lead programmerA it9s
a 4ay of organiCing his or her thoughts and creating an accurate picture of
the 4or3 involved. The process of 4riting it 4ill flag any of the uncertainties
on the programming side and any of the holesA am"iguities or a"surdities in
the functional spec.
<any good technical specifications vary from the form descri"ed here.
This form mirrors the functional specification to ensure that all areas of the
functional specification are covered. 0ometimes it9s easier for a team 4riting
this spec to organiCe it differentlyA if only "ecause they are splitting the 4or3
differently or "ecause of the organiCation of the underlying system. )f they doA
Game Design Documents Page $.
)9d recommend going through every line of the functional specification and do
a correlation 4ith a highlighter to ma3e sure nothing has "een overloo3ed. An
overloo3ed detail can lead to undesira"le results in the productA proFect and
team dynamic.
These guidelines 4ill not tell you ho4 to implement your game. )t9s
assumed that you are a technically competentA experienced game
programmer. An inexperienced or untrained game programmer should not
attempt this tas3. These guidelines are the result of 4hat )9ve come to expect
in a good technical specificationA though ) certainly couldn9t tell you ho4 to
program your game. These guidelines force you to define the most common
elements one finds in all games. 0ome may not "e applica"leA "ut each
should "e considered carefully. )t may spar3 a Euestion you haven9t as3ed
yourself yetP 4hich is sort of the 4hole point of 4riting this spec.
Game <echanics
This is certainly the "ul3 of the document. 'ight a4ay you9ll see that
any attempt to match up specific su"sections 4ith the game mechanics
section of the functional spec is totally ludicrous. The perspective must "e
from the system out as opposed to the designers9 or users9 perspective. This
starts 4ith the hard4are platform and the operating systemA the use of
externally provided code o"Fects 1D++sA NSNsA drivers2A and the delineation of
internally generated code o"Fects 1if any2. Then it "rea3s do4n the specific
mechanics of game code stemming from the control loop.
Platform and 80% )ndicate the hard4are platform and the operating
system and the versions supported. ;or P#J<ac gamesA mention the minimum
system reEuirements and the target machine. )f distri"uted on something
other than a #D li3e a cartridgeA indicate the target '8<.
Nxternal #ode% Descri"e the source and purpose of all the code used
"ut not developed "y the proFect team. This includes 80 code and
preprocessing tools of the various game platformsA drivers and code li"raries
li3e DirectSA any acEuired !D AP)A or any other offHtheHshelf solution.
#ode 8"Fects% >rea3 do4n the purpose and scope of the various code
o"Fects codedA compiled and "uilt into the NSN. )f any outHofHprocess or inH
process code li"raries 1D++s2 are usedA "rea3 them do4n as 4ellA "ut "e sure
to explain the use of o"Fect instancing and their persistence 1li3e Direct Dra4
o"Fects2.
Game Design Documents Page $$
#ontrol +oop% Nvery game has one. >e specific a"out ho4 control is
transferred from the startHup code to the shell and do4n into the main game
code. 0pell out the names of the functions in the core loop and 4hat they 4ill
doA li3e the collisionA movement and rendering routines. Nxplain the use of
multiHthreadingA driversA D++s and memory management. 8f course further
details on the li3es of multiHthreading and memory management 4ill "e
covered in the areas that they 4ill "e used mostA li3e the rendering or sprite
engineA sound code and A).
This su"section summariCes the system and underlying frame4or3 that
supports the core game play and game flo4 descri"ed in the functional
specification.
Game 8"Fect Data% 'ead carefully over the functional spec at all the
characterJunit descriptions and game play elements. Then list and formulate
all the data structures and their identifiers that are reEuired to support the
descri"ed attri"utesA functions and "ehaviors. To a certain extentA these 4ill
not "e complete until the game physics and statistics and A) su"sections are
completely thought through and documented. Add statistics for user interface
or any other area of the game that have unit or game play o"Fect specific
data 1i.e. iconsA @&D displaysA animation or special effect referencesA etc.2.
)f using o"Fect oriented programming methodsA sho4 the class
inheritance tree and each class9 interface properties and functions. Descri"e
the use of collections. )dentify any varia"les that could possi"ly "e made into
glo"al varia"les to increase performanceA such as any o"Fects varia"les that
may "e referenced multiple times during critical game routines such as
collisionA movement or rendering. AgainA )9m not telling you ho4 to program
your game. )9m Fust trying to get you thin3ing a"out common technical issuesA
specifically in regard to optimiCing data structures for neatnessA versatility or
speed.
Data ;lo4% Nxplain ho4 data is storedA loadedA transferredA processedA
saved and restored. :hile references should "e made to data entry or
processing toolsA separate functional and technical specifications should "e
made for any complex or user intensive tools.
Game Physics and 0tatistics% This is the nitty gritty G movementA
collisionA com"at G and pro"a"ly the most fun to document and implement.
@o4everA it can also "e the code that gets altered more than any other part
of the program. Designers li3e to change things. )t9s often only after they can
play it for a 4hile "efore they can really decide 4hat is right. ;or this reasonA
you should plan to implement things as modular and flexi"le as possi"le. Put
all the factors that control "ehavior into data files read at runHtimeA so the
designers can change and "alance things at their leisure 4ithout involving
coding changes and ne4 "uilds. The specification should clearly identify the
modularity and divisions "et4een code and the data that controls it.
Define each function or procedure. Descri"e its purpose. Define 4hat
statistics control its "ehavior 1constantsA varia"les etc.2 and ho4 they can "e
modified. )nclude the function prototype listing all the parameters. )f using
function pointers and function overloadingA specify 4here the different
versions of the function 4ill "e used. ;or exampleA you may have multiple
functions that handle movement for the various unit types G one for land
movementA one for airA one for 4aterA etc. >riefly descri"e ho4 the function
4ill 4or3. ;or complex functionsA use pseudo code to specify exactly ho4 you
4ill code it. This is especially important for #P& intensive functions that do a
lot of num"er crunching or are Fust called very often. Thin3 a"out ho4 they
can "e optimiCed to increase performance. Perhaps "itHshifting or macros
could speed things up.
Artificial )ntelligence% This often gro4s to a maFor section unto itself
and is then scaled "ac3 4hen the schedule dictates the necessity to 3eep it
simple. This sho4s a gro4ing enthusiasm for complex A)A "ut a lac3 of time
and resources to ma3e A) anything more than simulated intelligence or
scripted "ehaviors. >e mindful of this 4hen you design the A) scheme. Try to
accomplish the "ehaviors and decision ma3ing descri"ed in the functional
specification 4ithout adding a huge layer of unnoticed and therefore
unappreciated realism to the process. The "asic rule of production applies
here. )f something that costs less and ta3es less time to "uild does the Fo"A
then don9t spend more time and money creating something else.
8f courseA there are exceptions that should "e mentioned. 0ometimes
something might ta3e longer to "uildA "ut it saves the designers a lot of time
4or3ing on their levels. AlsoA creating something more flexi"le or po4erful
may ma3e it a valua"le asset to the company for other proFects or Fust ma3e
it more capa"le of handling design changes should they occur. Discuss these
4ith your producer and director of development "efore ma3ing a decision.
>e sure to include the methods of manipulating the A) as dictated "y
the functional specA i.e. 4hether it9s data driven or em"edded into compiled
codeA and 4hether it9s a scripted language or a fixed set of varia"les or a
com"ination of "oth.
Game Design Documents Page $*
A) should include path findingA target selectionA tests and events to
attach reactionary "ehaviors toA and other decisions made "y charactersA units
or intelligent game elements involving game situations and unit statistics.
D8 (8T include the actual scripts or data driving the A). That9s
production 4or3. <erely "e specific enough to explain ho4 the decisions and
"ehaviors 4ill "e derived. >rea3 do4n the statistics used to control the
"ehavior.
<ultiplayer% )t9s extremely important that the implementation plan is
revie4ed from a multiplayer perspective. This su"section should "rea3 do4n
all the multiplayer considerations in game mechanics and all the multiplayer
specific reEuirements specified in the functional spec.
<ultiplayer over multiple P#s 1as opposed to console sharing or
hotseat2 has a lot of uniEue reEuirements that should "e addressed. :hat
connection methods and protocols are supportedK )s it clientHserver or peerH
toHpeerK :hat are the pac3et siCes and ho4 often are they sentK :hat is the
structure of the pac3etK @o4 are missed pac3ets and latency issues handledK
:hat messages are "roadcast and 4hat are sent to specific hostsK @o4 many
different messages are there and 4hen are they usedK
&ser )nterface
+oo3 and feel is one area of the design that undergoes the most
changes during development. ThereforeA its necessary that the programming
for the G&) "e as flexi"le as possi"leA separating game purpose from G&)
functionA so that changes that occur to the user interaction methods 4ill not
affect other areas of the game or reEuire significant reprogramming. #reate a
variety of G&) o"Fects 1controls2 using inheritance to maintain a consistent
code interface to the events and the values. This 4ay a slider "ar can "e
exchanged 4ith a text "ox or radial "uttons 4ith little or no changes to the
calling functions. Assume that any of the G&) o"Fects can "e exchanged at any
point in the proFect.
To this endA your documentation should "e flexi"le and generic. :hile it
should "rea3 do4n the G&) into the screensA 4indo4s and menusA it should
not go any further into the specific interaction. )nsteadA document ho4 the
various G&) o"Fects 4ill 4or3A 4herever they are used.
<a3e references to functions in the game mechanics documented in the
previous sectionA "ut anything that9s interface related should go here.
Game Design Documents Page $=
Nxplanation of the dra4ing and clipping routines of the graphics engine
should "e left for the Art and Bideo sectionA "ut certainly they should "e
referenced here in terms of vie4 ports and @&D attachments and anything the
player can interact 4ith.
Document the names for any of the glo"al varia"lesA constantsA
macrosA function names or interface propertiesA so that other programmers
can refer to the documentation 4ithout having to dig through code. This also
avoids replication and inconsistency and increases clarity.
Game 0hell% +ist all the screens that ma3e up the game shell H all the
screens and 4indo4s other than the main play screens. These are derived
from the flo4chart in the functional specificationA "ut may include some
additional screens that the lead designer may have overloo3ed or "rushed
over 1li3e installation or setup screens2. Nach item listed should "e its o4n
su"section 4ith a description of its purposeA its scope 1i.e. "efore or after level
specific data is loaded2A the pertinent values it 4ill "e accessing and settingA
and 4hat functions it 4ill call.
<ain Play 0creen1s2% These are the one or more screens in 4hich the
core of the game is played. Though many people thin3 from the G&)
perspective do4n to the complexities of 4hat9s under the hoodA this should "e
4ritten from the lo4Hlevel mechanics perspective 1the engine and rotors2 out
to the G&) 1the hood and the dash2. This 3eeps it consistent even if the
out4ard appearance of the G&) should change.
Art and Bideo
:hile this section in the functional spec pretty much Fust listed the art
and videoA the technical spec has to explain ho4 the art and video 4ill "e
storedA loadedA processed and displayed in the game. This includes the
animation systemA 4hether it9s D or !DA and the video decompression and
streaming system. 8f course some of these might "e off the shelf solutionsA
especially the video code. >ut all the interfacing should "e mentioned here.
Graphics Nngine% :hether you are using spritesA voxels or !DHpolygon
rendering or a com"inationA "rea3 do4n their functions in very specific detail.
:hile it9s only sentences of description hereA it 4ill li3ely prove to "e a very
meaty piece of the spec. Descri"e areas li3e vie4 portsA clippingA special
effectsA and the connection to the collision and movement functions descri"ed
in the game mechanics.
Game Design Documents Page $-
Artist )nstructions% >rea3 out the details important to the artistsA li3e
resolutionsA "it depthA palettesA file formatsA compressionA configuration file
definitions and any other data the artists need to define to fold in the art.
#onsider 4hat tools can "e created to streamline the art pipelineA and
indicate their specifications here or create separate specifications for the more
complex or user intensive tools.
0ound and <usic
Descri"e ho4 sound 4ill "e loaded and played. >e specific a"out the
use of mixingA D<AA multiple channelsA !D soundA and methods of
determining priority. )f using third party driversA descri"e their interface and
purpose. >e sure to address all of the reEuirements specified in the functional
spec.
0ound Nngineering )nstructions% >rea3 out the details important to the
sound engineers and composersA li3e sample ratesA the use of multiple
channelsA !D sound definitionsA sample length etc. )f using <)D)A indicate the
version to use and the num"er and type of instruments that can "e used and
possi"ly stored. )ndicate the data path and file reEuirements including any
specific configuration files that need to "e created. #onsider 4hat tools can "e
created to streamline the sound pipelineA and indicate their specifications here
or create separate specifications for the more complex or user intensive tools.
+evel 0pecific #ode
>ased on the level design seeds in the functional specificationA descri"e
ho4 code specific to those levels 4ill "e implemented and ho4 it 4ill
accomplish the desired effect. Also descri"e ho4 any other level specific code
can "e interfaced to the game code should the need arise to add more. )n
generalA you should try to ma3e any of the level specific code as generic and
as flexi"le as possi"le so that it may "e freely used to accommodate similar
needs for other levels or ne4 ideas.
#ommon <ista3es
@ere are some common mista3es to loo3 out for%
@and :aving
)t9s very tempting to Fust list the functions and not fill in all the details
that force you to really plan ho4 you are going to implement them.
0ometimes they are Fust glossed overA "ut really the hand 4aving should end
4ith the functional spec. This spec is supposed to force the programmers to
really thin3 everything through ahead of time. @o4 else are they going to
estimate the tas3 time correctlyK
:hile it can "e very effective to assign portions of the technical spec to
the individual programmers responsi"le for implementing itA it9s not al4ays in
the "est interest of the game or indeed the programmer to do so 4ithout
some supervision. An entryHlevel programmer should get some guidanceA and
all the programmers should discuss and critiEue their documentation "efore it
gets all folded together. 0ome companies have regular code revie4s 4here
programmers critiEue each other9s 4or3. That should start even sooner during
the design phase.
Guidelines for Paper +evel Designs
The designers should do paper versions of level designs "efore they
"egin creating the levels in the editor. )deallyA the designers 4ill "e familiar
4ith the design paletteA the level editor and game engine capa"ilities "efore
they get started. Paper level designs are creating during the implementation
phaseA though they are "ased off of level design seeds expressed in the
functional specification. These seeds are the core idea for the level andJor the
"asic reEuirements that may indicate 4hat ne4 assets are "eing introduced or
4hat to limit the design to. )t9s "est not to do all of the paper designs at
onceA eitherA as the designers usually learn a lot 4hile implementing each
ne4 level.
;or some reasonA producers often expect the cart to come "efore the
horseA so "efore serious level design "eginsA push for a playa"leA prototype
level to "e created first. )t9s often a milestone unto itself that ensures that the
tools and game mechanics are 4or3ing 4ell enough to develop levels. )t
should also serve as a guide to 4hat can "e accomplished 4ith the editor and
engine and epitomiCe the vision for level design.
;ollo4ing the first playa"le missionA level design can start in earnest.
7et even hereA documentation plays an important role in saving time and
ensuring Euality through meticulous planning and the critical process. The
process of level design that 4or3s%
0tep 1% Thum"nail Q Discussion
The level designer conceives of a level layout that meets the
reEuirements laid out in the functional specification and asset revelation
schedule. @e or she then produces a thum"nail s3etch and discusses the
concept 4ith the lead designer. The thum"nail could "e on a 4hite "oard or a
note pad. )t is a visual aid in the discussion. )t does not need to convey the
entire idea or all the details for the levelA as these often evolve during the
discussion or get tossed out altogether.
The "enefit of doing a thum"nail s3etch and discussion rather than
forcing a designer to first thin3 everything through and document it is that it
saves time. A senior or lead designer can in a matter of minutes determine
4hether a proposed level design has merit and give valua"le advice that can
drastically alter the design. A fully detailed and documented paper version
can ta3e days or even a 4ee3 to put together. Depending on the s3ill of the
designerA a designer might get sent "ac3 to the dra4ing "oard many times.
This is especially true near the "eginning of the proFectA 4hen the designer is
still learning 4hat the lead designer 4antsA and near the end of the proFectA
4hen originalA compelling level concepts are harder to come "y.
0tep % Detailed Paper Bersion
:ith an approved thum"nail and level conceptA the level designer can
4or3 on a detailed paper version of the level design. The layout 1or map2 of
the level should "e much more detailed than the s3etch and should "e dra4n
to scale. This is "est done on a large sheet of graph paper using colored
pencils. )nformation a"out o"FectivesA "ehaviorsA "uildingsA enemiesA eventsA
locations etc. should either appear on the map or on a separate document
4ith reference points on the map. Any mission specific art or code should also
"e listed. This amount of detail can ta3e a fe4 days or as long as a 4ee3 to
dra4 and documentA "ut it saves a lot of time that 4ould other4ise "e spent
MsearchingM or MredesigningM in the actual editor.
:hen completedA the lead designerA producer and any other principal
decisionHma3ers should su"Fect the paper design to an approval process. They
may approve itA thro4 in some changesA or 3ill the level right then and there.
)t9s also important that someone technicalA prefera"ly a senior
programmerA revie4 the paper design from a technical standpoint. This gives
the programmers a heads up on 4hat the level designers are going to
attempt to do 4ith the tools and graphics engine. They might add some
features to the tools or ma3e some code adFustments to ma3e the level
possi"le or Fust easier to implement. They may also vote to eliminate or alter
any level designs that may "rea3 the game or are similarly unfeasi"le.
)t9s often very tempting to s3ip this step and Fump right into the editor
as it9s often faster to Fust "uild a prototype of the level than to 4rite up the
paper version. This is especially tempting in tight schedule situations. 7etA it9s
these tight schedules that ma3e documentation that much more importantA
"ecause it means there9s even more reason to get it right the first time and
reduce the num"er of surprises and time to redo the 4or3. The "enefit of a
detailed paper version is that it forces a designer to thin3 everything through
and express the fun and challenges "efore he or she implements it. )t also
ensures that the details that may involve more tas3s for programmersA artists
and sound technicians get documented and scheduled for completion "efore
the designer "egins 4or3ing on the level.
This article is focused on documentationA "ut for completeness to this
section and to this processA here are the remaining steps to level design as )
see them%
0tep !% #reating the #ore of the +evel
The designers should esta"lish the core game play of the level using
"road stro3es. They should get it to the point that it gives them the fun and
challenge they envisioned in the paper design. The designer should then get
feed"ac3 from the lead designer and producerA 4ho 4ill determine 4hether
the level has merit or not. )t may indeed prove impossi"le to accomplish 4hat
the paper design suggestedA or it may prove to not "e as fun as 4as expected.
This is simply a revie4 point in the level design that saves the designer time
should drastic changes need to "e made or the level dropped entirely.
0tep .% ;illing in the ;iner Details
8nce the core game play of the level is esta"lishedA everything else
should Fust ma3e it "etter. These are all the things that esta"lish the settingA
flesh out the levelA and liven up the fun "y providing more optionsA solutionsA
or surprises.
Game Design Documents Page 6!
8ften ne4 art or code assets may seem appropriateA so "e sure the
designers find out they can get them "efore putting placeholders in. Then
update the paper design and tas3 lists.
0tep $% Play Test
@ave the designers play their levels and get as much feed"ac3 as
possi"le. AgainA documentation plays a role here. >e sure they 3eep trac3 of
all their "ugsA feed"ac3 and tas3s 4ith at least a note"oo3 and pencil. )t9s
very easy to lose trac3 of issues at times 1not to mention sheets of paper2A so
a centraliCed data"ase 4ith level specific issues and feed"ac3 is ideal.
Documentation <ilestones and the Development
0chedule
>elo4 is a list of the typical milestones in a schedule and 4here the
documents descri"ed in this series serve as delivera"le items. ;ollo4ing each
milestone 4ould "e a revie4 of that milestoneA 4hich 4ould reEuire approval
to go on to the next. As the production schedule isn9t due until after the "ul3
of the documentationA then there shouldn9t "e an impact on the schedule if
time needs to "e spent going "ac3 to the dra4ing "oard and creating
specifications that everyone can agree 4ith. )t9s a recipe for disaster to race
into production 4ith iffy design documents Fust "ecause of the urgency to
meet an ar"itrary ship date. )n the endA it usually doesn9t save you any timeA
and in fact often leads to 4asted efforts and significant delays.
#onceptual Phase
Document% Game #oncept
Document% Game Proposal
Design Phase
Document% ;unctional 0pecification
Document% Technical 0pecification
Documents% Tool 0pecifications 1if applica"le2
Game Design Documents Page 6.
Production Phase 10ometimes #alled )mplementation
Phase2
Production 0chedule
Technology and Art Demo
;irst Playa"le +evel
Documents% Paper +evel Designs 1not al4ays a delivera"le2
Alpha H ;unctionally #omplete
Testing Phase 1Iuality Assurance2
>eta H ;irst Potential #ode 'elease
Gold <aster H #ode 'elease
There could "e more milestonesA as it9s often necessary for pu"lishers
to have some means of determining and ensuring that progress is "eing
made. 0ometimes there are ar"itrary monthly milestones for particular artA
codeA and design. The ones suggested here are the most common and have
the greatest significance.
Dealing 4ith #hange
)t can "e a "eautiful thing to 4itness a proFect run smoothly follo4ing
these guidelinesA "ut 4hat typically happens is some change to the vision due
to inspiration or mar3et trends. )t9s very easy to slip into designHonHtheHfly
mode to try to adapt to the ne4 vision 4ithout impacting the schedule. 8f
course it inevita"ly does any4ayA "ecause designHonHtheHfly has its dangers.
)n these casesA the only 4ay to ma3e sure this doesn9t happen is to "e
adamant a"out the guidelines and the procedures they promote. This is easier
if it9s spelled out in the contract. Don9t ma3e any changes to the game
4ithout it going through the documentation. A change to the functional
specification potentially invalidates the technical specification and su"seEuent
schedule. )t9s certainly grounds for reassessing the schedule. )t should "e very
clear to the principle designers 4ho may 4ant these changes that 4hen they
signHoff on the functional specification and deliver itA they do so 4ith no
expectations on "eing a"le to ma3e changes. ThenA if they really 4ant the
changeA the impact can "e lessened 4ith a period of updating the
Game Design Documents Page 6$
documentation and a reassessment of the schedule. The threat of "eing stuc3
4ith 4hat you got or "eing late is certainly compunction enough to put as
much forethought as possi"le into the design and produce the "est possi"le
documentation. The guidelines presented in this series of articles should help
you do Fust that.
Artists and Game Design Documents%
;rom )nterpretation to )mplementation
"y ,oshua Gordon
:ithout Euestion the "iggest pro"lem ) find during the design and
implementation of games is the lac3 of interactivity amongst the various
team mem"ers of a proFect. :e've all heard the comments 1lamentsA shoutsA
etc.2 M7ou 4anted it to loo3 li3e 4hatK?K?K?MA MThis is the dum"est character )'ve
ever seen?MA M) said round? (ot spherical?MHHand so it goes. As someone once
said M:ithout communicationA chaos rules.M
This article 4ill focus on the relationship and communication "et4een
artists and designers during the development process. Topics 4ill include%
M>lue s3yM meetingsA the design documentA methods for streamlining the
production process and a fe4 other random thoughts. (o4 a couple of those
randomA "ut importantA thoughts.
Designers% <any Are AutisticA (ot Artistic
:hile some individuals 1sho4 yourselves demons2 are gifted 4ith a
plethora of s3illsH creative thin3ingA the a"ility to spea3 4ellA 4rite 4ell and
create great artHothers are not so luc3y. <any designers find themselves in
the position of "eing thoughtfulA creative and having reasona"le 1hopefully2
communication s3ills "ut a total ina"ility to dra4A model or other4ise
communicate their ideas visually. :orseA many are not 4ell versed in the
diction of art 1you 3no4A Mthose dar3 highlights?M Hor ummA shado4s2.
ThereforeA it's important to remem"er the Martistically challenged designerM
needs your help. Designers can envision 4hat 4e "elieve 4ill "e cool loo3ing
and 4e 3no4 the types of game play 4e are afterA "ut 4ithout significant
participation from the art team it is almost impossi"le to realiCe 1much less
enhance2 the loo3 and feel of the game.
Designs% +oo3ing At the >ig Picture.
8ne final point "efore 4e dive into specifics. Design documents spea3
to a large audience% ProgrammersA artistA level designersA producersA
mar3eting and "usiness fol3sA etcH the 4hole enchilada. This can often ma3e
the document largeA fragmented and a Mhard readM. :hile no"ody loves
Game Design Documents Page 6*
reading several hundred pages of semiHliterate 4ritingA understand that the
document contains information that is crucial to an artist's a"ility to do his
Fo". :hile you may 4ant to s3ip over the treatise on A) 1artificial intelligence2A
or the hyped up mar3et spea3 this is almost al4ays a mista3e. 'ead the
documentA the 4hole documentA you'll "e surprised 1hopefully pleasantly2 to
find information pertinent to the artistic content hiding in some of the
strangest placesHHread the documentA get the "ig picture.
>lue 03y <eetings
;or the purpose of this discussionA let' s define M"lue s3yM meetings as
the preHdesign meetingsA discussions and other Msocial eventsM that ta3e place
during the formative stages of fame. 8pinions of M"lue s3yingM range from
critical to crapP ) "elieve the value lies 1or dies2 in the a"ility of each mem"er
of the team to spea3 his mind. &nfortunatelyA ) also "elieve that all too often
those 4ho are less outspo3en do not get heardA "ut rather are herded. Artist
as a group generally fall into the latter category 1the herded2. )'ve
participated in endless "lueHs3y meetings 4here you can identify each and
every mem"er of the art team as they're diligently doodling throughout the
discussions. :hile )'m sure they're reallyA really good doodles they don't really
help the process.
0pea3 (o4 or ;orever ;eel BictimiCed
0oA 4hat does this have to do 4ith the design documentK PersonallyA )
rely heavily on these meetings to help formulate the game design andA as
importantlyA to understand 4hat the team is interested in ma3ing. Ha great
game design is 4orthless if the team doesn't 4ant to ma3e the specified
game. Artists are as responsi"le for the creative game play content as any
other mem"er of the team. )f you don't communicate during meetings your
thoughtsA ideasA characters and environments 4ill not appear in the design.
#onverselyA if you do spea3 out you'll li3ely find many of your thoughts 4ill "e
present in the document 1even though the designer 4ill ta3e credit for 'em2. )
cannot stress the importance of this point. ) li3e to thin3 of designers as
prospectors loo3ing for ideasA some 4e'll dream up on our o4nA "ut a vast
num"er of ideasA charactersA situations and settings come from others. )t is
our Fo" to a"sor" the input of the entire team and to coordinate and refine
the creative vision. 0oA involve yourself in discussions.
Game Design Documents Page 6=
#ommunicate Bia )magery
@ere's a tip for the fol3s 4ho don't feel all that comforta"le trying to
"e heard through the de"atesA screams and other vocal exercises M"lue s3yM
meetings often "ecomeHcommunicate your ideas through s3etches and
reference material. 0ome of the "est ideas )'ve seen come from artists 4ho
appear at a meeting and drop a chun3 of dra4ings on the ta"le 4ith a Mho4
a"out these ideasM loo3. 'emem"er the old 1and overused2 adageH Ma picture
is 4orth a thousand 4ordsMHgive it a try. )f you're "oredA s3etch a characterA a
sceneA an o"Fect 1anything related to the game as opposed to your personal
doodleHglyphics2. 8ne final noteA the dra4ings don't need to "e high EualityA
Euite the oppositeA as long as they communicate your intentions you're Mgood
to goM. )'ll "e spea3ing more a"out concept imagery later.
Get AheadA Thin3 Ahead
A great 4ay to avoid "eing run over during discussions is to come
prepared. Thin3 a"out the topics for the meeting "efore you arrive. That 4ay
4hen you're in the middle of your idea and the piCCa sho4s upA you'll have a
note or picture to remind you of the point you 4anted to ma3e. )t also give
you the chance to gather your thoughts 4ithout some idiot saying MyeaA so
4hat? Get on 4ith it?M )f you're unsure a"out exactly 4hich topics 4ill "e
discussedA as3 your team leader "efore the meeting. ;ollo4ing is a "rief list of
design items screaming for artistic input%
8verall +oo3 and ;eel
The overall style of the gameA from gothic to technoA earthy to
industrial. :hat do you thin3 the game should loo3 li3eK
#haracters
;rom the player character1s2 through "osses do4n to the smallest
actor. :ho are theyK @o4 do they appearK :hat do they doK
+evelsJNnvironment
:hat types of levels 4ould you li3e to seeK @o4 should they loo3K
Game Design Documents Page 6-
<enuJ)nterface 0creens
They're almost al4ays an after thought yet the player interacts 4ith
them constantly. @o4 can you Fuice them upK
The Design Document
8/. The meetings are overA time has passed and the designer appears
4ith his magnum opus to the gaming 4orld. :hat is this thingK :hat did the
designer intendK @o4 much latitude do you have artisticallyK These are hard
Euestions to ans4erA game designs and designers come in all flavorsA shapes
and siCes. )'ve never seen t4o ali3e. @o4everA most design documents should
and 4ill spea3 to a set of game elements critical to the art team. ;ollo4ing is
a discussion of these elements and hopefully ans4ers to the Euestions a"ove%
'ead the :hole Thing
) said it a"ove and )'ll say it againHread the 4hole document. This
discussion 4ill focus on sections of the design that related specifically to
artists "ut remem"er you 4ill find pertinent and interesting items throughout
the document. ;orA exampleA much of the "usinessJmar3eting 4riting may
seem li3e a 4aste of timeA it's not. @eld 4ithin are the desiresA reEuirements
and most importantly the expectations of people 4ho you may not see "ut
4ill definitely impact your 4or3. &nderstanding ho4 the fol3s outside your
team are thin3ing is crucial. Another good example are the game play
dynamicsJmechanicsHthe "asic rule system for the game. &nderstanding the
core game play 4ill help you avoid designing charactersA o"Fects or scenesA
4hich 4on't 4or3 4hen placed in the game. :hile a ceiling danglingA fireH"all
shooting slug "oss may "e a cool idea it 4on't "e all that cool if the player
character can't Fump high enough to reach it and doesn't have a proFectile
4eaponHHmeaning the player can't fight your cool "oss 1generally not a fun
thing2. Al is another area often overloo3ed. )n my documents ) include a small
paragraph that outlines characterJo"FectH )f the character 3ic3s it "etter have
legs. )f it shoots roc3etsA it needs a roc3et launcher. ) thin3 you get the point.
8ther Al items can "e su"tle. )f the characters stop and loo3 around 4hen
they hear the playerA you need to ma3e sure they have heads that s4ivelA
"odies that rotateA etc.
Game Design Documents Page *5
Game +oo3 and ;eel
A section on the game's loo3 and feel is intended to communicate and
reinforce the overall graphical style of everything from the characters to the
environments. &nli3e many other areas of the game designA the game's loo3
and feel is almost al4ays decided up frontHother4ise you end up the
MGamorama NclectiaMHa hodgeHpodge of imagery 4ithout a cohesive themeA
loo3 or style 1generally not a good thing2. )nput should "e given during the
'"lue s3y' meetings andJor art specific meetings during preHproduction. )t is
during this formative period that you can affect the loo3 of the gameHand it's
a loo3 you 4ill live 4ith for the duration of the proFect. 0o 3eep you eyes and
ears open during this process and 4hen revie4ing drafts of the design
document. )t is also helpful to clarify the loo3 and feel during the design
creation process. )f the 4ording is am"iguous or unclearA don't hesitate to as3
for clarification. Barying from the game's overall loo3 and feel is ill advised.
;ollo4ing is a sample description of the loo3 and feel of a moc3 game titled
<egaHGame%
+oo3
<egaHGame 4ill use an edgyA hyperHrealistic style to portray a dar3A
alienA devastated loo3 4ith some lighter environments used for "alance and
contrast. Nach game environment 4ill vary significantly from the others
containing different musicA sound ;JSA color schemesA "ac3groundsA and (P#s.
The loo3 4ill generally "ecome dar3erA stranger and less MnormalM as game
play progresses. At the game start the loo3 4ill resem"le that of 0tar :arsA
to4ard the end it 4ill have a more postHapocalyptic Terminator loo3.
;eel
The feel 4ill "e that of a lone person or group on an almost hopeless
campaign to stop a universe threatening evil. The player should feel an
overall sense of an ongoing and increasing destructive forceA veiled in mystery
and intrigue throughout the game. As the player progressesA the story and the
player's ultimate o"Fective 4ill "ecome more clear 4hile the feel "ecomes
more and more t4isted and evil. An increased sense of a maniacal and
ruthless presenceA 4hich must "e overcomeA gets stronger and stronger.
There 4ill "e a strong emphasis on am"ience in <egaHGame. The
"ac3grounds 4ill "e MaliveM 4ith activityP utiliCing "ac3ground animationA
palette shiftsA etc. The music and sound ;JS 4ill "e used primarily to enhance
this MliveM and realistic feel.
Game Design Documents Page *1
(P#s
All (P#s 1nonHplayer characters2 4ill "e rendered in !D. They 4ill loo3
and "ehave as MrealisticallyM as possi"le. )n generalA this means that a large
strong loo3ing (P# 4ould cause greater damage and have greater resilience
than a smaller (P#. 1(ote% 8"viouslyA some smaller (P#s 4ill "e capa"le of
inflicting heavy damageA much as a rattlesna3e can severely damage a
human2.
(P#s 4ill loo3 and feel dangerousA aggressive and deadly 1the "ad
guys2. This is importantA as the player 4ill only "e allo4ed to fight 4ith M"adM
dangerous entities. <egaHGame 4ill (8T allo4 the player the opportunity to
attac3 any entity 4hich is nonHaggressive.
>ac3grounds
All "ac3grounds 4ill "e rendered in !D. As discussed a"oveA each level
4ill loo3 uniEue andA in generalA the levels 4ill "ecome increasingly dar3 and
t4isted as the game progresses. )deallyA the player should "e a"le to identify
any level 4ithin the game purely "y its "ac3ground.
+evelJNnvironment Description
)n general each level of the game 4ill "e descri"ed 4ithin the game
document. There should "e some4hat more latitude here than in the overall
loo3 and feel. That isA as long as the overall game loo3 and feel is follo4edA
the specific loo3 of any level can vary some4hat. )t is critical to understand
the plot line as it relates to the current level. )n the overall description a"oveA
it specifies that the game 4ill "ecome progressively dar3er and stranger. )f the
current level is at the "eginning you'll have less latitude to MgoHcraCyMA 4hile if
at the end of the game it is almost a reEuirement. During production you'll
4ant to 4or3 closely 4ith the level designer 4ho 4ill "e laying out the level.
A fe4 important items to note 4hen designing the loo3 and feel of a level%
Al4ays 3eep in mind the player characters' s3illsHcan the
character FumpA runA s4imA clim"A etc. :hile you may not end up
laying out the levelA your art4or3 4ill affect 4hoever does and
ultimately the funJchallenge of the game.
:hich characters are specified for the level and ho4 do they
"ehave. #haracter "ehavior 4ill often dictate the
architecturalJterrain styleH4all clim"ers need lots of open 4alls to
clim"A 4ater d4ellers need la3esA riversA aEueductsA fountainsA etc.
;ast characters need open or guided areas to move 4ithinP characters
4ith proFectile 4eapons or tools reEuire room to shoot and o"Fects to
hide "ehind during firefights.
:hat type1s2 of game play are designed for the player in this
levelK )s there a significant amount of movement 1hoppyHFumpy2A
handHtoHhand com"at shootingK Nach reEuires architectureA terrain
andJor o"Fects to aid the game play. A good example of game play
affecting art is related to MFumping aroundM. Does the game play
dictate Mdeath fallsM 1falls 4here the player is 3illed if a Fump is
missed2. )f the ans4er is yesA you need to create "uildingsJterrain 4ith
gaps high enough to M3ill the characterM. )f the ans4er is noA you'll
need to avoid high FumpsA orA create MnetsM 1o"FectsJterrain that catch
the player during a fall.2
;ollo4ing is a sample level description%
The ;inal #ham"er
A huge spacious cavern 4ith organic 4alls similar to those in MaliensM.
The ;inal #ham"er is suspended from the ceiling of the cavern. 0everal
M"ridgesM lead to the cham"er from the edges of the cavern. Thousands of
characters are moving enHmasse across the "ridges and into the cham"er
4here they are destroyed. The cham"er pulses rhythmically creating a deep
horrific soundA 4hich emanates throughout the cavern. All visi"le light pulses
to the "eating sound.
Due to the damage inflicted "y the crashing ship 1previous level2 and
the damage done "y the player reaching the #ham"erA the entire cavern is
"eing roc3ed "y sporadic Eua3es and explosionsA falling de"ris rains
do4n4ard and the "ridges leading to the cham"er sha3eA pieces snap off
dropping to the cavern floor far "elo4.
The #ham"er itself is a roundish structure 4ith the sine4y
"iomechanical supports leading to the ceiling and floor of the cavern. :ithin
the cham"er are a handful of elite enemy characters 4ho orchestrate the
death march of the other characters as they enter the cham"er and are
a"sor"ed "y the machinery at the cham"er's core. AdditionallyA there are
large automatic defense systems used to guard this humongous machine and
its ruler.
1. +oo3J;eel%
The inner sanctumHA holy 4orship of evil 1thin3% @ellraiser2.
Game Design Documents Page *!
A dar3 placeA full of death and suffering.
Bisually stunningA glo4ingA sha3ingA lots of movement.
(ote% The last level of the game.
. Path% Diagonal do4nA @oriContal .
!. GameplayJDynamics +ist%
)ntense actionJplatform.
@eavy fighting.
0lide dynamics.
Timed escape.
.. 0tory Nlements%
<a3e 4ay to the ;inal #ham"er.
;ight to Minner sanctumM.
Defeat >oss.
Nscape the level "efore the cavern collapses 3illing the player
(ote the inclusion of loo3JfeelA the "asic path4ayA game play dynamics
and story element "ullet points. These are all intended to help the artist and
level designer focus on items crucial to the game play andJor loo3 and feel.
#haracters
0ome of the largest parts of design document 1at least in my case2 are
the character design sections for the main player character1s2 and the
numerous (P#s 1nonHplayer charactersHenemiesA monstersA etc.2 @opefully the
designer 4ill have created a template used to define each character. This
helps the readers "y providing a consistent formatA 4hich allo4s the focus to
rest on each character's specific traits. #haracter design is an area ripe for
artist creativity and input. As long as the artist understands the purpose of
the character and its actions he can generally em"ellish and refine to his
heart's content 1limited "y those t4o pes3y restrictions% time and money2. )
"rea3 do4n my character designs into the follo4ing sections% descriptionA
referenceA health and damage informationA Al notes and animation list. Nach
is listed "elo4 4ith a "rief description of its intended purpose. #om"ined the
Game Design Documents Page *.
information provides a set of guidelines 4hile still leaving lots of room for
interpretation.
Description H A one or t4o paragraph outline descri"ing the initial
vision for the character and an overvie4 of its attri"utes.
#haracter references H BisualsA dra4ingsA videotape or other preH
existing material used to clarify the loo3 or actions of the character.
@ealth and Damage H @o4 much damage the character can ta3e
and ho4 much it can deliver 1per attac3 type2. This item is often
overloo3ed "y artists and can "e extremely important. Does the
character need recoil animation frames or death animation framesK
@o4 po4erful is the character relative to other charactersK Does a
single "lo4 significantly damage the player character1s2K
#haracter Al H A description of the character's "ehaviorA movement
and actions. AgainA this section is often passed over "y artist yet it is
3ey to defining the character's structureA loo3 and the set of
animations reEuired to enact the "ehavior.
#haracter Animation +ist H A summary list of the animations
reEuired for the character. )t is strongly recommended that you
complete any animation list 4ith the other items that define the
characterA often the list 4ill "e missing animations 1no"ody's perfect2A
or they 4ill "e inadeEuate for the artist's purposes.

Game Design Documents

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Game Design Documents

Uploaded by

Copyright:

Available Formats

Game Design Documents Page 1

You might also like