Think Like a Player!

Introduction

Playing the games in this year's comp brought to my attention some problems that affected multiple comp entries. Although there are a number of ways to classify them, they can almost all be stuck under the general header of "The author failed to think like a player."

What I mean by this is that the author knows much, much more about the game than the player ever will. From the beginning of any playthrough of the game, the author knows what things happen when, why they happen and what they mean. They even know things that don't appear in the game at all. By contrast, the player knows only what they've seen so far, plus anything they guess or speculate (which may well be totally wrong). The rest of this article talks about some specific problems caused by clashes between these two mindsets, and how, as an author, to create a better game by thinking more like a player. Some of the things I mention overlap with things I've discussed previously in my How to Write a Great Game article; if you're interested in seeing more design discussion from me I suggest reading that. Thanks is also due to Stephen Granade's article The Player Will Get It Wrong, which covers a number of the same issues I discuss here, from the perspective of one specific author and several games.

Almost all the examples used here are from the 2005 competition because that's what got me thinking about it, but the lessons here are applicable to many other games.

The Player Doesn't Know What's Important

One of the big differences between authors and players is that authors know what's important in the text that's mentioned and players don't. This has many benefits for game design — in a mystery game, it's great to have a clue dropped casually at the beginning suddenly attain more significance later on, and in a game like Escape to New York where the point is to scour the surroundings for valuables, it gives a better feel to have plenty of scourable things that have nothing at all valuable inside. But if the author's not careful, important information just gets lost and the player gets confused. Some things to keep in mind:

Don't bury relevant messages: Distress, for instance, runs at least a monster daemon, a ghost-images daemon, an NPC-health daemon, plus some other one-time events. Each of these three daemons produce multiple different messages (so it's not even clear initially they're all being produced by the same thing), some of which are important for the game and some of which are just for atmosphere. This is way too many for my tastes, even though I agree all three things are things the player wants to be informed of. In general, the way to deal with this is not to have more than one daemon running per room. If you can't limit yourself to one daemon per room, then limit yourself to introducing the daemons one at a time so the player can get a handle on what's what (and mentally group them together). It seems like Distress does this to some extent — at the start I'm mostly seeing NPC-health messages, and the ghost-images and monster noises don't start up until later — but on my initial playthroughs I was taking long enough that eventually everything got mashed together.

Don't make the player have to remember too much: At the start of the game, the player doesn't have any idea what's important and what's not, so they will generally feel obligated to remember everything — character names, location names, where objects come from and what their probable purpose is, and plenty more. This is especially problematic for rooms, since players also have to make a mental map of the world that includes each new room, and learn the muscle memory to get from one room to another. Otherwise-decent games like Xen: The Contest or The Plague (Redux) could have had roughly half their rooms cut out with no negative effects on gameplay.

It's not just objects, either — actions need to be weighed against the cost of the player having to remember it. Xen: The Contest, for instance, implements a backpack that you have to put textbooks into, and an entire cafeteria-meal purchasing-and-eating experience. Neither adds much to the playing experience, but they still require a half-dozen turns or so each time they come in to play. If a player is going to have to repeat a sequence of three or four commands, think strongly about eliminating or compressing it.

The Player Doesn't Think Your Game Is Special

Another major difference between authors and players is that games are special and magical and beautiful to the authors. To the players, on the other hand, they're exactly the same as the three dozen other games waiting for their attention, and possibly less tempting than the television. Therefore, it is of critical importance to encourage the player to keep playing when they start the game, and make sure they feel at the end like they didn't waste their time. I talk a lot about hooking the player in the Construction section of the How to Write a Great Game article, but here are some additional pointers:

The game must have something cool about it: I was surprised by how many games failed to do this. There are plenty of kinds of selling points: it could be a rarely-explored genre (Neon Nirvana tackles vice cops and Cheiron does practically non-fiction medical study); it could be fun puzzles; it could be compelling characters or writing. But there has to be something. Especially if the game is Yet Another Game In a Fantasy World, or In A Science-Fiction World, or (especially this year!) In The Present Day, it has to offer something — otherwise-solidly-done games like The Colour Pink or Space Horror I suffered seriously from not doing enough to distinguish themselves, and things like Dreary Lands didn't even try. On the other hand, Tough Beans is a totally standard setting and plotline but the characterization makes it stand out, while Vendetta carries out its genre conventions far enough to give them a little life of their own.

This should be the most interesting story to be telling: Again, I was surprised to see how many authors this year didn't seem to think about this. When you have an idea and characters, you want the game to be about the most interesting time in their lives, at the point when things are on the cusp of a change or cutting closest to the bone. In Snatches, for instance, virtually the whole game is prelude. It's not til we're almost at the end that we see any confrontation or any plot motion. Vespers, on the other hand, doesn't screw around with too much background, but just dives right in to "ok, this big event happened, let's see what transpires."

