Years ago, when I used to play with interactive fiction languages, I happened upon The Player's Bill of Rights by Graham Nelson. It was a part of his Craft of Adventure essay and it was mostly lost to the archaeological strata of the Internet. Despite its age and obscurity, the Player's Bill of Rights is still an elegant, relevant view of game design and the player's experience. Many of its core messages hold up well in today's game design environment.
There are parts of the Bill of Rights, though, that are pretty specific to text adventure games. Here's my version of the Player's Bill of Rights, based on the original with some topics updated to be more generally applicable. If you want to see more of Graham's original Bill of Rights, please check it out. It's a great read!
As a player, I have a right:
In the original, Army training version of Full Spectrum Warrior, any one of your soldiers could get shot at any time without notice--even from behind cover (provided the enemy had a narrow angle on the soldier, such as when the soldier peeked around a corner). As we created an entertainment experience out of that training tool, it became very clear that insta-death wasn't fun, even if that death was the result of a bad decision from the player.
We made a set of changes to help give players a second to assess the situation and react. For example, we guaranteed for the lowest two difficulties that an enemy's first shot would never kill a soldier on your squads. You always had at least a few seconds to process the fact that an enemy was firing on you, and react to it. This choice made the game feel more fair and thus more fun. A strategy game is all about learning how to think, and if players don't understand what just happened to them, they are unable to learn from the experience.
In the original Bill of Rights, these were two rules: one about unclear hints, and a second about needing to do unlikely things. Graham was was predicting the future here: he wrote these rules before the advent of the cat-hair mustache. My personal breaking point with inventory-based adventure games was the fish fertilizer puzzle from Kyrandia 3 (so skip the next paragraph if you don't want a spoiler).
I'm in a room with bricked-up exit. My inventory includes many items along with sesame seeds and an eel. I have to use the eel on the seeds to create fertilized seeds. Then I have to place the eel-fertilized seeds in a small hole in front of the door, water them from a flask, then watch them grow into a plant that breaks the bricks open. If you think that sounds tricky now, imagine it back in the days before Internet walk-throughs.
Most modern games have hints, but they're less about clues to solve a mystery and more about general direction for how to proceed and how to succeed in the game space. A few games use discovery as a core game mechanic, but even in these cases many players rely on wiki and database websites for answers rather than their own explorations and experiments.
So how clear is clear enough? The best way to answer that question is user testing. It's rare that you can make those decisions about your own game because you're too close to it, and your skills (mental and manual) are too honed by hours of testing it. Beyond testing, you can build in systems that let you adjust for clarity in the future like loading screens with tip text (which can be updated with a small patch or, better yet, live data).
I've combined two of Graham's rules here, since they're similar. We've all been there: you open the monster closet and--you guessed it--the monster pops out and kills you. This has a modern equivalent: is the boss only vulnerable to fire attacks? Did you, by chance, happen to bring a fire weapon into the battle? Oops.
Monster closet? Yes, I'm looking at you, Doom 3.
I used to encounter this problem most frequently in timed sequences. There's a certain appeal for designers in taking a skill players have learned over time in the game and requiring them to perform that skill under pressure. There's a difference, though, between adding pressure to the skill and having preset requirements that you have little or no time to anticipate during gameplay. You end up trying to memorize the sequence ("OK, so after this tunnel is the bit where the giant underground worm comes out on the left") which feels unfair and distracts from the action-packed finale the designers probably envisioned.
This also rears its ugly head during QTE (quick time event) sequences. Some games try to discount past life experiences by changing the exact button press required, but it doesn't change the situation. The requirement to replay sequences to learn what happens--and only learning by failure--makes most QTE sequences break this rule.
I first started this post before the 2012 holidays, and just now found time to finish it. I'd originally typed that I hadn't encountered games that break this rule in a while, but over the break I played 9 Hours 9 Persons 9 Doors.
Nine paths to frustration
999 is an adventure game that feels like a mix of interactive fiction and "escape the room" puzzles. I really liked it for the first 3 hours, then liked it OK for the next 2 hours, then ended up deciding I disliked it enough to debate buying the sequel. The underlying design premise of the game is that you can replay to make different choices and get a different ending.
The game lets you skip all the conversations when you replay to find a different ending, which must have been an easy choice because the game has a lot of talking in it. On the other hand, you can't skip or shorten the escape sequences, so you're replaying the same puzzles over and over again. I was willing to do that for the first replay, where I made some choices that led to a few different puzzles.
On the third replay, though, I realized getting the "good" ending wasn't about a path I hadn't chosen the first time: it was about a specific combination of choices that are not obviously different from any other choices you make. There are six endings to the game. Only one is the "good"ending. There is no indication as you play that any particular choice leads to any particular ending. There's certainly no way to determine that while playing the game the first (or even second) time.
This means there are strong odds while playing that any decision you make in the game--including some of the earliest--will close off the "good"ending, and you have no way to know it just happened until you finish the game, see the ending, the play the whole game again.
Some people would put game grind in this category, but not all grinds are bad. Some repetitive tasks are relaxing and have a certain zen to them, like playing Bejeweled or digging out corridors in Minecraft. Jeff Vogel calls it whittling. In these instances, the activity itself is rewarding and simple: you click, and there's a response that looks and sounds interesting as it changes the gameplay space.
Whittling changes the game space
Whittling is the edge case though. It requires a surrounding support structure of creativity, goals and environment to work without feeling boring. It's hard to get right, but that doesn't stop a lot of games from adding relentless grind without rewarding metagame structures or even entertaining aspects to the interactions.
When you add something repetitive to a game, ask yourself:
If the answer to all three questions isn't yes, then you should probably reconsider the mechanic.
In Graham's original Bill of Rights, he had two separate rules: "Not to have to type exactly the right verb" and "To be allowed reasonable synonyms." I've combined the two into one rule. There's a direct correlation between verbs in IF and game actions in modern games.
Game mechanics are all about creating a box for the player, then giving him tools to maneuver within--and sometimes escape from--that box. These tools can be actual tools (like an ax in Minecraft), or they can be more abstract like player movement modes (sprint or grapple).
When you give a player a tool, you're making a promise. You, the developer, promise the tool will work in a predictable way, usually with an associated risk and reward. You're also promising there are instances in the game where that tool will be clearly valuable.
In a good game, your goals and instructions are clear and provide the set-up to a given challenge or level. In a great game, the entire game world communicates to you. It broadcasts what you need to do (your goal), how you might get there (clear or subtle paths and obstacles) and which tools will be most useful in this specific scenario.
The Zelda games are fantastic examples of getting this right. Every tool you're given solves a specific type of problem in the game world. You can look down the path you're expected to travel and understand what the game is asking you to do. Even when it's tricky to figure out the right order or combination of interactions to achieve the desired result, the interactions themselves are clear.
Graham's original rule was: "To have a decent parser." There's a direct correlation between the role of the text parser in interactive fiction and the role of the controls and UI in modern games.
I love you, System Shock... but holy crap
We've come a long way since System Shock, which is one of my all-time favorite games but also has some of the most complex controls and UI I've ever seen. We have higher standards now, so when a game comes out with below-par camera, for example, it's all reviewers and players can talk about. Scan some reviews of Epic Mickey and you'll see what I mean.
The topic gets more interesting as our audience broadens. Momentum used to be more common in platformers--you would release the controller, but your character would continue to move forward a bit as the "stop" animation played. Yes, it looks more fluid, but it also adds a level of complexity that makes the game more difficult to play.
Similarly, we've seen UI come full circle. We started with the complexity of System Shock, went through our minimalist phase (where The Getaway made us count bullets), and now have come full circle. The advent of development tools like Scaleform makes it easier to have detailed, animated UI elements. Just because we can have the HUD bounce and pulse and show an immense of detail, it doesn't mean we should.
This rule is a source of debate among game designers. For example, when we were looking at kid's TCGs for Free Realms, we spent time with Pokemon, a game that relies quite a bit on luck. Some designers thought that was fine or even preferable for kids (so you could battle an older player and still have a chance to win. Other designers hated it.
You can see the concept of luck as a prevailing factor in free-to-play games like Candy Crush Saga, where it's used as a gate, and of course in many RPGs in the form of random loot drops.
If you don't monetize in Candy Crush Saga, your fate is 1/3 skill and 2/3 luck
I believe the question of whether luck is a valid player tool depends on the game style, and the impact of player skill on the element in question. If the element is closely tied to player skill, then having a bad roll of the dice feels unfair. You can see this very clearly in many FPS MMOs that use traditional server-side logic for damage. It doesn't matter if the shot visibly hits the enemy in the head: it does the same damage as hitting him in the elbow. As a player, you feel like you did the right thing--you used your tools in the way the game implied you should--and you were cheated out of the result you expected.
On the other hand, if the game element is not tied to player skill, randomness can be fun. For example, loot drops work fine with a heavy luck component because the reward after a kill isn't tied to player skill. The skill is in killing the enemy, not in looting it.
I wrote this on the whiteboard in the team area for Full Spectrum Warrior as our touchstone for the player experience:
You DO something. It looks COOL. You feel SMART.
Almost every game has something for players to figure out, some element of strategy. It can be in the meta-space, like a strategy to improve your manual dexterity or even to buy a better mouse to improve your aim, but it's still a strategy for how to do better in the game space.
The key loop for player satisfaction in terms of strategy is ensuring players understand a problem once it's solved, and on the flip side that they understand what led to any failures. This is essentially closing the loop on the promises you make when you create the player's box and give him tools.
In the original Bill of Rights, this rule was "Not to be given too many red herrings." We've all played those levels that seem to have multiple paths but only one valid one. The rest is a spaghetti ball of monster closets, loops and dead ends.
One thing I always keep in mind is that you can never erase the feeling of being lost even when the player wasn't actually lost. Even if the game is a corridor shooter, if the player feels like there are unexplored options or side paths that he could have taken--if he feels lost--then the effect is exactly the same as if you created a complicated, confusing level with multiple paths.
It might not occur to you until someone asks: "Are you close to the end of the game?" You realize you have no idea. Understanding where you are in a game is important to your sense of attachment, and your drive to finish. It has an intangible but sometimes profound affect on whether you'll recommend a game to your friends.
This comes in several forms. First, you want a sense of your own skill. How well am I playing? Am I making the right choices? Am I getting better at this? This was one of my problems with 999--I felt like I was making the right choices but I had no objective way to evaluate that, so when I got a "bad" ending, I felt cheated.
Second, you want a sense of progress. Am I halfway through, or almost done? Is the story going to wrap up? Is there a chance, with a little effort, my score this match will move me up the leaderboard? In most competitive multiplayer games, for example, there's no reminder of my leaderboard status during a match so I momentarily lose sight of that progress.
Achievements can give a sense of progress
Whether you love or hate achievements and scoring, players have become accustomed to them. When your game doesn't feature either one, keep in mind that you won't have the easy sense of skill and progress that come with them. Consider whether your story could be broken into chapters, which give a sense of progress even when players don't know how many chapters are in the game. Similarly, try to can arrange weapon choices into some sense of a tree (which implies how far players have progressed based on which weapons they have unlocked).
This is an addition to the Bill of Rights because I think it gets overlooked in today's world of freemium and free games.
For games that come with a fixed price tag, it comes down to the perceived value of the experience provided. Some players translate this into hours of gameplay but it's really about the quality of the experience (along with replayability). As a whole, developers have been in the business long enough that we have a sense for how we should price our games.
In freemium and free games, though, we're still figuring it out. Social games are at the far end of the spectrum. It's easy--and somewhat common--to spend $50 to buy about 15 minutes worth of game time. Not many players are willing to spend that kind of money, and even fewer will consider it money well spent that they'd be happy to spend on a regular basis.
The now-closed Adventure World provided about 15 minutes of play time for a $50 spend
I'm planning to talk about monetization in social games in my next post, so I won't go into too much detail here. As you plan monetization for either freemium or free games, ask yourself whether players who spend money will immediately understand the value they received for that money, and feel that it was money well spent. An offer that's weak from either perspective will struggle to find a foothold in a space that's getting more competitive every week.
There's one rule from Graham that I debated in writing this blog post: "Not to need to be American." At first, I extended that to "Not to need to be a straight, white American male." Then I thought about the original intent of the rule, which is about setting-specific elements and word choices that were specific to one region and unfair to another. It was about not having "boot" as a synonym for "trunk," or "lift" as a synonym for "elevator."
While you can argue that exclusionary design makes games less appealing to groups not in the game's core intended audience, it's not like getting stuck in an IF game because it won't accept the word "loo." Because it's a huge subject worthy of a longer conversation than a two paragraph rule, and because there's not as clear a relationship between tools in a player's toolbox and exclusionary design, I made the difficult decision to eliminate that rule.