Scott Blinn, Vexigon

In recent years a new set of tools for building games has emerged known as 'game grammar'.  Raph Koster, Daniel Cook, Stephane Bura and others have written and presented on these concepts in the past, but they have remained hobbled by two problems:

1. Most descriptions are highly theoretical and only considered useful to pointy headed academics or their mad inventors.
2. Game grammar appears to work best for simple, often single player games.

In a spirited discussion that spanned several intense, sleepless days our group of veteran designers sought to answer two pressing questions: 

1. Can game grammar be extended to the rich universe of multiplayer games?
2. Are skill atoms a pragmatic tool for working designers?

The following steps were taken during the discussion.

1. Overview of skill atoms: We started with a brief overview of Daniel Cook’s initial skill atom model. 
2. Analyzing existing games: From there we then went through a series of exercises applying the model to a variety of multiplayer games.  When the model failed, we revised it.  Our case studies included:
   1. Tic-tac-toe: A simple competitive starting case
   2. M.U.L.E: An example of bluffing in games.
3. Apply skill atoms to a new game design: We prototyped a new multiplayer game based off gifting and used skill atoms to guide our iteration.
4. Summary of skill atom strengths and weaknesses: In the end, we left with a revised model for describing how players learn and apply skills.  We’ve extended the initial system to work with multiplayer games, gained some insights about how it might be used, and raised questions for future exploration.  Mostly importantly we’ve expanded the discussion of this fascinating topic of game design.  

Skill atoms are a technique for modeling the player’s experience throughout the game.  The designer breaks their game down into a series of interactive loops that describe how the player learns a specific skill.  Each learning loop is known as a ‘skill atom’.  Skill atoms can be strung together in a graph to form ‘skill chains’.   You can read a much more in depth description of the model here:  Skill atom model on Lostgarden.com

The basic flow of skill atom

Skill chain composed of skill atoms.
Complex skills make use of previously mastered simpler skills.

Skill atoms model the following interactive process that occurs between the player and the game: 

1. Skills: A player possesses a mental model of how to interact with the world called a ‘skill’.  Based on their current circumstances, they attempt a skill from their current inventory.  Initially, players don’t know a skill very well.
2. Tools and Actions: The player attempts to execute the skill by using tools at their disposal.  These can be in game verbs like moving or using an item, or they can be combinations of verbs like using an item on an environmental object in a particular sequence.
3. Rules:  The game processes the player’s actions.  This could involve physics simulations, calculating resources or triggering the display of visuals.  The rules are black box simulation of how the game world actually works.
4. Stimulus:  The game responses with sound, visuals and tactile stimuli that the user consumes.
5. Loop: Finally, the player returns to the Skills portion of the loop where they process the new information and decide to continue using the skill or not.  Over multiple loops, the player gains a better understanding of the skill, eventually achieving either mastery or burnout, giving up on the skill.

The player goes through several stages of learning as they loop through the skill atoms

1. Inactive: The player has not yet attempted a skill.
2. Partial Mastery: The player has attempted the skill, but doesn’t fully understand how to execute it effectively.
3. Mastery:  The player understands the skills and feels that they can use it effectively.  At this point, the player usually experiences a moment of pleasure.
4. Chunked:  The player has used the skill enough that they don’t even think about it consciously when they use it.  When most people drive to work, they barely register all the various actions they are taking.  It is second nature.  Chunked skills can be used as elements in the mastery of more complex skills.
5. Burnout:  If a player fails to discover the utility behind a particular skill, they will stop attempting that skill.

With an understanding of the current state of the art in hand, we attempted to analyze tic-tac-toe, a simple multiplayer game.  By looking at a game with a small number of moving parts, the hope was that we could quickly identify any fundamental problems that might exist when applying skill atoms to multiplayer games.

One unique thing about multiplayer games is that another person is now part of the rules portion of the game atom. Remember that another name for the rules portion of the game is the ‘black box’, the mysterious system that the player is constantly attempting to model successfully by learning skills. In a single player game, the black box is controlled entirely by the computer.  When the player performs an action, a set of rules defined 100% by the designer, chugs along through a simulation and spits out the appropriate stimuli.

When you add another person into the rules, we’ve added to our black box a highly variable new element, not under the control of the designer.  The good news is that same basic logic applies:

• The player works on learning skills.
• These skills rely on a mental model of the rules of the world
• This model includes a prediction of how the mechanical rules work

The big addition to the basic skill atom model is a prediction of how the player’s opponent will behave.   Let’s dig into an example and then use that example to illustrate some of the additions to the model.

Basic Skill Atom Format
Here’s how we’ll write down each atom:

Name: Name of the skill atom

• Requirements: List of skills and tools that must exist for the skill atom to be activated
• Skill 1…N
• Tool 1…N
• Action: A short description of the steps the player goes through to perform the skill.
• Rules:  The game rules are acted out.  In a multiplayer game, the other player has a chance to act.
• Stimulus: What the player sees when the rules are complete.
• Stimulus 1…N
• Exit States: A list of exit states
• Failure 1…N
• Mastery

Tic-tac-toe Atoms

We started diagramming the simplest of childhood multiplayer games, tic-tac-toe.  Breaking down tic-tac-toe may seem a little bland at first, but this is the wax on / wax off portion of the essay that lets us eventually perform real game design karate.

Playing a game

• Requirements:
• Time to play
• A place to play
• Game rules
• Action: Abiding by the game rules and the rules of the magic circle. 
• Rules:  Players can communicate and change the game state using the protocols provided by the game. 
• Stimulus: The player sees that the opponent abides by the rules.
• Exit States:
• Failure:  Game is interrupted.
• Failure: The player fails to perform: he is bored, annoyed, agitated, distracted, incapacitated, he leaves, he forfeits, etc.
• Failure: The player breaks the rules of the magic circle: he throws the board away, a steals his opponent’s pencil, etc.
• Mastery: The game is played out to its conclusion

Alternating turns

• Requirements
• Deciding who goes first
• Skill: Playing a game
• Action: Players wait for their opponent to finish his move before playing themselves. 
• Rules:  -
• Stimulus: The player sees that the opponent is taking / has taken his turn.
• Exit States:
• Failure: Players play out of turn.
• Failure: Players don’t understand when it’s their turn to play.
• Mastery: Players alternate turns.

Select a square

