loonygames' Beaker's Bent

| - Contents - About - Submissions - Feedback - Archives

volume 1, issue 14

Today in loonygames:

New!! The Archives have been cleaned up, fead links fixed, and printable versions restored! Also, don't miss the new comments on the front page!

Livin' With The Sims: theAntiELVIS explores the wild and wacky world that is Will Wright's The Sims, asking the inevitable quesiton, "is The Sims the first step toward a virtual life where everyone is Swedish?"

Pixel Obscura: Josh Vasquez on Omikron: The Nomad Soul.

Real Life: Check out our newest comic strip, Real Life! Updated daily!

User Friendly: Updated daily!

Related Links:

Nothing New Under the Sun: Rich's Guest Editorial, the piece that started this column.

Feedback:

You've got an opinion...voice it! Drop a line to our Feedback column...you could end up with a free T-Shirt!

Random Feature :

Put a Little Love in Your Pocket!: Trying to understand Pokemon? Our loony editor got to the bottom of the GameBoy phenomenon.

Search the Archives!

Beaker's Bent:
Game Design Philosophy 101

By Rich "Beaker" Wyckoff

I've been designing games professionally for three years and thinking about designing them for most of my life (when not playing them). I tend to present strong opinions, but I want to make it clear that these are only opinions, and I don't want to come off like some of the famous names in the industry who seem to think that selling a lot of copies of a game and getting attention from the press makes them an expert on everything about making games. My tenet is that if you claim to know everything, you're missing out on the fact that there's always something new to learn, some other opinion which is worth considering, some experience you are still lacking...

omputer game design is not a subject which you can study in most colleges, and even those few that offer courses in it aren't offering the kind of training in critical thinking that you can get for creative writing or film directing at most of the better schools out there. If you want to become a game designer, or even a game artist or game programmer who can have more to do with the overall shape of the game than just doing some textures or coding a new 3D engine, however, you need to know how to be able to think critically about design. To a large extent, there is no common "language of game design" yet. Nonetheless, some common principles of game design have worked on many games in the past, and being aware of them is helpful not only in entering the industry, but also in making the best game possible.

The rest of this column will be a list of some of the principles and philosophies that I and designers I have worked with typically use when planning out a new game, or even just to guide us day to day as we take our plans and build them into game. If they all sound very basic and obvious to you, then good, you are already a step up on a lot of the game designers working professionally out there. Clearly if all the industry's designers had a set of guidelines and were actively following them, we'd see less terrible games. Yet for all the years I've been playing games, I haven't seen very many games at all which don't have at least one huge problem with their designs - and of those games that are nearly perfect, many have come from Japan. (This is not to say that Japanese designers are just better than American or European developers, because they produce their share of crap as well, but their best games, like Metal Gear Solid, are almost on a higher plane of design than even the very good American and European games, and design is what makes a game fun, not technology, not "attitude", not a license - it is always about design). Of course there are always different viewpoints on this subject, just as there are with any critical theory, and sometimes even people with a well-developed design philosophy can lack the skill to actually translate that philosophy into a game, but those are problems I can't address here. Some time in the future, designers will be able to go to school and learn both how to think critically about computer game design as well as how to communicate their thinking and implement it in a successful product. For now, plenty of mistakes will continue to be made, and designers will do most of their learning from their own mistakes and those of others.

Game Start/Interface

