Game Design
Ryan Clark
Copyright Jan 19, 2000
Page 1
Introduction
Game Design - Tips for the one-man army.
I have read thousands of pages of information regarding game design,
but only rarely have I seen discussion directed at the lone developer,
the "One-Man Army." I know that there are many of you out there, like
me, alone or with small supporting groups, hoping to compile your
myriad keystrokes into a playable work of art. Doubtless there have
been times when you've wondered whether it actually would be easier to
get an infinite number of monkeys and an infinite number of compilers
to see if one will code the next Quake killer. Well I say to you, lift
your mind out of that blissful monkey-gutter and take heed. Small
developers need to work smarter, not harder, and here are some ways to
do it.
Preparation
The Concept
Make sure that your game idea is something that sets your imagination
ablaze. You are going to be working on this project for a long time
hence, and if it doesn't positively tickle your fancy right now, you
can be sure that any tickling will end after the honeymoon. Talk to
your 'game playing' friends and see what they think. If you can't get
them excited about it after five minutes then your idea probably isn't
that good. The initial thrill of the concept is what gets people to buy
games, and if you can't thrill your partisan friends, how can you
expect the gaming community to be thrilled by the description on your
box or web-site?
Coming up with a great idea is one thing, but
you also have to be realistic with your vision. You know what you are
capable of achieving, don't fool yourself into thinking you're better
than you are. Design with your limitations in mind and you'll have a
much easier time when you finally start to code. Never let your
imagination run completely off the leash and then try to stretch your
technology to fit it, you will end up with the computer game equivalent
of a fat man in spandex.
Have a brainstorming session with
anyone that you feel has good insight into games. Come up with as many
'cool' additions to your concept as you can and be sure to write
everything down. After the session, take your notes and carefully craft
a feature list from the ideas that please you most, only you truly know
which are going to be feasible. Split your list into three sections:
Required, expected, and hoped-for. All of the ideas that you believe
are needed to make your game complete should be flagged as 'required'.
Any ideas you know would add greatly to your game but are not essential
should be 'expected'. And finally, those far-out and possibly difficult
to implement features that you've conceived should be labeled
'hoped-for'. Later, when identifying your milestones and deadlines,
take these three categories into account. You must ensure sufficient
development time to include all of your 'required' features and as many
'expected' ones as possible. If you have time left over afterward, try
your hand at some of the 'hoped-for' ideas, but don't get too attached
to them incase you have to let some go as the deadlines draw near.
The Design Document
There are divergent theories regarding the purpose and creation of
the design document. As I see it, for the small developer it does not
matter so much how you make your design document so long as you make it
concise and complete. Ensure that your design doc describes everything
in your game, from top to bottom. If you're going to have to program
it, record it, or draw it, it should be in this document. Describe the
functional specifications first, and only when this is finalized should
you create the technical component. Describe every algorithm you intend
to employ and every solution you intend to implement. If you can't
think of a solution for it now, don't include it in your game. Never
assume that you'll "figure it out when you get to it."
Keep your
design doc as modular as possible so that it can be easily added to or
subtracted from. If you need to make changes to it down the road you
should be able to do so without disrupting any unrelated items. Having
said that, I must now emphasize the importance of sticking to your
document once it's complete. Of course it is wise to allow for the
possibility of change, but as much as possible you should keep your
design static. It is very difficult to hit a moving target, and we all
know that hell hath no fury like a programmer scorned.
Once your
design doc is complete, coding should be a breeze. You'll already have
all of your solutions identified and you'll have a complete list of
items that need to be implemented. Just go through the list (in order,
have discipline!) and barring any major design changes, your game
development shall press forward like little girls at a Backstreet Boys
concert.
Deadlines and Milestones
Even the one-man army must make milestones and deadlines for
himself. Whether you have a publisher or not, it is a beneficial
practice. When you pass a milestone it's kind of like getting a pat on
the back, you know you've done well and it makes you feel good to know
that things are progressing. Additionally, the presence of deadlines
and schedules will entice you to do what needs to be done and to do it
on time. Without these constructs the development path becomes blurred
and you will find yourself straying to work on items further down the
path simply because that's where the 'fun bits' are. Development is
undoubtedly most efficient when undertaken logically and sequentially,
so make your design such that this process will be as painless as
possible.
Peruse your technical and functional documents and
extract what seem to be the most important milestones. Apply to these
milestones reasonably generous deadlines wherever possible. There is
nothing worse than the feeling you get as you see your deadlines flying
past and you realize that you are slipping, so keep this in mind.
If
your project has no set ship date, allow as much time for testing and
QA as you can. It is impossible to predict what problems may arise
during these times, so it is best not to try to compress the schedule.
You will know when you are satisfied with the quality of the product,
so ship when you're good and ready - one of the advantages of being an
independent one-man army.
Programming
The Engine
I hate to state the obvious, but it's what I'm good at: Make your
engine solid. Do not skimp on the development time you spend here, you
will pay for it later if you do. Would you rather buy a car with a
German motor, or something made in Cuba? Spend time on your engine
until it is complete, never assume that you can patch it up and hold it
together as you go. Duct tape can only do so much, even Cuban duct tape.
Make
the engine as general as possible. If you hard code anything naughty
into it you deserve to be thrown in the Sarlacc pit. Allow for as many
details as possible to be file driven. Every world, level, or character
should be loaded from a file created by your in-house tools. Try not to
describe AI in code either, create a scripting language and allow
everything to be interpreted at runtime.
I am a proponent of
object-oriented design. Any performance decrease you may encounter will
likely be negligible since the one-man army is rarely trying to create
cutting edge polygon pounding products like the big-boys. Lone
developer games need to impress gamers with their style, originality,
and gameplay, not speed and flashy effects. You will therefore likely
have enough leeway to incorporate an object-oriented design. This will
allow you to integrate new unexpected items (and they will arise, no
matter how hard you try to stick to your design doc) more easily and it
increases the overall robustness and reusability of your code.
Reusability is of prime importance to small developers; anything that
can cut down production time for the next game is like money in the
bank.
Tools
Gentlemen, start your engines! This is where all the hard work you
put into your game engine will start to pay off. In the real world of
game development, the programmers are rarely the ones designing the
levels or setting up the world. They need to create user-friendly tools
to allow game and level designers to interface with their beautiful
engine. Things such as level builders, character animators, AI script
writers, etc, will all facilitate and expedite the jobs of the
designers.
I can hear the one-man army saying "I don't need
tools, I do it all myself," but I don't believe this to be true. Your
game will end up looking more polished and refined in the end if you
have easy to use tools at your disposal with which you can tweak your
levels and get the most out of your engine. It is very hard to tell
what will be fun before you actually try it, so allowing easy
modifications through the use of tools will give you the power to tweak
up the level of fun with minimal effort.
Make your tools as
reusable and general as possible while still maintaining their utility.
Think ahead to your next game (or games) and try to ensure that the
tools as a whole, or at least some of the code, will still be useful.
Lone developers are usually not as affected by hardware advances as are
big developers, so tool reuse is quite plausible and beneficial.
The Interface
The interface should be as unobtrusive as possible. When the player
doesn't need it, it should ideally not even be there. Make actions
available to the user only when they can be performed, give the user
information only when it is needed or requested. By accomplishing these
goals you can ensure that the player never loses his sense of immersion
in the game world. The longer you can hold him in there, the better.
People play games as an escape or release, they do not want to have to
deal with uninteresting or extraneous information like they do in real
life.
In order to keep the player immersed, seek to avoid any
harsh 'reality checks' such as loading screens or menus that don't seem
to flow with the game. It's similar to what happens when a 'blue screen
of death' pops up while you're madly coding. You are awoken from your
WinDoze and you realize that the world is not a happy place full of
icons, menus, and 'for loops'. Don't do this sort of thing to your
players; you know how much you hate it when it happens to you.
Intuition
is the language of the soul, and the game player. Seek to exploit any
previous knowledge or habits that your target audience will have. If
you're making an RTS, for example, ensure that you include items now
standard to the genre such as click-and-drag selecting and shift-click
to add to group. Try to use obvious, unambiguous, and habitual
metaphors for your buttons and mouse cursors. When a player can't walk
in a certain direction, change the cursor to the big red 'no' symbol,
or give audible feedback; ensure that you give him ample queues to that
effect.
By far, the greatest thing about interface design is
that it is just as easy for a lone developer to create an outstanding
interface as it is for a large developer. It costs little to implement
these sorts of ideas since all it takes is ingenuity and a little
savoir-faire. Set your phasers on stun and try to wow your audience and
out-do the big-boys. This is one of the few areas where you may succeed.
Multiplayer
Is multiplayer required for your game? Most people nowadays are
quick to say yes to this question without properly thinking it through.
In truth, not all games really suit multiplayer action. I know I
wouldn't want to play a turn-based strategy (TBS) against seven people
over the internet; it's bad enough waiting for the computer to take its
turn in a single player TBS game, let alone a human. If nobody is going
to play it, should you bother to include the option? If you feel your
game will sell more units if it has the word "multiplayer" on the box,
then go ahead, but if you think that decreasing development time is
more important, then I'd advise you to drop it.
Now, truly there
are many games that do suit multiplayer and would fail without it as an
option, the RTS and FPS genres to name a few. Deciding on the solution
you'll use for programming the multiplayer feature is a critical one
for the lone developer. You likely have limited resources and paying to
maintain a dedicated server is probably not at the top of your 'things
to spend my money on' list. You need to put a lot of thought into
whether you're going to go with a peer-peer or client-server system.
Peer
to peer (P2P) is definitely the way to go - if you can make it work.
Sending packets directly between the systems involved is certainly
faster than bouncing them off of a server, but it can start to become
costly as the number of players involved begins to rise. A two player
game is ideally suited to P2P architecture, but as more players are
added each system has to send (and receive) increasing numbers of
packets in order to inform every other system of its game state. Packet
loss or lag can cause fragmentation, and your code would need to be
quite robust to hold high numbers of lagging systems together in a P2P
state.
With a server, however, the burden on the individual
systems is lightened. A client's sole duty is to keep the server up to
date, and it is the server's responsibility to inform the appropriate
clients of these updates. The indirect nature of information transfer
in a client-server mode can increase lag, however. Data flows from
client to server to client rather than from peer to peer. The
intermediate server step can add to delay and have adverse effects.
Ever play that old game 'telephone'? Similar misunderstandings can
occur as a result of lost or late packets from the server.
Fragmentation is not an issue, however, the server can hold the world
together effectively, only losing individuals if their lag becomes too
great.
Setting up a dedicated server of your own can be costly
and is obviously a deterrent for use of the client-server method, but
allowing one of the players to act as a server can solve the problem.
If the player with the fastest computer and best connection starts the
game (acts as the server) then this method can be employed effectively.
It is a tempting alternative indeed for the lone developer, and one
that I would recommend investigating.
Testing
Burnout
There's nothing worse than the smell of burnt toast - when it's
coming from one of your tester's craniums. Testing is obviously vital
to your game's success as the public and media will tear you to pieces
if your game is found to be buggy. It is important, therefore, to keep
your testing schedule light and varied in order to prevent the burnout
of your testers. When they look at the same levels over and over for
days on end they're bound to become lax and miss a bug or two.
Switch
it up. If you have any other games in development give your testers a
variety of tasks. You must destroy the assembly-line feel of testing
since it numbs the mind - the very thing you need at peak performance
for effectiveness. If your game has a multiplayer option, use it as a
reward for your testers, let them test the multiplayer after a hard day
in the trenches. Keep the balance between multiplayer and single player
testing appropriate, however. If your game is mainly a single player
offering with multiplayer as a bonus, ensure that the single player
aspects are sufficiently emphasized.
Fun Factor
Bring in testers from outside your development group to test the
playability and fun factor of your game. Let the tester play the game
uninterrupted and unaided to see where he has the easiest time, where
he gets killed too quickly, and where he gets stuck. If you have
allowed enough variability in your engine and your tools, you should be
able to tweak and tweak and tweak until you make the levels fun. If
your engine was too rigid to begin with you may find that your game
isn't fun no matter what you do, so beware.
During your
observations you may notice that a puzzle or course of action that
seems completely obvious to you will be anything but obvious to an
outside entity. Ever try opening one of those childproof bottles, and
fail? That is what your testers may feel like, so be sure to nip it in
the bud before it's passed on to the consumer. Nobody likes to feel
like an idiot.
Be conscious during your design to provide 'fun'
at a steady pace. It should never be a breeze, nor should it be
impossibly hard. You should, additionally, allow the player to go at
his own pace. As seen in FPS games, you go into a room, kill some
monsters (fun) and when you're ready for more 'fun' you venture forth
once again. Don't fluster the player with a deluge of monsters and
action at all times, give them a chance to dictate the flow of the
game. Testing is imperative in getting this right, it simply isn't
something that you can predict with any accuracy during the design
phase.
When people run out of 'fun' they stop caring about the
game world and start trying weird things. They shoot at their wingmen
and try throwing fireballs at villagers. You don't want this sort of
thing to happen, so take the feedback from your testers seriously. When
you are told repeatedly that something isn't fun or that something else
is, you should listen. You are likely too involved in the game to see
the truth of the matter.
Some Closing Tips
Read
everything that you can get your hands on regarding game design.
Regardless of the fact that most of it is written by the big players in
the business, the fact of the matter is that the community is mostly
made up of small developers like yourself. The data is still relevant
and can be bent to suit your needs. I find postmortems are especially
informative as they allow you to see where the big developers went
wrong, and how your game can avoid a similar fate.
Continue to
play games, lots of them, and of every kind. But not only should you
play them, you should study them. You must first know your enemy and
his tactics before you can ever hope to defeat him. Find out how Quake
has trained you to drool at the mere mention of the word "frag." Why
does Pokemon melt the brains of small children? What is it that makes
the Warcraft series an enduring classic? In other words, ask yourself
what game developers are doing to stay on the top of the heap, and soon
you'll be up there shoving 'em off.