At the Office

Home

On the Couch

At the Office

In the Library

Mailbox

Neighborhood

Five Things Non-Designers Tend to Forget

One of the things about working in commercial game design is that everybody you run into thinks they can do your job. Players think that because they've played the game and know it from that angle, they can improve on the design. The people you work with think that since they've developed the game and know it from that angle, they can improve on the design. Hobbyists who have done design in their spare time think of themselves as designers, so they think they can improve on the design. Random strangers think that game design is just sitting around playing games and thinking up ideas, and since they've done that, they think they can improve on the design. Designers love to bitch about this, but I think it's more important to educate people, to get them closer to the design frame of mind so to speak, and thus I offer up some of the most common things people tend to forget about when they're playing at design.

1) Cost
Working on commercial games is expensive. Features have to be built, and they have to be tested. That means developer time, and developer time costs money. The bottom line is that making games (at least the kind most people play) is a business. You have to make back more than you spent, or you don't stay in business. As I've said elsewhere, implementing a single feature can run into the tens and hundreds of thousands of dollars. It may seem like a simple and obvious idea, but one of the things you have to do as a designer is have a sense of the cost and compare it to what else you could get for that same investment. "Bang for the buck" is very much at the heart of design work.

Money is just one aspect of cost, though. When you're designing a game, you have to take into account all kinds of other costs. A game only gets so many CPU and GPU cycles on the current hardware; every feature uses some of that. Better AI? It's going to take more processor time, so you have to figure out what else you're going to cut. Flashier effects? More characters on screen? More detail? It's going to take more rendering time, and you have to ask whether the impact is going to be bigger than a simpler approach you can take.

Those are just the tangible costs. You've also got to think about the opportunity costs (what else could we have gotten if we had taken a different approach?); the psychological costs (will the player be willing to invest this much effort/time to master this dynamic?); the market costs (will this approach appeal to the audience we're trying to reach?); and the risk in general (what if this approach doesn't work? Will we have time to try another one? Will we be able to polish out the flaws given our schedule?).

Ideas are cheap, practically free. Part of what makes design different from daydreaming is that it has to take into account the complex economy of development.

2) Interface
Non-designers tend to think in terms of actions and scenes: things it would be cool to do or see if you were playing the game. The trick here is that nothing exists in the game if it isn't in the interface. If you can't tell a character to do something, you can't have an action; if the dynamics of the scene can't be represented to the player, you can't have a scene. It's obvious that the interface is going to be different on the PC (keyboard and mouse/high-resolution monitor) and on consoles (gamepads/television screen) but designers have to take a lot more than that into account.

First, you have to ask whether the control system is going to be intuitive to the player. Does it match existing conventions? Will they be able to figure out the differences? Will the control system become second nature over time? Fighting with a control scheme is not playing a game; in fact, the more transparent the controls are (that is, the less the player is aware of them) the more likely they're going to have fun playing the game. Complex behaviors run the risk of requiring complex control schemes, and the more complex and difficult to learn the control scheme is, the more likely players are going to walk away from it in that first crucial hour and never play it or tell their friends how much they liked it--which is one of the keys to selling games (see Cost, above). Complexity should arise from the dynamics of the game, not the control scheme.

Second, nothing exists to the player if they don't have a way to see it. You have to close the loop from input to output. The most sophisticated decision-making AI doesn't matter if the player can't see how it makes a difference in the game. The most beautifully detailed texture won't impress if it's being rendered in low resolution. If you have game systems that don't show up in the game world, they're either not going to matter or just going to frustrate the player. You also can't just throw up a graphic for everything you want the player to know; there's only so much space on the screen, and beyond that, you don't want to cause information overload by asking the player to track a dozen things simultaneously.

Third, everything in the interface has to work together. On a gamepad, for example, you can't put controls on the face buttons that you want people to use while they're using the right thumbstick. You can't expect players to manipulate both left thumbstick and the D-pad without pausing to relocate their fingers. Even on the PC, there are keys you simply can't use for high-priority events because the player won't be able to reach them and do the other things they're trying to do at the same time. On the output side, too, you have to understand how the colors of the HUD are going to interact with the scenes and lighting; it's all too easy to let a special effect wash out some critical piece of information, like the location of an enemy, and then the player's dead and he blames you, as he should.

