Designing Computer Games
------------------------
by Adam Wiggins (boone@ucsd.edu)
So why do we play computer games? I know that my love of game
programming second only to actually playing them. In fact many long
hours have been spent playing Angband, or Might and Magic, or Wing
Commander, when they could have been spent doing something more
productive like actually working on my own projects. But of course,
you can't write games without a good feeling for what's already out
there. Most of the very best game designers and programmers are
also avid gamers. And that is, I think, what sets apart game
programmers from other parts of the computer industry: there's
really no one in it who considers it just a job (at least, no one of
significance). Game programmers work long hours for pay that may or
may not be as good as the guy who works down the street 9 to 5
writing database front-ends. But hey, it's something we love, and
that makes it all worth it.
So what am I getting at here? I probably haven't told you
anything you don't already know. What I'd like to cover in this
article is something a little broader in the area of game design:
how can you make a game "good?" It's hardly something you can easily
describe, and nearly impossible to put into a design. Game players
even have a fairly wide range of opinions on what exactly is "good"
- does it mean fun? Does it mean enthralling? Does it mean
exciting? Does in mean awe-inspiring? Probably all of these
things, and more.
So how does one go about designing a game that is going to turn
out to be something people will want to play again and again? Stuff
like "we'll put in cool graphics, that'll make people want to play
it a lot" hardly does it. This might seem obvious, but it doesn't
seem to be these days. So many developers focus on filling up a
CD-ROM with pretty pictures and sounds that they forget about making
an actual game. Even people who are just getting started in trying
to write their own games seem to spend more time wondering how to
get into mode X or play digital sound or replace the keyboard
interrupt. All these things are certainly important, but they all
come later in the development of the game, during the actual coding
phase. I know that when I first started attempting some small
games, my first thought was to just start coding and see what I came
up with. The result was that I often didn't quite realize where I
was going and often ended up backtracking because I realized that
something wasn't going to work the way I had envisioned it, namely
because I hadn't thought it through. For a small project, though,
this isn't a big deal. For a large one (like any sellable game
would be) this can be fatal.
Let's assume, now, that you know how to program, and you know how
to program games. Now you want to put that knowledge to use by
creating a game that you can throw out onto the shareware market, to
get yourself "known" in the industry, and maybe even make a little
money on registrations. As a programmer, your first response is
probably to sit down and start by typing out main(). But that's
jumping the gun quite a bit. Instead, I recommend a (fairly simple,
actually) process before you ever begin coding. Obviously how you
do this is going to vary, and you should use whatever works best for
you. But I can't emphasize enough how important the design phase
is; don't get impatient and try to jump into coding.
Side note: the one exception to this is if you have an idea for
an engine using a new technique for 3D rendering or something. In
this case you'll probably want to write a small test program to make
sure your technique is going to work. I'll assume, though, that
you're writing a game for which there is already a "standard"
engine, such as an overhead RPG, a side-scrolling shoot-em-up, a
hex-based wargame, etc.
1) First things first - what kind of a game do you want to write?
This is going to depend a lot on the resources available to you. If
you don't have an artist and don't plan on getting one, and you're
not an artist yourself, you'll need to to something for which not a lot
of bitmaped art is needed. This might be a polygon-based flight
simulator or arcade game, or perhaps a tile-based wargame or RPG.
Also it should probably be a game which is going to appeal to *you*.
If you don't like wargames, don't try to write one just because the
art is minimal. I don't know what all to say about this, since
understanding your resources is probably only something that comes
to you once you've tried to do a game, so if it's your first try
you'll just have to take your best guess. If nothing else, plan on
something that you're sure you can do, rather than something that is
a little beyond your reach but you think you can probably do. This
stage is much more critical for "original" games. Once you decide
to do a side-scroller, you've probably already got a good feel for
how it works and the basic game mechanics since there are tons of
them out there. If it's something like Tetris, where the idea is
almost totally new, you have no idea whether the game has even the
potential to be fun. Games like these have a much bigger chance to
do really, really well since no one has ever seen anything like them
before (Tetris, Lemmings, and SimCity are all good examples) but on
the other hand it has a much larger chance of simply fading into
oblivion. (Remember Atomino, or Pipe Dreams, or Thunder Strike?
Didn't think so...)
2) What kind of game you pick isn't incredibly important, as long as
it's got potential (most do). The stage that is most important is
this one right here, number two. You probably should do no coding
until this stage is complete. What you do here also varies widely
with what type of game it's going to be. The most important thing
is to start out broad: what's the best thing about my game going to
be? If you answer "cool graphics" I condemn your game to rot on the
shelves along with Outpost and Strike Commander. If it's an
adventure, the answer should be something like "story" or
"setting." If it's an RPG, the answer should be something like
"exploration." If it's a shooter, the answer should be something
like "action" or "excitement." And so on.
From there, you also need to define how the game is going to try to
make you feel as you play it. Many games suffer from a sort of
schizophrenia in that they seem to get confused whether they are
trying to be funny, or mysterious, or exciting. Not that a game
can't be all of these, but balancing multiple moods is very tricky.
You need to pick a mood and put most of your effort into promoting
that. Doom, to pick one of the most wildly successful examples of
this, has you crawling through dark corridors, battling demons, and
doing other similar stuff, all of which promotes the suspense. They
back it all up remarkable well with dark graphics, low and driving
music, demonic sounds, etc - just like any good suspense thriller,
except it's all that much better because the player is the one in
control. Similarly, Lesuire Suit Larry has done remarkably well
given fairly linear plotlines and trivial puzzles due to the
constant antics of Larry Laffer. Ultima places you on a huge map,
gives you many virtual miles of dungeons, countrysides, and towns to
explore, filled with distinctive NPCs and interesting plot twists.
Maybe I'm using too many examples - you're thinking, "Okay,
that's great, but I want my game to be different!" It's hard to
just tell you how to do it, or even give an outline for it. I'm
just trying to give examples to show how games focus on one mood and
put all their resources into bringing that to the user. You might
even argue that wargames are different, since they are a more
objective type game - mostly lost of numbers and such. But a good
wargame makes you feel like you actually are controlling real units,
which respond realistically to your commands. A good wargame makes
you surprised when an enemy craft slips through your defenses, and
makes you feel pride when you draw your opponent into a carefully
constructed trap. I suppose the only *real* objection to this type
of game design would be totally abstract puzzle games like Tetris.
In this area, I can't offer much help, particularly since I really
play very few puzzle games. On the other hand, these kind of games
are in the minority, and I'd probably encourage you to avoid them
unless you think you have a really unique and intersting design.
Puzzle games are probably the most numerous type of game in the
shareware market, but very few that I have seen have done well.
Once you've established the basic goals of your game, start
getting more specific. But always keep the goals in mind for each
element of the game. Start with a broad idea of how the game will
play, and focus in on individual elements, right down to the
nitty-gritty of the interface, what kind of algorithms are going to
be used for the low-level stuff, etc. You are, of course, limited
by whatever the current technology can handle, so keep that in mind.
Write everything down; if you've got multiple designers working on
the game, sit down and brainstorm, but be sure to record it all.
Think every element through, make sure that it's exactly what you
want to do. Draw screen sketches, consider how you will code the
stuff, etc. When I first sat down to work on the game I'm currently
working on, I wrote out about 20 full pages of specs. It a fairly
simple game, and I'm glad I did that much but I almost wish I had
done 50 pages, or 100. When you've got more than one person that's
going to be working on it, this is even more critical - make *all*
the important design decisions here, and write them down so that
there is no misunderstanding later.
3) Okay, now all that's left it to write the damn thing, eh?
Naturally this is going to be the most time-consuming part,
depending on the complexity of the project, the number of people
involved, and what kind of tools you have available. But, you're
probably wondering, where to start? Now that you have a
well-documented spec for your sure-to-be bestseller game, should you
just plop down and start writing out your main? Or perhaps start
building the low level functions first? If you're doing a the type
of game where the engine basically _is_ the game (such as a
simulation or arcade game), you'll probably want to start low and
build your way up. If you're doing a strategy or puzzle game, it's
probably better to start by writing a text or simplified version of
the game, just to see how it plays. My preferred technique involves
a sort of "middle-last" approach. Rather than doing top-down or
bottom-up, I do both at once; I begin by writing out my header files
and my main function, then build the low level modules and gradually
work my way towards the middle-level functions. I also know people
who take this a step further - one guy likes to write out *all* his
header files before writing a since line of actual code. This isn't
a bad idea, as thinking about what kinds of data you're going to be
dealing with forces you to consider everything more carefully, in a
way that isn't really possible when you're just thinking about the
algorithms in an abstract way in your head.
You also have to consider what tools you already have available
to you: if you're writing a tile-based RPG from scratch, you'll
probably want to write a map-editor first. This will allow you to
define the file formats, write up simple display routines and such,
but since the editor probably isn't something that is ever going to
be released to the public, you can make mistakes, write a simplified
(read: unoptimized) version of your display routines, etc. There
are also all kinds of small low-level modules that you need: compression
routines, graphics functions, music and sound effects libraries,
text display, keyboard handling, etc. Some of this you may already
have from past projects, or you may have a prepackaged library for
some of these things. If you're going to put in modem play
(multiplayer gaming is the Next Big Thing, hint hint), you'll need
to write comm routines and smooth them out before trying to
integrate them into the game, etc.
4) So now you've spent every night of the last 14 months hunched
over your keyboard, swilling Pepsi by the two-liter with Sepultura
blasting through your stereo and twinkie wrappers all over the
floor, and you've written what seems to be a complete and working
game! Now enters the final stage, one which tends not to get the
emphasis it deserves. Assuming you stuck to your design fairly
well, and your design was a good one in the first place, your game
should pretty much achieve whatever goal it was you were after. But
now it's time to put it to the test. Of course you'll want to test
it quite a bit yourself, checking for obvious bugs and problems, but
now you need to turn it over to someone apart from the project, who
can come in with a fresh view and find those bugs you overlooked,
point out which features are annoying, which things don't make
sense, etc. This can be frustrating, as you may feel at this point
as if you've really finished writing the game, but you haven't.
It's easy to get annoyed when people find problems with your program,
but you have to roll with it, as it's all a part of the process.
I've been on both sides of the testing fence, but more often the
programmer. I know how frustrating it is when you write what you
think is the absolute, final, perfect version and two hours later a
tester appears at your door with a list of bugs, misspellings,
formatting problems and so on. At any rate, *don't* try to cut this
stage short. You'll be anxious to get it out on the market, but
releasing products to early has been the death of many products
which turned out to be quite good once they finally got to what
really should have been the release version (Darklands and Ultima 7
come to mind...).
One thing I'd like to throw in here, because so many games have
had this problem, is how important the little things are. That is,
I've seen many, many, many games over the years which could have
been truly excellent but were rendered nearly unplayable (or at
least highly annoying) due to little quirks in the interface or
engine. The interface, as with any computer program, is highly
important. In a game, the best interface is the one that you see
the least of - a truly intuitive interface will feel as if it's not
even there, whereas a bad one will distract all attention from the
game to itself. Mainly, it should be fairly obvious for someone to
figure out, but much more importantly is that it should make mundane
tasks (like pulling up stat sheets, or your inventory, or your
score) easy and quick once you learn how to use it. If there's
something that the user is going to be doing a lot, don't make them
go through multiple menus every time - have a single hot key.
Sounds obvious, like a lot of the ideas I'm presenting here, but I'm
constantly amazed at the crap many games make you go through to do
something as simple as finding out what weapon your character is
wielding. Aside from the interface, try not to place annoying
restrictions on the player, just to "make it tougher." This
includes stuff like giving them very limited inventory space,
forcing them to save only at inns, or not being able to pause during
critical situations. Keep in mind at all times: it's a game, it's
supposed to be FUN. If you want to make the game challenging, then
bump up the AI, or add more puzzles, or make good items harder to
come by, or _whatever_. Arbitrary restrictions simply annoy the
user and make him or her not want to play your game.
Finally, remember that everyone has different preferences. Your
interface should give the user a choice of how to do things -
clicking on icons, pressing hot keys, pulling down menus, or any
combination of the above. Arcade games should have fully
customizable keys. Strategy games should have a lot of options for
the AI's behavior, starting situations, fog-of-war, and other stuff
that varies from person to person. Even doing something as simple
as putting in difficulty settings on your RPG can open up your
product to whole new audiences. The user wants to explore a world
that you create with your game - they should never feel tied down by
the limits of the program, or simply by what the designer thinks
they might want. You can't please everyone, but forcing the player
into a linear little path and leading them through by the nose
pleases (almost) no one. And of course those "little things" that
you put in as extra touches, things that make the gamer say, "hey,
cool" or perhaps chuckle a bit, are always fun, and not a whole lot
of work. It could be putting in a secret level, or a special unit
not mentioned in the documentation, or even just an obscure little
gamer in-joke. (I couldn't stop laughing when I ran across Scorpia
in Might & Magic III...)
Now you're done, right? You've got a fun game which you know you
can make lots of money from. How to market it? I probably have the
least personal experience in this area than any of the others I've
mentioned, but I know quite a few people who have been through this
process. There are three main options. One is to go through
a "big" publisher like Virgin, EA, etc. It's very difficult,
however, to break into this market - a few friends of mine got
months and months of run-around trying to market their game this
way, and finally gave up. So I'd recommend shareware - the big
publishers take a rather large cut of the profits as well. As far
as shareware, you can either go through a shareware publisher
(Apogee and Epic are the two "big" shareware publishers) or just do
it yourself. There are merits either way. Many people have been
very happy with the marketing that these companies have done for
them. They handle stuff like advertising, distribution, take orders
(accepting credit cards for payment vastly increases your potential
profits since people are more likely to do it on the spur of the
moment), and even help you beta-test and fill in weak parts of the
game (art, music, whatever). However, they do take a good chunk of
the profits. Whether this is worth it to you depends on the game,
and how much time you want to spend supporting it (namely taking
orders and such). I'd say the easiest way to make a decision on
this one is simply to ask a few representatives to tell you what
kind of things you can expect the from the company they represent,
and at what cost. Then you can simply weigh it against the benefit
of the 100% profit you get from doing it yourself.
That's about it (whew!). Of course I'd really like to encourage you
to support your products, fix bugs that players find, maybe make
changes or additions that your (registered) users request. This may
seem a bit extraneous now, but in the end everyone wins since the
customer is happier, which means he or she will be more encouraged
to continue to support your efforts in the future.
I hope at least a little of this helps you on your game-design
attempts. It ain't easy, but the rewards are pretty damn good too.
Good luck!
-----
If you're wondering, the information contained here is a combination
of my own personal knowledge and experiences, combined with the
many, many people I have spoken with on this subject (both on-line
and in "real" life).
Feel free to mail me with comments, corrections, compliments
(gasp!), flames, questions, or whatever. And as usual you can
always find me on rec.games.programmer, where there are plenty of
knowledgeable people, so if I can't answer your question, someone
else probably can.