Recently, my amazing wife picked up a copy of Wii Fit. No, this is not a review.
Here is something you may not know about my wife. For the past year, she's been dealing with a rather serious, debilitating illness. One side effect is considerable and undesirable weight loss. On the positive side, she has enjoyed shopping for a new wardrobe to match her more petite frame. On the less positive side, many stores no longer carry clothes that are small enough to fit.
So when the Wii Fit first booted up and cheerily prompted her to set a goal, she decided to try to get her BMI back up to the 'normal level'. Every day or so, she's been exercising, weighing herself and doing yoga. So far she has found the game to be convenient and highly motivational tool for helping her to track her weight.
We've had other exercise equipment around the house before, as well as gym memberships, yoga classes, etc. None of them has been as motivating as a simple set of exercises wrapped in a system of game-like rewards. My wife's experience with Wii Fit speaks volumes about games potential to turn an often mundane activity into entertainment that is delightful, exploratory and highly meaningful. Thinking beyond scales Yet, who would have ever thought that weighing yourself could be turned into a game? Miyamoto did, but then again he is widely considered to be an uber genius. The skeptical observer might imagine that successful cross-over games like Wii Fit are one-in-a-million success stories. Suppose it works for Wii Fit, but nothing else.
However, if the lessons of Wii Fit were broadly applicable, entire industries could be transformed. Games are a competitive advantage that can turn a commodity scale into one of the hottest consumer products of the year. In highly competitive markets, that is the sort of product design super power that lets innovative companies walk away with market share.
As I contemplate my wife's success with the Wii Fit, I'm struck by a multi-billion dollar question: What other activities can you turn into a game?
Almost anything First, though there is no doubt that Miyamoto is a genius, what he does is reproducible by mere mortals. He is able to apply his game design skill (or at least his greenlighting abilities) to non-traditional games like Wii Fit because he understands game design at a very atomic level. Here is another way of looking at it. A craftsman builds tables the same way he was taught by his father and his grandfather can only build tables. But someone trained in mechanical engineering can use the fundamentals to build chairs, bridges, cars or even cathedrals. Similarly, by understanding the fundamental science behind traditional games, you can apply the theoretical tools of game design to transform wildly divergent activities into games. I've written about some of this in the past with essays on skill atoms.
It turns out that most learnable skills can be turned into a game. However, there are constraints. A skill must meet the following criteria before it can be turned into a game:
Decomposable into simpler skills
Skills can be nested
Skills can be arranged in a smooth learning curve
Skills are measurable
Performance can be rewarded
Skills are locally useful.
Let's look at these one by one.
1. Decomposable into simpler skills Complex learnable skills can be broken down into sets of easily acquired core skills. Players can only learn so much at once and overly complex skills overwhelm all but the most persistent players. By breaking skills up into digestible chunks, you are now able to apply many of the basic techniques of game design.
In Wii Fit, the complex activity of "Becoming fit" is broken down into skills associated with using the board, testing balance, endurance activities and more.
2. Skills can be nested Complex skills should build upon and reuse earlier skills. Advanced skills are best taught by the extension of existing skills, not introducing new metaphors.
Game design is built around the idea of core mechanics, skills that are exercised over and over again throughout the game experience. If you can't find a set of basic reusable skills that can be incorporated as the foundational elements of more complex skills, players will deem the activity shallow and lose interest.
In Wii Fit, the act of balancing while following rote exercises is used repeatedly throughout. It is an activity that is easy to learn, hard to master and contributes nicely to a wide range more advanced activities.
3. Skills can be arranged in a smooth learning curve There is a smooth ramp from learning easier skills to learning more complex skills. Initial skills should take only seconds since they leverage existing skills. Afterwards, learning activities should build in complexity until they take minutes, then hours. If the initial learning ramp takes too long, players will be confused or bored and stop playing.
In Wii Fit, you can learn to use the board in seconds. Just step on it. However, more advanced games are slowly introduced until must spend hours of your time to unlock that last activity.
4. Skills are measurable The game can detect when a skill is used correctly or incorrectly. Without this the game cannot provide timely feedback that pushes the player in the right direction.
The fact that Wii Fit is a giant sensor is perhaps to be expected. Within limits, it knows exactly what you are doing and when you doing something incorrectly. This is a dramatic difference from most exercise equipment or a workout video.
5. Performance is rewardable The game can provide the player with a timely feedback and rewards. If the game provides feedback too late or in a manner that is disconnected from the original action, the player won’t learn.
Unlike traditional exercise equipment, Wii Fit judges your performance. It lets you know when you are doing poorly and it praises you when you are doing well. It is not a passive tool, but one that seeks to mold you. This is how games work and is an integral part of their success as a teaching tool.
6. Skills are locally useful The skill can be exercised in a useful manner by the player in a variety of meaningful local contexts. If the skill isn’t useful, the behavior will extinguish.
Local utility is a tricky concept for many, especially those trained to think in terms of filling measurable customer needs. It basically means that the player finds an activity useful in the short term within the local context of the game. Grabbing a coin in Wii Fit may accomplish absolutely nothing in the grand scheme of the player's week. However, it does let the player unlock a new exercise. So for the moment, the player considers frantically gathering coins to be a completely utilitarian activity.
Skills that are eliminated by these constraints What skills are eliminated by these constraints? Surprisingly few.
The biggest sticking point often ends up deciding how to measure complex skills. With Wii Fit, they needed to engineer an entirely new device. It is not uncommon to invest substantial amounts of effort just gathering the right data so that you can reward the proper skills accurately and in timely manner.
Machines alone have a limited understanding of many cultural human activities. In these situations, you need to build your games to use other human beings as measurement instruments. The rating techniques of sites like Hot or Not or Amazon.com are widely applicable.
The other constraints end up being easily worked around with a little bit of thought and prototyping to find what works.
Conclusion When I look at our list of six constraints, it is obvious to me that there are a plethora of skills that are just waiting to be turned into games. Games like Wii Fit or Brain Training may seem exceptional strokes of genius, but in reality they are merely the tiny tip of an immense iceberg. Almost any human skill, be it physical, cultural, political or economic can be turned into a game that enlightens and enables.
As more leisure games emerge that mediate and accelerate the acquisition of skills, there is going to be a economic incentive to spread the science and craft of game design far beyond our tiny game industry. Game design is not just about games. It is a transformational new product development technique that can turn historically commoditized activities into economic blockbusters.
This morning, my wife came back from her morning Wii Fit session and proudly announced to me that she just worked her way back to her normal weight range. She is still on the light side and this odd little game was by no means the only source of her success. But it had its place as a tool that measured, encouraged and rewarded progress. As such it was worth every single penny.
When I look at Wii Fit and I hear the delight in my wife's voice, it is apparent that game design is again breaking out into the broader market. Obviously it isn't happening quite in the way many have predicted. The harbinger of game's ascendancy to all aspect of the modern life is not some piece of evocative art or Citizen Kane-a-like. Instead, our future appears in the form of a glorified bathroom scale. Still, if we can improve people's lives with a bathroom scale, just imagine how games can transform the rest of our world.
Project Horseshoe 2007 slides: Smashing the game design atom
Here are my slides (with talking notes) from Project Horseshoe. I blazed through this in about 30 minutes since dinner was waiting and there is nothing more ornery than a crew of wild haired game designers in complete glucose crash. See if you can spot the source of the infamous '8mm' meme that stalked the conference.
Since it was Halloween yesterday, let's start with a tale of horror. Not so long ago there was an experienced team, working with a known platform, and a known engine. They had just scored a popular girl friendly license valued at roughly $160 million. Their game had the potential to hit as big as Pokemon or Nintendogs.
The designer ignored all this. You see, he had always wanted to make a Zelda clone...one with the critical element that has always been missing from all Zelda games: Hardcore jumping puzzles. The designer thought, "Nintendo is smart, but how could they have missed such an obvious improvement?" Sure the license was targeted at tween girls, but tweens like big swords don't they? This was the game he personally had always wanted to play.
The team were contractually obligated to go along with the design. It had been green lighted. There were milestones tied to the completion of each voluminous chapter of the tome like design script. If the team missed the milestones, the penalties were extreme. So they crunched in happy little silos of artists, level designers and programmers, all in accordance to a strict production schedule. It was the only possible way to get all the specified content done in time for the looming holiday ship date.
Finally, as the end drew near, they sent it off to testing. Early reports come back that the jumps in the first few levels were rather clumsy. The designer relied on his gut and sent forth an email containing a new set of parameters that were intended to polish the jump mechanics.
Eventually, a month later, someone got around to playing the last few levels. Uh oh. They relied heavily on laboriously constructed jumping puzzles tuned to the old jump mechanics. The last few levels of the game were massively broken.
It was too late to fix all the early levels so they entered into a death march to rework the last few levels. Lacking time or resources, they busted their budget hiring extra crew to take up the extra workload. The game was still delayed by several months.
Surprise, surprise, the end result wasn’t a very good game. It received miserable scores, but even worse, the core audience who would have bought it on the license alone was completely alienated by the design decisions. They wanted to befriend and grow cute little animals. They didn't want to die repeatedly while being attacked by spiky monsters while scrambling through military obstacle courses.
When the licensee pulled out of the sequel, the team collapsed. The human cost was immense. Home were lost, families relocated, many were so burnt out on game development they left the industry permanently, their passion crushed.
There were a lot of problems in this tale, but the primary one was a blatant failure of the game design process at almost every level. The game designer really didn’t know what he was doing. He thought he was writing a movie script. He thought he was making a game for himself. He had no idea that the game systems he was dabbling in were deeply interconnected.
Most game design that occurs isn’t much better off. It is a combination of craft (such as cloning Zelda) and intuition (such as when he hoped that tweaking the jumping mechanics would fix all his problems.) There is no science here. No predictability.
We have the ability to do so much better. We can create a science of game design.
If we want to modernize game design and move beyond the land of craft and intuition, we need to face and conquer four great challenges. These challenges will define game design for at least the next twenty years and perhaps longer.
Modeling our players: What do our player really want?
Generating new games systems: How do we create new mechanics that serve those player needs?
Metrics: How and what do we test to make sure we are doing the right thing?
Results: How do we get the results quickly and iterate on them so we can evolve the game quickly?
If we solve these issues and start spreading the resulting practices across the industry, horror stories like the one I just told will become mostly a thing of the past. The ultimate promise of a deep pragmatic science of game design is better game, happier teams and fewer human tragedies.
We are starting to see a smattering of theorists and teams with money to burn tackling these problems. They are creating systems that save their butts from expensive design mistakes. This is damned exciting.
You’ve got the Halo folks tracking heat maps of where players die. Valve has been relying on metrics for years. Nintendo builds early player tests and kleenex tester right into their dev process.
On the game systems side you’ve got Raph’s game grammar.
We are starting to rely on real data to model players moods and reactions with Chris Bateman and Nicole Lazarro’s work.
The work is still at the stage where most pragmatic folks think of these systems as the domain of eccentrics. Yet, each isolated advance reminds me of the turn of the century when physics was being cracked. Brilliant theorists. Great experiments. World changing results.
All these systems are being developed in parallel. You can measure things, but you don’t know what you are supposed to measure. You can write about game grammar, but it never is anything more than a loosely applied system of egghead analysis.
Maybe, just maybe, we can come up with a unified system that tries to answer multiple challenges simultaneously. The connections are all there. We just need to put them together.
In my Seattle laboratory, I'd been working on one attempt. It mixes game grammar, player models and measurement systems into one delightfully unified game design process. I’ve got 10 minutes left to share it with you. Think I can do it?
I started with a player model. Let's assume for a moment that players are naturally inclined to wander about, sucking up tidbits of info in the hope of learning interesting new skills.
From the player model we can construct an atomic feedback loop that describes how they learn all the new skills. This basic atomic loop includes all the fundamental pieces of a game. We are taking the deconstructed analytic elements described in so many books and tying them back together into a functional system.
You’ve got your game system, that black box in the center of the loops.
You’ve got your player input
You've got feedback to the player
You have the the players cognitive model of the game.
We’ve reduced the scope to a single atom in order to making things managable and Press button, character jumps. That’s a skill atom.
Once we have a skill atom we can say interesting things about how the player interacts with it. First, skill atoms have states.
The player can figure out how to jump. They can exercise that skill by jumping on things. That is mastery. We can record this.
The player can fail to figure out how to jump. They never touch the button again. That’s early burnout.
They can get bored with jumping and ever jump again. That is late burnout. We can measure this as well.
Skill atoms are chained together. You can visualize them as a directed graph. Later stage atoms depend heavily on early stage atoms.
Want to kill a Koopa? You need to jump on him. Better hope you mastered the jump skill. We can now represent that classic relationship created by Miyamoto ages ago in a visual model. The theory is slowly catching up with the experimentalists.
You can turn these little chains into big chains that describe the entire game. Here’s a skill chain of Tetris.
Skill chains are remarkably flexible and rather easy to apply to almost any game. You look for the actions the user is performing, the skills they are learning and the positive / negative feedback you’ve built into the game. Any game with explicit rewards can be diagrammed.
There are probably a goodly number of you rolling your eyes at this point. You can create pretty diagrams to analyze anything. Here we've got someone who has created a very lovely and describing diagram of a penguin defecating. This is not a helpful diagram.
We ultimately need pragmatic everyday tools, not egghead analytics. The primary reason we create skill chains is to help solve two of our outstanding challenges:
Get real results quickly
Choose the right metrics so we aren't wading through huge quantities of data.
Skill chains can be used to create a rapid, iterative test driven game design process.
If we really rapid feedback, let’s build the feedback system into the game from the very beginning. Skip the giant paper tome phase. Start with a playable system that gives you meaningful reports.
The nice thing about skill atoms is that they eminently testable. When you write code that is going to be put in front of player, define your skill atoms. Its the same conceptual ideas behind writing unit tests.
You have a test framework.
You write the tests when you write game logic.
You run the test suite when you run the game logic.
You get a clean simple report when someone plays the game.
When you write your game systems, you can instrument each and every atom. It is a relatively inexpensive process.
You labels the rewards
You label the actions
You know when and atom is touched. You know when it is inactive. All those, states, burnout, inactive, etc you can record.
Remember burnout? The next time someone plays the game, we can visualize burnout directly on our skill chain diagram. You see instantly what atoms folks are missing. Here is someone failing to figure out how to complete a single line in Tetris.
You can also look at the data in terms of feedback channels and activity graphs.
Either way you get quick, easy to decipher feedback.
Instead of having a team that creates customized visualizations tailored to your game, you can use a more generalized system.
Instead of sorting through dozens or hundreds of badly organized logs, you can see in a glance where problems are occurring.
This requires a change in your development methodology. You want people to play your game as early as possible and as often as possible. Luckily automated testing of skill atoms reduces the cost substantially compared to traditional manual tests.
Anytime that anyone, anywhere in the world runs you game, you get valuable play balancing information.
Build up a database of a thousand players and release your daily builds to three people a day for every single day of your dev cycle.
In this day of web 2.0 and connected consoles this is now a broadly accessible practice.
Once you have rapid, daily feedback in place, you can use the resulting reports to evolve your design iteratively. All this analytical game grammar silliness becomes a foundational feedback system.
We can regression test game designs now.
We can fix busted skill atoms and see how things improve the next day.
What happen when we refactor our designs to make them more testable? I have no idea, but it excites me.
Imagine if a system like this had been in place when the 'designer' in our horror story made his jumping tweaks. The dashboard would have gone dark almost instantly with burnout spreading across the screen.
The systems I've described today are just the beginning; rough sketch of the future, if you will.
Our player models are primitive.
Our metrics can advance dramatically in their sophistication. We are just starting to tap into biometrics
Our player testing systems are still expensive to run.
There are amazing new games waiting to be designed and evolved into stunning experiences.
The great challenges are still out there. Both the theory and practice of our science is still very being born. Sometimes I wonder, "Who is going to take game design to the next level?"
I love this picture. 1927 5th Solvay conference. Einstein, Bohr, Curie. 17 out of 29 attendees went on to win the Nobel prize.
The first conference was in 1911, almost a hundred years ago. Einstein was the youngest present. Who is the youngest person here? These quirky, brilliant people revolutionized our understanding of physics. Without their work, we wouldn’t have semi-conductors, computers or video games. They were theorists and experimenters not so different than what we have in our industry today. A small group of eggheads changed the world.
I look out at this group and I see the same potential. We’ve got the brains. We’ve got the time.
Let’s make this an amazing weekend."
take care Danc.
PS: There was one more group photo shown immediately after the Solvay photo. It however, has been redacted due to national security concerns.
My latest essay on emotion in games is up on Gamasutra. There are pretty pictures about brains. You can read it here.
It asks that simple, innocent question,"What can we do to make games evoke emotions?" The answers are more about applying the lessons of experimental psychology than the 300 hot tricks of screenwriting.
While I was looking into this topic, I read an essay in Scientific American on 'dangerous ideas' and it got me thinking about the sort of 'unthinkable' ideas in game design. This essay contains a smattering of them and I'm curious which ones you find intriguing.
"Games are great at causing emotions."
"You can replicate meaningful religious experiences with a game."
"Most media such as books, movies and poetry are far more about our past experiences than any inherent value of the work. "
"Isolating gamers from the outside world is a highly effective strategy for maintaining service contracts."
"In order to increase the impact of games, we must engage the body as well as the mind." The Wii Fit is just the start, baby. That slack faced hardcore couch potato experience is about to become an experience for dinosaurs (fat, emotionally stunted dinosaurs at that)
Does it hurt to say such things out loud? I have great faith in the ability of science and reality to weed out the ideas that contain no substance. Whether any of these concepts hold water will be directly up to the efforts of talented and innovative game designers. But what if one or two of them held a kernel of truth? My god, what a brilliant future lies ahead.
I am quite looking forward to your thoughts on the essay. Grab a mug of tea, find a comfy chair and dig in.
It has been a bit quiet in the garden this summer as I've been busy working on a set of longer essays. The first, The Chemistry of Game Design, is up on Gamasutra this morning. You can read it here.
A blurb from the article:
'“…it was clear to the alchemists that "something" was generally being conserved in chemical processes, even in the most dramatic changes of physical state and appearance; that is, that substances contained some "principles" that could be hidden under many outer forms, and revealed by proper manipulation.”
I recently happened across a description of alchemy, that delightful pseudo-science of the last millennium that evolved into modern chemistry. For a moment I thought that the authors were instead describing the current state of the art in game design.
Every time I sit down with a finely crafted title such as Tetris or Super Mario Brothers, I catch hints of a concise and clearly defined structure behind the gameplay. It is my belief that a highly mechanical and predictable heart, built on the foundation of basic human psychology, beats at the core of every single successful game.
What would happen if we codified those systems and turned them into a practical technique for designing games?'
The article describes a psychological player model and a system for visually mapping out how skills are mastered throughout a game. There is even a diagram of what Tetris might look like. :-) This essay introduces the basic concepts. In the future, I'd love to explore how these ideas might be used as part of an iterative design process.
I find systems skill atoms and skill chains incredibly exciting since they have the potential to ween us off our over reliance on reuse of existing genres. By understanding the rules behind why games work, we can synthesize new, highly effective game play from the base elements.
Feel free to post any reactions (allergic or otherwise) in the this blog post. :-)
The Nintendo Wii has an inexplicably complex help system. A cat wanders onto the screen periodically. If you move your cursor quickly towards the cat, he'll run away. However, if you are careful, you can sneak your cursor up on the cat, your cursor will turn into a hand and you can grab him. When you do, you get a tip about how to use the Wii dashboard.
From a simple efficiency driven point of view, this is a baroque UI that makes very little sense. Surely, just putting up a hint button that says "hint!" would have been more efficient and discoverable. This is what most programs do.
Yet, we know from long experience that no one ever reads the hints. Designers often resort to placing the hint dialog at the startup of the application so that the user is forced to jump through the hoop of reading one hint every time. Most people immediately turn this 'feature' off after using it once. Some users find it highly irritating and form the opinion that the developer is punishing them for using the product. They complain to their friends and write pissy rants to the help desk about why your product is horribly difficult to use. This is not the way to build a viral buzz.
The Help Cat uses traditional game mechanics to help acclimate the first time Wii user to the new controller and the dashboard. In the process, it provides an interesting test case on how game mechanics can be used help users master new functionality.
Analysis I've broken down the Help Cat user experience in several levels of mastery. At each level, you'll see the user happen upon new information and adapt their behavior accordingly. I'm using my atomic game mechanics system from a previous post as a framework for identifying the various steps in the process.
This admittedly gets a tad anal retentive, but bear with me. It is a good exercise in analyzing a user interaction and understanding what works and where it can be improved.
Level 1: Passive interaction
Action: User looks at screen for X amount of time
Blackbox: Cat simulation runs
Feedback: A cat walks onto the screen.
Mastery: The user realizes it is a cat and activates their known tools for interacting with the cat. There is a small burst of delight often in the form of "Holy duck boot! It's a cat"
Level 2: Active interaction
Action: The user moves their cursor in the direction of the cat
Blackbox: Cat simulation runs
Feedback: The cat runs away from the cursor.
Mastery: Wow! It acts a lot like a cat. The user becomes aware that the speed and location of their cursor is important to interacting with the cat and begins consciously practicing mastery of these basic tools. They form an initial mental model of how the cat behaves. This too is delightful.
Level 3: Improving skills At this point the user is engaged and will often attempt to experimentally validate their mental model.
Action: The user begins varying the speed at which they approach the cat. This quickly become a case of seeing how close they can get to the cat before it runs away.
Blackbox: Cat simulation runs
Feedback: The cat runs away from the hand. However, if the cursor touches the cat it turns into a hand.
Mastery: The user has accidentally stumbled upon a new clue. The hand again is a symbol that taps into pre-existing conceptual tools. The user understands that they can use the hand to grab objects. This also ties into their knowledge that cats are an object you can pick up. A new goal suggests itself and there is a small burst of delight.
Level 4: Completion Experimentation continues with the goal now being to catch the cat.
Action: The user exercises the tools from the previous stages of mastery. They move the cursor at the right speed towards the cat and attempt to get the hand to appear. They test out their new model of how the hand works by clicking frantically on the cat. .
Blackbox: Cat simulation runs
Feedback: When you successfully click on the cat, the help box appears
Mastery: The user realizes the purpose behind the cat. There is a large burst of joy as all the clues finally click into place and the pattern of clicking on the cat to get help is chunked in the player's mind. They read the tip and realize that there are likely more tips if they catch the cat again.
Benefits of the Help Cat We end up with a variety of benefits from this less efficient, but more enjoyable interaction design. Each of these benefits goes beyond utilitarian expectations of a traditional hint feature.
Users actively attempts to 'collect' help tips. The process of gathering them is enjoyable so it isn't really work to learn more about the product.
Users also build critical skills in using the new control mechanism. All that pointing and clicking builds up muscle memory skills that make the process of using the Wii more enjoyable overall.
Lastly, the user is left with a positive product experience. They are delighted and are much more likely to promote the product to their friends.
Future improvements As far as it goes, the help cat is pretty nifty. However, the help cat was likely added as a minor bonus feature and as such, has limited functionality. It is easy to imagine additional game mechanics that increase the usability, enjoyment and addictiveness of the help system.
Tuning difficulty levels
User achievement tracking
Virtual pet rewards
Tuning difficulty levels Not everyone likes the Help Cat, mostly they can't figure it out. Anytime you create a black box that a percentage of users cannot decipher, you'll often find frustration and irritation. Users who find a problem too difficult will assume that it is broken. Users rarely blame themselves for failure.
For some, the help cat moves too quickly at first. Or perhaps people don't make the leap that they are supposed to click on it. Or they hate cats and couldn't imagine wanting to touch one. Since the help cat leverages existing cognitive tools in order to kickstart the mastery sequence, the limitations of your users can ruin even the most 'intuitive' design.
The fix is to test user response in order to establish typical responses. Tune the difficulty so that you make most people happy and able to master the sequence. Then set up boundary conditions that trigger more explicit instructions for the slower users. For example, if the Help Cat has run away multiple times but the user has not reacted, put up text that says "Click the help cat."
You need to be careful here. If you make the feedback too obvious, users won't experience the joy of mastering the blackbox. User achievement tracking Mastery typically occurs through practice of a gesture. Far too often, users glances through the help and then never actually performs the suggested actions. By tracking new UI gestures as goals and rewarding the user when they complete those goals, you dramatically increase the likelihood that users will experience the full range of the interface's functionality.
Each hint that the Help Cat gives represents an additional skill that for the user to master. As they meander through the rest of the UI, the existences of the goals acts as a strong reminder to try out the skills. The system can detect and record this practice. Every time you visit the help cat, he can give you additional stats on your progress and may even reward you with additional functionality.
A big benefit to this system is that it is completely non-linear. Users don't feel constrained to slog through a linear tutorial. They can cherry pick the new skills that sound interesting. They are also rewarded for personal exploration. If you happen to discovery skills on your own, the help cat will notice and reward you for the completed quests.
A secondary benefit is that once you get achievement tracking in place, you can easily hook it up to a logging system to gain a better understanding of what skills are being mastered and which ones are not. This can lead to more focused usability testing that improves your overall product.
Virtual Pet rewards Catching the cat to get a clue is interesting at first, but users quickly burn out on this simplistic game mechanic. You can improve usability and increase player addiction by making the cat become the user's friend. You can tap into the user's deep set of existing social tools with some well chosen feedback. The result is a strongly positive user experience for very little effort.
With continued usage of the Help Cat, decrease the response time when the cat runs away. Eventually, make it bounce excitedly when it sees your cursor.
When the cursor is over the cat, have the cat purr and rub up against the cursor.
After more use, when the cursor is moved over the cat, trigger various petting animations.
Explicitly reward goal completion with avatar items that appear on the cat and new playful animations.
These are all straight forward mechanics that require little effort to implement. However, they create strong positive feelings in the user. They can tell a little story to their friends of how they tamed the Help Cat and it is now their beloved pet. I wouldn't be surprised if there sprung up Help Cat fan sites in response. Contrast the warm and loving Help Cat to Clippy, an intrusive alien character that forced information on users. If you want the user to master an action, dangling a carrot (or in this case, a cute fuzzy cat) works much better than a hitting the user with a stick.
From a game design point of view, what we've done is cap the user's advancement along the mastery curve with an 'unwinnable' social mechanism. Such evergreen rewards like a purring cat have a much lower chance of burnout than internal rewards based off points and goals. We can only afford to put a limited amount of content into a mastery sequence, but we don't want to leave the user feeling that they've expended all this effort only to reach a meaningless dead end.
The other benefit of this mechanic is that the Help Cat becomes easier to use. Instead of chasing it around the screen, you simply click on it.
Closing thoughts The Help Cat is a simple interaction design, but it brings out a universally applicable pattern of user behavior
The user performs an action
While performing an action, they stumble upon evidence that a modification of their behavior may have better results. At this point, they experience joy.
The cycle repeats
We can design explicitly for this learning cycle through careful placement of feedback and tracking of user progress. Users learn the product more quickly and they are rewarded with a continuous stream of positive feedback.
I've been thinking lately about how game design applies to the broader topic of software development. Game design is all about creating pleasurable learning experiences and mastery of conceptual tools. Surely more traditional software could benefit from the design wisdom and theory that we've built up over the years in the game industry.
The current state of the art technique for user experience design is the scenario-driven development. It isn't all that good at creating pleasurable software, but it provides a good foundation for the discussion. Scenario-driven design typically involves the following activities:
Create a list of common user tasks called scenarios.
The development team builds a set of features that enable the user to complete those tasks.
You can then run some representative users through the scenarios to see if they can use the features to complete the tasks. If not, you improve your UI. If the tasks are readily completed, then you have a competent product.
This is a big improvement over the older practice of feature-driven development, where developers build the features that they desire and then pray that the users will like them. Well executed scenario- driven development results in eminently functional software from which most major annoyances have been stripped away.
It is not a perfect methodology. A good example of scenario-driven development’s failings is the much maligned wizard. By laying out the tasks of a scenario in a linear order, you satisfy all the constraints of traditional user experience testing. A wizard is easily testable, has great completion rates and is highly intuitive for new users. It also happens to be dreadfully dull, painful for advanced users and quite ill suited to taking on tasks outside the defined scenario.
There are three important questions that scenario-driven design has difficulty answering
How to you build a fun experience? Scenario driven design has no concept of user pleasure. It looks for problems to be solved, not pleasure to be given. Yet users obviously react strongly to the sheen on the buttons in OS X. Emotionally evocative feedback matters.
How do you deal with the issue of mastery? In the scenario driven world, the ideal program has no learning curve. Yet expert users obviously exist and they can perform miracles with the right tool.
How do you deal with the issue of flexibility? Scenario driven design is only as good as the scenarios you consider. Especially in a product where expert use occurs, there will be new scenarios acted out by users that you could never imagine.
Borrowing some lessons from game design Mastery-driven design is a refinement of pure scenario model that borrows heavily from modern game design. It brings into play two concepts:
There is a learning curve on every piece of software. This can be a source of great user pleasure and is a critical part of bringing new users onboard.
As the user progresses along the learning curve, they master a set of conceptual tools that can be used to efficiently solve tasks.
Mastery-driven design goes something like this:
Scenario creation: You start out with a list of projected user scenarios as before.
Tool definition: The development team prototypes a set of tools that the user will need to complete the scenarios. Each tool performs a set of useful actions. A next button might take you to the next page. A pen tool might allow you to draw a complicated line on the screen.
Feedback systems: For each tool, the team creates feedback systems in the form of rewards and punishment to encourage rapid and pleasurable user progress towards tool mastery. These are essentially the atomic game mechanics that I’ve described in an earlier essay.
Task completion tracking: Testing tracks the traditional task completion.
Mastery tracking: In addition to tracking task completion, testing tracks tool mastery. In order for a product to be considered complete, users must not only complete the task, but they must demonstrate mastery of the toolset. For example, after a user has used the pen tool once, they are given a different test with the pen tool. In such a mastery test, it is expected that they should complete that task in 1/10th the time due to their expert knowledge of the tool. With such tests, you can gain information on which tools are easily mastered and which tools are not. By testing the same tools across a variety of skill levels and scenarios, you build flexibility into your toolset.
Pleasure tracking: User pleasure in the learning activities is measured as well. You can survey users after each scenario and you can watch for their pleasure and pain during the tests. You can also track dropout rates by finding out when people stop using the tool and at what levels of mastery.
Once you’ve performed these steps, you record your feedback, figure out where you can improve on the various metrics and run through the cycle again. Over several iterations, you’ll converge on a product that is easy and enjoyable to learn and that provides great efficiency and flexibility to expert users. You also generate user lock in since newly learned skills are difficult to transfer. A dash of theory It is common to hear the term 'intuitive interfaces' bandied about, unfortunately with very little understanding of what it means. Often the popular interpretation of 'intuitive' results in a reductionist approach that serves the lowest common denominator. By bringing the concept of mastery into the picture, we gain a much stronger understanding of why one person may find a design perfect, another may find it complex and a third might find it insulting.
Intuition is something you can build in your users: What we consider an intuitive design is typically a design that leverages years of learned behavior and funnels it toward a new use. Humans live to grok new conceptual tools and then use that knowledge subconsciously to solve new problems. As interaction designers, explicitly tapping into this learning process helps us make better software. No only can we tap into users existing learned behavior, we can actively train users to see our software as intuitive.
Why mastery matters to interaction design: Most of the highly effective interaction design we use today has a strong component of mastery. Typing, for example, requires months, if not years of learning before users become competent experts. Yet, it has become a foundational toolset that makes almost every software task around more efficient. If we avoid the creation of tools that require mastery, we immediately filter out some of the most potent and effective designs. To compete with powerful features that dramatically improve your users' lives, you'll need to create tools that require mastery. Least common denominator design isn't enough.
Mastery is an opportunity, not a barrier: The traditional barrier to selling tools that require mastery is that when people don’t know how to use a tool, they’ll often give up on the product completely. The solution is to build the process of mastery into our product designs. as if it were a game. By providing hints, rewards, goals and other elements taking from game design, we can rapidly build mastery in our users. There exists a rich set of game design techniques beginning with rapid prototyping and including play testing, design testing and more
There is a surprising side effect to incorporating learning into interaction design. The initial user experience actually becomes more enjoyable. Our brains are flooded with a wash of pleasure when we grok a useful conceptual tool. By building software that encourages tool mastery through risk/reward feedback mechanism, we can create a mild, but highly effective psychological addiction within new users. We build delight directly into our software. Conclusion Slowly, but surely, we are integrating more of user psychology into the development and design of software. At each stage we’ve added something new.
Stage 1 - Functional Software: How do we make something?
Stage 2 - Utilitarian Software: ‘How do we make something useful and easy to use?
Stage 3 - Pleasurable Software: ‘How do we make enjoyable to learn and powerful for experts?’
It is my deeply held belief that game design will become an important player in all future software development. The lessons it teaches us about pleasure, mastery, feedback and the application conceptual tools to problem solving are applicable across the broadest range of interaction design.
Raph gave a fun, mildly inflammatory talk called ‘Influences’ questioning if games are fundamentally limited in their capability to explore the human experience. Such angst makes my geeky heart beat faster. What follows are the random late night thoughts jotted on the airplane ride back.
My heavily editorialized version of the talk: What if games are only spreadsheets? You can reduce a game into mechanics, stimulus, inputs and lots and lots of numbers. As the game is played, the player immediately strip away the initial sensations of wonder and end up with mechanical tools, a debug console of symbols that represent the ticking, clockwork heart of the game. But, but but…how can we expand our influences beyond the math? How could you evoke the taste of a peach? You can do it easily with a poem, a novel or a movie. But no one is doing it with games.
Games are limited as a medium. So is everything else. Suggesting that each medium lends itself to certain human experiences better than others should not be shocking. For example, you can create a deep understanding of an individual relationship with a novel. A painting on the other hand may only be able to capture a single emotion associated with a particular moment in that same relationship. Both are powerful experiences, but each medium still has obvious strengths and weaknesses. There are lots of mediums that have difficulty dealing with ‘peachness’. You could certainly shave a cat to look like a peach, but it is quite the tricky exercise.
From this perspective, of course certain peachy topics stump all but the most skilled game designer. At the very least we can say that games are poor at exploring experiences that require input and output mechanisms that are undeveloped either technically on the game’s execution platform or culturally in the game’s audience. For example, games right now lack a taste output apparatus. They also lack widely accepted stimuli that the audience will recognize as a metaphor for taste. So part of it is an interface problem and part of it is a cultural problem.
Limits to the medium exist. We should recognize them. We should also attempt to be insanely clever in getting around them.
The strength of games as a medium The mildly inflammatory bit is the suggestion that games have no superpowers. What if no matter how many steps forward designers make, we will still end up with shallow clockwork toys? Perhaps, if someone wants to create a meaningful experience, they should skip games all together.
There are at least two obvious counter arguments to this fear.
The process of creation is not the player experience.
Games do in fact have super powers, particularly in the area of letting player experience a situation directly instead of through an intermediary.
The process of creation should not be confused with the player experience Raph makes the point that games are just math. Math is one of game design’s most powerful tools, but it is not the final player experience. Often when we are in the muck of creating a project, we despair that our creation is nothing but numbers and fields because we’ve lost sight of how the virgin player will experience the product. Since we spend so much time playtesting and reacting to the feel of our prototypes, there is a strong inclination to blur the line between player and creator and treat the two roles as one in the same. At this point, if creator only sees numbers then surely it is a bad game.
I think of it as the difference between chemistry and perfume. A good bit of chemistry, equations, experiments and theory go into the creation of a new perfume. But that detailed process of enumerating chemical bonds doesn’t need to show up in the end experience. When she dabs a drop on the graceful arch of her neck, Marla won’t be thinking “Mmm…ketones!”
It is the role of the designer to take the clockwork spreadsheets and construct a mix of stimulus that the player can synthesize into a coherent, evocative experience. We are a expert judge of the experience, but we always need to recall that our deep understanding of the game’s theory and mechanics also builds within us an unavoidable bias.
The trick here is to always go back to your players. If your game starts feeling like a spreadsheet to the team, start running some play tests and see how players react. Tune your game based on player feedback to turn your spreadsheet into an amazing and visceral experience.
When the mechanics connect, the impact on the player is magical. When they don’t connect, remember, it isn’t the fault of the spreadsheet.
Game do, in fact, have super powers. Perhaps it is best to start with an example. One night, a few of us stayed up past the pumpkin-hour playing a game delicately titled “Asshole”. All the fratboys and sorority sisters know it: card, alcohol, and people you thought were friends. The trivial rule set can be described easily with a spreadsheet. However, a description of the mechanical clock does not tell the full story.
When played properly with a copious supply of tequila, Asshole is a game about social hierarchy. As soon as the first President and Asshole assume their positions, the players learn about the use and abuse of power. They learn about counteracting and influencing official authority. More importantly, they learn how the other players, people who are typically friends outside of the game, react in social situations that many would never deliberately put themselves into. Trust is built, friendships formed and treachery revealed. We learned to worship El Jefe.
I challenge any medium, be it movies, books, poems, music or theater to provide the same intimate experiential insight into the workings of the audience’s immediate social group that you find in a simple game of Asshole. This is magical, life changing shit. It is unique to games (and perhaps jam sessions)
Most static media is about the author processing the world and spitting out a result for an audience to consume and savor. Games are about the author building an interactive model that actively encourages the player to uncover their own truths. Both approaches exhibit expressive super powers. Both reveal something unique about the human condition.
If you prefer to create a canned, processed insight into an imaginary character, might I recommend building a novel or perhaps a movie. If you want to help the audience gain practical insight about their immediate friends and family through a safe and pleasurable interactive experience, try making a game. What you want to say has a large impact on how you choose to say it.
Self imposed viewpoints So enough with the angst! Games are obviously more than clockwork silliness. Certainly, they have weaknesses like all existing mediums. They also have impressive strengths that we should explore and extend.
Maybe games aren’t very good about describing the sensation of eating a peach. I can live with that. Our role as designers is not to build passively consumed descriptions of the world. Our role is to build direct experiences that provide players the opportunity to form their own insights.
Does this involve math and modeling? Absolutely. Are the insights that players take away only about math and modeling? For most players, I would say no. When someone takes on the role of President in a game of Asshole, I learn about them as a leader. I find out who is the joker in the crew and who is the follower. I see who complains when their status drops and who does not. Numbers are a foundation of the game, but they do not necessarily define the complete player experience.
Game designers and some hardcore players are perhaps the major exception. They tend to see the world through clockwork tinted glasses. In their quest to reduce, codify and model the world, it is far too easy to become blind to the wonder and beauty that the simplest games promote. If you see only clocks, seek additional perspectives that help you see what your players see.
The phrase “game mechanics” sends a pleasant shiver down my spine. At the heart of every game are these mysterious whirring clicking mechanisms that deliver to the player pleasure and thrills.
We use them, we build them, but I’ve never seen a good unified definition of game mechanics that gives us a practical base upon which to build great games. Here is one. It is clobbered together from a variety of influences though many of you will recognize some central tenets from ‘A Theory of Fun’ by Raph Koster.
Game mechanics are rule based systems / simulations that facilitate and encourage a user to explore and learn the properties of their possibility space through the use of feedback mechanisms.
It is a simple definition, but it offers a good amount of insight into why games work and how we can make them better.
Feedback loops Central to the model is the concept of feedback loops that encourage learning. Here is a diagram that should explain the concept in a more visual format:
(click to expand the diagram)
Player performs an action.
The action causes an effect within the simulated game world. The simulation contains public and private tokens and the causal rules that affect the states of the tokens. The player rarely knows all the rules and is highly unlikely to be able to instantly describe the complete possibility space described by the rules. The unknown portion of the simulation is a “black box” that the player must attempt to decipher.
The player receives feedback.
With new tools and information in hand, the player performs another action. Using what we’ve learned, we pursue additional pleasure.
Linking game mechanics to create a system of systems Interconnected networks of game mechanics make up the game as a whole. You can think of the game as a set of interlinked of puzzles where solutions to one puzzle lead to clues that help on additional puzzles.
The info treats that a game provides to the user need not be used to solve the immediate black box at hand. Humans horde potentially useful information like squirrels horde nuts for the winter time. We’ll store hints in our copious long term memory in the hope that there will be another black box down the line that will yield to our improved tool chest of knowledge.
The traditional metagame that sits on top of a game’s core mechanics is a good example of how one black box feeds into another. In this situation, the game mechanics are arrange in a temporal hierarchy where rapid feedback loops (often part of the basic control scheme) provide tools that enable the mastery of longer term feedback loops. The potential patterns of linking game mechanics together are nearly endless. This is a wonderful area of future study.
Humans are infovores Humans are wired to solve black boxes. It is a fundamental aspect of our neurological learning wetware. We get real chemical rewards when we grok a problem or gain information that we suspect will help in grokking a black box. Evolution has selected for this behavior over thousands of generations since it is the biological reward system that encourages tool use and technological adoption. Without this built in addiction to problem solving, we would lack agriculture, medicine, architecture and other fundamental survival techniques that make the human species such a remarkably successful animal.
A key aspect of our model is that games actively encourage learning. I can put a black box on the table with a hidden button. Unbeknownst to a potential user, pressing the button enough times and the black box will spew out a thousand shiny silver coins. This is not a game. This is a bizarre gizmo.
To turn it into a game, a game designer would need to do several things.
Encourage Discovery: First, make it obvious that the button in meant to be pushed. Humans are naturally curious creatures, but as game designers, we need to explicitly direct them to take certain actions.
Encourage Exploration: Second, the designer would put a counter on the front of the machines that lets the user know that their actions are having some impact on the system. The counter provides delightful drips of feedback and it is up to the user to interpret that feedback
Provide Tool Mastery: Third, the designer would post a note “Payout: 1,000, coins!” Not all games need explicit winning conditions, but hinting at future utility is a highly useful technique for encourage the player to begin interacting with a particular game mechanic.
We’ve turned a gizmo into a simple game of chance. The difference between the two is that our primitive 1-armed bandit is explicitly designed to encourage player learning.
Existing games are richly laden with techniques that encourage learning. A few that come immediately to mind:
Levels take complex systems and encourage players to explore and master one aspect of the possibility space at a time
The use of scores, coin collecting and experience points are all simple feedback mechanisms that let the user know they are making progress towards some future state.
The classic “See the treasure chest you can’t reach” in Zelda acts as a promise of future utility.
A system alone is not a game. A dump of information is not a game. A system that encourages learning through strong feedback mechanisms is a game.
Secondary effects I’ve just described the foundation of a game mechanic. Now lets dig into several of the secondary effects that immediate appear when you attempt to put this system into practice:
Burnout
Milking
Red herrings
Human factors
Burnout: A definition After merrily harvesting tidbits of information by plunking coins into the virtual pachinko machine, the player will eventually grok the system. The game mechanisms may still serve up information, but the tidbits are not longer as tempting. The info we receive has no resonance with problems that we are solving or problems we have solved. It activates no curious networks in the brain. We begin subconsciously filtering out the feedback from these mechanisms. Burnout is a state of completed learning where the player finally figures out that a particular action no longer yields meaningful results.
In Monkeyball, researchers were astounded to find the the biggest jolt of pleasured occurred when you fell off a cliff and died. People loved it! If you look at falling off the cliff as a huge learning experience, this makes perfect sense. However, when they replayed the animation, people hated it. Same stimulus, radically different response. The animation of falling off cliff lost its ability to teach the second time around. Ultimately, users are subconsciously constantly asking the question “Is this activity worth my time? Does it gain me anything useful?”
Premature burnout There are multiple paths that learning can take and not all are ones that game designers desire. We would like to imagine that groking a system results in complete and utter mastery of that system. In reality, ‘grokking’ means that that the user has stabilized on a mental model of the system they no longer feel like improving further. This model can be simple or complex, depending on the inclinations of the user.
A complex model of Black Jack might take into account probabilities of cards appearing based off what has already been played.
A simple model of Black Jack might conclude that cards appear pretty much randomly. There is more depth for the user to explore, but if they are a casual player, saying it is random is ‘good enough’ to judge the game.
A big frustration to game designers is that many users settle on a very simplistic model of how a particular game mechanic works. Players will claim that a game is unfair or too difficult and immediately toss it in a rubbish bin because the designer misjudged their reaction to a game mechanic.
Some mechanisms have highly predictable burnout rates. Most players immediately figure out that watching a cutscene again isn’t going to provide much additional information. Other mechanisms demonstrate a large variation in burnout rates depending on the person who is playing the game and their personal preferences and disposition towards addiction. Some players try a slot machine once and then never again. Others will ruin their lives in pursuit of the next reward, never grokking the simple truth that such machines exist to take money, not give.
The factors that influence burnout are numerous.
Personality.
Personal history.
Practical importance of imagined future rewards that stem from mastery.
The ability for the mechanism to signal that there is additional depth of mastery possible.
The first two factors are not possible to derive by simply exercising your superior intellect. A deep understanding of your target audience’s psychology is most helpful here. The second two factors are very much under the designer’s control and can be refined through heavy prototyping and player observation.
Milking: The transition from learning to tool use The flip side of burnout is grinding. If burnout is when a player discards a game mechanism because it is no longer useful, milking is when a player continues to exercise a game mechanic long after they’ve reached the state of mastery because the game mechanics continues to provide value.
When a player has learned one system, they will often keep interacting with it. On first blush, this seems mildly demented. The activity no longer provides burst of juicy learning. It is a bit like jawing on a piece of gum that long ago lost its flavor.
However, remember that games are networks of linked game mechanics. Player will continue to interact with a mastered game system in order to create a useful game state for exploring another black box. Mastery gives the player predictable pragmatic tools that helps them advance in other aspects of the game. The learning and mastery that occurs in other portions of the game provide the necessary reward that goads the player into revisiting old game mechanics.
You can extend the time that a player spends with a set of a game mechanics by ensuring that a mastered system still provides utility to the player. Designs techniques that build tools result in more gameplay for less development work.
Red Herrings: Black boxes external the game The network of blackboxes that the player considers valid can extend far beyond the systems in the game itself. Often, the player will collect strange bits of info that have no real impact on the game mechanics that the game designer built into the game. These pieces rattle around in our heads like a collection of oddball keys for a set of locks that we may never find.
Game designers can tease the player with hints to systems that do not exist in order to suggest depth to their games. A sly arched eyebrow in a cutscene triggers as massive cascade of meaning alerts. Our brains love people and faces and relationships and the breeding opportunities and politics! Surely, that eyebrow is important? The player greedily stores the memory away.
What impact will the collected information have on their gameplay? None. What impact will it have on their lives? Very little. This virtual person in a cut scene is no one they will ever meet. But our brains were not evolved to deal with such things. As apes, the tale of an arched eyebrow by a potential mate from our little tribe always meant something very, very important. So our brain rewards us with a little jolt of pleasure for noticing such an “obviously” beneficial tidbit.
The designer managed to suggest a system and get some of the benefits of that system without actually building it. It is not going too far to suggest that paintings, sculpture, movies and television all thrive on this simple quirk of our brain’s learning systems.
The downside is that such red herrings burnout quickly. Our brains becomes quite good at recognizing false, useless information. Almost no one watches a cut scene more than once. What would be the point?
My personal bias is to use red herring game mechanics sparingly. As game designers, we have deeper skills at our disposal. We can tailor potent electronic cascades of feedback loops that spin out a complex duet between computer and the player. Such system are highly effective at causing visceral pleasure and encouraging deep long term learning. As game designers, we conduct a majestic symphony of explicit learning and entrancing interactivity, something no static media will ever manage.
Sometimes though, it is worthwhile to suggest great mysteries with broad brush strokes. Setting, character design and plot can be crucial hooks that help make a game meaningful to players before they even press a single button.
Human factors: Emphasizing the humanity of games Some folks read about models and immediately see them as reductionist mechanisms that strip the humanity out of the soul out of creating artistic games. The game mechanics I’ve described in this article attempts to avoid this trap. They explicitly include social, narrative and emotional elements in addition to purely analytical problems. All aspects of the human experience, that have an impact on our ability to process and learn from stimuli, fall within the domain of potential game play.
This definition of game design is much broader than the current range of games available on the market. Though it works quite well with hit points, button mashing and high scores, the breadth of the definition is intended to encourage exploration of a much wider range of human learning. Some open questions that I find immediately suggested by the model include:
What are the feedback mechanisms that impact learning about relationships, love, hate or spirituality?
How do we build games around such topics that leverage these feedback mechanisms?
Existing games give us the foundation of practical knowledge that lets us make the same thing in a reliable fashion. A good theoretical framework helps game designers create future titles that are inclusive of a wider range of human experience.
Conclusion The goal of any model of game design worth its salt is that it both explains existing behavior and predicts future behavior of medium. In my experience so far, this model seem rather robust at explaining almost any existing game on the market ranging from board games to slot machines to social games. There is certainly room for improvement, but it is a good enough for my main goal.
I want a practical model that lets the good folks in this grand industry describe game designs in more exacting terms. The model should give insight into why their prototypes suck. It should allow them to discuss potential issues and solutions with shorthand language that cuts to the meat of the matter. A good predictive model allows for more intelligent design decisions with less waste and unnecessary rework.
So some of aspects of the model that I find useful:
It treats game mechanics as well defined, comprehensive atomic units. These units can be discussed individually and they can also be linked together in interesting ways.
Explicit identification of user value. Fun is not a nigh spiritual activity that spontaneously bursts forth from the ether. It has a testable neurological basis.
There exist clearly inputs and outputs that easily identified. You can easily tell when a specific game mechanic has all component elements such as actions, rules, tokens and feedback systems. Through observation, you can identify the player’s reaction to each mechanism and then adjust its impact.
All and all, the hope is that this model of game mechanics is a good foundation for future discussion. It is one that I’ll be leaning on heavily as I continue to meander through this lovely little series of essays on game design.
A theory of fun for game design: Raph Koster Many of the basic concepts in this essay build upon the ideas in this book. I find it helps my thinking to rework what I’ve read in essay form. Call it a form of active listening if you must. ( http://www.amazon.com/Theory-Fun-Game-Design/dp/1932111972
Other loose ends This essay became too long and started budding little essays. Some have been planted in new documents that may one day emerge in full blossom. The rest are here for your reading pleasure.
Is a book a game? With this big emphasis on learning, there is bound to be a wiseass who asks “Is a text book a game? It too encourages learning.” The problem here is that there are few strong feedback mechanisms evident. The user reads the book and without a doubt they get a burst of pleasure from ingesting the info. However, the act of turning the pages, and interpreting language are skills mastered through other activities ages early. At best, reading the book is an example of milking, where a player uses a mastered technique to advance the grokking of some larger blackbox.
The primary role of content. In this model of game mechanics, content in the game is meaningful only through it’s association with a feedback mechanism. Plot points become reward and hints, Damage becomes a punishment that clues that player into the fact they shouldn’t be doing something. There is no such thing as an inherently pretty picture that exists ‘just because.’ The image is pretty because it activates the brain’s learning systems which in turn feed back into actions.
In order to answer the question “what content does my game need?” you need to first answer the question “What feedback should my game mechanics provide to the user based on their actions?”
I happened across this article in New Scientist discussing how the brain processes information. Research by Irving Biederman of Universtiy of Southern California in University Park and Edward Vessel of New York University provides some indirect scientific backing for many of the concepts I’ve discussed here such as:
Games as drugs
Burnout
The pleasure of groking that Raph Koster has discussed so eloquently.
They also claim to have coined the term “infovore” (which already had 86,800 hits on Google :-) I'm a big believer that there exists a strong foundation of neuroscience underlying the highly predictable behavior of people playing games. Attempting to interpret information gives us a high Scientists are beginning to understand the exact mechanisms in the brain that encourage the release of pleasure when consuming stimuli.
“They claim that the neural pathways through which we learn about the world tap into the same pleasure networks in the brain as are activated by drugs like heroin. […] These are the areas that become active when the brain is trying to interpret the information it is receiving, whether that is an image of an object, or words on a page, or the song of a bird. Biederman and Vessel suggest that when this happens, the endorphins that stimulate mu-opioid receptors are released, causing a feeling of pleasure. “
How to increase the high We can improve the impact of our gaming systems by using information-based rewards that are highly pertinent to our audience.
“What’s more, because the number of mu-opioid receptors increases the further along the neural processing pathway, information that triggers the most memories and conveys the most meaning to a person causes the greatest pleasure response. It is this bonus that compels people to browse for new information.”
Burnout Burnout is briefly discussed. I’d like to see a lot more on this particular topic.
“Does this effect ever wear thin? Yes, with repetition. Reading a book for the second time is less stimulating than reading it for the first time. “
Delaying burnout The article also describes how delayed comprehension entices people to keep coming back to the same information source.
“Beiderman and Vessel say that endorphins are released at the ‘click’ of comprehension, and that until the penny drops people are happy to return to a subject. Children take longer to “click” than adults – which explains their enthusiasm for hearing the same bedtime story night after night.”
There exists a powerful group within the gaming world that actively seeks to stamp out innovation unless it falls along the prescribed lines of their rigid and conservative doctrine. Who are these people? They are every developer, gamer and publisher who promotes the ideal that a good game must have a story.
Raised on fine stories from the golden years of novel writing and movie production, story snobs see games as just another opportunity to tell great tales. Poor David Jaffe fell victim to the bitter wrath of the snobs recently when he talked about how developing story based games isn’t all that exciting. It was an honest comment that makes a lot of sense if you’ve ever experienced the joy of tweaking a surprisingly interesting interactive system versus the slog of polishing a series of plot points.
It is really very simple. Not all games need stories. Treat story as one of many available marvelous ingredients that can improve your game, not as a necessity. The logic of the Story Snobs
I like games with stories!
There aren’t as many great games with stories as there are books and movies with great stories.
It is therefore the fault of [the developer, publisher, etc] because they are not filling my needs.
As an advocate, I must passionately protect and promote any game with a story as the ideal.
Anyone who suggests games without stories are reasonable should be crushed. After all, it is a zero sum game here. Any resources spent on promoting non-game stories are resources that could have been spent on 10 more dialog trees.
The root of this unfortunate attitude is a classic tale of old media infiltrating and co-opting a new media. There are three players:
The fanboys
The movie and book industry wannabes
The publishers
The Fanboys There exist millions of fan boys who had great experiences with old adventure titles and Japanese-style RPGs such as Final Fantasy. These story rich titles were some of the first cross over genres that encouraged people not typically interested in games to pick them up and try them out. If you are a conservative media consumer used to movies, Final Fantasy is an easy dish to consume. You have to watch a few cut scenes, play a little bit of game and watch a few more cut scenes.
However, many of these new game players never moved onto new genres. Just like a good number of Brain Training new customers never try racing games, there are millions who started playing games with the adventure game genre and stopped when that market faltered. There are millions that to this day still play mostly Japanese-style RPGs.
For this demographic, the artificially sweetened formula of “Lots of plot with a dash of interactive bits” defines their total vision of gaming. As conservative media consumers, when game falls outside their nearly religious preferences they don’t merely accept and forgive. Instead, they are inclined to drag it behind their truck through the proverbial forums of Texas. “A game without a story? Impossible.”
Despite the copious evidence to the contrary.
The movie and book industry wannabes I had a great conversation with an animator at GDC. He’s an industry veteran and works primarily on cut scenes. He confided to me that his true dream was to work on CG for movies. He read all the movie trade magazines and avidly sucked up their tips and techniques. He was in the game business because it was kind
Techniques for designing consumer scales