Interface is one of the most difficult things to design. There are entire courses (and soon to be departments) on how people interact with different interfaces, and for a game, if the interface doesn't work well, the game doesn't work well.

3) Bandwidth
Online players are some of the most dedicated and most vocal. These are the people who show up in the forums. They are the tech-savvy and often the hardcore who enjoy the challenge of playing against real people rather than the computer. For all that, they often forget about issues of bandwidth.

Anything that's game critical needs to be synchronized in multiplayer situations. For example, if a door opens on one machine, it has to open on all the connected machines at the same time, or else bad things happen. If one player shoots another and the machines don't register the shot at the same time, or the positions of the two players are out of synch, players feel like they're getting cheated. So, the more game critical information you have, the more things have to be synchronized, the more bandwidth you need. On top of that, each player adds the load of not only being synchronized with the server but also with all the other machines. This is a geometric rather than arithmetic progression, and it adds up fast.

Any information that goes out to all the machines also takes up bandwidth. If, for example, you've got custom clan graphics for your uniforms, everyone's got to have those graphics, which means it's got to be sent over the network. If you do this on the fly (god forbid), that's one more thing clogging the pipeline that all the other gameplay information has to go through. If you do this prior to a match, you're going to get longer load times. The more information you send, and the more people who need it, the longer it takes. Plus, you're at the mercy of the bandwidth limits of all the people involved. The best net-code in the world won't overcome bad infrastructure, but it's always the game that gets blamed.

Games are information-intensive. As a designer, you have to consider what information is essential and what can be abstracted out without losing the core experience. You've only got so much bandwidth to work with.

4) Consistency
I know, I know, consistency is the hobgoblin of little minds. Well, be that as it may, it's one of the elements that makes a game world feel real to the player. In fact, you could argue that consistency is critical to any game, because if the rules change arbitrarily, you can't rely on the game as a system, and you're not really playing the game at that point. One of the key roles of a designer in a team environment is to make sure that all the elements of a game are consistent even though they may be developed by fifty or more people.

Consistency matters on a wide variety of issues. The look of the game has to be consistent with its story and emotional tone; all of the assets have to be consistent with each other. Equipment behaviors have to form a consistent set or you lose the tradeoffs that make choices interesting. Characters have to be consistent not just with themselves (especially if you're doing any sort of storytelling) but also with the world and the other characters around them. Difficulty needs to be consistent (not constant--variety is important) or you'll hit patches where the player is either bored or frustrated. Overall, the logic of the game world needs to be consistent. If it's not, players will argue with the game rather than play it.

Special cases are not only expensive (any thing you only use a few times is less bang for your buck than things you use all the time), they run the risk of breaking the player out of the game. To be fair, a lot of professional game designers forget about this point, too, and either break the rules themselves or expect the player to in special situations. More often than not, this produces horrid gameplay experiences, but because it occasionally works, the risks are all too often overlooked.

Ninety percent of ideas for a game can be ruled out simply on the grounds that they're not consistent. It's the first question anyone should ask before putting an idea forward.

5) Audience
Most ideas people come up with can be boiled down to "I want this". For a player, their experience is the most present, salient fact of the game. Designers don't have that luxury. We have to design games for an audience that includes a wide variety of preferences, hardware configurations (if you're designing for PC), gaming habits, backgrounds, and expectations, even in a relatively small genre. What seems like fun to one person isn't going to necessarily feel like fun to another, and if you want to make a successful game, you've got to come up with something that literally hundreds of thousands of people are going to enjoy.

The fantasy of game design is that we make the games the way we want to play them. Some developers even subscribe to this logic, arguing that if they enjoy it, so will all the other people like them. The fact, though, is that as a designer, you have to go beyond your own perspective and imagine how the multitude of different gamers are going to experience the game.

So, there you have it. There are a lot more than just these five, and at some point, I may write some more of them down, but like I said above, almost all the ideas that people casually put forward can be ruled out because of the negative impact it will have in one of these areas. Understanding the complexity of all these factors is one of the key components of translating ideas into workable designs, and both designers and non-designers would do well not to forget that.

Home

On the Couch

At the Office

In the Library

Through the Mirror

Mailbox

Neighborhood