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.