Making sure the player has an enjoyable first hour or two of gameplay is critical to getting them to play the rest of the game. While the view of some marketers and execs is that the only thing that matters is making a sale (given that the majority of games are sold at stores which don't allow returns), that's typically short-term American business thinking. I have several games I've bought but couldn't or didn't return which were so poor that I think twice about buying anything else from the same company, whereas an exceptional game will almost certainly get me to buy the next product made by the same people. You might be surprised to learn that more than any amount of expensive advertising, it is still primarily word of mouth that sells games, and word of mouth will quickly spread about a crappy game.

Allow the Player to Start Playing Quickly: without even getting into the installation hassles which still plague computer games, once the game is successfully running the player should be able to start playing with the minimum amount of effort. Even complicated games like strategy games and flight sims should allow the player to be playing the game in minutes instead of performing chores like loading weapons on their airplane or configuring their army. Set up tasks like these are likely to not be understandable or interesting to the average player until they've played the game some, and even the experienced player who might understand all the preliminaries would most likely rather try the game out some before worrying about the details. Everyone wants to get some instant gratification after they've installed a new game, and it is the job of the designer to make this gratification as instant as possible. Even after you've played a while, a game which doesn't let you load your saved game from the very first screen or requires you to do a lot of button pushing to try a new mission is going to be less attractive than one you can just jump into in one or two clicks.

Wow the Player Immediately: This goes hand in hand with the previous statement. Not only should players get into the game and be playing as soon as possible, they should be shown some of the most impressive things your game can do as quickly as possible. This is especially true of 3D games, and a mantra among a lot of designers is "make the first and last levels the best levels." It can be harder with strategy games and flight simulators and other games of this type to show the most impressive parts of the game immediately. Sometimes cutscenes are used, although players are becoming less and less impressed by (or tolerant of) the kind of excessively long, poorly directed game intros you used to see a few years ago, and many games nowadays have only very short intro cutscenes or nothing at all. In my opinion, this is great. Half-Life's introduction which is in-engine and first person but allows only limited interaction on the player's part is a perfect example of a great intro sequence for a modern game, and for strategy games look to Final Fantasy Tactics on the PlayStation. This game starts with a cutscene which sets up the first map, and the player immediately enters a battle full of dramatic dialogue and characters displaying powers which the player won't earn for hours of gameplay, and also tells the player how to play, fixing it so they can't lose even if they don't understand the controls well. You don't even really have to have read the manual to get through the first combat, and once you complete it, the tutorial information you can access from the menu will suddenly make a lot more sense.

Put all Game-critical Information in the Game: in the bad old days when interfaces were primitive, memory was an issue and it was much easier to copy a game (not everyone has a CD burner and blank CDs, whereas anyone who could play a floppy-based game could potentially make a copy), manuals and even paragraph booklets were essential parts of a game. Today, publishers attempt to keep manuals as short as possible to keep manufacturing costs down, and due to printing delays the manuals almost inevitably contain some information which became inaccurate in the final weeks of shipping the game. In my opinion, everything you need to know about playing a game should be contained within the game. A manual is nice, especially for looking at tables of units and combat charts and the like with a strategy game, but a truly great strategy game will go the extra step and add in a unit encyclopedia that is good enough that it can actually be used to do unit comparisons, as opposed to the more standard and often useless "one unit per page, no tables, no options" encyclopedia format in more run of the mill games. A good example from another genre is Half-Life, the only First Person Shooter (FPS) I've seen to actually include a tutorial. Any game which hopes to attract new players needs to show them how to play the game. Other FPS games just set you wandering around, and if you've never played an FPS before you can easily get stuck because you don't know how or why to duck (for instance), and you can quickly die the first time you meet an enemy before you even know what's going on. There are differing schools of thought on this, but I think that for 3D-type games, the basic controls should be introduced in the first levels of play in as slick a way as the first Final Fantasy Tactics mission described above, because most players are going to skip any optional tutorials in favor of playing the full game (see the first point). If the tutorial information is designed and developed as part of the full game, you have the added
as a regular level, instead of becoming one of the typical "oh-oh, it's the last month and we suddenly realized we need a tutorial" tutorial.

Ramp Complexity and Difficulty: Even if you don't agree with my thinking that the game controls themselves should be introduced in the first few minutes of play, it is at the very least good practice to follow what was commonly called the Sonic the Hedgehog principle among the designers at Looking Glass when I was there. In other words, look at the example Sonic sets: introduce elements of gameplay one at a time, making the player use them in order to proceed. Sonic makes the player apply one of their character's moves at a time, starting with the most basic (moving and jumping) and proceeding to the more complicated, like learning to use run so you can make it over the loops, then having to do a spin-attack (which starts by running) to get through a tunnel filled with enemies, and on and on. Perhaps the best example of the learn-by-doing school of game design is Super Metroid on the SNES, where almost to the end of the game you acquire new powers and abilities which let you get to previously inaccessible parts of the world, and once you are good enough at using the new ability to get past the initial barriers, you come across more complicated situations which may call for a better use of the ability or perhaps a combination of different techniques you've already practiced individually. With a little bit of thought, you'll see that this kind of design is directly applicable to almost any kind of game, and is the most transparent way of teaching the player without compromising the gameplay. When complicated rules of gameplay are merely described in excruciatingly dull detail in a manual or set forth as a lesson in a dry tutorial, many players turn off their minds and refuse to learn because they aren't having fun. When the rules are set forth one by one in the context of playing the actual game, people will have fun and become prepared to deal with the most complicated challenges the game has to offer without even realizing they are getting educated. (Education rant: I have long been a believer in learning with enough of an emphasis on its real-world uses, as if "applied" mathematics is somehow an unfit subject. High school and undergraduate math and science is actually useful all the time to ordinary people, even English majors like me, but these subjects are often taught, especially in college, more as a means to determine who is eligible for higher level courses and graduate school than as actual tools to be used.)

Interface: The Most Commonly-used Options Should be Easiest to Access: we've all played at least one game where something you need to do all the time, maybe even something as common as saving your game, requires going through three different menus or clicking through a dozen menus and pop-up windows, with buttons all over the screen. At times it can be hard to determine ahead of time which options in your game are going to be the most-commonly accessed, but this is what playtesting is for. To ensure you can really be responsive to the issues that come up in playtesting, though, care should be taken to ensure that it is as easy as possible from a code and content-creation side to rearrange, take out, or add in entire menu screens. A lot of the awkward interfaces out there are a direct product of bad code and content-creation procedures which made it more difficult to fix the interface than to keep the awkward one. This is still no excuse for having a bad interface, though.

Interface: Minimize Screen Switching: this is another design goal which has become easier to achieve with the increases in memory and screen resolution, but even in the comparatively ancient days of game design, the easiest-to-play games were the most clever about how they fit as much information onto the screen as possible. Doing this right is as much a matter of selecting the most important information as making it all fit: there's no sense in using screen space for some stat which only needs to be referenced once an hour. Like all other interface issues, being able to tune your screens to perfection requires a flexible code base and art team so that the interface can be fully redesigned if necessary. It also helps to have designers who are talented enough to put a lot of advance thought into the interface before it becomes playable and solve as many problems as possible before anything gets coded or drawn.

Game Play

It is hard to resist the temptation to jump ahead and start planning out the bulk of your gameplay before even dealing with the basics, and often initial game proposals are based on just this kind of thought, but a game that plays well but starts really poorly may lose players before they even see the good stuff, so don't overlook all the previous items in your hurry to make the game itself.

Don't Bore the Player: the designer's first commandment, really. This sentiment underlies most of the following design principles, and can always be applied on its own. The word "frustrate" can also be used instead of "bore" - they are both facets of the same problem: the player isn't having fun. A small amount of frustration can occasionally be a useful tool in keeping the game interesting, but it's almost never a good idea to deliberately bore the player. Both, of course, are very subjective issues, and that's why even if you feel that it is completely and utterly vital to your game to have three screenfuls of purple prose in a barely legible font at the beginning of every mission, you should make it possible for the player to skip through that text yet still get all the game-relevant information, just on the off chance that somewhere there is a person who doesn't find the text quite as you do. This also applies to things like levels with a lot of empty space with nothing to do, real time strategy (RTS) games which consist of twenty minutes of building your base and technology, and then forty minutes to wipe out every last enemy, RPGs where you have to put the plot on hold for an hour so you can build up your party through random encounters, and a hundred more boring parts of games we've all come across.

Constant Goals and Rewards: I talked about this two columns ago, but one of the best ways to prevent boredom is to ensure that the player always has a clear and short-term goal to strive for, coupled with a reward for attaining the goal. A goal of "finish the game" with a reward of "cool cutscene" is not sufficient, because if the player hits a tough section they can't get through or that is slowing them down a lot, they can easily decide that if all they have coming is a cutscene all the way at the end of the game, slogging on is not worth it. Rewards can be fairly simple, but they need to be relatively unique (gaining some ammo for reaching a high ledge or getting a standard skill point bonus when you go up a level don't quite cut it). I also don't feel that unclear or player-imposed goals, like "I know I need to get to the end of this level" or "ok, I'm going to get my character to 40th level" work well enough to stave off boredom, mainly because as goals that weren't specifically planned, they won't have specific rewards. If the game makes the end of the level special in some way and at least hints that to the player or gives some special character benefit only at 40th level, then you have a reasonable goal-reward set. If there are not enough goals and rewards, players without a lot of self-motivation (which is a lot of gamers, myself included - the last thing I want to do with my time is play make-believe about why I should be continuing to spend time on some computer game) may very well not want to keep playing. If your game runs out of goals and rewards too quickly, negative word-of-mouth will definitely spread - probably not enough to hurt current sales, but quite possibly diminishing your market in the future, and much as I hate to use horrible business speak like that, games are products which have to be sold. Making good games is the purest way of selling games (unfortunately, not the only way, but the fact that bad stuff can be sold by the ton is one of the most depressing aspects of our society). My personal feeling is that there should be some game-defined goal, no matter how small, at least every hour of gameplay and preferably every half-hour. My favorite games keep them coming at about this rate.

