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 of similar and he could get a job there.
I’ve had roughly this same conversation with a remarkable number of developers. The game industry is filled with writers who want to author the next great novel, designers who want to direct the next great movie and artists who would be perfectly happy doing character design for a Saturday morning cartoon. Even if they aren’t actively trying to use the game industry as a stepping stone, many of their core values are informed by older, existing media such as movies or novels.
These cultural transfers from big established media industries have a huge impact on the type of games that are made. First, their general grasp of how interactive systems are built is quite weak. They couldn’t design a set of valid game mechanics if they tried. More importantly the passion for interactivity amongst many of the developers in the game industry is unexpectedly low. When you talk about making a sexy Blizzard-style rendered intro, eyes light up with respect and admiration. This is their dream. When you talk about emergent gameplay in a title like GTA, you’ll get blank stares. It just isn’t their passion.
If you have the skills to make movies, everything looks like a movie. There are a thousand decisions made during game development that are the creative choices of the developers involved. If your labor force is trained to build and steeped in the culture, and aesthetic of linear media, guess what most games will end up looking like? That’s right. Linear media with chunk of half assed or cloned interactivity thrown in for good measure.
I got a chance to read a game design document for a now published title. It read like a movie script. Except they had little production notes like “And now the character fights a red monster”. Interactivity in games should be more than just a production note.
But it never will be when large portions of our industry’s workforce worships the values of linear media over the unique charms of interactive gaming.
Publishers I can’t blame the business folks too much. They have their creative people telling them that stories are critical. They got violently passionate customers telling them that stories are the most important thing ever. So they do what sheeple do and green light mostly story-based projects.
Consequences The vast majority of the budgets in modern games goes towards art, video, dialog and other plot related expenses. The development teams are further stocked with Hollywood refuse, which only increases their story-centric biases. Game mechanics work is generally given less development time, resources or room for experimentation.
Since the production risk of story-based games is lower, publisher tend to green light them more often. The developers don’t know how to replicate the complex playground games that do become hits. The market ends up being flooded with dozens of story-based games and only a few games that focus on interactivity as the primary driver of value. So we train more players to expect story-based games and we train or import more developers that know how to only make story-based games.
The industry becomes more and more weighted towards producing games with stories. You end up with a feedback cycle that reinforces the required presence of story elements in most games. If everyone wants story, how can it be wrong?
As various folks have commented, Tetris would never be published today. The current requirement that most games must have stories is a filter that prevents the creation and publishing of what are potentially the crown jewels of the gaming industry.
There are lots of great games that don’t require a story. Focusing our effort on only creating games with story substantially limits our creative exploration of the media and limits the types of games that we, as game developers, are encouraged to create.
Stories are not required to make great games. Before you think I’m a story hater, let me disabuse you of the notion. I like stories. I’m playing a darling little RPG right now called Aveyond that is quite plot heavy. Delightful stuff that simply would not work without the inclusion of a story.
Even as a story lover, however, the existence of the story fiends infiltrating every level of gaming irks me. They assume that stories are always a good thing. People are not thinking critically about whether or not their game needs story elements.
It is perfectly possible to have a great game whose plot elements fit on a postcard. Populous, Mario 64, Quake, Lumines, Bomberman, Guitar Hero, Counterstrike and hundreds of other titles succeed wildly as great gaming titles and yet all of them lack story beyond a rough setting. They don’t feed the player periodic plot points that extend a narrative. They don’t have characters with extensive histories that evolve and grow emotionally through a series of descriptive cut scenes. They don’t have fixed events that are described by a godly author as a way of informing the player about actions beyond the capabilities of the gaming system to simulate. And they rock none the less.
In fact, the one thing that prevents the game industry from turning into Hollywood with occasional button pushing to advance the plot is the fact that a lot of people purchase certain hits that shockingly have little evidence of tradition plot. Sports game and racing games consistently make a profit. Nintendogs and Brain Training came out of the blue and rocked Japan. Tetris made the Gameboy a success. All these smash hits have no plot and lots of interactivity.
So there is obviously a more complex tale to be told here. There exists a wide swath of games that can be successful without having a story. Just as there also exists a wide number of games that can benefit from having a story.
When players and developers simply assume that their games need stories because they have been blinded by their subconscious cultural biases, they fail to dig into the guts of why stories matter to games. When you say “Wouldn’t it be nice to have another cut scene because I like cut scenes,” you typically aren’t asking the hard question “What does this cut scene actually bring to the gaming experience as a whole?”
Story is a game design ingredient, not an end in and of itself. Story has a purpose in game development. It is a ingredient. It has little inherent value by itself. Its primary value is how it contributes to the entire player experience. You are selling a game, not a movie or a novel. You need to design the whole game as a complete experience.
To use a bizarre analogy, making games is a lot like cooking. You may really like bleu cheese. I do. I once found a fabulous recipe for bleu cheese lasagna. The recipe called for a few crumbles of bleu cheese, but the store only sold large hunks. I thought to myself “I like bleu cheese a lot. Why waste all this cheese…I’ll just throw it all in!”
Woops.
All the bleu cheese went in along with some expensive spices and other goodies. The result was a giant slab of goo that tasted intensely of bleu cheese. You couldn’t taste the spices, the sauce or the noodle. I ate it for two weeks straight and never ate bleu cheese again for months. I would have been better off just nibbling on the chunk of bleu cheese.
I added something in that I liked by itself, but I didn’t have a clue about how it would interact with or benefit the other elements in my dish. The same goes for gaming elements like story. What do they add to the game? If you end up with a game that is barely different from a movie, why not just make the movie in the first place?
What is a story to a game? Let’s take a look at the role story plays in game development.
First off, it is worth defining story. Story is a series of linear narrative elements in the fashion of novels and movies from ages past. This is a very traditional definition that I’m confident does a disservice to many of the wacky interactive fiction attempts being concocted by mad geniuses around the world. It also happens to be the one that is most descriptive of the use of story in modern video games.
In most games story elements are used as rewards for player actions. The player does something and they get a little dose of plot. Typically plot points fall into one of three categories.
Enabling reward: These rewards help the player advance through the game further. Examples include the conversations in Half Life 4 that let you know that the main generator is down and needs a fadangle to fix it.
Red herring reward: These are rewards that the player instinctually pays attention to as potentially important, but in reality they are just tossed in there to help build a fantasy world. The player, not being able to distinguish between what clues are pertinent to the game world, laps the red herrings up and experiences the same sort of pleasure they would gain from an Enabling reward. Examples include descriptions of a Dark Past Foozle that once caused a huge cataclysm. It never affects the actual game, but players latch onto it and try to make sense of it none the less.
Visceral reward: These rewards trick our sensory system into thinking something interesting is happening. Example include big bloody fight scenes, spooky scenes that cause us to think we are in immediate danger even though we are actually sitting in a comfy chair in a posh apartment on the west side.
The model we are using here assumes that gamers are constantly trying to grok the gaming world in order to interact with it in a more meaningful manner. The primary bursts of pleasure come from activation of learning systems in the brain. There are secondary burst of sensation that come from false sensory input that activates various fight or flight mechanisms. It is a simple model, but it generally works and is a far better starting place than designing by feel alone.
When should story be used in a game? So a story element is just a reward. It isn’t the only type of reward. It is one of many types of rewards. You could put in a cut scene when a big boss creature is destroyed, or you could let the player discover a new sword token that enables them to chop down the vines that have been blocking progress through the earlier jungle levels. Both might cost the same amount of development time and both are valid rewards that make the player feel great.
Instead of asking “how should I implement story in this game?” instead ask the question “What type of rewards best fit the game experience?”
Story-based rewards have several very distinctive characteristics that can influence your decision.
Triggers for specific types of emotions: The biggest benefit of story-based rewards is that you can use them to trigger social emotions such as sadness, humor or sympathy. These are typically difficult to trigger using algorithmic rewards, but are relatively easy to create using common narrative techniques and patterns.
Low initial production cost: With a line of text, you can hint at complex system that you never need to build. For example: “The tattered scroll describes the ancient history of Yendor where giant lavender airwhales ruled the skies” hints at a tantalizing other world that the game developer will never need to build. The cost? A few minutes of writing in a commonly available word processor. In general, a simple plot point can be created and polished at a much lower cost than what it takes to create an interactive reward.
Rapidly escalating costs as realism increases: As you attempt to increase visceral aspect of your story, production costs increase dramatically. Realism costs money in the form of expensive tools, talent and time.
Low execution risk: The risk of a story-based reward failing to be completed is very low. The production techniques for text, images, sounds and video are well understood and highly reproducible. If new technology is kept to a minimum, the use of story-based rewards is highly unlikely to delay the shipment of your game.
High burn out: Most story rewards have very low variability. When you see them once, you’ve sucked out 99% of their value. When you see them again, players get much less buzz. Repeated often enough and they become downright irritating. Imagine if you were forced to watch the main intro animation when you start up a game. It rapidly loses its appeal.
Limited economies of scale: With high burn out come very limited economies of scale. Every time you want a new reward, you need to custom craft a new one. The cost of generating new reward increases linearly with the number of rewards. More algorithmic systems, on the other hand, tend to have a higher initial cost but can be reused over and over again. Imagine having to come up with a unique and enticing story element every time the player killed a monster. It is much cheaper in the long run to simply give the player a few points or a health pack. Also note that the cost of a small increase in realism is multiplied across all the story rewards in your game. This gets expensive quicly.
Changes are expensive: Exploring variations on story elements is expensive. Often the plot points need to be rebuilt from scratch. If you are dealing with text, this isn’t so bad. If you are dealing with $50,000 cutscenes, it can be quite painful. Contrast this to more algorithmic system were changing drop percentages on rare items may be as simple as tweaking a single number and seeing what happens.
There are some folks out there who claim that stories work poorly with games. This has some root of truth. If you focus only on the quality of the story, you’ll find that your gameplay elements will appear to constantly interrupt and slow down the flow of the story compared to say your favorite movie. It can be difficult to built dramatic tension in a typical manner when the player is constantly jumping about, pressing buttons and performing other mechanical actions.
However, story can still be used as a vital element to the game. It can add an emotional richness to the reward system that is difficult and expensive to achieve using algorithmic techniques. Story must always serve the greater good of the game.
Conclusion To return to our cooking metaphor, I find story to be much like a fine wine. When you pour a glass of gloriously rich merlot, you’ll discover all sorts of delicate nuances that are simply impossible to find anywhere else. Yet, that same glass of wine can also be used to cook some wonderful dishes. A nice lobster bisque wouldn’t be complete without a dash of wine to accent the flavor. Stories in games are really the equivalent of cooking wine, an essential and useful ingredient for many popular genres.
On the other hand, there are lots great dishes that you can cook without using any wine at all, just like there are some great games you can build that don’t use story. If game design is anything like cooking, there is an entire universe of game designs that work perfectly well without any story elements.
If you are yourself a story snob (I was for many years), you need to ask yourself “Am I in this business primarily to build a great game or am I in it to craft a great story?”
Pick your passion. If you really want to make movies, go for it. Move to LA, buy a video camera and get started! For those who choose to remain in the game industry, we’ve got a unique and wonderful medium that deserves to be explored and expanded as a powerful expressive force in its own right. Learn from old school linear media, but never be bound by its constraints. Use it as one ingredient in your dish only if you want a dash of story flavor.
Don’t be a story snob and assume blindly that your game needs a story. Players buy games for the total experience and you should choose the appropriate reward system that best fits the experience that you are attempting to craft.
Take care Danc.
References
How the story fiends filter great games “I believe if Tetris were presented today, here is what the producer would be told: Go back give me more levels give me better graphics give me cinematics and you re probably going to need a movie license to sell that idea to the public. The producer would go away dejected. Today, Tetris might never be made.” Satoru Iwata, GDC 2006 Keynote http://www.thegamechair.com/2006/03/24/gdc-2006-nintendo-president-satoru-iwatas-keynote/
Burn out: When you create story elements as rewards, you experience the same reward over and over again as you play test the title. This leads to burn out on those rewards.
“And the thing is, once you have the IDEA, your fun- as a designer- is really over. If you are working in the single player action-adventure genre, and are fortunate enough to be working with a team that can execute the crap out of what you think is an amazing idea, you don’t get much out of actually seeing your idea executed. You get a little, sure. You get the little tinglies and such. It’s a neat moment to see your idea brought to life. But you already saw the idea, already experienced the amazing moment...but it was in your head months ago. Now it’s just a slog to execute the damn thing so OTHERS- the PLAYERS- can enjoy what you’ve already finished enjoying.” http://davidjaffe.typepad.com/jaffes_game_design/2006/07/changes.html
I was recently sent a gallery of erotic mathematical renderings by a friend with a remarkable nose for the obscure. They are certainly evocative. It goes to show how a little art training goes a long way in the pursuit of the harder sciences.
Naturally this got me thinking of on one of my favorite topics. How do we create high impact experiences without spending lots of money? Realism: The obvious solution? Suppose for a moment that I wanted to create a highly sensual environment in a game. The obvious solution is to drench the scenery in photorealistic voluptuous figures complete with taut pink nipples and pleasantly rippling pectorals (for the ladies in the house). By getting hundreds of thousands of little details 100% correct, by replicating reality in our game, we can evoke the same emotions as if the customer had experienced the situation for real.
Does the brain need all this stimuli in order to reach the equivalent level of arousal? Human perception is distinctly not photographic in nature. We see blurs where camera capture crisp detail. Our brains filter out extraneous shapes and details in the presence of faces or sudden distractions. Much of the history of the visual arts and almost all of the history of stage magic has been spent cataloguing and hacking into our brains imperfect, quirky and highly biased shortcuts for sensing of the physical world.
Gorillas in our Midst There is a famous study about a group of research participants that were asked to watch a tape of people passing a ball back and forth. The participants were asked to count the number of passes and if they got the right number they would get a prize. In the middle of the video, a person in an ape costume walks out into the middle of the room, pauses and then walks out of the room. Later when the participants were asked if they had seen anything unusual, a large fraction claimed to have not seen a thing. They were so focused on the task of watching the ball being passed back and forth that their brains had simply erased the ape from their senses.
If this had been a virtual room with virtual people passing virtual balls, would it have been cost effective for the developer to render the virtual ape?
Photorealism is a naïve strategy for rendering evocative experiences. We throw up our hands and say “I don’t know what causes people to tick, so I’m going to throw it all in and hope something sticks.” This is sometimes effective, but oh so expensive. Throw in a few untested skin shaders and a cutting edge facial animation system and you’ve created a classic high volatility risk cocktail. Even worse, sometimes by focusing on everything, you miss the few details that the human brain cues into strongly. The result is the uncanny valley where we create zombie-like monstrosities that do more harm to the experience than good.
Show only those elements that trigger responses The smart way to create a highly sensual environment is to create only the subtle triggers that trick our primitive brain into reacting viscerally. What if instead of rendering those lovely photorealistic nipples, we instead took the path of the mathematician artist above. With a few soft curves and the appropriate color palette, a skilled developer could generate a virtual pornacopia of erotic mathematical landscapes. Mathematica fetishists aside, I suspect the results would be surprisingly successful and far less expensive than motion capturing hundreds of professional actors. After all, what is more erotic? The half glimpsed form in the flickering firelight or the full on frontal nudity of a Playboy / Playgirl photo shoot? Certainly, the viewer’s mileage will vary depending on their end goals, but for most casual situations, the former is quite effective.
Visual stimuli are a highly effective, but also admittedly expensive tool for rewarding players of your game. Always remember that your beautiful creations are passed through that quirky biological sensor known as the human brain that carefully filters out a larger percentage of what it receives. Pick visuals that matter and are pertinent to the task at hand, not merely ones that are ‘realistic.’
Jesse Schell, over at Carnegie Mellon, dropped me a note on a fun project documenting game design innovations. I normally do not post the editorialized links that you find on many sites. For this, I’ll make an exception. Here’s the blurb:
"The Game Innovation team is launching The Game Innovation Database (GIDb) today. The goal of the GIDb is to:
Document every innovation in the entire history of computer and videogames.
Provide a comprehensive taxonomy for classifying videogame innovations.
Make its data available through an online wiki.
Serve as a forum to discuss the importance, influence, and possible future applications of various innovations.
Anyone can edit and contribute entries. The GIDb is designed for a variety of users. Instructors can use it for teaching videogame history and design classes. Game developers can use it as a tool for research and brainstorming. Game players, enthusiasts, and researchers can find information about specific games and can easily share their own knowledge. Those with a strong interest in videogame innovation may apply to join the GIDb Editorial Board.
Please feel free to make contributions and pass this along to friends and colleagues. We need your contributions and input!
So what? Here’s why I think this is important. Language is one of the biggest barriers to discussing game designs in an intelligent fashion amongst educated game designers. Currently, each designer is an island, isolated by and limited to their own design experiences. When they attempt to discuss even basic concepts with other designers, the terminology just doesn’t exist. Conversations devolve into exercises in semantic nitpicking as both parties desperately attempt to invent a common terminology on the spot. I overheard a conversation at GDC where two developers were talking about how games must be challenging in order to be fun. I butted in and said, “What about Animal Crossing? Surely, this is a game that is not about challenge?” It turns out they were discussing Animal Crossing as a prime example, and they looked at me like I was an idiot. Quite understandable. After a few more fumbling attempt, it turned out they were using the word “challenge” were I was using the word “inconvenience” I happened to have a very particular definition of the term “challenge” and the misunderstanding sunk the entire conversation before it even started.
Multiply this one situation by the thousands that have occurred throughout the history of modern game development and it is no wonder that game design is considered to be mostly black magic practiced by a few mysterious talents.
Academic language definition is not the answer Language is rarely defined through academic rambling. It instead tends to evolve and standardize through everyday usage. I would love to sit down and write a game design dictionary filled with exacting academically defined definitions. However, that would be next to useless. Many have tried and almost universally their work is ignored, except perhaps by a few brilliant eggheads. Academic definitions of game design contain too many words and not enough obvious practical applications where people can actually use the proposed terminology.
I like the approach taken over at gameinnovation.org because it consists primarily of practical examples. The site consists of dozens of types of game mechanics listed in a format that tells you why they are different, why they matter, and how they relate to others game mechanics. I can easily imagine a game developer browsing through the topics in search of inspiration on their next game.
Game design documents are rhetoric, and the same goes for text-based descriptions of game mechanics found in most writing on game design. In this wiki, however, most of the items listed are real games, many of which are available through emulators or in someone’s video game collection. You can play them and grok the described mechanics on an instinctual level. This is useful data that can be absorbed experientially.
The terminology listed in the taxonomy may seem secondary, but it always exists, lurking in the background. It helps guide your understanding of the information you are consuming and helps integrate your mental models of how games work. When you talk about the concepts that mechanics that you’ve learned with others, how do you communicate them? I am a lazy fellow, so I tend to forward the link from an existing web page onto my friends. I’ll reuse the same terminology so that I don’t confuse folks. The result is a common reference point, anchored in shared experiences.
In the end you have a pragmatic set of useful examples that drive language unification, not some academic dissertation on the definition of the word ‘fun’. It is a classic example where ‘show me’ may well work better than ‘tell me.’
Take care Danc.
PS: Blogger has informed that this is officially my 100th post on Lostgarden.com. That is a lot of pseudo-academic blathering, if you ask me. :-) Hope folks are enjoying it.
I was flipping through my copy of EGM with my fiancé just the other day. It was a rather embarrassing tour through the current gaming culture. In the first few pages, we perused the standard mixture of guns and ultra violence. “Look,” I pointed, “there’s Lara’s bum festooned with some charming grenade accessories. And check out those flying WW2 chaps on page 10. They certainly do bounce about when consumed in a massive fireball.”
Finally, we happened about a vivid image of a violated female corpse with a bloody bullet hole gaping in her forehead. Ah, the delightfully rank odor of publicly condoned misogyny. Apparently this is a great way to sell games. It is rare that you see such crude advertising images in movie, books or even comics, a market that supports far more extreme depictions of ultra violence. Yet they are commonplace in game advertising. It has always perplexed me.
The immediate response is to blame the marketing departments. Obviously, they are bastards. Yet, in the broader scheme of business, marketing is mostly a mercenary that attempts to convey a product’s value proposition to a potential customer. At its core, game advertising merely reflects and promotes the value that is exchanged between product developers and their customers.
So let’s turn this question of shock advertising around. What value proposition are mainstream games promising to customers that inspire our advertising to look like this drek?
Visceral Feedback To find the answer we need to go back to the basics. Games at their heart are about feedback cycles in which the player performs an action and the game provides either a reward or a punishment. The potency of your feedback system has a major impact on the addictiveness of your game play. Thus feedback systems are one of the most heavily developed areas in the majority of game titles. Early in the history of games, developers realized that the emotional impact of the game’s feedback can be easily magnified by using visually rich and shocking imagery. The introduction of faked ‘dangerous’ stimuli makes your reptile brain react in a physical manner is not so different than the thrills of a rollercoaster ride. You are never in any danger, but critical portions of your brain react as if you are. The brain evolved to deal with real threats, not 3D video cards pumping out super realistic explosions complete with force feedback. The flow of blood in your brain changes, your heartbeat increases and the excitement builds. The game play goes from interesting to thrilling. I call this ‘visceral feedback.’
Visceral stimulus enhances existing reward systems in games. For example, it is easily arguable that the fatalities of Mortal Combat improved the actual game experience. The thrill of finally ripping out your opponent’s spine kick starts your adrenaline and wakes up your brain. For another example of visceral feedback, check out this simple yet effective Flash game at http://www.winterrowd.com/maze.swf. The use of sound is particularly nicely done.
The core value proposition of games? Visceral feedback is a very popular technique with both customers and game developers.
With customers, several very public blockbuster success stories such as GTA, Doom and Quake suggest that “Visceral feedback means better games”. The link is questionable, but still the theory has become accepted as The Way of Things. Experienced gamers, indoctrinated into the gaming culture accept and promote the benefit of visceral rewards. They historically have put their money into better graphics and more extreme settings whenever the opportunity arises. Better visceral feedback has become a key indication of game quality, despite the general lack of real world correlation.
The business side of game development also appears to support the use of visceral feedback. This makes the most sense in light of modern game design’s attempt to constantly reduce and mitigate short term risk.
Generally visceral feedback relies on the production of new assets, not the creation of new game play systems. Asset production is a well studied and highly reliable activity that is unlikely to introduce schedule slippage.
The advances in hardware mean that taking advantage of new hardware allows designers to easily pump out a new title with the same mechanics and updated graphics. They merely increase the impact of the risk / reward systems and hope that this will give them a competitive advantage in the market place. By targeting R&D only at technology and not in the areas of game mechanics or business models, companies also reduce short term risk. Why bother creating a unique competitive advantage when you can recycle one?
Naturally, these two sides of the coin feed upon one another. Over many years, these patterns have led many in the industry to make the implicit assumption that the ultimate value proposition of games is to “provide players with visceral experiences.”
Marketing’s response If you boil a game’s core value proposition down to “providing visceral experiences” then the job of marketing is to promise increasingly powerful visceral experiences. Marketing people aren’t being obnoxious. They are simply doing their job based off the assumed benefits of gaming and assumed desires of the gaming population.
Unfortunately, game marketers are also encouraged to over promise a game’s visceral rewards due to the bizarre structure of our retail channel. We live in a “Buy and then Try” environment. The promise of an intense experience is often more cost effective at creating sales than actually developing a real experience. A photorealistic box illustration costs much less than a photorealistic game environment. Yet arguably the box and perhaps a few screenshots are more effective at driving sales. This is not a recent trend. The advertising of 2600 titles such as Combat are direct forefathers of the visuals used to promote modern games.
Shock advertising comes into play when someone always increases the viciousness of their ads in an attempt to compete in a market where the emotional rawness of your product is a major selling factor. Customers have two reactions. They can either leave gaming behind in disgust or they can learn to ignore the shock ads. Over time, the shock ads have increased in potency in order to reach an increasingly jaded, distrustful and hardcore audience.
Of course, non-gamers see gaming ads as well. They assume that the highly prevalent shock ads display the true nature of gaming. There are massive generation issues at work here, but gaming ads are structured in a way that deliberately and intentionally provokes an intense negative response from outsiders. A gamer would retort, “They are meant to be shocking, duh.”
The problems with visceral feedback The response of marketing reveals a deeper issue. Basing a game on visceral feedback is a remarkably shallow value proposition for your customers. Visceral rewards might seem exciting for the customer and easy to create for the developer, but they have some longer term issues.
The burn out rate on visceral rewards is very high. Sure, each fatality in Mortal Combat was rather cool the first few times you saw it, but after a while you begin thinking of them more strategically. A fatality rapidly turns into an abstract demonstration of skill and finesse. This deeper appreciation of the game mechanics can often be serviced using reward mechanisms that are much less expensive to produce. Players quickly stop experiencing the visceral nature of the reward.
Since value diminishes quickly, customers get little value for their money. Where a game like chess might last a lifetime, most games that rely on visceral rewards last mere hours. The gamer value per dollar is perceived as quite low. The more desperate gamers with money to spare burn through multiple games. This artificially buoys the industry. The less desperate (or less well heeled) will often give up on gaming completely due to the lack of value that it provides.
From a business perspective, visceral rewards are also one of the least effective.
Rapidly diminishing return on investment: Past a certain level of quality, customers have difficulty telling the difference between ‘good visuals’ and ‘great visuals’. Developers can quickly find themselves spending substantial amounts of money with no obvious return on their investment.
Poor competitive insulation: Great graphics and other visceral rewards are one of the easiest elements to add to a title and the most difficult to maintain leadership in over time. Any publisher can hire a bevy of talented artists and pump out gloriously sexy movies. Because the cost of entry is so low, it is easy for others to do the same. Competition drives down profit. Ironically, short term risk mitigation development strategies result in long term market instability.
To summarize, games that rely primarily on visceral rewards end up causing several issues:
They provide poor value to customers. Long term this lack of value often alienates customers.
They are a poor business practice that seriously increases the competitive risks for your company and the industry.
As a side effect, they encourage increasingly demented ads that strive to promote a shallow value proposition. This helps alienate both marginal customers and the world at large.
You are responsible for shock advertising If you develop a game that is ‘the same, but more intense’, you are directly responsible for the miserable and degrading ads that it spawns. You set forth a shallow value proposition in your product that the marketoids promote to the best of their ability.
You are also responsible in part for the vitriol flung at the game industry by an offended moral majority. I’m all for freedom of speech, but when the vast majority of content in a medium is radically out of step with other popular forms of media, there is something questionable going on. It would be the rough equivalent of the entire movie industry only producing porn. When you produce a shallow product that feeds on the subconscious base instincts of your customers, you should expect to get a bit of well deserved flak tossed your way.
Alternative approaches There are alternatives and they start with adjusting the core value proposition of your game. It turns out that visceral rewards are only one technique for increasing the emotional impact of feedback systems in games. Here are several alternative feedback techniques which are highly effective, lower cost and have much lower burnout rates. For example:
Real world rewards: Rewards that tie into real world goals of the customer. Examples include money in gambling games or the promise of better mental capabilities in the DS Brain Training titles.
Social rewards: Reward that leverage or help build social networks. Examples include prestige-based feedback in a title like Counterstrike’s leader board or Guild housing in an MMO.
Nested rewards: The nesting of carefully balanced feedback systems that augment and encourage the continual learning of new strategies. An example includes the turn structure in Civilization in which various building schedules encourage the player to continue for ‘one more turn.”
Possible paths towards better advertising In order to have more positive advertising messages, you need to create games that have a positive benefit for your customers.
Stop relying on visceral rewards as your game’s primary selling point. Use visceral rewards sparingly in your designs. You may lose a few hormonal teenage ‘hard core’ gamers who have bought into an empty gaming culture, but that is okay. There are better things you can do with your mad skillz than virtually stimulating their tender amygdala with sensory overload.
Focus on alternative feedback systems such as real world rewards or social rewards. You’ll actually be providing substantial, positive benefits to your customers and the smart marketing people will build their campaigns around this concept.
Encourage ‘Try before you buy’ distribution methods. The current retail channel encourages and promotes the status quo of both game design and advertising. The best marketing is to provide authentic, high value experiences to your customer and then leverage of word of mouth and other viral or grassroots techniques. When you encourage user trial of your product, you are no longer hiding behind the veil of questionable box shots, previews and magazine ads. Instead, you are establishing an honest, experience-based connection with your customer. The rapidly growing markets of casual gaming and MMO games follow this sales model very successfully.
Conclusion Many in our close knit industry are always willing to defend the excesses of visceral feedback as art. But I wonder if the situation isn’t the exact opposite. Art to me is the act of creating great and wondrous things that communicate the breadth of the human condition.
When I look at many games and the sorry advertisements that reflect back their pitiful value, I see people mechanically spewing out “more for the sake of more.” A game that only offers perfectly modeled bullet paths or the ability to murder beautiful women is a waste of talent and a blight upon our industry. I say this not because I’m morally opposed to such content, but because it doesn’t accomplish anything worthy for the customer, the industry or our industry’s wonderful developers.
Make something worthwhile. The game ads, though never perfect, will improve in direct response to the value of what you create. Perhaps, many years from now, I’ll be able to flip through EGM with my fiancé and not feel like such a dolt. :-)
The Blind Men and the Elephant: Thoughts on an integrative framework for understanding games
It was six men of Indostan To learning much inclined, Who went to see the Elephant (Though all of them were blind), That each by observation Might satisfy his mind.
John Godfrey Saxe, “The Blind Men and the Elephant”
To understand game design, it is common to look at games from a wide variety of perspectives. Much like the blind men describing the elephant in the old Indian tale, each perspective brings something new to the picture. However, if we restrict ourselves to studying only one perspective, we end up making ludicrous decisions. “What is this thing we call a game?” someone inevitably asks. The peanut gallery cries “It’s a movie! A set of rules! A very small pebble! No, it’s a duck!”
The result? Weak games, disappointed players and poor team dynamics. There is a better way.
Existing perspectives There are several predominant perspectives out there. A short list might include:
Games as entertainment: Games exist as a method of having fun. Is there anything else? (The answer is ‘yes.’ :-)
Games as craft: Development sees games as a production puzzle full of risks, costs, resources and schedules. Games are a craft with techniques and skills that property applied result in success.
Games as art: Games are a burgeoning new form of creative expression that will change the world by changing how people think about critical human issues.
Games as business: Games are a business complete with profit, loss and opportunities for squeezing out more cash with few resources.
Games as theory: Games are an activity based on well defined (if not yet completely discovered) theoretical foundations.
We could no doubt add games as a community, games as status symbols, games as instruments of Satan and innumerable other perspectives of varying degrees of importance.
It is likely that when you started looking into game design you fell into one of these major categories. At first, I saw games as simple entertainment. Then for a while, I passionately believed in games as art. I’ve dabbled in the other perspectives and always enjoy asking which bucket folks call their own.
There is one right perspective, right?
And so these men of Indostan Disputed loud and long, Each in his own opinion Exceeding stiff and strong, Though each was partly in the right, And all were in the wrong!
In general, someone who lives by a dominant worldview either A) rails against those who do not share his opinion or B) ignores them if he holds enough power. This is really quite understandable. Each perspective is attempting to reach a very different goal. Anything that doesn’t help reach the goal is either an obstacle or noise.
For example:
From an entertainment perspective, a game is a success if it helps person relax after a hard day.
From a craft perspective, a game is a success if it ships on time with a well-executed set of features. More is always more impressive.
From a business perspective, a game is a success if it makes money.
From an artistic perspective, a game is a success if it evokes emotions and makes the auteur a name. Ideally, it will get young vibrant artists laid. (Let us be honest. :-)
From a theorist’s perspective, a game is a success if it introduces or clarifies new theoretical constructs that spur a deeper understand of the medium.
We can all think of examples where these goals conflict. Ask two people about the same game and you will get very different opinion about its inherent value.
To a theorist, Façade is a great game. To a pure business man, it is barely worth the bits on the disk.
To a business man, Deer Hunter was an amazing success story. To the artist, Deer Hunter evokes all that is wrong with the world.
To a craftsman, Doom 4 is the peak of excellence. To the player, it doesn’t quite create the same sense of joy as it once did.
On the surface, we would appear to be stuck in the same eternal battle of opinion illustrated in the blind men and the elephant. For folks striving to reach a differing objectives, even mere discussion of other concerns is a simple waste of time and resources.
There is an elephant! It is easy to lose track of the fact that we are all feeling up the same beast. We are all talking about games.
What we need is an integrative approach to understanding games. When detailed conflicts seem impossible to resolve, it is often worth while to step back and look at the big picture.
Here are three questions we need to answer in order to make any integrative approach useful to real game developers working on real products. (Unfortunately, theory alone won’t pay the bills.)
What is an integrative framework to use as a starting point for the conversation? If we waste our time reinventing the wheel, we just end up with more arguments.
What is a common goal that subsumes the existing goals? If people don’t see a reason to work together, they won’t.
How do the various perspectives work as part of a coherent ecosystem? If there isn’t an obvious way the different perspectives benefit one another then the whole effort is a non-starter.
New Product Development as an integrative framework There are many possible ways of describing our gaming big picture. We need to start someplace, so let us look at games as a New Product Development (NPD) exercise. This is a common integrative framework that is used across many industries and is easily applicable to the game industry.
NPD is, not surprisingly, the act of bringing a new product to market. It is a process that includes everything from the fuzzy front end of defining a product all the way up to releasing the product onto the market. Apple, 3M, and IBM treat it as a core strategic competency. For auto manufacturers, it is a religion. Even a few software developers are starting to think about their work as more than just writing code.
One of the key benefits of the NPD framework is its comprehensiveness. It details a variety of stages, each of which has important links into on the commonly held perspectives of the game industry. A traditional NPD process looks a bit like this.
Idea Generation
Idea Screening
Concept Development and Testing
Business Analysis
Beta Testing and Market Analysis
Technical Implementation
Commercialization
A NPD (or the more loosely applied term ‘Product Design’) perspective allows us to look at any person who makes games and say “Yes, I understand your personal goals and this is how you contribute to the big picture.” When you follow an integrative framework, you no longer have to look at the world in terms of us and them.
A common goal Next, we need to answer the question “Why should we all work together?”
NPD has a simple goal. Everyone involved wants to create and commercialize a product that benefits an underserved customer need. There are lots of ways to reword the goal of product development in a manner that appeals to a wide variety of people. One of my favorites is “Doing good things for other people (and not starving while doing it)”
Many people coming to product development for first time often mistake it as a capitalist or business system. It borrows from these perspectives, but making new products is about something far more fundamental. It is about basic human decency and using our marvelous intellectual and social skills to better the world. You see someone who has a problem and you help them out. If your solution is good enough, they’ll return the favor.
Admittedly, there is one group -- let’s call them the ‘Self Absorbed’ -- that finds the general goals of new product development repugnant. The major sticking point is the horrendous thought of spending their precious time helping others. Some are young men who just need to grow up and live life. Some have bought into ill-formed notions of how art or innovation actually occurs. I happen to believe that once you cut out the world’s sociopaths, the group that does not willingly contribute to the welfare of others is thankfully quite small.
Working towards a greater good is one of the most energizing and unifying activities that we can do as human beings. It is built in to our wetware. Teams that recognize this fact and structure their efforts around reaching for a meaningful shared goal create the world’s most amazing games.
If ‘Doing good things for other people’ is the general theme, you still need to answer some hard questions in order to bring folks on board.
Who is the customer? Specifically, who are we doing good things for?
Does their need really matter to them? If we make something cool, are they going to show us monetary love or are they going to guiltily look the other way and start walking faster?
Is our solution any good? Can we make something that they think is worth buying?
If you can answer these questions in a clear, highly positive manner, you have a team goal that helps cut across all existing boundaries. You give folks a reason to subsume their personal agendas into a greater goal.
If you give vague answers or switch goals depending on how the wind is blowing, people will call you on your bluff and move back to supporting their own goals. Most people want to believe in a greater good, but they aren’t complete idiots.
A coherent eco-system Now that we’ve described a common goal for our integrative framework, we need to show folks how they fit into it all together. In essence, you are answering the question “How do we all work together to reach the goal?”
Here are some common ways that each group contributes:
Business: Business brings tools for measuring and managing sustainability and success of a product development effort. For example, ensuring that the company is profitable just means that the team can eat and continue doing what they love. Money can be seen as a useful measurement of value creation. If people pay you for your product, that’s a pretty good sign you are fulfilling customer needs.
Art: Art brings tools for identifying and meeting emotional needs that are not easily definable or reproducible by more empirical methods. Products are rarely bundles of only practical benefit. They can include status, comfort, stress relief, companionship and a million other fuzzy human benefits as part of their overall package. Those who promote games as art possesses potent tools for contributing these fuzzy human factors to a complete product.
Fun: The traditional entertainment perspective provides an established set of standard to benchmark your efforts against. Those who promote games as pure fun know what they like and are happy to tell you.
Production: The production / craft perspective bring together proven tools for building high quality products on time and under budget. Without production, you’ll never get your product out the door.
Theory: The theorists provide new empirical tools that can lead to radical innovative leaps. If making games is the craft of inducing fun in players, then theorists and academics provide the basic science that both drives the craft forward. They aren’t the only source, but they are an important input into the ecosystem of new game creation.
Each one of these is an essay onto itself, but I promised myself that I would try to write in more digestible chunks. :-) The important point is that it is easy to find common ground. Once you have an integrative framework and an understanding of shared goals, the benefit of widely divergent tools is quite apparent.
Conclusion During the writing of this little essay, I ended up starting four other essays. There are lots of areas to explore and I found myself delving into team building, research technology transfer techniques and a half dozen other remarkably intriguing fields. If NPD or Product Design is to be a unifying philosophy, it certainly needs to be fleshed out in much greater detail. There are many practical questions just begging to be answered.
I'm tempted to say "Hey, isn't this exciting!" but it would be perhaps idealistic to expect all the participants in our industry to be focused on the same goal of seeing the big picture. Our charming Godfrey’s poem ends on a pessimistic note.
"So oft in theologic wars, The disputants, I ween, Rail on in utter ignorance Of what each other mean, And prate about an Elephant Not one of them has seen!”
I prefer to remain optimistic. We have the start of at least one integrative framework that can help us avoid theological wars. We also have two big carrots that I hope will encourage others to pitch in:
We can advance game design by leveraging a common viewpoint. The result is tightly focused teams and a lot less arguing.
We can learn one another’s tools and use knowledge from multiple domains to solve our most difficult issues in innovative ways. The result is better games that satisfy customers more deeply.
Imagine for a moment if our blind men figured out that they were really describing an elephant. Would they train it to carry them about? Would they run away if it was angry (I would!). They certainly would figure out that perhaps they shouldn’t grab certain parts too tightly. At the very least, they could stop arguing and put their efforts into something a bit more practical.
Pause for a moment the next time you hear someone ranting on how their perspective on game development is correct and the other fellow is completely off his rocker. Perhaps it is worth asking “Hey, what is our common ground here?”
It occurred to me the other day, “What does the world of music have to offer to game designers?”
On my first dive into the topic, I latched onto the use of musical notation to express complex melodies. After pounding on buttons in my last session of Mario and Luigi: Partners in Time, there was an eerie parallel with the rhythm of rewards in a typical game. The bloops and bleeps of the various attacks and power ups seemed remarkably close to a strange form of music. What would they look like if we were able to write them down like music?
This essay describes a game play notation system that can be used to record and analyze any game. It turns out that games can benefit greatly from the use of a symbolic notational system that describes the rhythm and flow of a game play experience.
This is not an idle exercise. Our current design methodologies are broken and I’m searching for a replacement. We’ve explored design tomes in an attempt to learn from software development. No one reads them. We’ve recently explored the land of movies with the creation of ‘game scripts.’ The result is bloated cinematic epics based on movie-like scripts that somehow manage to avoid describing the ‘fun’ in any meaningful fashion. It should be no shock that design tools influence the final results. Design a game using a script and you’ll get a script-like game.
If you really want to change how games are made, you have to change the design methodology at its very core. This article is a step towards providing a new set of pragmatic tools for practicing game designers. When implemented as part of your design methodology, it will change how you design and ultimately what you design.
Notational systems in music Music notation as an information technology For thousands of years, early musicians composed new music using their instincts. Music was learned by rote memorization of previously composed tunes and limited innovation happened mostly during individual performances. The business of music was in the performance of old favorites with original works few and far between.
Eventually early Catholic monks began using a rough notation that helped codify and record sacred songs. Early musical notation was crude, but provided crucial information for understanding the songs. Over time, a pleasant fellow named Guido of Arezzo added a staff for recording pitch and timing information was recorded with more accuracy.
In our world of silicon wafers and mechanical gizmockery, we don’t typically think of such innovations as a technological advance. For the time, however, the introduction of musical notation was a major advance in information technology. It reduced the cost and increased the speed of music composition. The benefits of musical were two fold.
Rapidly understand and communicate complex structures: Instead of dedicating dozens of hours memorizing a particular song, you could learn the basics of a song by spending a few minutes glancing at a sheet of music.
Provide a framework for analysis and modification of failing compositions: Instead of getting together a group of musicians to learn and play a song in order to understand its flaws, you could quickly identify issues on the sheet of music and with a few pen strokes make major changes.
Impact on music composition As the process of describing music became codified, the act of creating original works became more prevalent. This was driven by two factors. First, the growing existence of a large worldly audience with a taste for new works provided a strong business incentive for composers to write new songs. Second the existence of a well-defined system of notation provided a comprehensive set of tools that facilitated and accelerated the creative process. The combination of both business need and process / technology maturity led to an explosion in the development of new music.
The songs of the times before the creation of advanced musical notation tended to be quite simple compared to the great symphonies of later generations. The human mind can build and modify complex systems much more easily if it has a way of simplifying them into an easy-to-manipulate notational format. Without musical notation, it is questionable if we would have the great symphonies and arias that grace music halls across the nation. Even ‘original’ pop music, with its heavy use of modern electronic notation systems, is unlikely to exist.
Imagine instead, a thousand years of dancing to Auld Lang Syne at every single event. Let us praise the advent of music notation as a potent and world changing enabling technology.
The primitive state of game design notation Game designers are still in the early prehistory where they seek to create addictive gaming experiences by tweaking old designs. They are much like the minstrels of ages past. They apprentice themselves to the designs of past masters in order to learn and continue our mysterious and sacred trade. They may innovate mildly in each performance, but never much more. That is the way of it has been and how many imagine it will always be.
The lack of a well defined language of game design is crippling. New ideas emerge from a game designer as vague emotional statements that dissipate quickly. They have no tools to record them in a coherent manner. How would you create a symphony is written music did not exist? Game design exists in a similar state.
The state of the art is the game script, stolen almost directly from the movie industry. The most a modern designer can manage is stringing together a fluffy narrative that reads like a movie script. Is it any surprise the many modern games feel like recycled game systems linked together with an innumerable series of plot snippets? We simply do not have the symbolic language to create anything greater without risking deadly design ambiguity.
We lack the basic informational technology to do more than this. We lack the terminology and we lack the system for describing important systematic interactions.
In the world of music composition, Guido of Arezzo sat down and said “Pitch is a critical factor in music and we should represent this factor symbolically.” He created a powerful design tool that unlocked the creative potential of millions.
We need to do the same for games.
We need to understand the basic mechanical elements that describe the game play experience.
We need create a notational language for expressing, analyzing and manipulating these key elements of game design.
The challenge Creating a complete and robust notational system is a Herculean task. There are so many aspects to even a simple game that it seems impossible to capture them all without building a monster theoretical diagram that no one understands, maintains or cares about.
In these situations, I love to simplify the problem down to one that we can solve. Often the results give us 80% of what we are looking for with 10% of the pain.
Here’s the basic premise: If we can measure and transcribe existing game experiences in a robust symbolic fashion, we can reuse the same system to improve new games. Just like the Catholic monks of yore, we are figuring out how to record our medium in a meaningful fashion.
The game play model The first issue to solve in any recording problem is answering the question “What information should we record?” We’ll start with a simple, yet comprehensive game play model that I’ve been working with for some time. It deals with two aspects of game play,
The mechanical structure of the game
The psychological experience of the player.
Elements of a game’s mechanical structure The mechanical structure of the game defines the basic elements of a game and how they interact. These elements have no value associated with them, they simply form an interactive machine that clicks and burps when it is poked.
Verbs: Discreet actions that can be performed by tokens on other tokens. The act of jumping in a platform game is an example of a verb.
Tokens: Any object in the game that is manipulated. The player’s avatar or an enemy is an example of a token.
Rules: The basic rules of interaction between tokens and verbs. The logic that an avatar jumping on an enemy kills it is an example of a rule.
Elements of a player’s psychological experience The psychological experience describes how the player reacts to the mechanical structure of the game.
Actions: An action is the goal oriented series of executed verbs that is necessary to activate reward. “Save the princess (in order to win the game)” is an example of an action.
Rewards: An indicator that the player has done something meaningful in the context of the game. The general goal of a reward is to make the player feel good. The fireworks when you save the princess are a good example of a reward.
Risks: An indicator that the player is executing their actions in an unsuccessful manner. The general goal of a risk is to provide feedback that points a way forward. The simplest version of this feedback is “Don’t do that again.” The death animation when you die is a good example of a risk.
In the past I’ve argued that a simple model of fun is based off a series of layered psychological reward schedules. As the player is rewarded with a series of overlapping rewards, they build up a complex and mildly addictive buzz.
Both the mechanical and psychological structures I’ve described are present in all games, ranging from Tetris to World of Warcraft’s leveling system to Dance Dance Revolution. In my experience, any game can be described in a complete and robust fashion using these six simple elements, so it should be a very useful starting place for our notational system.
Notational devices In the upcoming sections, I’m going to describe five important notational devices derived from our game play model.
Buzz notes
Reward Channels
Verbs
Master Buzz Meter
Statistics
Buzz note: The basic notes of a game In music, you get a burst of emotional value when you hear a note. In a game you gain a burst of emotional value when you receive a reward.
Rewards act as the core building block of our notation system. We are starting simple and ignoring verbs, tokens, rules, actions, and risks. These elements matter, but we’ll add them as we need them. One big benefit to starting with rewards is that most built-in rewards are relatively easy to measure. They are typically events that are triggered by the game in response to a player action.
If you collect a star in Mario 64, a cute little award animation plays and a resource counter increments. If you complete a line in Tetris, your points increase. Ultimately, someone has to program the basic feedback systems in any game title. Given a set of game mechanics, it is trivial to classify and tag the reward events.
Psychologically, rewards create a little blurp of pleasure in the user that rapidly degrades over time. We represent this psychological response as a symbol in our notational system. This pulse is represented by a “buzz note.”
A buzz note is an exponential curve with the following characteristics
Start time: The time at which the reward occurs.
Strength: The magnitude of the reward.
Fall off period: How long the pleasure takes to dissipate.
For now I’ve displayed the buzz notes in a rather literal manner as curves. In the future, as we identify different classes of buzz curves we can start using more symbolic representation.
Reward Channels: The instruments of the game Imagine that your rewards are instruments. As a designer, you set up systems that the player triggers that result in a cascade of buzz curves along a number of discrete reward types.
Visually we can give each reward its own channel and then simply record the buzz notes when they occur. The visual metaphor is inspired by many of the old tracking programs used to create MOD files.
It turns out that many games, even seemingly complex RPGs, have no more than several dozen reward channels. This works out well since you end up with a set of channels that you can rapidly scan on a single screen. The ability to make complex game data ‘glance-able’ is a critical factor in the creation of a useful notational system. Remember, we are attempting to take a complex emotional experience and compress it down to an easy to manipulate symbolic experience. A successful notational system needs to fit in a person’s head without genius level comprehension skills required.
Introducing verbs into the mix We run into an interesting divergence from the musical metaphor. Rewards alone are not enough to produce a meaningful notation of the game experience. You clearly see what the player experiences, but it is difficult to understand what happened in order to cause the cascade of rewards. If we don’t represent the player’s interaction, our game notation is meaningless.
Ideally, we could record the actions that the player performs. However, it turns out that this is quite difficult. Imagine in a game of chess that you capture a pawn. There were countless moves that lead up to the capture of that pawn, some of which involved the player’s intent and other’s the opponent’s intent. You can describe a conceptual strategy that defines the action of capturing a pawn, but identifying the exact sequence of events that go into an action is difficult.
The solution to this dilemma is to record all the verbs that the player performs and list them them according to time across the top of our chart. The game designer can quickly scan through what the player is doing and see rewards are occurring simultaneously. Sometimes there will be a direct correlation. Other times there will be an indirect correlation.
When you record an actual game play session, the result is quite fascinating. You can see on a single scrolling screen the entire history of how the player experienced the game. Down the side are the reward channels and sprinkled across the channels are the timed reward events.
In more advanced implementations, you can add a playback head that scrubs through the log file and shows the actual recorded game play in either a video window or the actual game engine. This provides a very clear understanding of what happens at various points in time.
The Master Buzz Meter: The volume graph of the game All this detailed data is very useful for digging into specific problem areas, but too much data is useless. When a dozen testers generate reams of data, you simply don’t have time to look at it.
If you sum up the buzz curves across all the reward channels, you get a single graph that shows player buzz over time.
You can use this to quickly identify periods of low reward activity.
First by glancing at the chart you can learn to ‘read’ problem areas quickly.
Second by setting thresholds, the system can automatically mark areas of low reward activity and call them out with color.
Statistical snapshots Even using the Master Buzz Meter, our notational system can generate far too much data to process in a reasonable amount of time. Games are interactive and every game session results in a static snapshot of a single player’s experience. A dozen players playing a dozen sessions and you are in the hundreds of data files to analyze.
Here we turn to statistics to give as an overall view of game play. From each of our elements, we can determine a variety of key statistical factors that help us understand various systems at a glance.
Master Buzz Meter Information
Average buzz per session: By sorting sessions by average buzz, you can identify low buzz scenarios and examine them in more detail.
Average buzz across all sessions: This allows you to track progress on various versions of the game. As you make improvements, you should see the average buzz score improve with each subsequent prototype.
Variation per session: What is the standard deviation for the master buzz meter? This tells you if certain sessions are providing highly variable experiences.
Variation across all sessions: This tells you if players are having dramatically different experiences.
Gameplay time: Very short sessions are often worth looking into.
Reward Channel Information
Average time between rewards per session
Average time between rewards across all session: This helps determine the reward frequency. In the standard display, reward channels sorted by reward frequency since it gives you a real world grasp on what activities are core game mechanics and which ones are additional layers on top. In general, you should focus the majority of your polish efforts on the high frequency action – reward cycles.
The major point of all these statistics is to be able to quickly select from potentially hundreds of log files a ‘typical’ game play scenario and one or two outlying game play scenarios. The designer can then dig into these in more detail, identify problem areas with prototypes and start building a list of solutions.
Essential Technology: Logging Systems As might be apparent, a critical aspect of using our notational system is a robust logging system. This should be built into your game engine and the data should be recorded religiously from the first prototype onward. If you aren’t logging, you are prototyping blind.
The type of data you collect is highly flexible. In the most basic situation, you are recording player verbs and reward events. Such information can be highly compressed and stored in a wide variety of media without too much slow down. In more advanced situations, you are creating a complete record of the game play. This is a lot more data, but may be worth the effort as you become more experienced with interpreting subtle notational symptoms.
Advanced features include:
Playback of log files in the game engine with full seek and scrub capabilities.
Capturing sections of the log file for reference in future discussion. Think of this as taking a snapshot of a problem area.
Zooming mechanisms similar to those in video timelines for looking at the big picture and then zooming in on the details of a particular area.
Expanding the Notational Model What we’ve built so far is a very simple notational system. Here are some other factors worth taking into account when you build such a system for your games. Some are based on basic human psychology and others are issues worth keeping in mind.
Burn out
Expected and Unexpected Rewards
Suppression
Risks
Game Structure
Unusual events
Burnout When a reward repeated, it becomes less effective and the strength of the buzz curve is reduced. However, if the sequence of rewards is interrupted by other rewards, the reward recovers some of its former impact.
There is some interesting work to be done here to determine what patterns typically cause burnout.
Expected Rewards Two common types of rewards are expected rewards and unexpected rewards.
An unexpected reward is a reward that the player doesn’t know is coming. The player experiences a small bit of delight when they happen upon a random bonus. It is represented by a standard buzz curve.
An expected reward is one that the player is told will happen. These two part buzz curves consist of an expectation curve and a standard buzz curve. The expectation curve is kicked off by a defined hint that promises a future reward. The player then experiences a mild buzz of expectation until the promised reward is delivered.
The classic expected reward is a hidden room in Zelda. The player is shown a room that they cannot get to. The expectation of reaching the room will give players enough of a buzz that they’ll keep playing the game even when there are few short term rewards. The buzz that comes from uncompleted tasks can be an extraordinarily powerful motivator for more hardcore player personalities.
In our notation system, an expected reward is recorded by tagging certain events in the game as ‘hints’ that are associated with a particular reward. Once the hint is given, a mild buzz curve is in existence until the promised reward is reached.
Suppression When a player experiences too many rewards at once they suppress the lower strength buzz curves and only focus on the easily discernable rewards.
Suppression in combination with Burnout tells us why we can’t make a game that is all rewards all the time. First, if we repeat rewards, players will learn to ignore them. If we pile too many rewards on at once, players will also ignore them. By building these concepts into the notation system, we ensure that designers are always aware of such concepts.
Risks Identifiable risks should be treated just like Buzz notes and recorded in their own risk channel.
Some risks can be recorded and some cannot. Often the most powerful risks are opportunity costs as opposed to concrete punishments so be careful of thinking you have all the risks accounted for if you add risk notes to your system.
Game Structure In music, songs often have distinct sections that form a structure. For example a chorus might be label A and the refrain might be labeled B. Several classic structures include Binary: AB, Ternary: ABA or Ronda ABACADA.
Most games possess substantial structure as well.
Binary: AB where A = The game is off, B = Actively Playing the Core Game. This might be your typical arcade game.
Ternary: ABCA, where A = Off, B = Playing the exploration portion of the game, C = Playing the combat portion of the game. This might be your typical console RPG.
All games will at least have a Binary structure. If your game has discrete sections, you should record and label them. Often each section has unique balancing issues that must be dealt with individually.
Unusual events Part of using the notation system correctly is understanding what constitutes a meaningful event and logging it appropriately. Rewards, for example, are more than just power ups and coins. They also include many of the aspects of the game that historically have passionately been defended as important, but no one can tell you why.
Plot: Plot sequences are really just another reward. Press the right button and get a bit of plot. The wonderful thing about plot sequences is that they act as a nice reward, but they also tend to contain a clue that sets up another expected reward.
New graphics: You know those sexy new graphics the artist spends so much time slaving over? It turns out that they can be easily represented as a reward. Simply record the first time that the player sees a new monster or a new area as a reward. This helps you identify the rate at which you introduce new artwork and ultimately how much artwork you need. If you are balancing your other rewards appropriately, you can often maintain the player’s buzz without investing in heavy art resources.
Dying and death. Record these! They are the most basic form risk and often provide important insight.
Resetting or restarting. You need to look at the entire play experience and record it as part of your game structure.. This involves player who save and restart. It involves resetting or turning off the game in frustration. Ultimately the log file should contain the player’s entire experience with the game, not just small snippets of game play. Those hours they weren’t playing the game are just as important to your balancing efforts as they hours they are playing the game.
Other areas of further work Here are some obvious holes in the current system that -- while not preventing its usefulness -- should be acknowledged.
It needs real world testing: This is a design for a notational system, not a case study. Real world testing will help polish the system.
Social Rewards and other player invented goals are not measured: Any reward or risk that is not explicitly called out in the game mechanics cannot be measured. The joy that a player gets from taunting another player or the fun they experience from randomly stacking crates is difficult to track at this time.
Long games are difficult to manage in an iterative manner: If a game takes 6 months to experience, it can be difficult to collect enough log files to gain a statistical understanding of player experiences. You still however can focus on sections of the games that occur on shorter time scales.
Rules, Actions, and Tokens are not well described: There are several other major elements to a game design that are not included. This means that the notational system is not a complete and cannot be used to design full games.
Buzz note values are not derived from real world data: We can make assumptions about how long a buzz note will last and which ones are stronger than others. However, until we hook someone’s head up to a pleasure sensing device, these are merely educated guesses.
Practical usage of a notational system for games So once you’ve created your logging system and built out your pretty pictures, what next? What do we do with all this data?
Our notational system is a method of clarifying and providing conceptual feedback on psychological impact of existing game mechanics. Woot. That is indeed a mouthful so let’s dig into it in more detail.
“Existing game mechanics”: You need to have a working game in order to record game notation.
“Psychological impact”: By focusing on rewards, we are illustrating a crucial part of the player experience, but at the expense of the mechanical structure. You can’t design a full game using this form of game notation.
“Clarify and providing conceptual feedback”: What we do get is the ability to describe a game using well defined terminology. Instead of saying “This is boring”, you can point to a period of 5 second in buzz graph with no rewards and identify the events leading to that situation.
How to use it Our notation system is best used in an iterative development process where play testing is readily available.
Build a benchmark suite of successful games. Typically this can involve logging publicly available games such as Tetris or past games that you have worked on.
Build a prototype with logging.
Examine the initial log files in details. Compare and contrast them to your benchmark suite. Are there any glaring issues? Focus on the high frequency rewards first.
Record these issues in terms of the results you want to see in the next set of logs. Create goals for future success in terms of buzz curves, reward channels, and statistics.
Create a new prototype and repeat the process. See if you hit your goals. If not, try again.
You’ll need to have a group of dedicated testers. Try to get a good mix of first time testers (Kleenex testers) in addition to your more experienced testers. These will provide the log files that drive the process forward.
Benefit: Steerable design This is a very different form of a development than many teams practice. The game industry is roughly five to ten years behind the rest of the software industry in terms of process management and methodology. They’ve historically focused heavily on a waterfall-like development methodology with long preproduction cycles and rigidly defined production milestones. The rigid methodology is one major factor that leads to risk averse, stagnant design.
By using the notation system as a critical part of development, you build into the team strong structures that encourage a more agile form of design.
Prototyping is essential. You can’t develop the next step without prototyping first.
Design goals are easily communicated and cover the immediate future. No more fuzzy ideas that introduce unacceptable design risk.
You steer the design using constant feedback instead of writing it down in a fit of artistic genius.
Ironically, all this lets you take more risks, not less. The feedback cycle provides a safety net that encourages innovation instead of punishing it.
By having clearly defined goals coupled with strong feedback, you’ll design better games with fewer expensive errors.
Benefit: All game content is on an equal playing ground Art resources, physics systems and combat mechanics all are ultimately translated into the notational system in the form of the customer experience. Instead of optimizing each silo, you can focus on optimizing the overall game experience.
Benefit: Tightly targeted games You’ll also likely make smaller games that serve customer in a more focused manner. By clearly understanding what works and what doesn’t work, you can invest in the right features instead of being throwing more features at the customer in the hope that a few will stick.
You may not make God of War, but you may make Nintendogs. In our world of ever increasing development costs and industry consolidation, being able to hit your market in a highly targeted manner means higher profitability with lower risk of failure.
Conclusion That brings us to the end of our exploration of game play notation. We’ve covered a lot of heady concepts quite quickly, so here is a quick recap:
Key concepts
Notational systems are good! A notational system can increase the creation speed and final quality of a game design. It provides powerful information management tools that help mere mortals manage designs of staggering complexity in a reasonable fashion. It works for music and it can work for games.
We can display basic elements of the player experience in notational form: By focusing on the psychological rewards that a player receives, we can represent the player’s fun over time. By also recording the verbs that the player performs, we can link player behavior to they player’s psychological state.
Layered information display makes log files useful: Our systems ‘layers’ information at various conceptual levels of detail for ease of use. You can easily get quick overviews of the game and you can dig down in to find out the exact details of the game play.
The use of notation encourages rigorous design habits: Instead of being forced to rely on vague, often emotional hand waving, a designer can identify problem areas and describe them to the team with a high level of rigor and accuracy.
When used in conjunction with iterative prototyping, game play notation can enable a powerful agile design process: Logging prototype play sessions and recording them in a simple notational form provides the entire team with a clear feedback mechanism. You’ll make more focused games more efficiently.
The future The industry needs to develop a solid set of information technology that describes how games play. If we can’t accurately describe what we are making, we cannot have an accurate discussion about how to improve our product. We should all be tired of muddled design documents that no one reads and bear only a limited resemblance to the finished product. Our current design practices are expensive and inefficient. They actively hurt the advancement of our art by promoting risk adverse behavior.
I encourage folks to explore game play notation systems as one path toward building modern, effective design tools. It certainly isn’t the only path, but it is more promising than the status quo and worth pursuing.
The notational system I’ve described is a first attempt. After all, there were several hundred years between the notation of the ancient Catholic monks and the development of our modern musical notation. However, if the technique is useful, others will innovate and improve on the basic concepts. If you implement such a system, drop me a line. I’d love to hear how it worked out for you.
Design Testing: The use of addiction metrics to force rapid evolution of innovative game designs
One of my goals with this blog is to formulate a 'new game development methodology' that empowers the little guy and helps the growth of innovation in the game industry. How do we build innovative, highly addictive games more quickly and with lower risk? Part of the answer is the rigid application of gaming metrics to the process of improving player addiction.
The Legacy of Cowboy Designers The traditional designer is a cowboy designer. Modern game designs are the result of the messy, content dependent process a cowboy designer intuitively follows when building a game.
Cowboy Programmers The term comes from the land of programming where early programmers would whip out l33t code in as little time as possible. Cowboy programmers were lone guns, experts in their field who possessed a deeply intuitive understanding of what works and what doesn't.
Coding standard, methodologies, even team work were taboo for the ancient cowboy programmers. Their code was inscrutable and many decisions seemed arbitrary. Troubles inevitably arose as the industry matured. Project didn't scale and many failed as they were bogged down in a plague of bugs. Eventually the world figured out better ways of programming that were more reliable, less risky, and produced better results. God bless process advancement.
Cowboy Designers: Copy cats with a hip attitude Cowboy Designers are similar in many ways. They shoot from the hip when it comes to decisions, relying on their own finely tuned sense of 'fun' to design systems and create requirement docs. This sense of 'fun' is typically built up after internalizing the game play of dozens of similar game titles.
Such expertise works well when you are creating a clone or focusing on the later layers of the game design where you can't do much damage. Adding the 101st 'designer inspired' Pokemon is about as risk free as adding the 100th one. Subtle, oh so well crafted variations on existing themes are the bread and butter of a cowboy designer. The 'I could build it better' syndrome that drives many game designers is not only a contributing factor to the stagnation of innovation, but is actively encouraged by most game publishers as a means of reducing risk.
Cowboy designers stifle innovation The big problem is that intuitive cowboy designers have high failure rates when it comes to inventing core game mechanics. Experience in pre-existing genres is a poor guide for success when your job is to put together new rules that result in dynamically different psychological scenarios. When cowboy designers attempt to refine a new genre, one of two things typically occur.
The half-breed design: The designer mixes two well defined genres. Since their decisions are informed by experiance and not psychology, the result is rarely enjoyable to play.
The mush design: The design mixes multiple genres together with rules that are untested and arbitrary in nature. Randomly designed games tend to a remarkably low success rate.
Either way, the result is ruined teams and failed games. It is no wonder that publishers are adverse to large investments in innovation.
Bad process, not bad people It doesn't have to be this way. We are simply using the wrong design methodology to build innovative games. The old cowboy method only works with Shooter Clone #64. It fails miserably when attempting something new. With the right design methodology built around the concept of make risky game design decisions painless, innovative games have the opportunity to prosper.
Introducing feedback: A miracle design tool What we really need is a reliable feedback mechanism that lets us reduce investment risk in order to create a safety net for innovation.
The modern feedback desert Consider the traditional feedback cycle in game design. You spend 12 to 18 months building a game. You recieve the majority of your feedback from traditional game testers and internal 'team testing'. The information is very useful, but runs into several difficulties
The information is subjective: Most feedback is qualitative and is filtered through a pre-biased team of hardcore game developers.
Feedback is not statistically valid: Testing occurs with small numbers of testers that do not accurately represent the target market, nor are their opinions verifiably the same as larger market.
At this stage you still don't get a chance to react. Almost all gameplay fixes occur in the higher layers of the game design due to its lower risk nature. You can change some art or a few engine variables, but rarely is there time to alter core game mechanics due to the exponential cost of change in a content heavy system.
Once the game is released and in the public's hands, you finally get your first pieces of accurate feedback on your design decisions. You either sell a lot of copies, or you don't. If your game happens to end up a failure, there is no second chance. You didn't get it right the first time and now your entire team will be culled in a grand bloodletting by your disappointed publisher.
This isn't a healthy feedback cycle. The opportunity to make meaninful changes is limited from an early stage. Those who make mistakes are punished dramatically. Those who survive see their lifeless brethren on the roadside and learn that risk taking is dangerous.
Specifying a useful feedback mechanism We need a tool that:
Rapidly informs us when design decisions unbalance the game
Lets us test multiple variations on a rule without risk
Allows us to see the effects of a change before we invest heavily in expensive, difficult-to-change content.
Such a design tool would allow incremental investments in new game designs. If you make a mistake, you can back that change out without putting the entire project at risk. Since the cycle time on between changes, feedback and exception or reject of the change is short, the team can iterate through a series of changes quickly.
Enter the Metrics There are a wide variety of testing systems available that give us interesting feedback.
Unit testing
Market testing
Design testing
I'll briefly describe each the first two and then explain how Design testing can radically change how you go about game design.
Unit testing The most common testing in game development is the unit test, borrowed from Agile programming methodologies. These are covered extensively in a wide variety of books and websites and deal primarily with code integrity and refactorability. This is certainly good important stuff that is essential to creating an agile game design methodology. However, unit tests address only programmer risk, not design risk.
Market testing (aka Market Research) Another common method of product testing involves giving a product sample to users and having them rate how likely they would be to purchase. Market tesing is a huge field and contains everything from focus groups, to concept testing, to full on market testing with a wide scale deployment of the finished product.
Traditional market testing has some fundamental problems when applied directly to game design.
Expensive: This restricts its use to only the biggest of game developers and publishers.
Provides limited insight: Second, and most damning is that it is nearly impossible to tell anything about the addictive qualities of a game without actually playing it. I can show you a box with a guy with a gun on it and ask potential players if they would buy it. But such a survey gives me no meaningful information on whether or not I have the next Halo or Daikatana on my hands. "How does it play?" is critical competitive information.
Games, as a testable product, exist in a market research vacuum. Many of the tradition techniques honed over decade of consumer product research simply do not apply. They don't capture 'addiction', the competitive essence of games.
Design testing We need tests and metrics that capture such ephemeral qualities as 'fun' and 'addiction'.
What makes me think we can test 'fun' and 'addiction'? I believe that core game mechanics rely on relatively simple psychological reward schedules. A successfully addicted player exhibits easily identifiable behavioral symptoms. By tracking these symptoms in a statistically valid manner, the designer gains useful feedback on the addictive properties of their gaming system.
Common Metrics for Design Testing Testing for addiction is easier than you might imagine. The following are easily gathered metrics for measuring system-wide addictive behavior.
Length of playtime
Intensity of play time
Willingness to play again
Length between play times
Number of play times
Spot exit surveys
Game Token Metrics You can also get more atomic and measure metrics for each game token in order to dig down into why a particular pattern of addiction is occuring.
Use time of each token
Frequency of use for each token
Gap between token use
Spot surveys of user's token enjoyment
ROI metrics Finally, you can gather ROI metrics by combining the information from metrics above with cost of production information from your project tracking. This gives you some interesting information on where your development investments are paying off.
ROI of each token: Calculated by use time / development cost.
ROI of each game system
Intriguing results immediately pop to the surface once you implement ROI metrics. Additional level design has a marginal ROI. Character art is the same. You can add a new monster or a new level to the game and the addictive qualities of the title don't budge an inch. On the other hand, add a new powerup system and watch the addiction rise.
Control Charts You can track these metrics on control charts. This simple charting method tracks changes in specific metrics over time. When a system is changed, you can usually see the results immediately in the control chart.
In general there will be one or two key metrics that (Key Performance Indicators, or KPI) that give you a strong indication of the addiction of your gaming system. Other metrics will be secondary factors that influence you KPI. For example, the reuse time of the powerup system is not the single most important factor in the game, but it influences total session playing time, which is your primary indicator of addiction.
Using the data Once you have the control charts populated with data, it is a simple matter following a clearly defined change regimen
Create a design change
propagate that change your game players
Measure the results
If the change is positive compared to the previous baseline, keep the functionality.
If the change is negative or mixed, create a new set of changes
Track the key metrics over time to ensure that there is a steady improvement.
Other areas of future exploration This is a very rough overview of the techniques involved in design testing. It is both a broad and deep field that borrows from many well-developed ideas in the world of market research and process engineering and applies them them to the problem of game design. Other topics include: Batch testing: Test a wide number of variations in game design mechanics simultaneously. Take the best results and explore them further. Tie KPI to financially meaningful results: Use regression analysis to link key statistics to financially meaningful results. For online games, measure re-up rate on subscriptions. For ad-based games, measure customer referral rates and number of impressions. For shareware games, measure initial purchase rates.
Design Testing Limitations Design testing is the core of a rather radical new game design methodology. Let's take a look at some of the limitations.
Not every game can be design tested Design testing is not for every team nor is it for every type of game. To borrow a term from the agile programmer world, most modern game designs are poorly refactored. They are clumsy, non object-oriented messes of content spaghetti strung together by cowboy designers and their complacent teams of artists and programmers. The typical modern game design has the following attributes:
Change is expensive.
Testing takes forever.
Development cycles are long
Static content is king
None of this is conducive to an effective design testable system. I think of applying design testing to an adventure game and shudder. The sheer mass of the static level content combined with the linear sequencing of content results in a system where a change to one location has no effect on any other location. Players are likely to play the game only once and it will take them 40 hours to complete. Good luck getting any timely feedback.
Requirements for a design-testable game To use design testing as part of our process, we need a game design that is ammendable to thorough application of the technique. The following are some key characteristics of a design-testable game.
Refactored Design: The game is composed of highly reusable object-oriented elements. Changes to these elements propagate throughout the entire game system.
Game Mechanics focused, not Content focused: Static content in the form of level designs, sequenced boss attacks, fixed plot points, etc is rarely used. Instead the focus is on interesting game rules, meta game rules, dynamically generated levels to create an enjoyable game experience.
Automated update mechanism: The game designer can rapidly push changes out to a population of game players.
Real-time metrics: When a change is made, statistics on current player usage are immediately sent back to a central electronic dashboard. Most commonly this will be through an internet-based tracking system connected directly into the game.
Large population of game players: Statistics are worse than meaningless if you do not have a pertinent population to survey. Testable games require a large standing population of active game players. This suggests extensive open betas and other mechanisms to encourage player interaction before the game is finished. Subscription-based models also work well with this requirement.
Markets ripe for design testing Online games have a clear advantage. Many of the tracking systems are already built into the web and you already have logs and a database ready to receive the data. You are guaranteed 100% correct information since you see everything that occurs. MMOGs are already doing many of the things outlined in this essay. Their success is readily apparent and I challenge you to find a more addictive genre.
Consoles are moving online in the next generation and most gaming PC's are online already. The technological infrastructure is certainly possible. All it takes are teams innovative enough to improve their development process. Indy games, Nintendo DS titles, and mass market consumer titles all are place where new methodologies might blossom.
Is design testing worth it? If you want to make a design testable game, you need to throw out decades of highly polished game design experience and theory. You need to rely on cold metrics instead of your warm fuzzy 'I could do it better' cowboy designer instincts. You need to shun common content heavy genres that you grew up with and love in the deepest core of your gamer heart.
What you lose Design testing fundamentally changes how games are developed.
Long development schedules cloistered away from the public: Feedback critical to the product's final success. Alphas, Closed beta, and Open betas become essential tools to releasing a polished game.
Offline games: If you aren't online, you've got no way of gathering data about gameplay.
Static level design: You need a refactored game design that allows changes to be made quickly.
Plot: If the ROI isn't there, kill it. You've got data that proves you better things to spend you development time working on.
What you gain What you get in return is the ability to make radically addictive, highly competitive games with limited risk of failure.
Increase your competitive advantage: The other guy is spending all his effort just to maintain his position at the top of the king-of-the-genre battle. He invest in mature genres and every game burns out his hardcore audience a little more. You can come onto the scene with a fresh new title that is more addictive than his current offering. When his FPS is merely one of many such competing titles, your title is a one of the kind 'must have' title.
Reduce your costs: Instead of spending millions on movie level content, you gain your addictive rush from intelligent, informed game mechanics. The result is a lower cost structure. Because you have ROI metrics built into your design
Reduce product failure risk: From the very beginning of development you know, to the decimal point, how addictive your game is with your target market. This lets you cull the bad games early, and focus your efforts on the winners.
If I can make a game that does the three things listed above, I'm willing to give up all the game design traditions that don't work for design-testable games.
The result is a refactored, innovation friendly game design methodology. You can take risks and succeed. You can spend less money and still beat the big guy. As the next generation titles come upon us, the smaller game developers have a choice. They can either work smarter or they can die. Design testing is a great tool for avoiding the later.
A practical definition of innovation in game design
Making a great game with limited resources is all about focus. There are a wide variety of areas that you can put resources into ranging from core gameplay to level design to story. The problem facing most new game developers is that they attempt to have the best of all worlds. That, my friends, is a recipe for failure.
This little post describes the concept of game design layers and gives you some very simple analytical tools for understanding where you are investing and what the consequences can be. In the end we'll:
Arrive at a practical definition of innovation.
Describe major strategies of product differentiation.
Show how pursuing innovation can affect your team structure.
(And if you ever hear an indie game developer talking about level design, either shoot them in the head now to help them avoid their future misery, or direct them towards this essay.) The layers of a game A game is built like an onion. Each layer of the game polishes an aspect of the previous structure and makes it slightly more appealing. Areas near the inner core give you the most bang for your buck. Areas near the outer edges of the game design are easier to change without unbalancing the system, but don't make as big of an impact.
Core game mechanics
Meta game mechanics
Base setting
Contextualized Tokens (Graphics, Sound, etc.)
Contextualized Scenarios (Levels and Scripted events)
Overall story
1. Core game mechanics: The basic risk and reward schedules that the player partakes in form the fundamental basis of the gameplay. In general, the gamer will spend 80% or more of their time performing simple, repetitive core game mechanics. In Doom, this might include running around and shooting enemies. In a RTS, it might involve building up units and attacking other units. Core mechanics borrow from the world of board game design and can typically be abstractly defined in the following terms:
Object-oriented tokens.
Properties on tokens.
The interactions between tokens and the player as defined in an explicit set of rules.
2. Meta game mechanics Meta game mechanics are a set of game mechanics that tie together core game mechanics. The most classic example is an RPG. The first RPGs had a simple exploration mode that gave a way of linking multiple tactical battles together. Meta game mechanics also include simple initial starting conditions and end of game rules.
3. Base Setting The base setting is simple background information that gives context to the actions performed within the game. From a marketing perspective, setting acts as an initial hook that gets the player involved and interested in the game in the period of time before the addictive quality of the core game mechanics sets in. An example setting would be labeling a game as a 'fantasy game' or 'golf game'.
4. Contextualized Tokens (Graphics, Sound, etc.) Graphics and sound extend the base setting and provide additional visual context for the abstract game mechanics. By providing a richer, more intuitive set of symbolic stimuli to the player, the game designer can shorten the learning curve of the core mechanics. A blocky red 'alien' from Space Invaders is difficult to recognize as 'hostile'. An enemy from the latest Doom game is much more immediately understandable as a token that must be avoided.
5. Contextualized Scenarios (Levels, Scripted Events etc) Core game mechanics often focus on the interactions between various pre-defined game tokens. Levels and pre-scripted events exist to put the player in an emotionally interesting arrangement of tokens that support both the base setting and the contextualized tokens.
6. Overall Story The range of emotions that core gameplay can evoke is relatively limited. The context provided by levels and scripted events allows an additional level of emotional involvement. Story brings a narrative element to that game that provides an additional wrapper of context for the actions that the player performs. This lets the designer evoke additional responses beyond what the core mechanics allow.
The hierarchy of layers Each of these six layers build upon one another. You must have the lower layers in order to attempt the higher layers.
The metagame, for example, is impossible to create without first defining core game mechanics. The story is impossible to tell without having the ability to construct pre-defined scenarios.
Most commercial games have all six layers, but historically this has not typically been the standard. Let's briefly look at the game of chess:
Core gameplay: Very well defined
Metagame mechanics: Limited to governing the beginning and end of the game
Base setting: Limited to an abstract conflict between to medieval forces.
Contextualized tokens: Limited to rough descriptions of pawns, knights, queens, etc. In reality, the names exist primarily to support the base setting and give little, if any intuitive understanding of how the pieces operate.
Contextualized Scenarios: None. You could make a very tenuous argument that the two lines of tokens evoke armies facing one another, but why bother?
Story: None.
So you can build a very successful game without investing anything in the last two layers and paying mere lip service to the concept of contextualized tokens. In a game like Tetris, the designer really only worried about core gameplay and metagame mechanics.
A new game designer should be aware of the various layers and most importantly know that you can still make a great game without investing substancial effort in all six areas. This lesson alone can save many projects from feature creep and burnout.
The cost of investing in each layer Each game design makes an explicit decision to invest in the various layers of the final game. When you invest human resources, you are ultimately investing money. With money comes financial risk and payoff. If the game is a success, you'll receive more money back based on your investment. If the game is a failure, you made a poor investment in the various layers of the game.
Not all game design investments are equal. In general, investments in lower layers early in the game's development have the greatest impact on the addictive qualities of your game. Investment in the higher layers have smaller impact.
However, this is not the complete story. With each change, there is always a risk of unbalancing the game's psychological risk and reward schedules. Unbalancing ruins the addictive qualities of your game and increases the chance of the game's failure. Changes to lower layers have a greater risk of unbalancing a game design, while changes to higher layers have a lesser risk of unbalancing the game design.
All of this pose some fascinating resource allocation decisions for game designers and publishers. Two extreme strategies immediately become apparent. On one hand the designer may focus on early layers and get a lot of bang for their buck. However, they dramatically increase the chances of the game being a failure since any change along the way can hurt the addictive qualities of the game. On the other hand, the designer can start with a proven addictive core game mechanic and focus their efforts on later layers. This is much more expensive, but ensures the team has a good chance of producing an addictive game that is 'better than proceeding generations'.
A method of classifying games This is all interesting, but ends up being overly abstract for most people. Let's make it practical by showing you how you can apply these concepts to your game.
Take a game design and break it up into the tasks necessary to complete the project.
Assign each task to one of the 6 layers.
Put a cost (either in time or dollars, depending on your project) on each task.
Add up the cost of all the tasks in each category and divide them by the total project cost to get the percentage of resources you are spending in each layer.
You should end up with a distribution graph that looks something like this:
The Innovation Scale You can also calculate a general 'innovation' scale to classify your game title by taking the weighted average of all six categories. For example, you might have something that looks like this:
Chess innovation score = (60% x 1) + (20% x 2) + (10% x 3) + (10% x 4) + (0% x 5) + (0% x 6) = 1.7 out of 6
Now we have defined a scale from 1 to 6. At one end of the scale are highly innovative titles and at the other end of the scale are highly polished titles.
Uses of the innovation scale It should be very clear that the innovation scale relates primarily to the game developer's investment and not to the market's perception of innovation. This is intended to be a tool used by game developers who have intimate understanding of their development costs. Without development costs, it is difficult to gain an objective innovation rating across multiple titles. The layer classification scheme gives developers a 'balanced' score card management tool that lets them quickly and easily understand where they are investing their valuable resources.
This is also of use to publishers when they are balancing their portfolios. The 'genre' method of balancing portfolios is limited and punishes innovative games. The layer-based classification system takes into account risk and cost of production without culling titles because they fail to fit into an established category.
Innovation and the life cycle of genres Genres have life cycles. They start out with the majority of titles investing heavily in lower layers of the game design. These high risk titles have lots of innovation, but very little polish. As they mature, titles invest more in the higher layers of the game design. This results in less innovation, but lower risk. These are self evident results, but it is always good to throw something obvious at a new framework.
Innovation and Indie game developers To put it simply, independent game developers generally cannot afford to invest in the higher layers of game development. With limited resources, you can't be innovative and polished at the same time.
In my opinion, the ideal indie team is a small agile group composed primarily of programmers with only 20 to 30% artists. Such a team can compete with the best teams that EA has to offer in terms of core game mechanics. They have the luxury of being able to inexpensively and rapidly change the game design, iterating through dozens of rulesets in order to find one that offers a uniquely addictive experience.
As soon as you bring complex level design and story to the design, you lose flexibility. You lose the ability to innovate. Companies that focus on polished games have artist heavy teams and rigidly defined production cycles. This results in a huge investment in human capital and a corresponding high cost of failure. Remember, each layer builds on the preceding layers. The moment you start making changes to the core game mechanics, you send a ripple of changes all the way through the rest of the game. Content needs to be tossed or reworked.
In a innovation-oriented team, an interesting change to core game mechanics might result in a few weeks lost. In a polish oriented team, changes to core mechanics late in the development of a game can result in dozens of man years lost. Polish-oriented teams are inherently anti-innovation.
Larger teams try to balance both low layer activities and high layer activities by splitting the development into a 'prototyping' stage and a 'production' stage. The result is incremental innovation cut off short by the looming end of the prototyping stage and constrained the intense logistical demands of the production team.
The innovation-focused game team What would happen if instead you doubled the resources spent on the traditional 'prototyping' period, worked in tight interative cycles and then shipped it the product directly to testers? Instead of levels, you use procedural content. Instead of plot, you focus on interesting reusable game objects that introduce delightful meta-game mechanics into the title. After every iteration, you have a playable game.
The development team follows agile development processes with rapid iterations and considerable playtesting
The majority of development effort is put into core mechanics and meta-game mechanics.
Graphics and sounds are abstract tokens only loosely connected to a base setting.
No level design is allowed since it is a waste of time.
No plot is allowed since it is a distraction.
Statistical metrics of player addiction are used to judge success. (How long did they play, how often did they play, were they willing to play again)
This is game design refactored. The result is an agile object-oriented system that responds swiftly to change, and does not inherently resist it like current team structures. Innovation-focused teams build radically different types of game that are guaranteed to be less expensive and shockingly more original that those produced by the current game development model.
Conclusion The basic concept of 'innovation' has been discussed in vague terms for far too long. The concept of game design layers provides a framework for classifying the game developer's investment in innovation and polish oriented activities.
With hard numbers in-hand, developers can make more informed strategic business decisions regarding the balance of innovation, risk, and team structure. I believe that there is a huge opportunity in the game industry to create smaller, agile 'innovation-focused' teams. Smart game designs that are based on a deep understanding of balancing resource investment in the various game design layers have a greater probability of producing original, genre-busting game designs.
This site is about art and game design. You'll find galleries of my latest illustrations. Also, I have extensive ramblings on a wide variety of game design topics.
Why people read this site
"[...] probably the most interesting article I've ever read." Tycho from Penny Arcade on the Nintendo Innovation Strategy article
I've been a game designer, pixel artist, painter, tools designer, product manager and marketing guy. I got my first job while in college working on a shooter called Tyrian at a little company called Epic Megagames. These days, I'm designing games deep in the forests of the North West.
I remain, to this day, not a chickadee plucker. Despite the rumors.
Techniques for designing consumer scales
