I’m evaluating books on game design as potential texts for a game design course at Union College and also perhaps RPI. The first book I’m looking at is “Game Design: Theory & Practice” 2nd edition by Richard Rouse III.

Overall, I like it. He mixes high level ideas with both analysis of specific games and interviews with game designers, and talks a lot about nuts and bolts. For example, there’s a chapter on the design document, and another on documentation in general. There are also two appendices of example design docs, one for a hypothetical game, the other for The Suffering. He also takes a historical perspective, analyzing Centipede and Tetris along with The Sims and GTA III.

It seems to be a lot of “soft” stuff, e.g. “limitations affect your game design.” It doesn’t have any list of points to know or other structured, specific info. Although, we could probably come up with something like that as a supplement, some “take home” messages that could be used as a take home message, and the basis of lecture notes. Still, it would require some work to transform the material in this way.

It definitely assumes you know something about games. Stuff you could figure out from having played a lot of games, but it assumes you know terms like “custscene,” “engine” and “FPS” (as either First Person Shooter or Frames Per Second depending on context.)

The interview chapters probably aren’t that useful in a course, but students who are generally interested in game design might eat them up on their own time.

Chapter 1: What Players Want

A good list of reason people play games, and what sort of experiences should be found in a game. Make make a good introductory lecture.

Chapter 3: Brainstorming a Game Idea: Gameplay, Technology, and Story

Mostly about limitations, and how making choices in one of three areas (technology, story and gameplay) limits other areas. Important for students to know. However, the examples are mostly high level concepts of the entire game. Might be good for a later lecture, after e.g. level design has been covered.

Chapter 4: Game Analysis: Centipede

Starts with an overview of classic arcade games, including a description of the genre and a list of their traits. Describes Centipede’s input, mechanics, the interplay between the gameplay elements (and interplay between player’s goals), and talks about how tension escaltes. Interesting source for an analysis class.

Chapter 5: Focus

The reader of this chapter probably needs to have some design experience, say building a few levels. It would be good for a project class to read the week before their initial project ideas are due. It deals with writing a paragraph on what’s absolutely central to your game, and using that to guide descisions made along the way. It also talks a little about involving the rest of the team in the development of the focus, and what to do if you need to change focus.

Chapter 7: The Elements Of Gameplay

I’m a little disappointed with this chapter; it’s more high level stuff, generalities that border on being too vague to be useful. It seems most appropriate for someone with a fair bit of game design experience. It starts with a good description of why you should allow emergence, so that any reasonable solution the player thinks of is likely to work, rather than only the solutions you could anticipate. Then there’s a section on non-linearity which amounts to “it gives the player a sense of authorship/freedom/agency; without it, they’ll feel constrained. It also lets them put a difficult puzzle aside, and once they’ve racked up some sense of accomplishment somewhere else they can come back with renewed energy.” The reality section points out that using a real world setting the players get rules and possible actions for free, but that reality for reality’s sake can be annoying, e.g. needing to eat in ’80s RPGs. “Teaching players” talks about how you need to ease players into a game through tutorials or (better) easy first levels. And input/output says you need to make the controls simple, and provide feedback. Overall, it seems like a somewhat arbitrary collection of points, none developed with all that much depth or substance. I’d have a hard time presenting this to a class as a backbone of good design/gameplay.

Chapter 8: Game Analysis: Tetris

Again a mix of specifics of one game (Tetris) and thoughts on its genre, although its genere is the same as last time (Classic Arcade), so there’s a lot of repeat. Still, Tetris is good for people to know if only because it’s the ultimate counterexample: it has no story, not even a pretention of one; nothing even connotative of the real world; the graphics are as primitive as they get; yet this was the most popular game of all time until The Sims. It also has no “opponent” who is pursuing the same goal as you, no AI. A testament to richness that can emerge from stark simplicity.

Chapter 9: Artificial Intelligence

Starts by describing the Turing test, how it would work in a game, then rejecting this as a definition of AI. Would be confusing to students unfamiliar with the Turning Test. Makes some good points: AI is a part of design, not just programming; AI’s goal isn’t to be as smart as possible, but rather to not do dumb things (e.g. have NPCs help create the illusion of the simulation, whether it’s a town or DOOM), challenge the player (especially difficult in RTS and God games), be unpredictable (i.e. not feel repetative), assist storytelling, create a living world (e.g. bystanders in Grand Theft Auto). It gets into some points that are good but only useful for people with some experience, e.g. that the programmer goal of being on equal footing with the player (i.e. not cheating) is generally not the most fun, and certainly can take much longer to develop than letting it cheat occasionally; that the optimal strategy might not be fun, e.g. hide where it’s hard to be found; that it must be matched to it’s environment (e.g. does it need to climb ladders? Deal with bridges?) and levels must be designed in conjuction with AI; that players are willing to give AI the benefit of the doubt when it does something unexpected; that scripting is often just giving the AI a few clues/goals, e.g. a destination to go to, but let it’s usual path planning figure out how to get there. Overall, there are many interesting/important points, but they could easily be lost on students with little/no design (or even game) experience.

Chapter 11: Storytelling