Continual Player Power Growth: this is almost just an example of goals and rewards. The player should continue to become more powerful as they play through the game - this could mean more weapons, new types of units in a strategy game, more hitpoints, new moves, etc. I suppose this could be categorized as one of my personal opinions about game design, as there are successful games out there, especially among RTS games and platform games, where the player attains all possible units or moves or whatever as early as half way through the entire game, but there are plenty of counter-examples within each genre where you don't gain your last powerup/unit/weapon until very near the end of the game. The best games have even found ways to avoid the frustration factor of getting something cool and not being able to use it very much because the game ends soon afterwards, by allowing you to keep playing even after the end, or by allowing all weapons to be used in multiplayer, or by giving you the end-game weapons or units near the start of the inevitable all the steps even when the answer is obvious, it is probably just too difficult. I find it much more pleasurable to continue to make progress through a game while dealing with a string of easier puzzles which I can solve in no more than three or four attempts than to be stuck at one tough bastard of a puzzle trying over and over again to solve it. I'm guessing that most people would agree with me. Random-guessing puzzles are almost as bad as learn-by-dying puzzles, and should always be avoided. Combination locks, for instance, should always have their combination available somewhere in the game, even if determining it requires deciphering a bunch of other hints. If the hints for the combination are particularly subtle, the combination should also be given explicitly in a very difficult-to-find location. The player can always go through resort to random guessing if they want, but they should be trained by early puzzles in the game to look around until they find themselves frustrated. It is better still to give the player a way to occasionally bypass entire types of puzzle altogether, like in System Shock where you could find electronic lockpicks to open the puzzle locks - but finding the picks themselves could be as much of a challenge as finding the combination. The more options players have, the better. Unfortunately, one of the main reasons that obnoxiously tough puzzles with single solutions are deliberately put in is to extend the play time of a game which would otherwise be quite short. To that, I can only say that an hour of play time spent trying to get through one puzzle is not equivalent to an hour spent making progress through a game, unless the actual playing of the puzzle is transcendently fun even when you repeat it fifteen times. This does occasionally happen, but not, for instance, in Myst or 7th Guest, and I am incredibly glad that the "we got our design from back issues of Games Magazine" game is almost dead. I used to subscribe to Games Magazine until I figured out that it was really supposed to be called "Puzzles" magazine.