• Requirements:
• Tool: Pencil for marking X
• Tool: 3 x 3 grid with empty spaces
• Tool: Assigning symbols (X or O) to each player
• Skill: Alternating turns
• Action: Select an empty square on the grid. 
• Rules:  You now own the square you've selected and the opponent can't select it. However they take their turn and select another square.  
• Stimulus: The player sees the opponent’s response.
• Exit States:
• Failure:  Someone wins or the board is full.
• Failure: The player fails to perform: The player is unable to make a mark.  This should only happen for very small children or those with physical disabilities.
• Mastery: The player figures out how to select a square.  (this should happen quite quickly! J)

Select a winning square

• Requirements:
• Skill: Selecting a square.
• Tool: A winning square is on the board.
• Action: Select an empty square that completes a row of three. 
• Rules:  Once you’ve completed a row of three, you’ve won the game.
• Stimulus: The player sees that they’ve completed a row of three and the face of their opponent droops. 
• Exit States:
• Failure: The player fails to perform.  They select the wrong square.
• Mastery: The player knows what a game state that leads to victory on the next turn looks like.

Blocking a threat (by playing in the last square of a line with two of the opponent’s symbols)

• Requirements:
• Skill: Select a winning square
• Action: Select the last square of a line with two of the opponent’s symbols, so that the opponent cannot play there and win on the next turn.
• Rules (Opponent reaction):  The opponent marks a square.         
• Stimulus:
• Opponent creates a threat (willfully or not).
• Exit States: A list of failure states
• Failure: The player does not recognize the threat or can’t apply this skill in the event of a double threat.
• Mastery: The player prevents the opponent from winning using simple threats.

Create a threat (by placing two in a row)

• Requirements:
• Skill: Block a threat
• Action: Select an available square that leaves one spot open in a row of three. This open spot is known as a ‘threat’ since if it is not filled the player can win the next turn.
• Rules:  The opponent marks a square.         
• Stimulus:
• A: Opponent fills in the threat square.
• B: Opponent does not fill in the threat square.
• Exit States:
• Failure (A): The opponent did not behave as predicted.  The opponent saw the threat and blocked it.  I guess they aren’t naïve after all.  Time to try something new.
• Mastery (B): The opponent behaves as predicted: The opponent didn’t fill in the threat square.  The player suspected they wouldn’t see the threat and they didn’t.

We’ve created a simple skill chain that describes four low level skills: Select a square, Select a Winning Square, Block a Threat and Create a Threat. If you were to teach a small child tic-tac-toe for the first time, you would clearly observe these skills being learned.  This is not a complete skill chain, but should suffice for the sake of this exercise.  A complete skill chain might look a bit like the following:

Tic-tac-toe skill tree:  Focuses on how skills are learned.

All rules and logic are encapsulated inside the individual skill atoms.   Skill trees are a limited, but useful ‘big picture’ tool for looking at how skills are learned and flow into one another.  They won’t tell you how to build a game or how turns are executed.

There are several new descriptors that we’ve added to the skill atom model.

• Exit Criteria:  Specific reasons why the player stops attempting a skill atom.
• Failure: Player fails to perform
• Failure: Opponent does not behave as predicted
• Mastery: Opponent does behave as predicted.
• Implicit and Explicit atoms:  The skill is reinforced by the game itself.

Exit criteria
During the Loop step, players either stop performing a particular skill or continue through the loop again.   In order to understand multiplayer interactions in more detail, we decided to break out this decision making process in more detail by explicitly defining failure states for the atom.

• Failure: If a failure state is reached, the player will break from performing the skill and attempt another skill. An example failure state might be “no obvious state change when an action is performed”.  If you press a button and nothing happens, then pressing that button is a behavior that will rapidly extinguish. 
• Continue: If a failure state is not reached, the player will continue performing the skill for an additional loop. By default, players will keep looping through a skill.
• Mastery: If a player masters the skill, they may exit the skill to look for a new skill to learn.

Failure: Player fails to perform
Select a square and Select a winning square are simple single player skills. The player is mastering the basics of changing the world state with little regard for their opponent.  It is common to find skills that concern only a single player early on in the multiplayer skill chain.

You’ll notice that there is a failure state that the two atoms share in common: “Player fails to perform.”  This was a common state that we found throughout most of the skills.  The exact details differ from skill to skill, but the general category is quite common.  We’ll be on the lookout for this state when we analyze other atoms.

Failure: Opponent does not behave as predicted
The skill atom Create a threat is the first time that the player attempts to model the behavior of another player. The following process goes on in the player’s head

• The player consults their mental model of the opponent and evaluates the board. 
• The player predicts that their opponent has not yet mastered the ability to “block a threat” skill. 
• The player chooses the skill that is most likely to give them a likely victory.
• When the action fails, the player must revise their mental model of the opponent.

Throughout all the multiplayer games we analyzed, we again and again saw the failure state “Opponent does not behave as predicted’.  This causes the player to exit the skill atom and attempt another skill.

The player’s existing mastery of the game’s skill chain places hard limits on their mental model of their opponent’s skill chain. If they are not yet aware of particular skill atoms, they are unlikely to include them in their prediction of the opponent’s behavior.  If they have not mastered the atoms, they may misinterpret the opponent’s performance of those atoms.

Mastery: Opponent behaves as predicted
We also have our first example of the mastery condition “Opponent behaves as predicted”.  The player has evidence that the opponent’s mental model fits the player’s prediction of their mental model.  When this occurs, the player feels a brief surge of joy (or despair if he predicts his defeat)

Implicit and Explicit Atoms
Lastly, our tic-tac-toe example also demonstrates two classes of atoms, implicit and explicit.  Explicit atoms are skills whose learning loop is directly supported by the game through clear rules and stimuli.  For example, the Select a Square skill results in the player’s mark appearing in a square and the opponent, in turn, responding with their own mark.  This is an explicit in game stimulus that provides the player with mastery and failure information related to the Select a Square skill.

Explicit atoms are very common in lower level game skills and single player games.  They ease the learning curve by helping players make connections early on and letting them know they are on the right track.  The downside is their cost.  Much of the budget of modern games is spent providing crisp, evocative stimuli that supports gameplay skills explicitly.

Implicit atoms are skills whose learning loop is not directly supported by the game.  The rules likely support the action, but there is nothing in the game that hints that the action was a success.  Success and mastery occurs solely in the player’s head.  Creating a threat is an example of an implicit skill.  There is no change in the board corresponding to the failure conditions that is unique to the Create a Threat atom.

Implicit skills are found throughout multiplayer games.  As the moves and countermoves build up in the player’s mental model of their opponent, many moments of mastery happen only in the player’s mind with little direct support by the game designer.  The upside of a game with many implicit skills is that they often exhibit impressive learning curves for a relatively low development cost. Consider for the moment the thousands of emergent skills involved in Go that have little direct support from the ruleset. The upside is added tactical and strategic depths. The downside is that not all players are going to master the implicit skills.

