Humbled: a Review of Gemini

High-concept games impress me; I like it when my understanding of reality is enhanced by having been twisted in a particular way, as with Portal and Miegakure.

Sometimes, though, it doesn't take much for a game to be a mind-opening experience for me.

This year at PAX Prime, I came across Gemini. Drawn in by the soothing graphics, I picked up a controller at an available station.

In Gemini, your avatar is a small sparkling circle. The world is 2D. There are no apparent obstacles; just the ground, which is a line you can't fall past. The game uses all of two buttons: left bumper and right bumper.

Naturally, I moved both left and right along the ground, but I didn't seem to be making any progress. I glanced over at the other players. They were clearly able to go up. I wanted to go up, too.

After skittering along the ground for another minute, I started pressing every button on the controller in a vain attempt to start flying. Sometimes I hopped a little. One of the devs caught me button-mashing, and tapped me on the shoulder. "Those are the only controls," he said, pointing at the LB and RB icons on the screen.

Exasperated and embarrassed, I looked up at the game's poster for additional clues. I finally parsed the name, Gemini. The twins, a constellation. Wait a minute. Twins. Should I expect another player to show up?

There was a glowing bauble that appeared from time to time. I had presumed it was a part of the background. It had moved around some, but didn't seem to do anything. I had ignored it. I did recall, though, that every time I'd hopped off the ground, that bauble had been nearby. Maybe it was important, after all.

So I went back over to the little glowing orb, and sure enough, I jumped a bit. But it wasn't a real jump. Instead, I ascended somewhat unpredictably while in its proximity. With more experimentation, I found that it would follow me upwards. The bauble and I were entwined, but only just so. I couldn't get too close, or it would repel me like the wrong end of a magnet. I couldn't get too far, or we would both drift to the ground. If I kept to a certain 'Goldilocks' distance, however, I'd move upward, and it would follow me a little bit. Only together could we ascend.

I found that I had the power to fly wherever I wanted, but I could never take a direct route to get there. Gemini rejects precise, Mario-like controls. Instead, you make a butterfly-like dance across the screen with your companion orb.

When I made this realization, I had to blink back an actual tear.

You see, I'm from a WEIRD (western, educated, industrialized, rich, and democratic) culture. We emphasize the individual over the group more strongly than any other people in the world. The boundary I draw between myself and others is so strong that it took me several solid minutes to figure out that I even had a companion in a game called Gemini, let alone that my interactions with that companion could let me fly.

For gods' sake, I had rejected the power of flight in favor of telescoping in on the one aspect of the game I had the most control over. I was blind to the fact that my avatar could even exist as a system between a pair of entities. Consider my eyes opened, Gemini devs, and thank you.

NYU Game Center Incubator, please release Gemini soon. Every WEIRD person in the world needs to play it and be humbled.

Maintaining the Joy of Altruism in MMOs

Designers often rely on players' enjoyment of helping others when guiding them through their first steps in the game. New players may not yet understand XP or the advantages of leveling, but they do understand that the people around them need their help. First quests in MMOs often illustrate how the world is in danger; they give players the opportunity to assist while teaching them the basic mechanics of the game.

As players' time in the game wears on, they see more and more violent events. Many quests ask players to kill NPC animals or people. Art props in the game world often include bones and corpses, and less commonly, wounded NPCs.

My suspicion is that after a while, some players become inured to the violence around them, and become less likely to respond to pleas for help from the NPCs. At the same time, players learn more about how the game works, and discover how to direct their play experience towards the improvement of their characters. Some players become more likely to pick up a quest for its XP, gold, or gear than for the emotional reward of assisting the NPC.

If the joy of altruism could be maintained throughout a player's in-game career, it ought to provide for a more engaging experience. Briefly, here are a couple of methods that may help with this goal -

• Let the player see that they've changed the world around them for the better. Admittedly, this is easier to do, and more commonly found, in single-player games than in MMOs - but even a wave and a smile from an NPC can help them seem more human and less like XP vendors.

• Tell the story in a way that players understand. If a quest is too wordy, it won't get read, and if the story is too complicated, players will ignore it. Many games succeed by relaying the narrative with the help of the world itself.

Tidbits and Takeaways from GDC 2009

