|The Third Annual Game Design
Project Horseshoe 2008
Group Report: Multiplayer Game Atoms
Scott Blinn, Vexigon
|Scott Brodie, Microsoft|
|Stephane Bura||Daniel Cook, Microsoft|
|Nicholas Fortugno, Rebel Monkey||Victor Jimenez|
|Facilitator: Kathy Schoback, Think Services|
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:
In a spirited discussion that spanned several intense, sleepless days our group of veteran designers sought to answer two pressing questions:
The following steps were taken during the discussion.
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
Skill atoms model the following interactive process that occurs between the player and the game:
The player goes through several stages of learning as they loop through the skill atoms
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 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
Name: Name of the skill atom
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
Select a square
Select a winning square
Blocking a threat (by playing in the last square of a line with two of the opponent’s symbols)
Create a threat (by placing two in a row)
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 chain
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.Tic-tac-toe Analysis
There are several new descriptors that we’ve added to the skill atom model.
Failure: Player fails to perform
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
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
Implicit and Explicit Atoms
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.M.U.L.E multiplayer trading: an example of Bluffing
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.M.U.L.E. Skill atoms
Skill: Buyer bluffs by tempting the seller
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:
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.Ambiguous signaling
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.True learning includes understanding of exit states and basic skills
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.Part 3: Using skill atoms as a tool to help prototype a game
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.The Process
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.
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:
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.3. Playtest
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.4. Gut analysis and crazy whiteboard action
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.5. Application of the skill atoms
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
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 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.
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.Part 4: Why skill atoms are interesting
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.
Skill atoms have some clear limitations
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.Areas of future development
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:
The Project Horseshoe group will continue to develop and promote skill atoms and other methods of analyzing and describing game design.
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
In the process, we added some useful concepts to the existing skill atom model
Not everything fit in the main essay, so we added a series of appendixes for your additional intellectual stimulation.
As we dug into diagramming atom, several other useful structures and concepts were apparent. Think of these as expert features of a skill atom.
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.
Some common anchor atoms include
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.Skill atom: Aware or Unaware
We’ve noticed that players have two other states that they can be in orthogonal to their learning stage:
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:
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
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
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.
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.
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.Diagramming “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.Alternative: Tool-Based Skills and Meta-Skills
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.Victor’s Streamlined Skill Chains
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.
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.
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.
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.
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.
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
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, NomicCommon social behaviors that were considered
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
select a section:
Copyright 2000-2014, Fat Labs, Inc., ALL RIGHTS RESERVED