As the designer, you can convert implicit skills into explicit skills in order to ease the learning curve. Imagine a computer-based version of tic-tac-toe that highlighted threat squares automatically as the player moved their mouse over various potential squares. When a threat square glowed, a bit of text said, “Win in 1 move.”  This new feedback system gives the player major hints about how to master the skill Create a Threat. They are likely to learn the skill more quickly.  This is admittedly a trivial example, but the same process can be applied to convert most implicit skills into explicit skills. 

Now let’s move onto another example, this time involving the common multiplayer behavior of Bluffing. At the heart of Dani Buten’s classic M.U.L.E. is a small mini game in which players attempt to negotiate a price by moving their characters towards one another.  The seller appears at the top of the screen and the buyer appears at the bottom of the screen. The higher up on the screen both players are when they meet, the higher the ultimate selling price.  It is therefore in the best interest of buyer to somehow convince the seller to move lower to get a low price.

This is a classic example of negotiation between players.  Both players can signal their intent to the other player via the position of their character. However, it also opens up the possibility of bluffing where a player sends false signals in order to cause the other player to do something desirable.

Skill: Buyer bluffs by tempting the seller

• Requirements:
• Skill: Move up
• Skill: Move down
• Action: Move forward until within striking distance of the other player.  When they move forward to make a deal move back. 
• Rules:  The seller responds
• Stimulus:
• A: Seller doesn’t move forward
• B: Seller moves forward to meet the player and catches the player
• C: Seller moves forward to meet the player, but stops or moves away when the Buyer retreats
• D: Seller moves forward to meet the player and doesn’t catch Buyer and gives chase when the buyer moves away. 
• Exit:
• Failure A:  Failure to predict the seller: The seller is not behaving as expected. Perhaps they don’t want to sell or they want a higher price.
• Failure B: Failure to perform: The seller was faster on the draw and caught up with the Buyer.
• Failure C: Failure to predict seller:  Seller figure out what the buyer is attempting to do and breaks the pattern.
• Mastery D: The seller acts as expected.

Even with a bluffing situation, we see many of the same exit states that we saw in the simpler tic-tac-toe competitive example including ‘failure to perform’ and ‘failure to predict opponent’.

Though we’ve only outlined a single atom, there are a few interesting aspects of the exercise worth nothing:

• Map only what we need
• Ambiguous signaling
• Learning includes understanding of exit states

M.U.L.E. is a deep game with a vast number of skills. However, we are only interested in one very specific player skill.  Unlike some system, we only need to map out a single atom in the middle of the design in order to gain insight into how this particular mechanic works.   In practice, this is a helpful aspect of the atomic nature of the grammar.  We can start jotting down notes about a particular mechanic at almost any level of the design and examine it in isolation.  You can approach writing skill atoms much like a mind mapping exercise.  Write down the ones that seem important and organize it all later.  

Stimulus A, where the opponent stops moving, is a classic example of an ambiguous signal. Many games allow players to perform actions without fully declaring their motivations for the action.  When the player encounters such a situation, he must first identify that something isn’t right and second revise his mental model of the opponent.

When the opponent’s signal does not contain enough information for the player to accurately predict the opponent’s mental model, it is an ambiguous signal.  The player must make an informed guess in the face of high uncertainty. In effect, they are gambling with all the associated highs and lows of gambling, but no ‘unfair’ dice, just unreliable opponents.  Ambiguous signaling combined with another player’s clever free becomes a useful replacement for mechanisms of chance in social games.

In fact, trades in M.U.L.E. can be quite surprising and go against what logic alone might dictate.  This adds an important source of variability and excitement to the game.  The fact that decisions involving high uncertainty tend to engage our emotional decision making systems only adds more zing to the experience.

Bluffing in M.U.L.E. is a complex behavior involving a wide range of exit states, possible stimuli, and basic skills such as moving your character.  We find this complexity in many atoms and it points to an important lesson about learning.  True mastery of a skill not only includes demonstrations of competence.  It also includes a deep understanding of when and why to start or stop pursuing a particular skill.

In many rote learning systems, students are taught how to do a particular set of actions that often corresponds to the mastery state in the exit scenarios.  If a player were to only understand the mastery requirements, they would still fail to successfully apply the skills.   On the requirements side of the atom, they may not understand how to perform the basic skills such as moving.  On the exit side of the atom, they may not understand when to stop performing the bidding skill.

The skills atom model demonstrates how rote learning often only provides the facade of mastery, but is often of minor use in practice.  Complex skill atoms are best learned by the player exploring the various states of the atom through repeated trials of success and failure.  Only when they experience the exit states and mastery states on their own do they gain a deep understanding of the skills at hand.  Over time players develop an understanding of the risks involved in using the skill as well as it potential return on investment.

Our analysis of existing multiplayer games was interesting, but we really wanted to dig into using skill atoms to help prototype a new multiplayer game.

For our topic, we picked, Potlatch, a ceremonial gifting practice performed by the Native Americans of the Northwest.  Families hold lavish gatherings in which they demonstrate dances and give other gifts of food and drink.  The families that give the most gain the greatest status within the greater tribe.

There is some delightful meat here for a game.  Players must behave altruistically in order to win.  However, this opens them up for shortages if other players do not also gift generously.  Who you gift to results in increasing their ability to gift and in a multiplayer game a single person could rely on politics to completely out-gift others.  There are strong competitive and cooperative strategies at play.

Stephane, late one sleepless night, came up with a sketch of a Potlatch game design.  Being a gaggle of game designers, we immediately thought it would be a brilliant idea to prototype the game right there on the spot.  It turned into a lovely opportunity to apply skill atoms as a tool in a working game design.

We went through the following process when designing the game.  It can be fun to read descriptions of game designers designing ‘in the wild’, since these blow by blow accounts offer some of the best insights into how we might improve our profession.

1. The rough sketch
2. Production
3. Playtest
4. Gut analysis and crazy whiteboard action
5. Application of the skill atoms
6. Sketch of the next iteration

Most game designs start as a rough sketch.  The core idea that Stephane dreamt up was that social debt could be represented concretely by a set of debt tokens.  Everything else was a rough framework to turn the core concept into a playable game as quickly as possible.

Here’s the initial design:

• Each player was assigned a color and had four gift tokens and four debt tokens of that color.
• All players sat around a table and play preceded in sequential turns starting with a player selected at random.
• During their turn, a player can take the following actions:
• Give a gift:  Give one or more gift tokens to any players of their choice. In return, the receiving player would give the player a debt token of the receiving player’s color.
• Convert debt: Convert 3 debt tokens into one gift of their choice.
• The first player to gather up a set of 4 gifts, each of different color, wins the game. 

