

                      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.