Mortality has a big confrontation, but it's the wrong one. The game up til that point had been all about the relationship between the guy and the girl, whether the guy loves her and what kind of life they're going to have later. So the confrontation, when it came, should have been about that thing too. Instead, it ends up being about whether the girl's love (or what passes for it) wins over her fear. This is also a cool topic, but it's not at all what the game has been about so far. This is especially frustrating, since the ending text in Mortality brings up a confrontation that really would be perfect to have played out — but it's just speculated about and never comes up. Anyway, the moral here is that just like in static fiction, it's often useful to take a step back and see what the story looks like. It may be that the game needs the intro removed or extended, or the ending changed or replaced, to tell the best story you can tell.

Don't do stupid things out of habit: This is 2005. There is no longer any reason to reflexively include mazes, inventory limits, hunger, keys, or hitpoints. If you do include any of these things, it should be for a reason. Take The Plague (Redux), for instance. Having an inventory (and weight!) limit was a terrible idea. Although it's realistic to limit the amount a person can carry, and this is a survival game, it's a bad idea in this case because the limit has no effect on gameplay. There's no time limit on the game, and no restrictions on moving around within "open" areas, so you can always circumvent the inventory limit. On the other hand, The Plague (Redux) also has a thing where you have to hunt around for spare change. This is another kind of limit, plus a treasure-hunt cliche, but this one works much better because it encourages desirable player behavior: exploring and looking around, desperate for a few coins that earlier in the protagonist's day would have been valueless.

The Player Can't Read Your Mind

...and doesn't want to have to. Important things should be in the game, and things in the game should be important.

Puzzle solutions should be conceptually reversible: Not in the sense of being able to undo moves you make in the game, but in the sense that the player should be able to solve the puzzle starting from an unsolved state and working in a logical manner forward, and when it's solved, they should logically be able to work backwards and see why their actions solved the puzzle. This is of course the classic guess-the-verb/guess-what-the-author-is-thinking gripe that has existed for ages, but since I'm still seeing it in some games this year, I'm going to talk about it in more detail. Neon Nirvana has a good example of one way to do this wrong. There's an initial puzzle where you want to do X. To do X, you need to sabotage Y and then tell somebody about it. To do that, you need to fiddle with a part of Y that isn't described, and then do something else unexpected to cover up your involvement. From the author's perspective, after the puzzle is solved this is totally plausible — you sabotage Y, the person cares about Y so they go to look, and then you can do X while they're distracted. But from the player's perspective, that's not more plausible than any one of a dozen other ways to do X, let alone the number of ways you can then think of to sabotage Y. It is absolutely mandatory that puzzles be solvable from the player's perspective or else, you know, players aren't going to solve them.

In general, when the player is confronted with a puzzle they should either be clear about the immediate goal, and have to figure out the method to accomplish it, or know methods for accomplishing lots of things, and have to work out which is the right immediate goal to solve the long-term goal.

The game shouldn't tell the whole story, it should tell the right parts of the story: The author knows the whole story, or as much as there is to know. The player only knows what the game tells them. The game must, therefore, tell them everything they need to know, and not tell them things they don't need to know. It's possible to err here in either direction. On the one hand, Xen: The Contest gives too much information. There's some bit about a rogue agent who never appears in the story and makes no difference whatsoever. But nevertheless one of the NPCs feels compelled to explain that she's not the most powerful one around, she's only the second-most-powerful agent because of this other guy. On the other hand, it's also possible to avoid giving enough information — Waldo's Pie never makes the motives of the villain clear even after you've won. It's useful to throw in details for color, and it's useful not to include irrelevant information, but in the end, the game has to be written so every important question has an answer, and nothing that isn't important looks important.

Putting It Into Practice

The best way to make use of these tips is to actually play your game repeatedly, keeping the player's perspective in mind as much as possible and really see what your game feels like to someone who doesn't know how it works. Remember to try things that aren't necessarily essential — players are going to examine everything, ask NPCs about various topics, move in directions they shouldn't and take objects they oughtn't, because they don't know what's a correct move and what's not. Also remember to test the whole game like this, not just the beginning. You may need to write a debugging verb or replayable transcript to jump to later scenes of the game so you can make sure they get as much attention as the earlier scenes (or nearly as much; by the time they get to later scenes players will hopefully understand how the game works a little better and go off-track less).

Conclusion

There are obviously a lot more things to be learned from this year's set of games than the few things I've listed. For that matter, there are plenty of games that did good stuff that I didn't touch on, since mostly I was looking for bad examples. But I hope this article is helpful in giving authors some guidance. By thinking like a player when writing and testing your game, you'll come up with games that are better-designed, more playable, and just more fun.


If you'd like to see more IF-related things from me, you should look at my main IF page.