We gathered up a handful of toys from around the room.  For gifts, we used small plastic Indians and for debt tokens, we found some colored sticks.  The important lesson here is that we didn’t spend much time.  The whole process of ‘production’ portion of the prototype took about 2 minutes.

We gathered four people around the table and began playing.  Often you’ll find fatal errors in the design after the first couple of turns, but surprisingly, we were able to get though an entire game.  The whole process took perhaps 10 to 15 minutes.

Once the playtest was over, everyone immediately started tossing out ideas on what could be improved.  The lack of shared terminology became very apparent at this point.  Stephane and Nick both began have involved conversations that were for the most part quite parallel to one another.  Nick commandeered the whiteboard and began writing and talking frantically about how the problem needed “Two vectors!”  Periodically he would cry out “Vectors!  They must be orthogonal!”

The process was rather entertaining and quite familiar to everyone in the room.  Many designers process problems and come out with solutions by sketching out concepts and talking through designs.  The result is rapid iteration in a high feedback environment.  The problem is that for the first portion of the analysis the wild gesticulating can be quite incomprehensible to other participants.   Critical ideas are missed and it becomes difficult to accurately prioritize the next actions.

At this point in the process we stopped, took a deep breath, and agreed to go around the room.  Each person would list problem and we’d try to understand it as a break down in the skill atom model.  The issues we found in the first pass could be split into a couple of categories

• Stimulus issues:  The mechanic generally worked for a particular skill, but players weren’t gaining mastery due to inappropriate or lacking stimulus.  Stimulus issues were generally easy to fix.
• Rules issues:  There was a problem with the core black box that led the player to adopting skills that were either not enjoyable or allowed players to ignore other interesting strategies. 

Stimulus issues

• First move was not a meaningful action.  At first, it did not really matter who you gave gifts to. We may need to change initial conditions so that the different players in the game present clear value propositions to the players so that they are eased into the process of gifting. 
• Not immediately clear that win condition required four colors, not four items: This is a problem with the stimuli portion of the “Win Game” atom.  We need a clearer explanation of win condition either in the form of written instructions or something that indicates progress was being made towards collecting a set. 
• Players forgot what color they owned:  We discovered a minor skill atom “Remember your color” and realized we might need a new tool such as bin for tokens that represented your particular color. 
• It was hard to tell which player had the highest status: There was an ill formed skill atom “determine status’ that was difficult to players because there was insufficient stimulus to indicate your status in the game.  We need to create an explicit stimulus for status (i.e. scoreboard, or early reward within the game system for making the optimal move such as creating buildings that add to the village)

Rules issues

• Reimbursing debt by giving back a token of the same color = giving debt has two potential impacts on the game and the causes of those two impacts should be separate (design different impacts for providing debts of different colors)
• The “convert debt” action didn’t feel like it was providing interesting choices:  The intent converting debt was to create a strategic skill that would allow a player to cleverly horde resources of a particular type and then come from behind to win in an alternate fashion. This did not occur.   Possible solutions include removing the rule or coming up with an alternate system that makes the using the skill more meaningful.
• An optimal strategy emerged from play: Players could prevent others from winning by hoarding gifts of their colors and by gifting others with gifts of their own colors.

Overall, the skill atoms brought a large amount of clarity to the process of critiquing the prototype.  The ‘typical’ method of ad hoc brainstorming led to considerable thought, but very little concrete communication.  This has been a major problem with game design conversations for decades and it was delightful to see communication issues emerge so clearly in our prototyping exercise.

Ease of turning intuitive observations into concrete design problems:  Everyone started the critique with intuitive observations about the gameplay.  “This didn’t feel right” or “I was confused here” were common starting points.   Such comments are difficult to turn into actionable designs.   When we went through the exercise of identifying the skills associated with each problem area, it was like shining a light on the structure of the issue.   Many problems revealed themselves to be issues with transferring from one stage of the skill atom to another.  These framed the design problem much more clearly and provided a firm foundation for brainstorming of solutions.

Improved prioritizing of issues:  Due to the fact that we could frame the design problems more clearly and in many cases see simple solutions for many issues, it was much easier to determine which problems should be focused on first.   In particular, a large number of issues were simple stimuli problems that were easily fixed, but wouldn’t substantially affect the skill tree of the game.

Illumination of structural issues:  Even though skill atoms do not specifically deal with rules, they do describe the user’s experience that is derived from the rules.   As such it is possible to observe issues with the rules by mapping out the skill tree for the game.   Our prototype’s skill chain demonstrated two interesting issues: 

• The skill chain lacked numerous implicit skills.  This suggested that there wasn’t much strategy to playing the game and we weren’t getting the emergent gameplay we desired.
• Existing skill atoms had limited failure conditions:   There were few opportunities to decide to leave a particular skill atom.  This pointed to a lack of choice in the design.

The prototyping exercise gave us good insight into how to apply skill atoms in a real world environment.  Skill atoms are best used as an analytical tool to pinpoint issues with an existing game.  They are not a prescriptive design tool, but instead are a helpful addition to an existing prototyping process.  The play test is an essential the collision between the player and the black box of rules that you just threw at them.  Skill atoms are a method of illuminating and describing the experience that results.

Once you’ve performed your play test, you can follow the process below to best leverage skill atoms.

1. Identify what worked:  What seemed fun?  What worked?
2. Identify the problems in a fuzzy manner:  What didn’t feel right?  What seemed boring?
3. Write down the skill atoms associated with the issues:   Start jotting down the skill atoms associated with each item in your list, both fun activities and problem areas.   The process of giving concrete names to the skills present in your game is a clarifying design activity in its own right.  Don’t hesitate to split up or combine skill atoms
4. For problem areas, identify which skill atoms seem to be the culprits.   If there are no skill atoms, maybe you are missing some.  What should they be?
5. Write out the various pieces of a problematic skill atom:  Be sure to list out the stimuli, the requirements and the failure states since these are the most common sources of trouble.
6. Rewrite problems with reference to the skill atoms:  If you find a stimulus problem with particular skill atom, jot that down next to the issue.
7. Identify big structural issues: Often the higher priority issues will be big structural problems.  Fixing these can invalidate some of the smaller issues that you are seeing elsewhere.  Drawing out a skill chain for how various skills and resources flow into one another can be very illuminating in this situation.
8. Brainstorm targeted fixes:  Use the skill atoms to brainstorm highly targeted fixes.  If you can solve a problem by tweaking the stimuli, do that instead of rewriting game rules that may affect other skill atoms.

