Handling player state

A players state is the data describing the value of all the variables pertaining to things which might happen in the game.

If that sounds like "blabla", it's because I was extra careful to word it unambiguosly, but it's probably failing utterly to communicate the basics of what I mean to describe.

So, let me give you an example: the players charactersheet in dungeons and dragons is part of the players state. Abstractly speaking, values which the player has not had a chance of influencing yet are also part of the player state; the lack of a level 20 ability on a level 10 character sheet can technically be thought of as part of the player state, because it is implied by the player state.

Now, as you can imagine, there's one heck of a lot of variables in the player state in a computer game: the player characters XYZ coordinates in the 3d space he inhabits, for example, are part of it.

All of these variables, together, form a cartesian product. A cartesian product is something usually used in math, but the short story is, it's a function, it's sometimes useful, and while it's definite, it's usually not finite, and it's not usually something you can picture in your head unless you're rather brilliant.

I bring it up, because understanding how to handle player state, as a game designer, inevitably ties in to handling the cartesian product: the cartesian product of the player state variables is the collection of all the possible permutations of all the variables.

If the variables were strength and agility, and those variables went from 1 to 3 each, the collection of permutations would be:
(str=1 agi=1,str=1 agi=2,str=1 agi=3,
str=2 agi=1,str=2 agi=2,str=2 agi=3,
str=3 agi=1,str=3 agi=2,str=3 agi=3)
Here, I've seperated each permutation with a comma.

That is, in other words, the cartesian product, and you can hopefully see what I mean when I say it is this product you need to keep in mind when designing a game...going by the above example, if the player only gets to level his stats twice, with a free choice between agility and strength, if you want to cover all your bases in a quest, you need to deal with both players who are 2str2agi, 3str1agi, and 1str3agi...since that's the possible player states at that time, supposing the player is forced to use level up points.

As you can see, all of these are present in the cartesian product above...the cartesian product, in other words, is the source of possibilities the player can expose the designer to, though it almost always contains permutations that couldn't happen at a specific point in a game.

Games are, by their nature, fun because they make manipulating the player state difficult. Handling player state, then, becomes a question of designing fun difficulties for the player. Thinking of the game designers job in this manner makes it seem ever-so-slightly sadistic, but regardless of what it seems like, it is what it is: You're out to stop the player from getting what he wants, to make him fight for it, and to (hopefully) make him beat you whilst he retains the illusion that you wanted to win too Which you didn't. But shh, lets keep quiet about that.

There's more to it than simply designing fun roadblocks though; you want the player to feel as though you are not limiting him, but rather, that he is limiting himself. For instance! the classic jump puzzle, while not very fun, makes the player limit where he walks because you punish him if he does do something else. Think of a room you as a player must walk across. If the state possible within the room is simply the entirety of the room floor, the room is boring. Clearly, where the player is able to walk has been limited by the designer. Put a chasm in the middle of the room, though, and have the player jump over the chasm or be forced to restart at the start of the room, and suddenly, both the player and you limit the player; see, the player limits himself by wishing to avoid the chasm. It doesn't really matter that you designed both obstacles; it doesn't matter if the chasm is a very small challenge to overcome...because it accomplishes the most important thing: the player is suddenly thinking in terms of what he wants to do, and what he wants to not do; not in terms of what you want him not to do.

Since we, as game designers, are forced to make sure our players don't do certain things (walk through our walls for example...he must stay on the path, as it were), it serves us well to try and design the fashion in which the player can change the player state in such a way that he inhibits himself, and thinks in terms of what he does and does not want to do. This, we do by making sure the player can be punished, if only ever so slightly, by being careless.

And that's really it; we should focus on making the hard edges in the player state soft, whereever possible...so instead of being constrained on a huge balchony, the player is on a huge balchony and part of the railing has come off so the player could possibly fall over, if he was careless.

This probably sounds...like a weird hypothesis, but I believe that this type of design is part of the reason Batman: Archam Asylum feels exceptionally free and open, in spite of being quite linear, and oftentimes quite constrained. The fact that you have choice, even if it's sometimes useless and clearly bad choice, it keeps the player making up his mind out the limits of the world, keeps him thinking...and that's really enough to make the player forget about the game designer and his artificial boundaries...