The 2008 Project Horseshoe reports are up! We wrote about how to diagram multiplayer games using skill atoms. Truly a brilliant weekend. The discussion was quite wide ranging and as a result the write up became a bit...long. However, the results should spark a few brain cells. Let me know what you think! :-)
A few odds and ends have collected in my inbox lately.
Video of the Princess Saving Application is up! All the videos from the night are posted up on OfficeLabs.com. My talk starts 10 minutes into the first video and lasts approximately 30 minutes. There’s also a bit of Q &A after all the talks finish up. You can get the original slides here.
&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;a href="http://video.msn.com/?mkt=en-US&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;playlist=videoByUuids:uuids:d0cabdcc-97bc-4799-a579-4da3b73f865b&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;showPlaylist=true&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;from=msnvideo" target="_new" title="Microsoft Office Labs &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; Engineering Excellence IxDA Event Part I Daniel Cook"&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;Video: Microsoft Office Labs &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp; Engineering Excellence IxDA Event Part I Daniel Cook&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;lt;/a&amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;gt;
FishingGirl update I’ve seen some sneak peeks of the FishingGirl prototypes and people are making great progress. It will be possible for someone to win a gold medal this time around. If you’ve started a prototype, finish it! There is solid fun lurking in that design and you still have a couple of weeks left to build something wonderful.
The store and the acquisition of the various rods adds a great sense of exploration and progression to the game.
The gameplay improves substantially if you give your fish a small dash of intelligence so that they move towards your lure if it is in their sight.
Making the game winnable. There is a story arc to the game and it feels incomplete if you don't let the player finish.
Skill atoms in action Tex, over at the delightfully titled Tin Man Tex’s Slap Dang Blog, put together skill chain describing his mod. I liked how he intuitively started writing down skill atoms and then only later began connecting them together in a skill chain. Analyzing a game using skill atoms has an element of mind mapping to it that is pleasantly organic. Check it out. I hope to see more such examples in the future.
Other prototyping notes BuschnicK created a nicely fleshed out version of Play with your Peas. It is a faithful implementation of the game and deserves a very solid silver reward. However, I still think the fun hasn't been completely uncovered.
At this point, we've had some reasonable implementations of the original concept. I suspect that the design may require some big changes to make it work. So here is a question: Why isn't Play with your Peas mind-thunderingly fun and what could be done to improve it?
Last Thursday, I gave a talk on game design to the local Seattle chapter of the IxDA, an interaction design group. About 100 folks were in attendance and the catered finger food was downright delicious. Other speakers included George Amaya, who spoke about recent research on social/party games, and Mark Long, CEO of Zombie. Mark gave a lovely presentation on how narrative and storytelling immerse players. His new game looks gorgeous.
My talk was on building an application that rescued princesses. The goal was to give interaction designers some insight into how game design might be applied to the domain of more utilitarian applications. The talk was recorded and should be up sometime this week. When it appears online, I'll link to the video from this post.
Here are my slides both in PDF format and as the original PowerPoint.
The notes fields are heavily annotated with more details about each visual. For those of you who attended, this deck also includes a third section on game design patterns that I didn't have time to cover in the time allotted.
Recently I was chatting with some friends about the role of 'theme' in game design. Theme, in this discussion, was the setting of the game, be it fantasy, sci-fi, military, etc. At first blush, the typical game designer's use of theme appears a bit primitive.
Limited range compared to the wide variety of themes in movies or books. Games recycle a half dozen major themes or in some cases invent their own surrealist themes that make little sense outside the context of the game. Books, despite being grouped into narrow genres, have explored many thousands of powerful, evocative settings. You have books about bored European manuscript editors exploring the bizarre world of the pseudo occult and you have books set inside the mind of a quadriplegic. The disparity in variety is intriguing.
Crudely applied. Theme is applied in broad strokes at the beginning of many games, but almost always plays second fiddle to interesting game mechanics. Goombas are mushrooms, but this matters little beyond the fact that they are squat, match the scale of the world and can be squashed. If a novelist lazily integrated a character into their book's theme the way that game developer do on a regular basis they would never be published.
The result is that theme is often seen as an interchangable 'skin' that can be applied after the fact to a set of working game mechanics. The task is typically left to marketers to round up a popular license so that it can be painted onto the latest hot collection of game mechanics. This attitude towards theme affects the very fabric of game development.
And yet, something interesting occurs when we work this way. Very few licensed games turn into major long term franchises. They often feel incomplete and the pieces ill matched. On the other hand, seminal 'grown from scratch' games like Bejeweled, Mario, Quake, GTA or Sims end up doing amazingly well. Despite their surreal and often disjointed themes, they are surprisingly fun. In these titles, the theme of the game mechanics and the theme evolved hand-in-hand, often undergoing major switches half way through before settling into a successful partnership.
The Sims was a game about architecture that morphed into a game about playing dollhouse.
Grand Theft Auto was a cops and robbers chase game where you were the cop. It evolved into a game about being a free roaming criminal.
Quake was an Aztec style world where you tossed about a giant Thor-like hammer. It evolved into a nameless soldier battling against the mutants in a series of brown dungeons.
Bioshock was originally about Nazi's on an island.
If you start to dig into how game generate 'fun', many of these thematic transformations are, if not inveitable, certainly commonplace. It turns out that most game designers are not complete idiots when it comes to integrating theme and setting into their game designs. Designers aren't ignoring theme. They are simply using theme in a manner appropriate to the medium in which they work.
Some logic behind the madness If you look at games as being about exploratory learning, they tend to teach the player a series of skills. First the player learns basic skills (how to press a button) and overtime assemble a scaffold of skills that lets them engage in more complex scenarios like 'save the princess'. Each moment of learning gives a burst of pleasure.
These basic skills are utilized over and over again. If the player fails to learn them, the rest of the game is lost on them. Games reward involvement, yet there is a high cost the player must pay in terms of initial learning necessary to become involved.
"Theme" from this perspective, is shorthand for a collection of preexisting mental tools, skills and mental models. I think of it as a tool chest of chunked behaviors that the designer can rely upon to smooth out the initial learning curve.
The theme you select directly influences how you present your initial skills to the user. By saying "Pirates", I turn on a particular schema in the player's brain and a network of possible behaviors and likely outcomes instantaneously lights up. If they see a pirate with an impressive sword facing a small soldier, the goal of fighting the enemy is self evident. With a small visual cue, I've eliminated minutes of painful initial learning.
There is a fascinating moment in the sequence of exploratory learning where players say to themselves "Oh, I recognize and have mastered this situation already, so let me demonstrate my excellence." Because of the triggering of the theme, the challenge appears possible and attainable. If on the other hand, I had substituted the pirates with gray blob A and orange blob B, the player might be quite confused and not even bother to pick up the controller.
Why so few themes? To a certain degree this perspective on games explains the limited number of themes used in games compared to books or movies. A book uses theme as a hook to get people interested in plot and character dynamics. There are lots of potential hooks and the more unique they are, the more intrigued the reader is to find out more. This encourages a proliferation of fascinating settings.
On the other hand, a good theme in a game is one that triggers a number of clear mental models that are applicable to the game mechanics at hand. If you push too far outside the experience zone of potential players, you make them feel inadequate.
It also suggests that occasionally a literary theme simply is not needed. Sometimes it is better to just tell the player, "Hey, it is a game and like any game you've played, we'll educate you as you go." The same triggering of appropriate schema occurs. If it is enough to grease the wheels of learning, then our mission as a game designer is accomplished.
"Skinning" game designs is a bad practice When you look at game design from the 'games as learning' perspective, the idea of creating an slap-on aesthetic skin for a set of game mechanics starts to break down. In the best games, mechanics and theme evolve in lockstep over the course of the many iterations. If a mechanic isn't working, you have a couple choices. You can adjust the rules or you can adjust the feedback that the player receives. The two act in concert to produce the player's learning experience.
A good portion of the time, it makes sense to adjust the feedback side of the equation. What if people don't understand that the pirate is their character? Maybe it makes sense to make the pirate wear a right red outfit and the enemy a bit more evil looking. When you do so, the theme of the game shifts ever so slightly. Over hundreds (or thousands) of tweaks, a theme for the game might emerge that is quite different than what you originally envisioned. This is often the case for the best game in the history of our industry.
In fact, the final theme may be semi-incoherent if you attempt to analyze it as a literary work. However, that doesn't matter because it provides the moment-by-moment scaffolding of feedback that helps the player learn their way through the game. As long as the game is fun and delivers value to the customer we can often toss the literary definition of theme out the window.
In fact, you start getting into trouble when you make the theme so rigidly defined that you can't adjust the feedback for specific game mechanics. What if you are dealing with a license where the pirate isn't allowed to wear a red outfit? That design option, which may have been the best one available, is taken off the table. The hundreds of little trade offs that occur when theme coherence wins and gameplay loses diminishes the effectiveness of the game.
So you can't just 'skin' a set of game mechanics. When you do makes the attempt, a well executed iterative process of game design will often result in a game that is quite different than its source material. A poorly executed process results in a game that plays poorly.
Conclusion There are a couple lessons here.
The most effective game themes exist primarily to facilitate the learning process for the player. This may be a traditional narrative theme, but it doesn't need to be.
Theme evolves in lock step with the rules of the game over a process of many iterations. You might as well plan for it. Early on develop vertical slices of your game. This will help you converge on working combinations of theme and rules. As you go allow for iteration on production assets.
Locking in your theme too early and too rigidly can stunt the exploration of more effective feedback systems. A bit of flexibility often yields better gameplay.
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.
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 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: 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.
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'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.