This is a very low cost process that can be done on any whiteboard with any group that has a basic understanding of skill atoms.   Try it and see if it gives you additional insights into your design.

Skill atoms are one of the few analytical techniques available that provide a clear, concise model of where ‘fun’ comes from in a game design.  They rest upon the scientific observation that the process of learning creates pleasure deep, aka ‘fun’, within the brain.  Games, of all types, rely upon our innate learning processes when they facilitate pleasure in a player.  This insight into the fundamental nature of games allows us to describe the practice and science of game design with a rigor that has previously not been possible.

Skill atoms have the following attributes that make them a powerful complement to existing game design techniques.

• A functional model:  Unlike the slew of disconnected elements that arises from purely deconstruction-oriented techniques like MDA, atoms describe how each element in a game interacts to produce fun. If something breaks, you can usually pinpoint the exact step in the process where something is going wrong. This helps you identify issues more crisply and with less wasted philosophizing than other methods. 
• Based on science of psychology: The model behind skill atoms is based on studies of how the human brain works.  In particular, skill atoms tightly link the concept of 'play' to well documented learning mechanisms.  This foundation makes skill atoms more testable than many purely philosophical definitions of games. 
• Atomic: Each atom stands alone. This makes analyzing complex system easier since you can focus on just the area that you need.
• Fractal: The same working model used for the lowest levels of interaction is also used for to describe higher level strategic interactions. This allows you to tackle design problems at the level of detail most suited to the task at hand.
• Specific: Unlike techniques like generalized design patterns or using blue prints of existing games, skill atoms can be specific to an individual game.  This allows you to talks clearly about the new problems present in your existing game and clearly identify exact issues.  It is also possible to call out common atoms as a method of describing patterns, but more work needs to be done here.

Skill atoms have some clear limitations

• Analytical, not generative: Skill atoms are an analytical model that helps you identify gaps in your design and talk about those gaps in a logical fashion using common vocabulary. They do not work as well as a generative model or even ‘game writing’ technique.  Game atoms are not a designer friendly replacement for writing actual code and putting working games in front of users.
• Player-centric, not state machines of game mechanics: Skill atoms model the key elements of ‘fun’ from the player’s perspective.  They are not a replacement for prototypes, state diagrams or architectural diagrams.  They are about the process the learning not playing.
• New and untested: Skill atoms are still a new model of game design.  At the time of this writing there are only a handful of published skill chains and a half dozen or so active practitioners.  Like any language of design, they gain power if more people use and understand their concepts.  It is a delight to use these concepts in a group of educated designers, but such an occasion is still quite rare. 

Though these limitations exist, practical uses of skill atoms are being uncovered with surprising rapidity. Skill atoms offer keens insights into a wide variety of interaction design that goes far beyond games alone.  As software grows ever more complex, it becomes a business imperative to produce products that have the attributes of games. The upcoming wave of consumers was raised on games and is likely to have the expectations of game players.  They want software to be more social, leverage deep skills and above all to be delightful to use.  Of all the design techniques available, skill atoms are uniquely suited to identify and pinpoint these fundamentals of gaming. We have started to mine a deep vein of game design theory that is likely to spark an entirely new generation of both design tools and products that are inspired by them.  

The skill atom model, though functional, is very much a work in progress.  The model currently straddles a delicate line between a quick and dirty method of analyzing prototypes and an all inclusive description of game dynamics.  With more detail comes the very real risk that the model stops being widely useful and instead evolves into something that is only interesting to a small number of academics.

With this risk in mind the following areas could use more work:

• Resource flows: With the addition of the requirements section of the atoms, we added a simple diagramming convention for describing how resources (such as money, experience, mana) and tools (spells, weapons, new actions) flow throughout the game.   Based off our initial investigation, this provides some lovely insights into the structure of the game design and many of the addictive loops that occur in the best games. This needs to be written up in more detail. 
• Describing how players select their next skill:   Once the player exits from a skill atom,  they must choose which skill to attempt next.   In many cases, there are clear game theory or economic tradeoffs that are made by the player.  In other cases, time pressure or uncertainty in outcomes requires players to make gut decisions on what do to next.  None of this is currently captured.    The skill tree, combined with the requirements section of the skill atom, only describes which skills are possible choices.  Victor has started exploring down this path. 
• Emotional impact of systems:  There are some fascinating hints that different steps of the skill atoms as well as different configurations of skill atoms result in predictable emotional responses.  The joy of mastery is built into the basic definition of a skill atom, but there are others like the frustration of failure, the satisfaction of execution and the sadness of losing a skill that are also present.   By understanding where emotions arise in the cycle of an interaction, designers can better tailor the emotional experience of the game. Stephane has started exploring down this path.  I like to think of it as his “Periodic Table of Systems-driven Emotions” 
• Promoting skill atoms to other designers:  Skill atoms are useful at solving communication issues if other people on the team understand the model.  An electrical engineer understands how to interpret a drawing of a NAND gate because they have been trained to understand a standardized diagramming system.  The same sort of education needs to occur within the design community with regards to skill atoms.   

The Project Horseshoe group will continue to develop and promote skill atoms and other methods of analyzing and describing game design.

• Get a more readable version of this article published in a widely read website such as Gamasutra.  The goal of this document was to capture the vast flood of concepts and ideas that were discussed  at Project Horseshoe.  However, the end result does not make for the clearest reading.   Ultimately, it would be nice to turn this document into a series of essays, each of which clearly describes an aspect of the skill atom model and how it can be applied to a practical design issue.
• Create a talk: Put together a talk on practical application of skill atoms to the prototyping process for a future GDC. 
• Continue refining the model: Continue work with one another on Grand Unified Theory of Game Design, in particular focusing on areas of future development.

We’ve covered a lot of territory in this essay and there is still quite a bit that we didn’t have time to write up.   The team also diagramed bluffing in M.U.L.E., passing the ball in American Football, and Buffing another character in an MMO.  Many additional comments are described in the Appendix. Over the course of the workshop, we made were able to clear up our major initial questions

• Skill atoms are useful for analyzing multiplayer games.  In particular, the skill atoms provide a clean method of describing a player’s mental model of their their opponents and teammates.
• Skill atoms are a pragmatic tool for everyday design situations:  Skill atoms and the skill chains provide an effective method of analyzing and deconstructing prototypes.  They reduce the cost of communication when talking about design with others who also understand the skill atom model.

In the process, we added some useful concepts to the existing skill atom model