End Game

And finally, the topic of ending a game. This is an issue I'm still cogitating on myself. None of the work I've done on end games has made it into a shipping product so I don't have any real experience to draw on yet, and I can't even point out many games final sequences that truly satisfied me. The only guidelines I've come up with so far are loose ones, as follows.

Great last level: as mentioned above, in games that have levels or areas, the first and last levels should be the best ones. Not all players will see the final level, but the last thing you want to do is disappoint those people who do manage to play all the way through. It usually pays off to construct the first and last levels at the very end of your project, so they can benefit the most from any last-minute improvements the programmers may have made, and so that the experience everyone will have gained in building the game will be best displayed.

Satisfying endgame: so many games end with boss fights nowadays, and so few of those fights are even good. Many of them wind up being boring slugfests, and in a lot of games you can even find ways to dispatch the final bosses in seconds. I think the way to go is a really involved and satisfying non-combat sequence, but you don't want the end of the game to be incredibly frustrating, either. Yet if you make the final puzzle too easy, finishing will become anti-climactic. Ending with an "escape" sequence is another promising alternative which has worked in a few games, but again, if the player has to try it too many times it will just be frustrating, and it could easily become as much of a cliche as the boss fight. There aren't any tried-and-true methods here yet, and finding the perfect ending for the perfect game is going to take a lot more work.

There's probably plenty more to be said, but this has already become my longest column. if you end up entering the industry and in some way referring to this info, I hope you someday find a way to publish your own two cents about game designing. The more designers writing and thinking critically about design, the better chance all designers have of improving our skills and being able to make better games.

- Rich "Beaker" Wyckoff is a game designer on the game Trespasser for DreamWorks Interactive.

.

Credits: Beaker's Bent logo illustrated by and is © 1998 Dan Zalkus. Beaker's Bent is © 1998 Rich Wyckoff. All other content is © 1998 loonyboi productions. Unauthorized reproduction is strictly prohibited, so don't do it. We have ways of making you talk.