Overall a really good chapter, perhaps the best so far. Starts by distinguishing between the designer’s story (the story written by the designer that’s the player has no control over) and the player’s story (what they did & why. The designer creates the setting, but has little influence on the sequence of things the player tries.) Gives some good examples of the “holy grail” of interactive story telling, the parent ad libbing while reading a story to a child, and the D&D DM. Has some good points about the pros and cons of in-game vs. out-of-game story telling, and a good list of various ways to accomplish each. It also talks about the pitfalls of treating game writing like writing for other genres, namely making it too linear. It then talks about the role of the player’s character’s personality, and that if it’s too strong it can be annoying, although gives some good examples of successful strong characters (Duke Nukem 3D, Monkey Island, No One Lives Forever, Oddworld, Max Payne, Final Fantasy). It talks about how the story in The Suffering was driven by the gameplay, and how he sees these as guidelines or sources of inspiration, rather than a limitation. Makes some good references to adapting a novel to a movie, and that the overall story is secondary to good situations and characters, quoting Howard Hawkes on The Big Sleep. Ends with “The Dream,” about how Civilization and SimCity have no designer’s story at all.

I’m starting to get a feeling for what’s missing from this book: in this chapter, there was no list of parts of a story, antagonist/protagonist, conflict/climax/resolution, etc. It has a very different flavor than a “representation” like that.

Chapter 12: Game Analysis: Loom

Unlike the earlier Game Analysis chapters, this one doesn’t attempt a definition of a genre (in this case, adventure games), nor is this game a prototypical adventure game. It describes the mcehanics briefly, but mostly talks about how much simpler and therefore better it is than a text parser. It makes some good points, such as: it’s really annoying to know what you want to say but not how to get the machine to understand it; being killed, or worse being unable to finish the game, just penalizes you for not saving often; there’s a place for easy games, and games with a predetermined story. Not as good as earlier game analyses.

Chapter 13: Multi-Player

Starts by talking about how non-gamers think of games, even multi-player games, as anti-social. Also points out that virtuall all non-computer games are multi-player. Why people play: increased challenge/depth of experience; ups emotional stakes by making success/failure public; socializing. Single System: constraining player to be close to each other vs. split screen; problems of seeing other player’s info in split-screen; physical proximity makes it very social. Online: more immersive since can only see others through game world; FPS & sports titles work well; MMP games are “the ultimate in immersive online gaming.” This chapter, up to this point, is much more of a taxonomy of game types with a good discussion of how the differences impact gameplay. Good.

In contrast, the Design Considerations section launches into an odd collection of important yet minor points: you can’t pause, but you need to give players some way to take breaks; you want to have a target length of time in mind for the game (e.g. Monopoly, Risk and Diplomacy can take too long); players who are behind need to feel they have some way of catching up, e.g. through negative feedback; players who are dropped need some way to reconnect. He talks about customization, but doesn’t distinguish between ones that affect gameplay (e.g. class in RPGs) vs. those that don’t (appearance in FPS). A more important point is that the gameplay needs to be much more emergent in multi-player games, the player can’t be thinking “What does the designer want me to do here?”

In “Playing to Strengths” he mentions that designing for multi-player isn’t just taking a single player design and replacing the AI with other players — and as an example, mentions a case where that actually works, FPS deathmatch. Suggests negotiating between players as form of balancing. Mentions that encouraging cooporation is hard, that even in games like Battlefield 1942, which tries to create strong incentives for it, people don’t do it much. Suggests creating strong incentives to get people to cooperate anyway. The “Protect Newbies” section is quite good, talking about players who are fumbling with controls, player killing in MMPORPGs, explicit incentives for helping newbies, and simplifying controls.

“Socialization” section is good. With non-computer games, those that require cooperation or back-stabbing lead to more socialization than e.g. chess. In online games, you need to provide hooks for socialization: text/voice chat, allowing players a safe place to chat/speak, repeatedly meeting the same people in RPGs leads to friendship vs. FPS, friendship brings people back to your game. “Development Issues:” multi-player has large impact on game mechanics, so include it from the start, don’t add it late in development. You can get multi-player working before single player, which helps motivate the development team and iterate on the game dynamics much earlier. Playtesting with the general public is essential, open betas for MMP games attract more players than possible in-house. Discussion on fixing problems after release and player feedback.

Chapter 15: Getting the Gameplay Working

Time/budget for games are much more unpredictable than movies, due to the uncertainty of gameplay. Develop a prototype and have people play it. Experienced designers use a lot of prototypes. Don’t ramp up the team or create a detailed design document until you have the gameplay worked out, which includes having a playble demo. You’re financial backers may not let you do that, so try to develop “under the radar” or be self funded until you have a demo.

The “Building the Game” section stars with sentences like “Work on the most basic and essential systems first, and then build the systems that depend on that system. This allows you to implement a system, test it out, see if it “feels” right, and only then move on to the next system.” For someone whose a little hazy on what goes into a game in the first place, this wouldn’t be very helpful. A list of typical systems might be more helpful. He gives an example later under “Incremental Steps,” but that’s too late for a n00b and resulting list is rather incomplete.

Building the Game: build the foundations first then add to them; programmers like working on their own part of the code so make sure you have frequent integration; working with cutting edge technology can be dangerous because you don’t know whether it will achieve it’s technical objectives, and if it doesn’t, it may kill the gameplay; it is rare that technology will make or break a game design, though it may make or break the game itself. Make sure it’s always playable.

Build an entire level as soon as you can, because no matter how complete you think you are, you’ll have forgotten about a lot of stuff. You’ll have to throw away a lot of stuff, and your developers and you will be attached to it. It is worth learning to program if you want to be a designer, even if you never do any coding on the games you ship.

Chapter 16: Game Analysis: Myth: The Fallen Lords

Myth isn’t a typical RTS. It’s an inspiring example to those familiar with various RTSes and their differences, but that’s not what you want for a first class, you’d rather have an analysis of a popular, “straight up” RTS.

This project, of finding good texts for an introductory class in Game Design, is being put on hold. We’ll see what happens when I talk to RPI, but for now, that’s the end of the review.