• Exit states:   Exit states provide much clear descriptions of why players burnout on a particular atom.  By defining exit states, designers can gain useful insight into why players stop performing a particular skill.
• Requirements:   Requirements describe the necessary skills that must be learned as well as the necessary resources or tools a player needs before they can master a skill.  This addition allows designers to look at an individual atom without needing to write out the larger skill chain.
• Implicit/Explicitly rewarded atoms:  Identifying implicit skills and then changing them to explicitly rewarded skills is a very useful way of changing the difficult of a game. 
• Exit conditions in multiplayer games:  We needed to add only a couple of exit conditions around predicting opponent or teammate behavior to extend the skill atom model to multiplayer scenarios. 
• An improved description of the various stages of mastery:  The full description of the various stages of mastery let us understand how pleasure occurs during the learning cycle in a more robust fashion.

• Skill Atom models:  http://lostgarden.com/labels/skill%20chains.html
• Raph Koster’s Game Grammar work: http://www.raphkoster.com/tag/game-grammar/
• Stephane Bura’s Emotional Engineering: http://www.gamasutra.com/view/feature/3738/emotion_engineering_a_scientific_.php
• Potlatch gifting: http://en.wikipedia.org/wiki/Potlatch 
• Story of a gifting society: http://tqft.net/wiki/Maneki_Neko

Not everything fit in the main essay, so we added a series of appendixes for your additional intellectual stimulation.

• Appendix 1: Additional skill atoms structures
• Appendix 2: Improved Diagramming Techniques for Skill Atoms
• Appendix 3: Previous design techniques
• Appendix 4: Charade Atoms
• Appendix 5: Rough Notes

As we dug into diagramming atom, several other useful structures and concepts were apparent.   Think of these as expert features of a skill atom.

Anchors Atoms
(aka Maslow atoms)

Successful skill chains tend to terminate in atoms that serve fundamental human needs.  These are called anchor atoms, or Maslow atoms based of their eerie similarity to the needs found in Maslow’s hierarchy of needs.

Terminal atoms that are purely rooted in game mechanics usually aren’t very satisfying.  People figure out a particular skill and then feel cheated when it has no practical purpose.  A common example: players collect badges, but there is no purpose for the badge.  Players are utilitarian in their investment in short term goals.  If a skill doesn’t prove useful, they stop doing it.

Diagramming an anchor atom

Some common anchor atoms include

• Improved status or reputation
• Improved social bonds
• Insight into self or the world
• Improved wealth
• Relaxation
• Self improvement

You can learn important lessons about your design by identifying the anchor atoms.  For example, refer back to the tic-tac-toe skill chain.  Notice that the very end of the tic-tac-toe skill chain, Force a tie does not tie into an anchor ‘Maslow’ atom.  There are some anchor atoms associated with building relationships and demonstrating status earlier in the learning process. This perhaps explains why tic-tac-toe is enjoyable to learn, but not so much fun to master completely.

One of the side effects of this analysis is that it is very hard to come up with a game that is ‘just a game’.  Almost all good games offer some practical value.  Though they may not offer the most effective way to achieve a particular outcome, through their use of carefully calibrated skill chains, games often offer the easiest path towards satisfying a basic human need.

We’ve noticed that players have two other states that they can be in orthogonal to their learning stage:

• Unaware: The player doesn’t know that the skill is possible.
• Aware: The player realizes that a skill is possible and might have some utility.

In the initial discussion of skill atoms, the emotion of joy or ‘fun’was associated with mastery.  As we dig into the exact process of learning in more detail, we’ve found that there are in fact a variety of emotions that are triggered at various stages.  Emotions tend to appear at three points in the skill atom loop:

• The transition into partial mastery: There is a feeling of interest, and occasional dismay when the player realizes what they need to do.   I think of this as “understanding the problem.”
• The transition into mastery:  There’s an ‘aha’ emotion when the player sees how they can reach mastery.  This does not happen for all skills.  When it does there is often a sense of anticipation about being able to perform.  I think of this as “hypothesis creation.”
• The act mastery:  There is a distinct feeling of satisfaction upon performing the skill.  This rapidly fades if the skill is not useful.  I think of this as “proving the hypothesis.”

 Some skills are very deep, with long periods of partial mastery. For example ‘hitting a ball accurately in golf with a driver’.  Yet there are numerous ‘aha’ moments.  How does such a skill fit into the model?

Explaining deep skills: There are two possible ways of dealing with deep skills in this model

• Sets of implicit skills: Some deep skills are actually a set of implicit skill atoms.  Each one of those aha moments is a moment of mastery.  If you can identify the implicit skills, you could expand a deep skill atom out into a series of simpler implicit skills.  In golf there are numerous lessons one can learn about assuming the proper stance, creating the correct follow through, training muscles, etc.
• A failure to transition from mastery to chunking:  Learning is does not always move forward.  In many atoms, players repeatedly experience feelings of mastery when they validate their mental models.  However, the models can be wrong.  Or they can be inaccurate. So they revise and feel another ‘bit of pleasure’. Reaching a state of mastery does not mean the end of learning.  It simply means that at that moment, you feel like you are going in the right direction.

Games of pure chance, such as slot machines are a good example of a deep skill where players fail to transition from mastery to chunking.  The player sees a slot machine in terms of gaining skills, even though all the player is doing is pressing a single button. In many slot machines, players feel they are making progress and mastering the system.  They predict streaks and attempt to model failures.   The result is often learned habits and rituals that don't change their actual success rate, but do affect their perceived success rate.  It is still all skill learning, but the skills just happen to be highly ineffective. People are unable to accurately understand and model probabilities, so they do the best that they can.

You’ll often see sequences like

1. Mastery: “Oh, I think I’ve figured it out!”
2. Return to Partial Mastery: “Uh, nope.” 
3. Mastery: “Oh, but I’ve got it this time!”  However, Chunking never occurs, so you are stuck wandering about a single skill atom.

The best systems will often give feedback that makes players feel like they are making progress towards these false skills.  The use of streaks (that end unexpectedly), the use of red herrings (that cause people to make false correlations with their chance of winning), the use of intense stimuli to signify importance (where there is none)...all these things encourage the formation of players skills, at least in the mind of the player.  Which ultimately is all that matters since it is this complex mental model that encourages them to keep pressing the button.

While it is important to model the probabilities in a game of chance, it is equally important to get into the head of the player and find out what skills they think they are applying.  By building feedback around these imagined skills, you can make encourage players to continue playing.

Appendix 2: Improved Diagramming Techniques for Skill Atoms

Showing Tools and Resources in skill chains