Design games based on your interests and hobbies. For example, Shigeru Miyamoto realized it was fun to weigh himself every morning, and from that we got the Wii Fit.
(from Satoru Iwata's keynote speech)

Our brains are wired with a 'Seeking Circuit'. Seeking out a reward, in and of itself, is at least as satisfying as actually receiving a reward. A person receiving a gift misses out on half the gift if it isn't wrapped.
(from Chaim Gingold's presentation)

Games need weenies - navigational reference points that draw the player towards certain locations, pique the player's interest in future activities, and help the player set goals. The term was coined by Walt Disney; it's in reference to how you might wave a weenie in front of a dog.
(from Scott Roger's presentation)

"If I had given up, there wouldn't be any Metal Gear series. There wouldn't be any Splinter Cell series either, I guess...." This made me lol.
(from Hideo Kojima's keynote speech)

Passing money over a social network damages friendships. Money is there for when friendship won't cover what you need. "Facebook wouldn't be Facebook if it was a giant Amway party."
(from Nicole Lazzaro's presentation)

People move towards light, but more importantly, away from darkness. This point was reinforced in several talks. Lighting is one of our most powerful tools in guiding player movement and behavior.

Blizzard's WoW quest designers had to deal with concerns about spoonfeeding players with quest bangs, the quest log, and quests after level 10, among other things. Jeffrey pointed out, "players need a lifeline to the best moments in game. This is elegant game design, not hand-holding."
(from Jeffrey Kaplan's presentation)

Lionhead Studios likes portals. They were working on a portaling concept before Portal came out. Peter Molyneux demonstrated an experiment that his team had put together - a pair of mirrors that you could drop objects into, and depending on the objects' attributes, they change as they go through the mirrors. "Portal proved how brilliant the guys at Valve are."
(from Peter Molyneux's presentation)

Want to make great games? Bring a behavioral psychologist on staff! Valve has just such a person: Mike Ambinder, PhD, and I made a point of attending his talk. In a nutshell, he encourages designers to take a scientific approach to game design.
(from Mike Ambinder's presentation)

The Eyes of Master Chief

"Why are you getting Halo 3?" my co-worker asked.

I gave him my answer. "I cannot go another day forward as a game designer without playing Halo 3. It is too important of a game for me to have missed." (And I'm over a year late!)

I had read the reviews and back story, of course, and I'd had many long conversations with fellow game designers about the glories and wonders of Halo 3, but somehow, none of that prepared me for playing the real thing.

At once, I drank in the beauty of the game. The music, the environments - and all the loving detail put into the weapons, vehicles, and characters - it was delightful.

In the initial sequence, my teammates help me up. They're so happy to find that I am well - they treat me like we've been friends for years. They have so much respect for me, I don't know if I've ever felt so welcomed.

What an unexpected sequence of emotions! I thought I'd be shot to death many times over in the first few minutes, not step into a living world surrounded by friends.

Then, at the end of the intro, the camera shifts to become the eyes of Master Chief.

Somehow, I wasn't prepared for it. Yes, the first two letters of "FPS" stand for "First Person" - you'd think that would be a big giveaway.

So I try moving around. No good - apparently my armor is still locked up. However, my friends are here to help, and one of them offers to recalibrate my suit.

He asks me to look up, so I look up. Then he asks me to look down, so I look down. We repeat the process. And then he tells me he's set my look style to "inverted."

I'll admit that I'm most accustomed to 3rd-person-style controls. In many 3rd-person games, your camera sits on the outside of a sphere and always looks inward towards your character's head. Thus, when you move the camera downward, you see more of what's above your character, and likewise, when you move the camera up, you look down. While it is "inverted" to move in the opposite direction from the way you want to look, it's completely natural for someone used to playing in the 3rd person (like me).

Satisfied with my inverted controls, my armor unlocks, and I'm free to move about on my own. I try all the buttons. Movement with the left stick - check. Shooting with the triggers - check. Reloading with the bumpers - check. Jumping - how do I jump again? Ok, the A button makes sense.

And then I try looking around. I can't do it. Looking up and down is great - we tested for that - but every time I try to look left, I end up looking right, and vice versa. What gives?

Unable to aim my weapons, I hit pause and go straight to the configs. I check all of them, and realize my problem. Inversion is only an option for the Y axis, not the X axis.

I try to get used to it. I run around, trying to look at rocks, plants, and my companions. It's a no-go. I'm moving the stick the wrong way every time.

Disheartened and frustrated, I go online to see if anyone else has my problem. Yes! Games with unalterable X axis controls are frustrating people on both sides. Final Fantasy XII has an inverted X axis that you can't switch to normal, whereas many FPS games, like Halo 3 and BioShock, have a normal X axis that you can't invert.

Sadly, many of the forum posts I read were hurtful. To put it nicely, players said that those who use inverted controls are backwards, and players who use normal controls don't know how to use a camera. Arguments on both sides generally ended in "just get used to it!"

So that is what I did. It took me a long hour of play to start looking in the correct direction, and it took me another hour to learn to aim accurately.

During those two hours, I spent a lot of time hiding behind rocks, being frustrated, and not shooting aliens. I felt like I was letting down the Arbiter, Avery Johnson, and the rest of my team. I could have jumped right into the game if I could have inverted the X axis.

With this experience, I have taken this lesson to heart: It's important to make a game's controls be configurable in as many ways as possible without breaking the game.

Designers can't assume that they know where a player is coming from, and players should not be forced to re-map what's intuitive to them - nobody likes to hear that they must "just get used to it."

Aside from that point, I took to Halo 3 fairly well. In fact, it's probably because the rest of the game is so intuitive that my X axis issues stood out like a sore thumb... or should I say, a confused thumb!

Are Designers Playing Too Many Games?

Game designers tend to agree that playing games helps you learn about how to design them.

For example, in Rules of Play: Game Design Fundamentals, Katie Salen and Eric Zimmerman write, "Students should play every possible kind of game, digital and non-digital, contemporary and historical, masterpiece and stinker."

They give several good reasons why, including the fact that designers need to learn how games function to create experiences, and they need to see what does and doesn't work about design choices.

Yet, Raph Koster offers a word of warning in his book, A Theory of Fun for Game Design.

He writes, "They [game designers] build up encyclopedic recollections of games past and present, and they then theoretically use these to make new games."

So what's the problem? Essentially, due to the way human brains work, designers are more likely to pull from their existing mental library of game design solutions than they are to try to innovate new ones.

Raph writes, "The most creative and fertile game designers working today tend to be the ones who make a point of not focusing too much on other games for inspiration."

So, the very library of knowledge that designers must build in order to understand and design games can prevent them from exploring new potential game designs.

How do we get around this?

Game designers, of all people, need to "stay ahead of the game." Not playing as many games probably isn't going to help.

Perhaps simply having an awareness of our 'mental game libraries' can help designers choose whether or not to select a solution from them.

Perhaps, too, we can be mindful of fun wherever it occurs. For example, it might be worthwhile to make note when you see yourself or others having fun outside of a formal game environment, and ask yourself how you could bring that experience into a game.

Prepare to be Tested

When I was first hired in the games industry, it was based on the merits of my portfolio. At that time, only one of the companies I applied to gave me a test. I saw it as an unusual hurdle.

This time around, however, it became the norm. Virtually every potential employer gave me one or more tests; I ended up taking over a half-dozen of them. Some tests took me only 2 hours, others took me over 2 days.

So, at this point, I feel adequately informed to offer some advice to those seeking game design work.

1) Don't be offended. If a game design company says you must pass a test (or even several tests), don't act shocked. Don't make the assumption that the company doesn't like you, even if someone else who applied there wasn't given a test. Simply, if the company is one you want to work for, take the test.

2) Be timely. Do not take more than 6 days to complete your test. If you're really interested in the company, be done in less than 3 days. If they ask for the test to be completed in a certain number of hours, finish in under the time limit. If you have schedule conflicts, discuss them with your potential employer so you don't have to rush.

3) Be clear and concise. Companies aren't just testing your game design skills - they want proof of your ability to communicate effectively. You must walk a tightrope with each of your answers. You cannot afford to ramble, yet you must explain your thought processes and math choices.

4) Research. All but one of the tests I took was "open book." If you come across something that you're not sure about, Google is there for you. Cite your sources as needed. Plagiarizing is just as unwelcome here as on any test.

5) Edit your work. When you're done with the test, go do something else, then come back and edit your answers with a fresh mind. You'll at least catch some typos (well, I sure did), and you may come across answers you'll want to rework. If it's a timed test, save a few minutes at the end to give your answers a once-over.

6) Pace yourself. Read through the whole test before you start answering questions, so you have a good sense of what you need to do. Design tests can vary widely in content, though the core of most tests will have you design a game, level, or quest/adventure. In general, if you find yourself spending too much time on one answer, come back to it later. You may find that you have fresh insight after working on other questions.

7) Don't worry. Even if you aren't offered employment, by working through the test, you've learned more about game design and you've become a better game designer.

Uncomfortable Design

This is less a thought about game design, and more a thought about designers themselves.

Looking at my own and others' experiences, game designers seem to learn the most about their trade when they step outside of their zones of comfort.

For example, if designers work on nothing but a single system for years, their design skills - even in regards to their most familiar system - improve if they work on another system in the game. On a broader scale, I'd even say that console design can inform PC game design, and vice versa.

When designers leave their most familiar contexts, while it may be uncomfortable, I think it grants them more opportunities for lateral thought, and greater game-making potential.

Paper Prototypes

Designers love to design, and they are full of design ideas.

For most game designers, the early stages of a project are candy - brainstorming, throwing piles of ideas out on the table, and discussing them with other designers. It's genuine fun to work on something new; to get to decide the rules from the beginning.

An issue with developing prototypes for most computer games is that they require an engine, and a comprehensive set of tools for implementing assets and content. If these are not already developed, designers (if they are not also coders) can end up with a lot of time on their hands while they wait for the coders to get the fundamentals in place.

Here's the danger. Because game designers love to design games, it's easy for them to use this time to design additional, and potentially overambitious, aspects of the game. In a worst case scenario, you end up with a game far too enterprising for the scope of the project.

Considering the <20/>80 rule of thumb that I discuss in a previous post, designers ought to be spending this extra time playtesting their prototype. But how can they do that if their prototype only exists as a design document?

The problem can be solved by testing the game system on paper while it is being coded. I've seen it work. Applying iterative design to a paper UI can help solve many design problems ahead of time, and help make the system more fun than it would have been.

If you time it right, when the code is ready for the final design and content steps to be taken, it's possible to have many gameplay kinks worked out (instead of a thicker design document).

Paper prototypes for the win.

Portal

Many gamers routinely lose track of time while playing a computer game. For me, it has been years since it happened last.

When I finally sat down to play Portal, I finished the game thinking it was around 8 or 9PM, 10 at the latest. It was 2:30AM.

Some have complained that Portal was too short a game. Truth is, if it had been longer, I wouldn't have gotten any sleep that night!

Steve Williams has said most of what I would say about the game (all of it glowing praise). To his comments, I add the following:

If you are a game designer, or anyone curious about how designers make games, complete the Portal maps to unlock their Developer Commentary.

Listen to the Portal devs, and you'll see how they applied playtesting - and the principles of usability - to the game. In Portal and in Team Fortress 2 interviews, the developers have commented on how iterative design helped them make their games more usable.

Also, I think we'll be seeing a lot more songs written for/with computer games after the success of "Still Alive," the closing song to Portal, sung by voice actress Ellen McLain and composed by Jonathan Coulton.

Happy Portaling!

A Rule of Thumb from Rules of Play

Within Rules of Play, the authors advocate something so phenomenal, I am compelled to quote it:

"We have a straightforward rule of thumb regarding prototyping and playtesting games: a game prototype should be created and playtested, at the absolute latest, 20 percent of the way into a project schedule."

My heart grew three sizes when I read those words. Look at the rule another way: At least 80% of a game's development cycle should be testing, redoing, and polishing. at least.

Imagine what awesome games could be made if design teams were expected to take 80% or more of their development time refining and perfecting their prototypes.

There exists at least one such game - Puzzle Quest. Infinite Interactive had a playable prototype for Puzzle Quest up and running after only 2 months. Then they spent an additional 25 months tinkering with, adding content to, and polishing the game. Having a working prototype just 7.4% of the way into their project schedule allowed them to develop a fun, successful game.*

While I couldn't find precise numbers for World of Warcraft, we can infer that a large part of Blizzard's development cycle is spent on iterative design, given the high level of value they place on game polish.**

In my experience, games like these are the exception.

I'll be keeping my eye out for other examples of games that followed the <20/>80 rule of thumb during development. It would be an interesting chart to look at game success vs. how much time dev teams spent in the prototyping and iterative design phases.

References:
* The September 2007 issue of Game Developer has a comprehensive story on the development of Puzzle Quest.
** Rob Pardo's keynote speech for AGDC 2006 gives some hints on the amount of time Blizzard spends polishing.
I encourage all game designers to read Rules of Play, a game design textbook by Katie Salen and Eric Zimmerman.

Peggle vs. God of War

In my quest to learn more about game design, I decided to play God of War this past weekend.

I enjoyed the character, Kratos, and had a great time spinning his Blades of Chaos with Apollo's Ascension to hack enemies to bits. Then I came to the Rooftops of Athens, where I promptly got stuck. The room is like this: archers shoot at you while you jump from one vine-covered pillar to the next, then onto a platform.

Easy enough, right? I jumped over and killed the archers, then hopped nimbly back onto the vine-covered pillars. I could jump between the pillars easily, but the jump to the platform was simply impossible. I tried it dozens of times, and even recruited a gamer friend to help out. He just kept falling, too. Neither of us could figure out the catch.

I looked up three different online walkthroughs, and none of them spoke of that jump as being difficult at all. I went back and tried the jump another several times, then gave up in frustration.

Eager to feel some sense of success, I decided to give in and download the Peggle trial that Cuppycake suggested. The juxtaposition of genres nearly broke my soul.

After I won a few games, and got over the rainbows, woodland animals, and flashing colors, I found myself playing with the main menu. That's right. The main menu. I discovered that each of the buttons plays a different note on mouseover. There are eight buttons, one for each note of the scale.

Of course, the first song I played on my new Peggle xylophone was Ode to Joy, the music that plays when you win a game of Peggle. And I couldn't stop laughing, because that's exactly what the designers of Peggle must have been thinking when they assigned mouseover sounds.

On that note, it reminded me how important it is to include little things in your game that allow players to not only play in the game, but play with the game.

The other design lesson of the day is to not make jump puzzles so hard that the average player can't make it after several tries.

As for me, I'd love to see a Peggle interface mod with God of War graphics and sound. Can you imagine Kratos shedding a tear as you mouseover the Quit button?

Writing for Quests

Attending Jess Lebow's panel at AGDC, I was reminded of just how difficult it is to write quests for MMOs.

Jess spoke of the differences in approach that designers and writers take to quest writing.

Typical designers often just want to get the instructions across to the player, like so:
"Take Spike's club to the Ulbroth foothills. Ask an attendant of the Great Gates where Ulbroth Graveyard is. Go to the Graveyard and search for Spike's gravestone, then right-click Spike's club to activate it at his gravestone."

Typical writers often just want to tell the player a story, like so:
"The great ogre, Spike, once wielded this very club. He smashed more giants than any other ogre at the battle of Ulbroth, where the ogres fought the giants for control over the Ulbroth foothills. This battle meant everything to both factions, for Ulbroth is a land rich in both iron ore and peasants waiting to be turned into slaves..." (writer hits text character limit)

My experience indicates that a third kind of quest writer exists - the 'hardcore' quest writer.

These 'hardcore' quest writers intentionally omit key details from their quests because they want players to figure out the quest for themselves, like so:
"All that is left of the great ogre, Spike, is this club. Some legends speak of him fighting giants."

And, I must admit, depending on the complexity of the game you're writing for, sometimes a puzzling quest is a welcome diversion.

So what's the ultimate goal? Ideally, quest writers must balance all three of these needs (instructions, story, and puzzle) within the context of the game they're working on. They have to give the player enough of a clue to figure out how to resolve the quest, tell enough of a story to keep up the player's emotional interest, and generate enough of a puzzle to keep the player's mind engaged... and do it all within the text character limit constraints of the game.

It's not easy.

Transportation vs. Travel

In my last two posts, I've been careful to use the word 'transportation' instead of 'travel,' and with good reason: My goal is to highlight the gameplay differences between the two.

Transportation lets players move among places they've already been. In some cases, transportation lets players move among places that their characters would have had easy access to - even if the player is new to the place.

Players travel when they go somewhere new. When players successfully travel through a new area, they often earn new modes of transportation.


However, the line gets blurred fairly easily. For example, when players choose to take 'the long way' or 'fight their way' through an area they've already been, I would say that the players are traveling.

Another blurry line appears when players use their own mounts or vehicles. If players can whiz by content that would put them in danger if they weren't on their mount/vehicle, then I'd say that's transportation. However, if the use of the mount/vehicle only causes players to encounter danger more frequently, then I'd call that travel.

Links to my other posts on the subject:
Meaningful Transportation
Beautiful Transportation

Beautiful Transportation

So, let's run with the idea that transportation in MMOs doesn't need to generate fiero. This still leaves designers with a variety of emotional options.

My two favorites are delight and wonder - the twin joys of beauty and discovery. No matter what the medium (running, teleportation, vehicle-on-rails, etc.), transportation gives designers the perfect opportunity to bring about these emotions in players. It fits because players can be shown things they don't often see, and because the experience doesn't last long. Wonder is a brief emotion, just like transportation in MMOs must be a brief experience. On top of all that, there's a real-world connection: wonder and delight are emotions of fun that you experience while traveling in the real world.

Taking players to places they don't often go is a great way to generate wonder. In WoW, for example, the griffon flies over places that are inaccessible to players, and each different griffon route shows players another piece of Azeroth they would never have otherwise seen. Taking players over these areas encourages them to piece together the world and discover its connectivity. This is a refreshing mental exercise in WoW, since the main play experience has players spending their time in walled-off zones.

Viewing enjoyable artwork generates delight, and moving through an artistic landscape heightens that delight. Artists who know their trade can work with designers to put together amazing transportation paths that elicit delight at every hill, lake, or turn. Vehicles and mounts should be artistically engaging, if not detailed; players are likely to watch their mount or vehicle more than their own avatars during travel. Even in a teleportation situation, the means of teleportation can be made delightful with the skillful use of particle effects, animations, or cut scenes.

Possibly the most important fun emotion related to travel is the visceral pleasure of movement, which can be represented in games by animations.

If 'run' animations for avatars, pets, vehicles, and mounts are crisp, clean, smooth, and exaggerated correctly, it can give players an enjoyable sense of movement. If those animations include some sort of whimsy (like the cat ears that swivel in WoW), all the better. As someone who has studied birds, I'm something of a connoisseur of flight animations. It's more enjoyable to watch strong, flexible wings that pull you through the air with each downstroke than it is to watch stiff wings with plain up-and-down movement. Well-made animations can make earning a mount (or any form of travel) worth the hassle.

So, looking at these emotions (delight, wonder, and pleasure of movement) as the requirements for fun travel, we can evaluate the types of travel found in games.

Meaningful Transportation

Players often expect 'meaningful travel' from MMOs, and they become frustrated when travel becomes trivial. I think some player frustration could be alleviated if there was a clearer separation of transportation from travel in MMO gameplay.

From both a social and gameplay standpoint, transportation in an MMO can't take more than a few minutes. An emotionally invested (hardcore) player will have a higher tolerance for longer travel times, however, ultimately, it's an MMO's job to get players playing with each other, and if it takes too long for players to meet up, transportation becomes a huge deterrent to group play.

Games use a variety of strategies to create the illusion of distance. There's teleportation via interactable objects or player-cast spells; rail transportation, which includes vehicles and mounts that go along fixed paths in the world; player-owned vehicles and mounts that increase player run speed; and any combination of the above.

If fun can only come from fiero, the joy you feel at overcoming adversity, then options for transportation are limited. For example, if players start out in different areas of the world, and each player must fight through tough mobs to earn a griffon ride to the dungeon, they'll experience fiero, but they'll also lose time that could have been spent with each other.

I think it will help hardcore players to think of the situation this way: What is a dungeon if not a place where groups run a long distance while fighting mobs? If you think of the dungeon as the place where 'meaningful travel' occurs, suddenly, the act of getting your friends together in front of the dungeon - transportation rather than travel - doesn't have to cause fiero - you can trust that the fiero will be there for you inside the dungeon, and it will be accompanied by and magnified by the social fun you will have.

Timing Emotions of Relief, part 2

I'll muse on X for a bit.

If X is too large - such as when designers make puzzles comparatively easy to solve yet difficult to execute - then it can lead to player frustration.

I remember the infuriated screams of one of my friends as he played Tomb Raider. He had figured out which jumps to make, and he knew when and where to make them, but because the timing was so delicate, he ended up failing too many times. When he finally made it to the next area, he was still quite angry about having wasted so much time. I saw his fiero change from a potentially cheerful "Hurray, I did it!" to an angry "Finally!" Not only that, but the negative emotions of his frustration likely overran the "Cool" emotion he would have felt at discovering and exploring the next level.

That brings up an interesting aside. One player behavior I've noticed frequently in myself is that I prefer to save games in the middle of levels. After completing a level, I find that my curiosity about the next level is so high, I seek relief (Cool!) by going and exploring it. Once that need has been met, I feel more comfortable ending the game session.

Back on topic, an example of highly variable X can be found in Shadow of the Colossus, where players fight nothing but bosses called colossi. Each fight is a puzzle, and depending on the boss, the battle requires more or less dexterity of the player. For a few of the colossi, once I figured out how to defeat them, I killed them on my very next attempt. For most of the colossi, it took me a few tries once I solved the puzzle. And, for a few of the colossi, it took me a frustratingly large number of attempts to take them down even after I knew exactly what to do.

So, how do we keep X from becoming frustratingly large? I think that after players have solved a puzzle, they should be able to execute the successful strategy in just one or two tries. X can (and probably should) be greater for boss fights, since players have emotionally invested more in the game by the time they reach a boss, and will be more tolerant of failure.

On the opposite end of the spectrum, if X is too small, it may be possible for designers to prevent players from savoring their "Aha!" moments by overwriting them with potentially more powerful "I did it!" moments. Then again, if players are allowed "I did it!" right after "Aha!," the effect of both forms of relief might be magnified. It warrants observation.

Timing Emotions of Relief

Players experience relief when they achieve goals, but in games where they must reach multiple smaller goals to accomplish a larger one, when should they experience different types of relief?

In many games, especially first person shooters and platformers, players run into a new area, suffer setbacks, figure out why they were set back, then use that knowledge to avoid the setbacks. Usually, the player iterates through this process a few times, solves the area, and proceeds to the next one.

Players experience emotional relief* in at least three ways during this process. First, there is the relief to their curiosity, which happens when they learn what's in the game area and how to manipulate it (Cool!). Next, there is the relief they feel when they figure out what they need to do to solve the game area (Aha!). Lastly, players experience fiero (I did it!), and the relief that follows it, when they actually solve the puzzle.

So, should players experience these emotions at once, a few at a time, or widely separated from one another? I've heard Damion Schubert** suggest that the cycles of tension and release be based on the level of emotional investment a player has in the game. It makes sense that a casual player should experience relief (or reward) more frequently. As the player moves up the continuum from casual to hardcore, the cycles of emotion should take longer, and the relief achieved should be greater. This pattern can be seen in most MMOs, where getting from level 1 to 2 takes minutes, yet getting from level 49 to 50 takes days.

If we accept that players' emotions (and game designs) follow the 'short time, small emotion leads to long time, big emotion' pattern, I'd like to focus further on when players should experience the different _types_ of emotional relief.

I'll use a hypothetical game experience as an example: In an FPS, you reach a big room that has several ledges high on the walls, a few boxes scattered on the floor, and a rope hanging from the ceiling. After playing through the room several times, you discover that a monster appears on one of the ledges after you have been in the room for a short while, that there is a horde of ankle-biting creatures that appear on the floor, that the boxes are movable and stackable, and that you can swing on the rope to get to a few of the ledges (Cool!). The price you've paid for this information is, let's say, six deaths: four from the monster's guns, and two from falling.

You get excited (Aha!) when you solve the puzzle: You've found the place where the boxes must be stacked so you can jump up to the rope. You've also figured out which is the best ledge to swing to; it gives you a few extra seconds before the monster can climb up to you. You've discovered that you need those extra seconds to use a combination of weapons and available artillery against the monster, but once the monster joins you on the ledge, only one of your other weapons can kill it. You've solved the puzzle, but you haven't completed it yet.

Now, you prepare for your moment of triumph. Stacking the boxes is dangerous; the creatures on the floor bite at you mercilessly, and you can't afford to spend time killing them. The jump from the box to the rope is a tricky one. If you don't make it on your first try, you're too exposed and the monster gets in enough shots to kill you. After X number of additional tries, you finally manage to kill the monster (I did it!).

Let's look at X for a moment. X is the number of times players must attempt to execute the correct strategy before they succeed at their game's objective. We can also look at X as a variable span of time: How long after a moment of puzzle-solving relief (Aha!) do players experience fiero relief (I did it!)?

Each different span of time between moments of player relief could be given its own variable. For example, we could also look at V, which we could define as the gap in time between when a player experiences curiosity relief (Cool!) and puzzle-solving relief (Aha!).

Watching when X and V (or any other gap) become too large or too small may be valuable in game design.

~~~
References

* My parenthetical emotions borrow from Nicole Lazzaro's 'fun keys'.

** Damion Schubert's blog is Zen of Design. The concept of players existing on a continuum of casual to hardcore is just one of the ideas I learned from his panel at AGDC.
~~~