In the requirements section of each skill atom, we list other skills and tools or resources that are needed by the player in order to master the skill.  You can leave these elements embedded in the skill atoms, but occasionally it is useful to show them as part of a skill chain.

Let’s look at a common situation.  Suppose that a player uses a ‘sword’ tool as part of a skill called kill monster with weapon.   What happens when I get a new +2 sword, a simple tool change in the game rules?

Solution A:  More skills: The easy solution is to create an additional skill atom “Kill monster with +2 sword.”   This has some benefits since it deals well with practical side effects of getting a new weapon.  I can kill monsters faster; take on new monsters, etc.

As a solution it bugs me. 

• You aren’t really learning any new skills. You are still doing the same thing, but in a more efficient fashion. 
• Nor are you improving your existing mental skills so you aren’t really advancing through the learning stages for the skill.  We’ve only improved a tool, not changed the player’s behavior.
• Visually, separate skill atoms become messy to diagram.   For each weapon increase in power, you have a new skill atom and your diagram becomes bloated.  

Solution B: Effectiveness:  Here is a proposal…add an attribute to an atom called Effectiveness.  In addition to learning state which describes the player’s mental understanding of a skill (and lives almost exclusively in the ‘skills’ section of the atom), we add another variable which is ‘effectiveness’.   This lives in the ‘tools and actions’ section of the atom.  It can be increased through better physical performance or through the use virtual items such as +2 swords.

The interesting outcome here is that you can improve effectiveness independent of your skill.   This shouldn’t be a problem since the player’s execution of the skill is still gated on their progression through the learning stages.   It is the rough equivalent of giving a newbie a very powerful weapon, but still they get slaughtered because they don’t know how to use it.

Example of a tool improving the efficiency of a skill as diagrammed in a skill chain

• Show a tool that improves effectiveness as a rounded rectangle on the skill tree:  Tools can be the result of mastering a skill or they can be something that occurs as a natural part of the game.
• Use solid arrows to show necessary skills: A solid line with an arrow denotes that the source tool is necessary for the execution of the target skill.  So tools feed into skills as part of their requirements. Arrows are a must because if you don’t have them, you can’t tell how the player’s learning progresses along the skill chain.
• The graph of solid lines is always acyclic.  This means that you never create infinite loops where it is required that you must learn Skill A in order to learn Skill B in order to learn Skill B.
• Use dotted arrows to show skills that change effectiveness: A dotted line with an arrow denotes that the source skill improves the execution of target skill.
• Put a Plus sign next to an arrow that improves effectiveness
• Put a Minus sign next to an arrow that reduces effectiveness.

It works for resources too: It is important to note that resources can be diagrammed as ‘tool’ objects as well.  You can easily show the flow of points, currency, ore or other resources in relation to player skills. This system gives us an easy method of the flow of resources throughout the player experience.

For some games where using the right tools is part of the challenge, effectiveness might not be enough since it’s a game design perspective. For instance, if the player gains effectiveness by equipping a dragon-slaying sword before fighting a dragon, Adjusting gear to suit challenge is probably a skill in the game, as could be Recognizing challenge type.

In games that offer choices in strategy of puzzle-like challenges, this idea can be extended to the concept of using the appropriate skill at the right time, introducing meta-skills like Pick appropriate tactics or Evaluate strategy.

These tool-based skills and meta-skills are probably the ones that can be transferred from one game to another the most easily.

Visualizing skill chains as a graph are great if you have a white board or a graphical diagramming tool.  However, sometimes you’d like to describe skill chains using text alone.  Victor Jimenez created such a method.   The basic format involves writing down higher level skill and then listing the skills that are requirements of that skill. 

• Turn: Select Square | Declare Win | Declare Loss | Declare Tie
• Select Square: Create Threat | Block Threat
• Create Threat: Single Threat | Double Threat
• Block Threat: Block Single Threat | Block Double Threat
Appendix 3: Previous design techniques

A bit of history is perhaps useful for understanding the landscape of game design tools: how did we get to game grammar and why is it worth looking at? The theoretical tools available to build games have grown greatly in the past decade.  There are several major utilitarian methods of analysis used in the game industry.  Game atoms serve as an additional type of analysis that seeks to improve upon some of the shortcomings of the previous efforts.

It is worth noting that is a very incomplete list.  Books like The Art of Game Design: A Book of Lenses or Rules of Play survey dozens of design tools used throughout the ages.  The approach taken is to give the designer as many tools as humanly possible in the hope that they will find a few that stick.  The result is a tool chest full of unrelated piecemeal solutions that do not offer a unified functional model for understanding game design flaws.  For this reason (and for the sake of brevity) I’ve left them out of this particular discussion.

Iteration driven by an intuitive designer

The most widely practiced method of analyzing games involves first building the game, playing the game or watching it be played, and reacting to issues that are revealed.  A game designer, ideally with vast amounts of experience building games, relies on their intuition and accumulated wisdom to predict what changes need to be made in the next iteration.  This process works quite well and has produced the greatest games in the history of our industry. 

Unfortunately, it has some limitations.  First, each designer (and there may be many working on the project) will often speak their own unique design language that has evolved over many years of intensely personal experiences.  Different concepts will have different names and complex interactions are often best described as "I know it when I see it".   As teams increase in size, this can lead to substantial communication issues.

The other problem is that intuitive knowledge is often difficult to generalize across different game genres.  The result is that you end up with designers who are very experienced in a particular genre (such as FPS titles) but are unable to create original designs in other genres.  Or for that matter create original genres.  There is a distinct inability to design from first principles that leads to creative stagnation. 

Deconstruction into component elements

The next technique that emerged was terminology that allowed designers to break games down into recognizable pieces.  A commonly referenced example of deconstructive analysis is MDA (Mechanics, Dynamics, and Aesthetics) where elements of the game are classified according to tokens, interactions, or 'paint' that makes these pieces pretty.  The creation of a standardized vocabulary seeks to solve the communication problem inherent the typical iterative design process.  

Deconstruction also runs into some serious issues in practice.  You end up with a set of disconnected elements.  For example, if you use Chris Crawford's definition of a 'verb', you can readily identify the actions that the player can take, but knowing this tells you very little about whether or not those actions are fun.  Or if they are not fun, why aren't they fun?

Patterns

Another popular technique tackles the problem of fun, the core value proposition of our industry, head on.  Patterns of game design, similar to patterns in programming, seek to identify successful sets of mechanics that are proven to exhibit ‘fun’ and then apply them to future games.

In their simplest form, designers use patterns by pointing to an existing game and telling the team that they are going to make something similar. A more generalized pattern might include a leveling system in an RPG.  The idea is that this pattern can be lifted wholesale and applied to another game to achieve a similar result.  The game Bookworm Adventures successfully applies the leveling pattern to a traditional word game with good results.  There is at least one book of generalized game design patterns and most designers have numerous informal patterns that they rely upon. 

The problem here is that only rarely can you apply a pattern directly to a new game.  Games, by their very nature, generate complex emergent possibility spaces.  The exact interactions of the rules tend to produce unique edge cases that are rarely the same from game to game.  As such, an immense amount of effort goes into adapting and evolving a pattern to a particular game.  In the end, patterns are useful brainstorming tools for big, structural design issues, but they aren't very helpful during the day-to-day process of iterating and polishing a design.  At their worst they can blind teams.  Instead of exploring unique solutions tailored to their specific game, teams spend their precious time shoe horning their game into an ill chosen pattern.

Play Styles

Our last major technique involves surveying actual players and attempting to understand how they play and what they desire when they play.  This psychological approach is very promising and includes a rich body of work ranging from Nicole Lazzaro’s Four Types of Fun, to Richard Bartle’s Bartle types to Chris Bateman’s work on play styles.

Play styles give great insight into how players approach play as well as their basic motivations.  It can help designers make a rough prediction about the appeal of a particular system to a particular audience.   However, it is often frustratingly difficult to apply play styles to specific issues in an existing design.  Ultimately, play styles run into many of the same pros and cons as patterns.

Other miscellaneous techniques

There are a variety of other common game analysis techniques that offer insight into games, but have not proven themselves to be pragmatic design tools. I’ll list these in passing.

• Philosophical systems:  There is a wide variety of intellectually stimulating work that seeks to understand how game fit into various philosophical frameworks.  Unfortunately, due to their abstract nature, such endeavors rarely provide practical guidance for building games.
• Game criticism: There is also a wide ranging critique of games that seeks to tie games into a broader discussion of media and culture.  Much like literary, art or movie criticism, the point is to spark interesting discussion, entertain or explore a particular player’s experience.  It is rarely about improving the game.  The game becomes a cultural artifact atop which is layered a message or theme of the writer’s choosing.  In a designer’s mind, it is not usually fruitful to consider a game as a finished sacred artifact.
Appendix 4: Charade Atoms

The following is an example of a cooperative game analyzed with skill atoms.  We worked through a variety of such examples over the weekend, but this was one that made it into writing.  It offered no unique insights and so was relegated to the Appendix.

Charades is a game in which a player known as the ‘actor’ attempts to act out a word silently and another set of players called ‘guessers’ attempt to guess the word.  It is a cooperative game that is all about non-verbal communication. We analyzed an atom from the perspective of the actor.

Actor acts out phrase

• Requirements:
• Skill: Actor recognizes the phrase
• Skill: Actor
• Skill: Acting ability
• Action: Act out the situation that is clearly related in the minds of the Guesser to the phrase.  
• Rules:  Act until you get feedback from the audience.
• Stimulus:
• A: Guessers don’t understand and ask for more information
• B: Guessers misinterpret the acting and guess the wrong thing
• C: Guessers guess something highly related to the phrase.
• D: Guessers guess the correct answer.
• Exit:
• Failure (A,B): The player fails to perform.  The actor interprets stimulus A and B as if they are not acting out the situation correctly.  They may redouble their efforts.
• Failure (A, B) The team mates fail to perform.  The actor interprets stimulus A and B as a failure on the part of the guessers to understand and make the right connections.
• Mastery (C):  Teammates perform:  
• Mastery (D): The player wins!
Appendix 5: Rough Notes

The following are rough notes from the weekend.  Any editor worth their salt would have removed this section in a heartbeat. [editor's note: I am not worth my salt]

How does AI figure in this?

We turn on a very specific part of the brain when we are interacting with human beings. We start modeling human before if we detect a human. When we interact with a system we execute a Turing test. If we don’t detect a human, we start problem solving.

Games considered for analysis

Tic Tac Toe, basketball, Diplomacy, Risk, poker, Settlers, Mario Kart, Stratego, LOTR board games, Quake, Hide & Go Seek, Battle Tetris, Splinter Cell, D&D, Pac Man VS, Giant Citizen Kabuto, Tag, Mornington Crescent/Rock-Paper-Scissors, Nomic

Common social behaviors that were considered
• Enforcing the fantasy/in-game social norms
• Negotiation
• Influence
• Bluffing
• Bidding in auction games
• One vs Many
• Covert vs overt action (hiding/communicating available information)
• Team vs environment
• Asymmetrical roles
• Gaming the game/metagame
• Gifting & reciprocation
• Differing levels of knowledge among players
• Acting emotionally
• Anticipating others' actions/guessing other peoples' minds
Design techniques for improving a player’s ability to anticipate the other player’s state
• Audio cues
• Musical moods
• Physical posture or representation
• Facial expressions
• Chat
• Gestures,
• Establishing threshold values for what "tells" to show and when in the game design
Clarke vs the Skill Atoms

Any sufficiently advanced technology is indistinguishable from yet another mundane bit of our perplexing natural world.   I witness people interacting with new and unexpected technology on a regular basis. Never once have I seen a player encounter a massively complex bit of technology that they didn’t understand and claim that it is magic.

Instead, if it doesn’t immediately work as expected, they assume it is broken.  If it works, they treat it as a natural law like a hammer hitting a nail.  If it has mildly complex behavior, they treat is like a puppy.  Soon enough, most well balanced human beings will see an amazing new thing as part of the natural way of the world.  We see the world through the lens of our existing mental models.  Things that exist outside that model are met with standard biological responses of frustration or ignorance, not awe.   It is only when we start to comprehend the intricate workings behind the technology do we experience moments of magical surprise.

Since games are about learning the intricacies of complex systems, they are an ideal medium for generating such moments.

How skill atom states map onto existing learning theory
• Unaware and not competent = not attempted:  Skills you don’t even know exist.
• Aware and not competent = partial mastery: Skills that you know exist, but don’t quite know how to perform.
• Aware and competent = mastery:  Skills that you’ve recently mastered.  There’s a joy about using them.
• Unaware and competent = chunked:  Skills that you use without even thinking about them. 

section 5

next section

select a section:
1. Introduction  2. Speakers  3. Executive Summary  
4. Concept Sketches for Game Design: Best Practices for Prototyping within the Game Industry
5. Multiplayer Game Atoms
6. Game Designer as Artist
7. Please, Let Me Play the Game I Bought
8. The Gaming Date
9. Dramatic Choices
10. Game Designer's Bookshelf
11. Project Unity
12. Schedule & Sponsors