Friday, December 29, 2006

Escapist article on 'Boutique MMORPG'

Allen Varney over at the Escapist just posted an interesting follow up article to my Lessons from Touring Band essay. He provides some solid number and lots of wonderful examples of village games. You can read it here.

A hundred petri dishes
I'm impressed that Allen tracked down so many great examples. One thing that I noted was the fragmented nature of the market. This market is nothing like the mainstream world (aka WoW land) where you have a unified gamer press all discussing the same game. Every month that passes, I end up hearing about new titles that had existed for years, but for some reason I had never heard about. This delights me and give me great hope.

Market consolidation generally leads to the emergence of standardized product offerings. Niche games targeted at niche audiences are like a hundred petri dishes, each brewing their own particular gameplay potion.

Such companies may not create the over the top productions that you find in AAA titles, but they can prove beyond a shadow of a doubt that that new mechanics, new social systems and new business models work. Think of village game companies as a vast network of diligent prototypers. These working examples do far more to get big, risk averse money flowing (albeit slowly) towards new ventures than the most well reasoned pitch docs.

The reward? Many of the folks running these boutique shops do quite well. That also delights me.

Village games learn the lesson of casual games
The ease of use is also starting to improve as we see the 'pick up and play' philosophies of casual games applied to the traditionally dense MMORPG genre. I stopped by the Sherwood Forest game and was presented with a single link. Instead of jumping to the website that explained how I might, if I wanted, think about talking about trying the game, I was dumped immediately into the game world. Boom, I give a name, pick an avatar and I'm off slaying monsters.

I'd love to see this 30 second rule applied to more games. I should be playing and enjoying the game within 30 seconds of hitting the link. No fiddling with controls, waiting on loading or download screens. Portable games do it. Flash games do it. So should online games.

take care

Wednesday, December 27, 2006

The Wii Help Cat: A lesson in interaction design

The Nintendo Wii has an inexplicably complex help system. A cat wanders onto the screen periodically. If you move your cursor quickly towards the cat, he'll run away. However, if you are careful, you can sneak your cursor up on the cat, your cursor will turn into a hand and you can grab him. When you do, you get a tip about how to use the Wii dashboard.

From a simple efficiency driven point of view, this is a baroque UI that makes very little sense. Surely, just putting up a hint button that says "hint!" would have been more efficient and discoverable. This is what most programs do.

Yet, we know from long experience that no one ever reads the hints. Designers often resort to placing the hint dialog at the startup of the application so that the user is forced to jump through the hoop of reading one hint every time. Most people immediately turn this 'feature' off after using it once. Some users find it highly irritating and form the opinion that the developer is punishing them for using the product. They complain to their friends and write pissy rants to the help desk about why your product is horribly difficult to use. This is not the way to build a viral buzz.

The Help Cat uses traditional game mechanics to help acclimate the first time Wii user to the new controller and the dashboard. In the process, it provides an interesting test case on how game mechanics can be used help users master new functionality.

I've broken down the Help Cat user experience in several levels of mastery. At each level, you'll see the user happen upon new information and adapt their behavior accordingly. I'm using my atomic game mechanics system from a previous post as a framework for identifying the various steps in the process.

This admittedly gets a tad anal retentive, but bear with me. It is a good exercise in analyzing a user interaction and understanding what works and where it can be improved.

Level 1: Passive interaction
  • Action: User looks at screen for X amount of time
  • Blackbox: Cat simulation runs
  • Feedback: A cat walks onto the screen.
  • Mastery: The user realizes it is a cat and activates their known tools for interacting with the cat. There is a small burst of delight often in the form of "Holy duck boot! It's a cat"
Level 2: Active interaction
  • Action: The user moves their cursor in the direction of the cat
  • Blackbox: Cat simulation runs
  • Feedback: The cat runs away from the cursor.
  • Mastery: Wow! It acts a lot like a cat. The user becomes aware that the speed and location of their cursor is important to interacting with the cat and begins consciously practicing mastery of these basic tools. They form an initial mental model of how the cat behaves. This too is delightful.
Level 3: Improving skills
At this point the user is engaged and will often attempt to experimentally validate their mental model.
  • Action: The user begins varying the speed at which they approach the cat. This quickly become a case of seeing how close they can get to the cat before it runs away.
  • Blackbox: Cat simulation runs
  • Feedback: The cat runs away from the hand. However, if the cursor touches the cat it turns into a hand.
  • Mastery: The user has accidentally stumbled upon a new clue. The hand again is a symbol that taps into pre-existing conceptual tools. The user understands that they can use the hand to grab objects. This also ties into their knowledge that cats are an object you can pick up. A new goal suggests itself and there is a small burst of delight.
Level 4: Completion
Experimentation continues with the goal now being to catch the cat.
  • Action: The user exercises the tools from the previous stages of mastery. They move the cursor at the right speed towards the cat and attempt to get the hand to appear. They test out their new model of how the hand works by clicking frantically on the cat. .
  • Blackbox: Cat simulation runs
  • Feedback: When you successfully click on the cat, the help box appears
  • Mastery: The user realizes the purpose behind the cat. There is a large burst of joy as all the clues finally click into place and the pattern of clicking on the cat to get help is chunked in the player's mind. They read the tip and realize that there are likely more tips if they catch the cat again.

Benefits of the Help Cat
We end up with a variety of benefits from this less efficient, but more enjoyable interaction design. Each of these benefits goes beyond utilitarian expectations of a traditional hint feature.
  • Users actively attempts to 'collect' help tips. The process of gathering them is enjoyable so it isn't really work to learn more about the product.
  • Users also build critical skills in using the new control mechanism. All that pointing and clicking builds up muscle memory skills that make the process of using the Wii more enjoyable overall.
  • Lastly, the user is left with a positive product experience. They are delighted and are much more likely to promote the product to their friends.

Future improvements
As far as it goes, the help cat is pretty nifty. However, the help cat was likely added as a minor bonus feature and as such, has limited functionality. It is easy to imagine additional game mechanics that increase the usability, enjoyment and addictiveness of the help system.
  • Tuning difficulty levels
  • User achievement tracking
  • Virtual pet rewards
Tuning difficulty levels
Not everyone likes the Help Cat, mostly they can't figure it out. Anytime you create a black box that a percentage of users cannot decipher, you'll often find frustration and irritation. Users who find a problem too difficult will assume that it is broken. Users rarely blame themselves for failure.

For some, the help cat moves too quickly at first. Or perhaps people don't make the leap that they are supposed to click on it. Or they hate cats and couldn't imagine wanting to touch one. Since the help cat leverages existing cognitive tools in order to kickstart the mastery sequence, the limitations of your users can ruin even the most 'intuitive' design.

The fix is to test user response in order to establish typical responses. Tune the difficulty so that you make most people happy and able to master the sequence. Then set up boundary conditions that trigger more explicit instructions for the slower users. For example, if the Help Cat has run away multiple times but the user has not reacted, put up text that says "Click the help cat."

You need to be careful here. If you make the feedback too obvious, users won't experience the joy of mastering the blackbox.

User achievement tracking

Mastery typically occurs through practice of a gesture. Far too often, users glances through the help and then never actually performs the suggested actions. By tracking new UI gestures as goals and rewarding the user when they complete those goals, you dramatically increase the likelihood that users will experience the full range of the interface's functionality.

Each hint that the Help Cat gives represents an additional skill that for the user to master. As they meander through the rest of the UI, the existences of the goals acts as a strong reminder to try out the skills. The system can detect and record this practice. Every time you visit the help cat, he can give you additional stats on your progress and may even reward you with additional functionality.

A big benefit to this system is that it is completely non-linear. Users don't feel constrained to slog through a linear tutorial. They can cherry pick the new skills that sound interesting. They are also rewarded for personal exploration. If you happen to discovery skills on your own, the help cat will notice and reward you for the completed quests.

A secondary benefit is that once you get achievement tracking in place, you can easily hook it up to a logging system to gain a better understanding of what skills are being mastered and which ones are not. This can lead to more focused usability testing that improves your overall product.

Virtual Pet rewards
Catching the cat to get a clue is interesting at first, but users quickly burn out on this simplistic game mechanic. You can improve usability and increase player addiction by making the cat become the user's friend. You can tap into the user's deep set of existing social tools with some well chosen feedback. The result is a strongly positive user experience for very little effort.
  • With continued usage of the Help Cat, decrease the response time when the cat runs away. Eventually, make it bounce excitedly when it sees your cursor.
  • When the cursor is over the cat, have the cat purr and rub up against the cursor.
  • After more use, when the cursor is moved over the cat, trigger various petting animations.
  • Explicitly reward goal completion with avatar items that appear on the cat and new playful animations.
These are all straight forward mechanics that require little effort to implement. However, they create strong positive feelings in the user. They can tell a little story to their friends of how they tamed the Help Cat and it is now their beloved pet. I wouldn't be surprised if there sprung up Help Cat fan sites in response. Contrast the warm and loving Help Cat to Clippy, an intrusive alien character that forced information on users. If you want the user to master an action, dangling a carrot (or in this case, a cute fuzzy cat) works much better than a hitting the user with a stick.

From a game design point of view, what we've done is cap the user's advancement along the mastery curve with an 'unwinnable' social mechanism. Such evergreen rewards like a purring cat have a much lower chance of burnout than internal rewards based off points and goals. We can only afford to put a limited amount of content into a mastery sequence, but we don't want to leave the user feeling that they've expended all this effort only to reach a meaningless dead end.

The other benefit of this mechanic is that the Help Cat becomes easier to use. Instead of chasing it around the screen, you simply click on it.

Closing thoughts
The Help Cat is a simple interaction design, but it brings out a universally applicable pattern of user behavior
  • The user performs an action
  • While performing an action, they stumble upon evidence that a modification of their behavior may have better results. At this point, they experience joy.
  • The cycle repeats
We can design explicitly for this learning cycle through careful placement of feedback and tracking of user progress. Users learn the product more quickly and they are rewarded with a continuous stream of positive feedback.

take care

Mastery-based interaction design

Atomic Game Mechanics

Help Cat video
Here's the source of the delightful Help Cat video that was the source of this post.

Sunday, December 10, 2006

Building fun into your software designs

I've been thinking lately about how game design applies to the broader topic of software development. Game design is all about creating pleasurable learning experiences and mastery of conceptual tools. Surely more traditional software could benefit from the design wisdom and theory that we've built up over the years in the game industry.

The current state of the art technique for user experience design is the scenario-driven development. It isn't all that good at creating pleasurable software, but it provides a good foundation for the discussion. Scenario-driven design typically involves the following activities:
  • Create a list of common user tasks called scenarios.
  • The development team builds a set of features that enable the user to complete those tasks.
  • You can then run some representative users through the scenarios to see if they can use the features to complete the tasks. If not, you improve your UI. If the tasks are readily completed, then you have a competent product.
This is a big improvement over the older practice of feature-driven development, where developers build the features that they desire and then pray that the users will like them. Well executed scenario- driven development results in eminently functional software from which most major annoyances have been stripped away.

It is not a perfect methodology. A good example of scenario-driven development’s failings is the much maligned wizard. By laying out the tasks of a scenario in a linear order, you satisfy all the constraints of traditional user experience testing. A wizard is easily testable, has great completion rates and is highly intuitive for new users. It also happens to be dreadfully dull, painful for advanced users and quite ill suited to taking on tasks outside the defined scenario.

There are three important questions that scenario-driven design has difficulty answering
  • How to you build a fun experience? Scenario driven design has no concept of user pleasure. It looks for problems to be solved, not pleasure to be given. Yet users obviously react strongly to the sheen on the buttons in OS X. Emotionally evocative feedback matters.
  • How do you deal with the issue of mastery? In the scenario driven world, the ideal program has no learning curve. Yet expert users obviously exist and they can perform miracles with the right tool.
  • How do you deal with the issue of flexibility? Scenario driven design is only as good as the scenarios you consider. Especially in a product where expert use occurs, there will be new scenarios acted out by users that you could never imagine.

Borrowing some lessons from game design
Mastery-driven design is a refinement of pure scenario model that borrows heavily from modern game design. It brings into play two concepts:
  • There is a learning curve on every piece of software. This can be a source of great user pleasure and is a critical part of bringing new users onboard.
  • As the user progresses along the learning curve, they master a set of conceptual tools that can be used to efficiently solve tasks.
Mastery-driven design goes something like this:
  • Scenario creation: You start out with a list of projected user scenarios as before.
  • Tool definition: The development team prototypes a set of tools that the user will need to complete the scenarios. Each tool performs a set of useful actions. A next button might take you to the next page. A pen tool might allow you to draw a complicated line on the screen.
  • Feedback systems: For each tool, the team creates feedback systems in the form of rewards and punishment to encourage rapid and pleasurable user progress towards tool mastery. These are essentially the atomic game mechanics that I’ve described in an earlier essay.
  • Task completion tracking: Testing tracks the traditional task completion.
  • Mastery tracking: In addition to tracking task completion, testing tracks tool mastery. In order for a product to be considered complete, users must not only complete the task, but they must demonstrate mastery of the toolset. For example, after a user has used the pen tool once, they are given a different test with the pen tool. In such a mastery test, it is expected that they should complete that task in 1/10th the time due to their expert knowledge of the tool. With such tests, you can gain information on which tools are easily mastered and which tools are not. By testing the same tools across a variety of skill levels and scenarios, you build flexibility into your toolset.
  • Pleasure tracking: User pleasure in the learning activities is measured as well. You can survey users after each scenario and you can watch for their pleasure and pain during the tests. You can also track dropout rates by finding out when people stop using the tool and at what levels of mastery.
Once you’ve performed these steps, you record your feedback, figure out where you can improve on the various metrics and run through the cycle again. Over several iterations, you’ll converge on a product that is easy and enjoyable to learn and that provides great efficiency and flexibility to expert users. You also generate user lock in since newly learned skills are difficult to transfer.

A dash of theory

It is common to hear the term 'intuitive interfaces' bandied about, unfortunately with very little understanding of what it means. Often the popular interpretation of 'intuitive' results in a reductionist approach that serves the lowest common denominator. By bringing the concept of mastery into the picture, we gain a much stronger understanding of why one person may find a design perfect, another may find it complex and a third might find it insulting.

Intuition is something you can build in your users: What we consider an intuitive design is typically a design that leverages years of learned behavior and funnels it toward a new use. Humans live to grok new conceptual tools and then use that knowledge subconsciously to solve new problems. As interaction designers, explicitly tapping into this learning process helps us make better software. No only can we tap into users existing learned behavior, we can actively train users to see our software as intuitive.

Why mastery matters to interaction design: Most of the highly effective interaction design we use today has a strong component of mastery. Typing, for example, requires months, if not years of learning before users become competent experts. Yet, it has become a foundational toolset that makes almost every software task around more efficient. If we avoid the creation of tools that require mastery, we immediately filter out some of the most potent and effective designs. To compete with powerful features that dramatically improve your users' lives, you'll need to create tools that require mastery. Least common denominator design isn't enough.

Mastery is an opportunity, not a barrier: The traditional barrier to selling tools that require mastery is that when people don’t know how to use a tool, they’ll often give up on the product completely. The solution is to build the process of mastery into our product designs. as if it were a game. By providing hints, rewards, goals and other elements taking from game design, we can rapidly build mastery in our users. There exists a rich set of game design techniques beginning with rapid prototyping and including play testing, design testing and more

There is a surprising side effect to incorporating learning into interaction design. The initial user experience actually becomes more enjoyable. Our brains are flooded with a wash of pleasure when we grok a useful conceptual tool. By building software that encourages tool mastery through risk/reward feedback mechanism, we can create a mild, but highly effective psychological addiction within new users. We build delight directly into our software.


Slowly, but surely, we are integrating more of user psychology into the development and design of software. At each stage we’ve added something new.
  • Stage 1 - Functional Software: How do we make something?
  • Stage 2 - Utilitarian Software: ‘How do we make something useful and easy to use?
  • Stage 3 - Pleasurable Software: ‘How do we make enjoyable to learn and powerful for experts?’
It is my deeply held belief that game design will become an important player in all future software development. The lessons it teaches us about pleasure, mastery, feedback and the application conceptual tools to problem solving are applicable across the broadest range of interaction design.

Food for thought,

What are game mechanics?
A discussion of a feedback based game mechanics model that is useful in execution of mastery-driven design.

Games are food for infovores
A brief discussion on how groking results pleasure.

Games design mechanics used in common websites
Andrew Chen forwarded me this nice overview of simple game systems applied to popular websites.

Monday, December 4, 2006

Sprawl: The world's first public Silverlight game

A little casual game design of mine called Sprawl finally made it out into the big wide world. I started building the graphics and brainstorming on the concept after playing an elegant board game called Hey, That's My Fish at Project Horseshoe.

Pete, my old compatriot from Anark, was looking for a game design concept to turn into sample game for the Microsoft WPF/E samples they launched this Monday. He actually made it work with AI and everything. WPF/E (aka Silverlight) is a lovely little web platform that Microsoft announced last year. It is in the early stages, but I have high hopes. I've also been working with Harold on a sexy DirectX version, but since he is building his uber engine from scratch, it isn't quite yet ready to share.

The game is a simple turn-based strategy game involving the capture of resources and the containment of enemies. If the response is good enough (and the programmer willing), there are quite a few more features I'd like to add.
Whoever beats every level gets a cookie. It is very possible to win, just incredibly hard.

take care

PS: Most of the game graphics were created in another product I'm designing called Expression Design. I'll try to post the source files for the artwork at some point on the site. I don't tend to talk about work too much on my blog, but there is a trial available.

Edit: Noted that the player does in fact run nicely on both Firefox and Mac. Tis, true.

Sunday, November 26, 2006

The Passion of the Developers

A thousand little decisions go into the creation of a great product. Most are not in the specs or master plans. Instead, they are implemented by testers and programmers. Yet, these are the same people that are traditionally lampooned as geeky and out of touch with the target customers.

What would happen if the developers possessed a deep understanding of their customers needs and desires? Suddenly, those thousand little decisions aren’t introducing random noise into the product. Instead, they are pushing the product forward. A single decision might not make much of a difference, but taken en mass, the momentum generated by enlightened developers can result in a massive reduction in design risk. You’ll develop the right product sooner and with fewer errors.

You can’t unfortunately just say “Dude, I looove my customers” and expect to get results. To harness the power of the passionate developer, you need the following pieces in place:
  • Empowered developers
  • Meaningful customer feedback

Empowered Developers
One philosophy is that we need better specs and those damned monkeys need to implement the specs exactly as designed. Better command and control system and more rigorous process is obviously the trick to success. This tends to generate poor results.

Imagine that you are a highly creative individual whose life is reduced to a series of highly detailed checkboxes that you are told to fill out one after another, day after day. If you deviate, you are punished and ridiculed. The results are gun-shy, non-communicative production workers that rely on obfuscation and deliberate bending of rules in order to express their innate creativity. Many wonder why they got into this dreary business in the first place. Others just give up.

When indentured coders and testers make design decisions, they lack both the experience and the desire to do the right thing for the user. They’ve been trained to take orders from management instead of building up an intimate empathy with their user. In the best of worlds, they implement uninspired versions of the features described in the specs.

In the worst of situation, they labor in secrecy, adding a little bit of their own uninformed creativity back into the product. When confronted with the havoc wreaked by Byzantine architectures and convoluted, unnecessary features, the humanoid production resources are surprisingly defensive. How can you be angry? They were just trying to salvage a small bit of their creative souls.

Such feature creep is not the fault of the individual testers or programmers. It is the fault of the team and management for turning a creative and invigorating process into menial labor where talented creators have no other option but to rebel.

We need a different philosophy based on passionate, educated team members that put the user at the center of their world. Developers gain the power to make their own decisions through their deep understanding of their customers.

Simple beliefs
Empowerment is a word that has been stripped of much of its initial meaning by the hippy liberals of the world, but the concept is rather simple. An empowered person is someone who has the ability to make their own decisions.

Let’s look at some building blocks that need to be in place before you can have empowered developers. You need to believe these are true and the people on the team need to believe that they are true. If these foundational beliefs are weak, it is very likely that you’ll end up falling back on command and control decision making structures in the face of emergencies or pressure.
  • Developers are passionate people: Even technical people burn inside with an inner flame of intense creativity. It can be hidden. It can be misdirected. But you must believe that it exists. The other insight here is that developers are motivated by very human issues. Dream, fears, respect and social hierarchy have a greater impact on productivity than economic incentives or logical rules.
  • Most decision should occur at the edges: Management serves a useful role in maintaining group cohesion. They rarely however, have intimate knowledge of the production issues experienced by individual workers. When developers at the edge with customer empathy are encouraged to solve problems that they happen across, a hundred issues that are invisible to managers start going away. A well functioning team is bursting with these small acts of ‘goodness’. Over the course of a project, the momentum results in an order of magnitude improvement in product quality. The most important outcome of this philosophy is that the people who build a piece of customer work flow hold absolute responsibility for it’s usefulness to the customer. “I’m just doing what I was told to do” is the vilest of attitudes.
  • Encourage learning through failure and feedback: The urge to control production often stems from fear of others making mistakes. “The morons are going to just screw things up!” is a common refrain. If you remove the opportunity for people to make bad decisions, you slide rapidly down the slippery path of command and control. An empowered developer has permission to fail. In fact, rapid, low cost failure is actively encouraged since it is the single best way to learn about how to make the product better.

Customer feedback
Now we have a team of passionate people. They are solving problems at the edges and they have permission to fail. Wonderful! We still, however, are missing the most critical element. We need to build a strong customer feedback mechanisms that encourages the team to create a product that matters.
  • Identify the customer
  • Believe in the customer
  • Get close to the customer
Identify the customer
Identifying your customer is where an amazing number of teams fail. They become focused on a bit of technology and imagine that users will just appear out of the woodwork. The whole process of iterative product design requires an identified customer so that you can know when you are on the right track and when you need to change direction.

The first step is to write down your customer definition. You’ll take into account market data, economics, opportunities that you’ve noticed and a billion practical details. It will feel like a very intellectual pursuit. The next step is to go out and find an actual, breathing human being who represents your customer. Customers are not data points. They are people that you can question, observe and befriend. The customer definition is just a tool that helps you narrow down your search. The real win is when you can get your customer in the room with your developers and they can drink a beer together. PBR FTW.

This isn’t easy. You may not be able to find a single person who represents your typical customer. You may end up with multiple customers that represent different needs. You may find that people on the team had very different ideas of who the customer might be. You’ll likely redefine your customer multiple times once you start talking with your initial customer prospects.

It is okay if it is hard. Don’t give up. Choosing your customer is the single biggest product design decision that you will make over the course of your entire product’s development. My belief is that no project should be green lighted for even minor development unless the team has had extensive conversations with an identified target customer.

Belief in the customer
The user of your product must be worthy of great passion. Remember, we are dealing with passionate developers thrive on living meaningful, creative lives. When the target customer is considered unworthy or boring, the development team will feel little urge to empathize or go the extra mile.

Product development is a service to others. The products we produce make someone’s world a better place. The team must be able to explicitly articulate why it is worth spending years of their precious lives providing the target audience with a new bauble. If you can get everyone on the team to passionately proclaim that they wish to serve the customer, you have built a powerful unifying vision that will carry the team through hard times.

It is worth noting that practically any customer can be worthy of great passion. All customers are people with dreams and passions of their own. They have tricky problems that result in very emotional human costs. An important aspect of connecting the passion of the developers with the passion of the customer is to identify the human, emotional aspects of the customer problem and bring those to the attention of the team.

Get close to the customer
Once you’ve identified your customer, you need to figure out ways of gathering information about them. One of the great Zen mysteries of product design is that in order to successfully serve your customer is that you should never give them what they request. So you can’t just grab a customer of the street and ask him to design your product. An average customer is good at identifying problems, but they are poor at prioritizing, understanding larger patterns and generating elegant solutions. That is your job. Your customer is there to let you know when you get things right and when you get things wrong.

The feedback cycle is pretty straight forward
  • Identify a problem or opportunity
  • Build a valuable solution that fits the available resources constraints.
  • Present the solution to the customer and record their response. Do they realize the value of your solution?
  • Use the data to identify new problems and opportunities. Look at the big picture and start the cycle all over again.
There are a plethora of good techniques available for getting closer to the customer. IDEO has their 51 ideation cards, college design courses teach books worth. They operate at different timescales and give you different types of information. Implement multiple ones and see which ones work the best for your particular customers. Here are some of my favorites:
  • Use your own product: Try to replicate what you see your users doing. Mimic the masters so that you understand their thought process by doing. This builds developer empathy with your customers and is one of quickest feedback cycles around. It also however, can be highly biased.
  • Onsite customers: Make a customer or two part of the development team. You get very rapid feedback and lots of cultural transfer into the team. The downside is that customer objectivity can be polluted by constant contact with the team.
  • Observe customers using your product: Set up usability studies and gather both quantitative and qualitative data. Every team should do this, but it can be expensive and feedback only happens in spurts.
  • Hire psychologists and ethnologists to study your customers: You’ll often gather key insights that would otherwise slip by someone not trained in methodical observation. Making these results actionable often takes additional work.
  • Listen to lead users: Some users are actively solving the same big problems that you are attempting to solve, often years ahead of the market. Find them and learn from their successes and failures.
You are always balancing three different aspects of the customer feedback.
  • Reduce feedback cycle time: The more quickly you can fail, the less effort you can put into each failure and the sooner your can correct your course
  • Improve objectivity of results: It is easy to get biased results. Many of the issues dealing with customer psychology are fuzzy in the best of situations and the developer’s own interpretations often dramatically skew the data.
  • Improve clarity of results: With more data comes more noise. Boiling down the flood of information into actionable, meaningful results that the team can understand is an ongoing activity. Many teams collect customer information, put it in a binder and then never look at it again. If you don’t act upon the customer feedback, it isn’t useful.
There is a substantial cost to all of these activities. You’ll need to change your development practices. Daily builds and regular check-ins help ensure that you always have a product that your can put in front of users. You’ll need to spend money. Bringing in users, ethnologists and usability experts adds to your headcount. This is the cost of doing business.

I’ve laid out two pieces of a successful product design team. The first is empowered passionate developers and the second great user feedback. Without the first, user feedback is either ignored or fails to permeate the multitude of small decisions that go into building the product. Without the second, the team spirals off into wasteful directionless exploration.

The single biggest barrier to creating a team of developers that are passionate about their customers is the core cultural beliefs of the people already on your team. Chances are good that they rose to where they are today by mastering a traditional command and control style system. They’ve been personally rewarded throughout the years by checking off the check list or writing checklist for others. They got a big fat raise for staying late and adding those 12 new features from the spec. When the product fails, they are told, “We should have added those 6 more features that got cut because developers were so slow.” The weak ones leave and the ones that are great at silently adding questionable features are promoted and promoted again. They are trained, their egos are invested. After five to 10 years of this, an experienced developer builds up an unshakable, unquestioned belief in command and control style development that only falters when they finally die off.

A thousand little successes do not start with a mandated policy. They begin to gain momentum when the role models within the company start acting upon the beliefs in concrete ways. This is where most process change breaks down. People say one thing, but revert back to habitual behavior when the going gets tough. They still believe, deep down, that the old method of command and control is less risky than trusting a team driven by passion and customer feedback.

Only when people on the team have personally experienced success using the new techniques and they’ve adopted new beliefs as a core of their personal philosophy will momentum sweep through the entire team. Several items need to be in place:
  • The right people: You need a core group of people willing to believe in both developers and customers. These folks are rare since the current system isn’t focused on producing them. If you find one, hire him or her immediately. The culture they bring to the team is worth as much as their skills alone.
  • The right situation: Often people need to be in the middle of a failing project before they will consider that there might be alternatives.
  • Time: Smart, strong people do not give up their culture overnight. After years of steady and obvious success, they’ll start to shift. Start with a like-minded core and grow it slowly.
Very few companies have all these items align. I was chatting with one insanely successful game company that follows many of these methods. They’ve given talks on their process. They’ve partnered with other companies and attempted to teach their process. Each time it fails. Imagine a company that consistently releases highly profitable AAA titles merrily giving you their secret formula. Would you take it?

Yet no one does. It would require companies giving up their most fundamental beliefs about how software is designed and built. They would need to give control to the lowest people in the organization, embrace a constant stream of failure and put customers, not their creative urges, at the center of the design process. That, my friend, is scary. Product success is cool, but a shot a being Top Monkey in the current ineffective system is much more attractive.

Why are we in this business again? Where is our urge to build great and wonderful things that serve the world? It seems a shame to let tradition, habit and hierarchy get in the way.

Lately I’ve been contemplating a nuclear bomb of a statistic. 80% of software features are either never used or used very rarely by customers. Anyone who does software development should be staring at that number in shock. 80% of your sweat and tears has little to no customer value. In most cases, customers would be just as happy if you were to give them 1/5th of the existing product and make that little sliver work better. How much time and resources could you save if you only delivered the right features?

This in turn has gotten me thinking about the common software development practices, the ones that fixate on execution risk instead of design risk. What we build is just as important as the fact that we can crap out a product by Christmas.

Passionate developers that empathize and listen to feedback from customers form the foundation of an efficient team for one central reason: They are very good at reducing the risk of building the wrong product.
  • Team members more readily identify areas of design risk that require iteration with customers.
  • Any big design mistakes are caught early through customer feedback.
  • Small decisions are made more rapidly with fewer errors.
You aren’t going to save 80% of your development time since all this iterating does chew up a serious effort. But you may save 50% or 60% of the budget. More importantly, you may end up releasing a product that is of value to someone that you care deeply about.

Passionately yours,

Sunday, November 12, 2006

Killing the elder game

I had a chance to sit down with Andrew Tepper, the designer for A Tale in the Desert. His game is a good example of a village game, one of those small MMO that flourish in the dark corners of the internet. They’ve got a small group of dedicated developers making a wonderful, profitable game that is invisible to much of the world. They bootstrapped themselves into existence without selling their souls and are planning for an optimistic future. I believe the market could eventually sustain a couple hundred more such carefully targeted titles without undue competition. Just don’t make a traditional fantasy MMOG

One of the fascinating things about A Tale in the Desert is that it ends. Every 18 or so months, the game starts over again with a new ‘Telling’. This is highly uncommon. Most online games are actually two very distinct game designs mashed uncomfortably together.
  • The advancement game: The newbie grind
  • The elder game: The eternal end game

The two games
In the advancement game, the player gain levels, learn skills and build in-game friendships. The grind up to level 60 in World of Warcraft is a good example of the advancement game.

Once you've completed the advancement portion of an MMOG, you begin the elder game. Now that you’ve got hundreds of hardcore max-level players, you need to keep them entertained in order to keep the subscriptions flowing. Typical mechanics that you find here include PvP, Quests for items that give social standing but not practical benefit and lots of guild politics.

The elder game is all about maintaining a steady state. Brian Green describes it as an episode of Star Trek. No matter what crazy things happen in an episode, everything is back to the same situation by the end. Sure, you spent two months planning a raid to capture that enemy castle. The balance is carefully tweaked however so that eventually, you will lose the castle. Use of heavy negative feedback means that all the PVP, legendary questing and more is ultimately and intentionally for naught.

There is obvious tension here.
  • Game balancing. Building and balancing two distinct play systems cost a lot of money, time and effort. The shear scope of the game systems is often a problem.
  • Audience Expectations: During the advancement game, you’ve attracted and trained a population of players that loves advancement. Then you plunk them into a steady state system. The whole process provides a schizophrenic value proposition to the customer
  • Cultural shifts over time: Steady state systems are even more difficult to balance in the face of shifting cultural dynamics. When the game launches, you want a lot of investment in the advancement game. As the game evolves, you need to start improving the elder game to keep the players who have maxed their character. Finally, you need to start streamlining the advancement game since the newbie zones are often desolate after the initial rush of players. So over the life cycle of the game, you end up with radically different design requirements that are constantly shifting.
Cyclic games
A Tale in the Desert is a great example of how you can run the game in 'cycles' or 'Tellings' in Andrew's terminology. Instead of heading directly into the elder game once the advancement game is played out, you end the game and start it over again. This gives you the ability to start out all the players from scratch and let them replay the game that they originally fell in love with. Think of it as the repetitive play of Tetris, but on the scale of 3 to 18 months instead of 15 minutes.

You end up with some great benefits:
  • More focused design: Instead of multiple game designs, you have only one, the advancement game. This can reduce costs and improve balancing.
  • Built in opportunity to refresh the game play. Suppose you want to add a completely new system into the game to address some flaw that was uncovered in a previous Telling. In a traditional MMO, you’ll often run into massive resistance from the player base if you try to alter an existing system. They seek to protect their investment. When a new Telling begins, you have license to add new mechanics. Players may even expect it; there is a thrill in discovering new systems.
  • Clearer player expectations: It is easier to align player expectations with the design. You aren’t forced to constantly shift the design as the player demographics age.
  • Marketing relaunch opportunity: You get the opportunity to relaunch the game in the market. Every Telling is in effect a new version of the game that can be promoted and sold as a bright and shiny new thing.
Not all is rosy
You introduce some interesting new problems, but these are not insurmountable.
  • How do you get players to go happily into the light? Andrew’s answer is group goals. The group chooses to complete goals that win the game and start the next cycle. By empowering the player to make the choice, there are far fewer complaints. The designer engineers the Seldon-esque dynamics of the system to encourage player choice to flow, on average, in a particular direction, but the players still make the final choice.
  • How do you prevent increased player churn at the end of the telling? Currently, the churn doesn’t seem so bad from the numbers that were bandied about. A small meta-game involving tokens that indicate social hierarchy might be enough to stem end of Telling churn even further.
  • Wither the player content? When you reset the world, you wipe clean vast quantities of player content. I don’t honestly know how bad of a problem this ends up being. This social force could easily contribute to the dramatic momentum of the game. Imagine one group trying to prevent the end of the world and their clashes against those who want to advance to the next round. Setting player expectations regarding the purpose and life span of their creations is likely the biggest challenge.
  • Gaps in the advancement game turn away new players: In a typical advancement game with lots of grinding and leveling, there quickly emerges a gap between players that join only weeks apart. In a traditional MMOG, you know that if you grind long enough, you can ultimately join your friends at the elder level. Cyclic games that only have the advancement game always have to deal with players that exist in classes based off when they joined. One such cyclic title: Earth 2025, mitigates this somewhat with the use of allegiance systems, where new players can join existing groups. In other games, setting up a healthy flow of economic value between newbies and elders can also increase the collisions between players of different levels.
All in all, these cyclic online games are a fascinating variation on the typical MMOG. It only goes to show that the dominant game design model is not the only model and that there is still an enormous space to explore in online games before we've completely tapped out their possibilities. Thanks to Andrew and Brian for the great conversations.

take care

A Tale in the Desert
Andrew Tepper's game.

Brian’s web site. He mentioned the elder game concept to me.

Earth 2025
One of my favorite examples of a cyclic game.

Village Games
My article on village games from 2005

Saturday, November 11, 2006

Millions of Peaches: The value of games

Raph gave a fun, mildly inflammatory talk called ‘Influences’ questioning if games are fundamentally limited in their capability to explore the human experience. Such angst makes my geeky heart beat faster. What follows are the random late night thoughts jotted on the airplane ride back.

My heavily editorialized version of the talk: What if games are only spreadsheets? You can reduce a game into mechanics, stimulus, inputs and lots and lots of numbers. As the game is played, the player immediately strip away the initial sensations of wonder and end up with mechanical tools, a debug console of symbols that represent the ticking, clockwork heart of the game. But, but but…how can we expand our influences beyond the math? How could you evoke the taste of a peach? You can do it easily with a poem, a novel or a movie. But no one is doing it with games.

Games are limited as a medium. So is everything else.
Suggesting that each medium lends itself to certain human experiences better than others should not be shocking. For example, you can create a deep understanding of an individual relationship with a novel. A painting on the other hand may only be able to capture a single emotion associated with a particular moment in that same relationship. Both are powerful experiences, but each medium still has obvious strengths and weaknesses. There are lots of mediums that have difficulty dealing with ‘peachness’. You could certainly shave a cat to look like a peach, but it is quite the tricky exercise.

From this perspective, of course certain peachy topics stump all but the most skilled game designer. At the very least we can say that games are poor at exploring experiences that require input and output mechanisms that are undeveloped either technically on the game’s execution platform or culturally in the game’s audience. For example, games right now lack a taste output apparatus. They also lack widely accepted stimuli that the audience will recognize as a metaphor for taste. So part of it is an interface problem and part of it is a cultural problem.

Limits to the medium exist. We should recognize them. We should also attempt to be insanely clever in getting around them.

The strength of games as a medium
The mildly inflammatory bit is the suggestion that games have no superpowers. What if no matter how many steps forward designers make, we will still end up with shallow clockwork toys? Perhaps, if someone wants to create a meaningful experience, they should skip games all together.

There are at least two obvious counter arguments to this fear.
  • The process of creation is not the player experience.
  • Games do in fact have super powers, particularly in the area of letting player experience a situation directly instead of through an intermediary.
The process of creation should not be confused with the player experience
Raph makes the point that games are just math. Math is one of game design’s most powerful tools, but it is not the final player experience. Often when we are in the muck of creating a project, we despair that our creation is nothing but numbers and fields because we’ve lost sight of how the virgin player will experience the product. Since we spend so much time playtesting and reacting to the feel of our prototypes, there is a strong inclination to blur the line between player and creator and treat the two roles as one in the same. At this point, if creator only sees numbers then surely it is a bad game.

I think of it as the difference between chemistry and perfume. A good bit of chemistry, equations, experiments and theory go into the creation of a new perfume. But that detailed process of enumerating chemical bonds doesn’t need to show up in the end experience. When she dabs a drop on the graceful arch of her neck, Marla won’t be thinking “Mmm…ketones!”

It is the role of the designer to take the clockwork spreadsheets and construct a mix of stimulus that the player can synthesize into a coherent, evocative experience. We are a expert judge of the experience, but we always need to recall that our deep understanding of the game’s theory and mechanics also builds within us an unavoidable bias.

The trick here is to always go back to your players. If your game starts feeling like a spreadsheet to the team, start running some play tests and see how players react. Tune your game based on player feedback to turn your spreadsheet into an amazing and visceral experience.

When the mechanics connect, the impact on the player is magical. When they don’t connect, remember, it isn’t the fault of the spreadsheet.

Game do, in fact, have super powers.
Perhaps it is best to start with an example. One night, a few of us stayed up past the pumpkin-hour playing a game delicately titled “Asshole”. All the fratboys and sorority sisters know it: card, alcohol, and people you thought were friends. The trivial rule set can be described easily with a spreadsheet. However, a description of the mechanical clock does not tell the full story.

When played properly with a copious supply of tequila, Asshole is a game about social hierarchy. As soon as the first President and Asshole assume their positions, the players learn about the use and abuse of power. They learn about counteracting and influencing official authority. More importantly, they learn how the other players, people who are typically friends outside of the game, react in social situations that many would never deliberately put themselves into. Trust is built, friendships formed and treachery revealed. We learned to worship El Jefe.

I challenge any medium, be it movies, books, poems, music or theater to provide the same intimate experiential insight into the workings of the audience’s immediate social group that you find in a simple game of Asshole. This is magical, life changing shit. It is unique to games (and perhaps jam sessions)

Most static media is about the author processing the world and spitting out a result for an audience to consume and savor. Games are about the author building an interactive model that actively encourages the player to uncover their own truths. Both approaches exhibit expressive super powers. Both reveal something unique about the human condition.

If you prefer to create a canned, processed insight into an imaginary character, might I recommend building a novel or perhaps a movie. If you want to help the audience gain practical insight about their immediate friends and family through a safe and pleasurable interactive experience, try making a game. What you want to say has a large impact on how you choose to say it.

Self imposed viewpoints
So enough with the angst! Games are obviously more than clockwork silliness. Certainly, they have weaknesses like all existing mediums. They also have impressive strengths that we should explore and extend.

Maybe games aren’t very good about describing the sensation of eating a peach. I can live with that. Our role as designers is not to build passively consumed descriptions of the world. Our role is to build direct experiences that provide players the opportunity to form their own insights.

Does this involve math and modeling? Absolutely. Are the insights that players take away only about math and modeling? For most players, I would say no. When someone takes on the role of President in a game of Asshole, I learn about them as a leader. I find out who is the joker in the crew and who is the follower. I see who complains when their status drops and who does not. Numbers are a foundation of the game, but they do not necessarily define the complete player experience.

Game designers and some hardcore players are perhaps the major exception. They tend to see the world through clockwork tinted glasses. In their quest to reduce, codify and model the world, it is far too easy to become blind to the wonder and beauty that the simplest games promote. If you see only clocks, seek additional perspectives that help you see what your players see.

Now, who wants my top two cards?

Take care

Raph Koster’s talk at Project Horseshoe

Rules of Asshole

Tuesday, November 7, 2006

Project Horseshoe

I attended a unicorn convention in Texas this past weekend.

I always tell people that the role of 'game designer' is really a mirage left over from the days when there were one person teams and we needed a term to described the person who mashed together the messy creative gunk inside a game. Nowadays, we have specialists: Level designers, producers, creative directors, AI programmers, UI coders, writers, artists and more. Few companies seem to really hire the old definition of 'game designer'. Instead you are posthumously awarded the title when no one knows exactly what the heck you do any longer.

The Fatman and his wonderful wife managed to round up a herd of actual sparkling game designers, the impossible sort that think deeply about the big picture of how game systems work. The assembled brain trust was easily responsible for hundreds of games, many of which are legendary or at least ballsy beyond compare. For three days, they gathered at a remote Austin ranch and talked intensely about game design.

The goal: To solve the biggest problems facing game design over the next five years. I’ve cobbled together a few essays from the event that will eventually get posted on this website. More importantly, there will be no doubt stunning papers from the working groups posted later on down the road. Sparks were flying. And hay. Don’t forget the hay.

More than anything, it gave me faith that if you just get the brightest people of our industry off their isolated islands and give them a chance to talk, amazing ideas are inevitable. Experience shared is multiplied, not diminished.

Take care

PS: Despite all the magnificent displays of mental virility (complete with glowing horns and stamping hooves) there was a surprising lack of supple young virgins (male or female). I can only imagine that this will change once word gets out about the event.

Project Horseshoe website

Monday, October 23, 2006

What are game mechanics?

The phrase “game mechanics” sends a pleasant shiver down my spine. At the heart of every game are these mysterious whirring clicking mechanisms that deliver to the player pleasure and thrills.

We use them, we build them, but I’ve never seen a good unified definition of game mechanics that gives us a practical base upon which to build great games. Here is one. It is clobbered together from a variety of influences though many of you will recognize some central tenets from ‘A Theory of Fun’ by Raph Koster.

Game mechanics are rule based systems / simulations that facilitate and encourage a user to explore and learn the properties of their possibility space through the use of feedback mechanisms.

It is a simple definition, but it offers a good amount of insight into why games work and how we can make them better.

Feedback loops
Central to the model is the concept of feedback loops that encourage learning. Here is a diagram that should explain the concept in a more visual format:

(click to expand the diagram)
  • Player performs an action.
  • The action causes an effect within the simulated game world. The simulation contains public and private tokens and the causal rules that affect the states of the tokens. The player rarely knows all the rules and is highly unlikely to be able to instantly describe the complete possibility space described by the rules. The unknown portion of the simulation is a “black box” that the player must attempt to decipher.
  • The player receives feedback.
  • With new tools and information in hand, the player performs another action. Using what we’ve learned, we pursue additional pleasure.
Linking game mechanics to create a system of systems
Interconnected networks of game mechanics make up the game as a whole. You can think of the game as a set of interlinked of puzzles where solutions to one puzzle lead to clues that help on additional puzzles.

The info treats that a game provides to the user need not be used to solve the immediate black box at hand. Humans horde potentially useful information like squirrels horde nuts for the winter time. We’ll store hints in our copious long term memory in the hope that there will be another black box down the line that will yield to our improved tool chest of knowledge.

The traditional metagame that sits on top of a game’s core mechanics is a good example of how one black box feeds into another. In this situation, the game mechanics are arrange in a temporal hierarchy where rapid feedback loops (often part of the basic control scheme) provide tools that enable the mastery of longer term feedback loops. The potential patterns of linking game mechanics together are nearly endless. This is a wonderful area of future study.

Humans are infovores
Humans are wired to solve black boxes. It is a fundamental aspect of our neurological learning wetware. We get real chemical rewards when we grok a problem or gain information that we suspect will help in grokking a black box. Evolution has selected for this behavior over thousands of generations since it is the biological reward system that encourages tool use and technological adoption. Without this built in addiction to problem solving, we would lack agriculture, medicine, architecture and other fundamental survival techniques that make the human species such a remarkably successful animal.

A key aspect of our model is that games actively encourage learning. I can put a black box on the table with a hidden button. Unbeknownst to a potential user, pressing the button enough times and the black box will spew out a thousand shiny silver coins. This is not a game. This is a bizarre gizmo.

To turn it into a game, a game designer would need to do several things.
  • Encourage Discovery: First, make it obvious that the button in meant to be pushed. Humans are naturally curious creatures, but as game designers, we need to explicitly direct them to take certain actions.
  • Encourage Exploration: Second, the designer would put a counter on the front of the machines that lets the user know that their actions are having some impact on the system. The counter provides delightful drips of feedback and it is up to the user to interpret that feedback
  • Provide Tool Mastery: Third, the designer would post a note “Payout: 1,000, coins!” Not all games need explicit winning conditions, but hinting at future utility is a highly useful technique for encourage the player to begin interacting with a particular game mechanic.
We’ve turned a gizmo into a simple game of chance. The difference between the two is that our primitive 1-armed bandit is explicitly designed to encourage player learning.

Existing games are richly laden with techniques that encourage learning. A few that come immediately to mind:
  • Levels take complex systems and encourage players to explore and master one aspect of the possibility space at a time
  • The use of scores, coin collecting and experience points are all simple feedback mechanisms that let the user know they are making progress towards some future state.
  • The classic “See the treasure chest you can’t reach” in Zelda acts as a promise of future utility.
A system alone is not a game. A dump of information is not a game. A system that encourages learning through strong feedback mechanisms is a game.

Secondary effects
I’ve just described the foundation of a game mechanic. Now lets dig into several of the secondary effects that immediate appear when you attempt to put this system into practice:
  • Burnout
  • Milking
  • Red herrings
  • Human factors
Burnout: A definition
After merrily harvesting tidbits of information by plunking coins into the virtual pachinko machine, the player will eventually grok the system. The game mechanisms may still serve up information, but the tidbits are not longer as tempting. The info we receive has no resonance with problems that we are solving or problems we have solved. It activates no curious networks in the brain. We begin subconsciously filtering out the feedback from these mechanisms. Burnout is a state of completed learning where the player finally figures out that a particular action no longer yields meaningful results.

In Monkeyball, researchers were astounded to find the the biggest jolt of pleasured occurred when you fell off a cliff and died. People loved it! If you look at falling off the cliff as a huge learning experience, this makes perfect sense. However, when they replayed the animation, people hated it. Same stimulus, radically different response. The animation of falling off cliff lost its ability to teach the second time around. Ultimately, users are subconsciously constantly asking the question “Is this activity worth my time? Does it gain me anything useful?”

Premature burnout
There are multiple paths that learning can take and not all are ones that game designers desire. We would like to imagine that groking a system results in complete and utter mastery of that system. In reality, ‘grokking’ means that that the user has stabilized on a mental model of the system they no longer feel like improving further. This model can be simple or complex, depending on the inclinations of the user.
  • A complex model of Black Jack might take into account probabilities of cards appearing based off what has already been played.
  • A simple model of Black Jack might conclude that cards appear pretty much randomly. There is more depth for the user to explore, but if they are a casual player, saying it is random is ‘good enough’ to judge the game.
A big frustration to game designers is that many users settle on a very simplistic model of how a particular game mechanic works. Players will claim that a game is unfair or too difficult and immediately toss it in a rubbish bin because the designer misjudged their reaction to a game mechanic.

Some mechanisms have highly predictable burnout rates. Most players immediately figure out that watching a cutscene again isn’t going to provide much additional information. Other mechanisms demonstrate a large variation in burnout rates depending on the person who is playing the game and their personal preferences and disposition towards addiction. Some players try a slot machine once and then never again. Others will ruin their lives in pursuit of the next reward, never grokking the simple truth that such machines exist to take money, not give.

The factors that influence burnout are numerous.
  • Personality.
  • Personal history.
  • Practical importance of imagined future rewards that stem from mastery.
  • The ability for the mechanism to signal that there is additional depth of mastery possible.
The first two factors are not possible to derive by simply exercising your superior intellect. A deep understanding of your target audience’s psychology is most helpful here. The second two factors are very much under the designer’s control and can be refined through heavy prototyping and player observation.

Milking: The transition from learning to tool use
The flip side of burnout is grinding. If burnout is when a player discards a game mechanism because it is no longer useful, milking is when a player continues to exercise a game mechanic long after they’ve reached the state of mastery because the game mechanics continues to provide value.

When a player has learned one system, they will often keep interacting with it. On first blush, this seems mildly demented. The activity no longer provides burst of juicy learning. It is a bit like jawing on a piece of gum that long ago lost its flavor.

However, remember that games are networks of linked game mechanics. Player will continue to interact with a mastered game system in order to create a useful game state for exploring another black box. Mastery gives the player predictable pragmatic tools that helps them advance in other aspects of the game. The learning and mastery that occurs in other portions of the game provide the necessary reward that goads the player into revisiting old game mechanics.

You can extend the time that a player spends with a set of a game mechanics by ensuring that a mastered system still provides utility to the player. Designs techniques that build tools result in more gameplay for less development work.

Red Herrings: Black boxes external the game
The network of blackboxes that the player considers valid can extend far beyond the systems in the game itself. Often, the player will collect strange bits of info that have no real impact on the game mechanics that the game designer built into the game. These pieces rattle around in our heads like a collection of oddball keys for a set of locks that we may never find.

Game designers can tease the player with hints to systems that do not exist in order to suggest depth to their games. A sly arched eyebrow in a cutscene triggers as massive cascade of meaning alerts. Our brains love people and faces and relationships and the breeding opportunities and politics! Surely, that eyebrow is important? The player greedily stores the memory away.

What impact will the collected information have on their gameplay? None. What impact will it have on their lives? Very little. This virtual person in a cut scene is no one they will ever meet. But our brains were not evolved to deal with such things. As apes, the tale of an arched eyebrow by a potential mate from our little tribe always meant something very, very important. So our brain rewards us with a little jolt of pleasure for noticing such an “obviously” beneficial tidbit.

The designer managed to suggest a system and get some of the benefits of that system without actually building it. It is not going too far to suggest that paintings, sculpture, movies and television all thrive on this simple quirk of our brain’s learning systems.

The downside is that such red herrings burnout quickly. Our brains becomes quite good at recognizing false, useless information. Almost no one watches a cut scene more than once. What would be the point?

My personal bias is to use red herring game mechanics sparingly. As game designers, we have deeper skills at our disposal. We can tailor potent electronic cascades of feedback loops that spin out a complex duet between computer and the player. Such system are highly effective at causing visceral pleasure and encouraging deep long term learning. As game designers, we conduct a majestic symphony of explicit learning and entrancing interactivity, something no static media will ever manage.

Sometimes though, it is worthwhile to suggest great mysteries with broad brush strokes. Setting, character design and plot can be crucial hooks that help make a game meaningful to players before they even press a single button.

Human factors: Emphasizing the humanity of games
Some folks read about models and immediately see them as reductionist mechanisms that strip the humanity out of the soul out of creating artistic games. The game mechanics I’ve described in this article attempts to avoid this trap. They explicitly include social, narrative and emotional elements in addition to purely analytical problems. All aspects of the human experience, that have an impact on our ability to process and learn from stimuli, fall within the domain of potential game play.

This definition of game design is much broader than the current range of games available on the market. Though it works quite well with hit points, button mashing and high scores, the breadth of the definition is intended to encourage exploration of a much wider range of human learning. Some open questions that I find immediately suggested by the model include:
  • What are the feedback mechanisms that impact learning about relationships, love, hate or spirituality?
  • How do we build games around such topics that leverage these feedback mechanisms?
Existing games give us the foundation of practical knowledge that lets us make the same thing in a reliable fashion. A good theoretical framework helps game designers create future titles that are inclusive of a wider range of human experience.

The goal of any model of game design worth its salt is that it both explains existing behavior and predicts future behavior of medium. In my experience so far, this model seem rather robust at explaining almost any existing game on the market ranging from board games to slot machines to social games. There is certainly room for improvement, but it is a good enough for my main goal.

I want a practical model that lets the good folks in this grand industry describe game designs in more exacting terms. The model should give insight into why their prototypes suck. It should allow them to discuss potential issues and solutions with shorthand language that cuts to the meat of the matter. A good predictive model allows for more intelligent design decisions with less waste and unnecessary rework.

So some of aspects of the model that I find useful:
  • It treats game mechanics as well defined, comprehensive atomic units. These units can be discussed individually and they can also be linked together in interesting ways.
  • Explicit identification of user value. Fun is not a nigh spiritual activity that spontaneously bursts forth from the ether. It has a testable neurological basis.
  • There exist clearly inputs and outputs that easily identified. You can easily tell when a specific game mechanic has all component elements such as actions, rules, tokens and feedback systems. Through observation, you can identify the player’s reaction to each mechanism and then adjust its impact.
All and all, the hope is that this model of game mechanics is a good foundation for future discussion. It is one that I’ll be leaning on heavily as I continue to meander through this lovely little series of essays on game design.

Take care

The pleasure of killing monkeys
See research lesson #1. I don’t agree with their conclusion about what causes the reported result, but I find the data fascinating.

A theory of fun for game design: Raph Koster
Many of the basic concepts in this essay build upon the ideas in this book. I find it helps my thinking to rework what I’ve read in essay form. Call it a form of active listening if you must. (

Feedback loops
A slightly different definition of feedback loops that comes from control theory.

Games are designer foods for infovores

Other loose ends
This essay became too long and started budding little essays. Some have been planted in new documents that may one day emerge in full blossom. The rest are here for your reading pleasure.

Is a book a game? With this big emphasis on learning, there is bound to be a wiseass who asks “Is a text book a game? It too encourages learning.” The problem here is that there are few strong feedback mechanisms evident. The user reads the book and without a doubt they get a burst of pleasure from ingesting the info. However, the act of turning the pages, and interpreting language are skills mastered through other activities ages early. At best, reading the book is an example of milking, where a player uses a mastered technique to advance the grokking of some larger blackbox.

The primary role of content. In this model of game mechanics, content in the game is meaningful only through it’s association with a feedback mechanism. Plot points become reward and hints, Damage becomes a punishment that clues that player into the fact they shouldn’t be doing something. There is no such thing as an inherently pretty picture that exists ‘just because.’ The image is pretty because it activates the brain’s learning systems which in turn feed back into actions.

In order to answer the question “what content does my game need?” you need to first answer the question “What feedback should my game mechanics provide to the user based on their actions?”

Sunday, October 15, 2006

Persistent myths about Game Design

The straw man concept of game design involves the sole genius game designer who writes his thoughts on a golden tablet and passes it down to the production minions to build.

There are several beliefs about the process of game design and development evident in this stereotype.
  • Heavy upfront design and preproduction are critical to the creation of a great game.
  • When these activities are not done early in the process, there will be mistakes made later in the development that are almost impossible to correct.
  • A single individual must drives the creative design process. Otherwise there will be a lack of vision that cripples the project.
To this day I still come across designers who enthralled by such philosophies. How often have you heard comments like:
  • “If only we had more preproduction time, we wouldn’t have run into this problem.”
  • Or “If only I had been given more creative control, the product would have turned out better.”
These statements sound quite reasonable and many of us can bring up examples where such practices appear to have worked. However, as the industry becomes more experienced, many have come to understand that traditional upfront design presents a myriad of problems including delayed schedules, conservative design choices and years of our lives spent producing game designs that customers simply don’t want.

Our development beliefs have deep roots in the creative processes that have been historically promoted as the right thing to do. Let’s look back at why they are so prevalent and why they fail when applied to modern game design and development.

Historical Roots: Software development as an engineering discipline
Back at the turn of the century, manufacturing believed that heavy upfront planning was the key to efficiency. The mantra was “Do it right the first time”. There is a rich history of ‘time and motion’ process development where learned men with stop watches would plan out manufacturing steps performed by their laborers to the second. Software development, in an attempt to add rigor to their fledgling discipline adopted the manufacturing philosophies whole heartedly.

The following are wisdom gleaned from this ancient era. In small doses, they are quite beneficial. When they are followed dogmatically, time and experience has proven that they destroy projects.

Myth: “Upfront design reduces risk”
We all are familiar with waterfall style preproduction, production, post production cycle. The idea is that by planning upfront you think through problems early and avoid stupid mistakes. In this line of reasoning, the longer you think about a problem, the more edge cases you’ll discover.

When teams are given plenty of time for upfront design, they will typically design elaborate systems for problems that do not really exist. The interaction of software with users is notoriously difficult to predict. Problems emerge from the most unlikely areas and other issues that take of dozens of hours of planning end up not being all that important. When a team plans in isolation from feedback, the result is bloated software that either poorly solves the actual problem or does not connect with the users needs.

A better technique is to test your ideas early and often.
  • Build working systems that you can show to users as early as possible. This allows you to gain real world knowledge at the earliest possible point.
  • Try multiple paths early in development. This results in the cross fertilization of expert knowledge necessary to create truly innovative solutions.
  • Do the simplest thing possible. Instead of worrying about every contingency, do the simplest thing that will solve the problem at hand. If you get feedback that it needs to be improved, go for it. This dramatically reduces feature creep.
  • Defer decisions as long as possible. The longer you can gather information, the more likely you’ll make the right decision. This may smack of being wishy-washy, but it is an attitude that encourages building flexibility into the system and allows you to adjust to feedback more easily.
  • Iterate: By building rapid feedback cycles into your development process, you’ll converge on an optimal solution far faster than you would if you spent time in planning.
  • Include customer feedback. Play that game constantly. Watch others play the game. Collect real world data and share it with everyone on the team. Act on the problems you witness.
There are two forms of risk, execution risk and design risk. Execution risk is the risk that the project will not be completed as planned. Historically, it is what our fledging industry has been overwhelmingly concerned with. “Can we even make a game?” Design risk is the risk that you will complete the wrong product. This is where mature developers should be focusing their effort “Am I making the right game?” Upfront planning focuses on reducing execution risk. In reality, long preproduction delays the production effort and results in a product that is disconnected from the needs of the market.

Rapid iterative development reduces both production risk and design risk. Design risk is reduced by constantly reconnecting with the customers. Production risk is reduced because you find that you often need to do a lot fewer features in order to satisfy the core customer’s needs. It is amazing how you can cut production schedules by simply doing half as many features. Just make them the right customer focused features instead of the flights of fancy of a planner locked in a dark room.

Myth “The cost of change increases exponentially as time goes on”
Many conservative design decisions are motivated by fear of change. We are told that a change late in the process will cost 1000 times as much as a change early in the process. The argument is that it takes five minutes to write a spec, two days to program the feature, two weeks to test it before deployment and a month to write a patch that fixes a problem after deployment.

This belief encourages logical people to optimize their behavior in peculiar ways. The first inclination is to create highly detailed plans of action that are presented to the production teams as the Bible for the game. Some common problems include:
  • Locking into design details before real experience based information is available
  • Locking the development team into a design that is guaranteed to be wrong.
  • Discouraging ‘Aha’ moments that occur later in development as the team learns about new and exciting attributes of your emerging gameplay. If it isn’t in the plan, it doesn’t get developed.
Second, you want to choose the lowest risk designs as possible. Changes are expensive and low risk designs are less likely to change. The result is a glut of surprisingly narrow minded design decisions made early in product development.
  • Choosing well known designs that are already implemented in other projects over new designs that have multiple unknowns.
  • Discouraging experimentation after preproduction in the belief that it will lead to difficult to plan for innovation and feature creep.
It turns out that the act of attempting to control the cost of change through waterfall techniques bloats the cost of even simple activities. The team puts on spec blinders, focuses on low risk designs and fails to consider the surprising solutions that appear when smart people slowly attain mastery of a complex system. The process itself of excess upfront planning causes the exponential cost of change, not the inherent nature of the work.

When you take the same activities in put them in a software development environment that emphasizes rapid feedback cycles and modern coding techniques, you see a much flatter cost of change. This requires systematic changes throughout the team, not just in the area of game design.

Introduce flexibility into programming activities:
  • Refactor religiously. Use a language that lets you refactor and make refactoring part of your daily coding habits.
  • Use modern source control and coding standards.
  • Reduce rigid code ownership. This ensure that the right person is available when the time comes to make a change across multiple areas of the program.
  • Encourage unit test suites. This builds a safety net that allows programmers to experiment without worrying about irreversibly breaking existing code.
Introduce flexibility into artistic activities:
  • Create highly reusable artwork that follows a standardized format. Procedural content is a must. One shot disposable artwork such as cinematics or in-game cut scenes should be avoided.
  • Reuse artwork from previous projects. Prepare to ship with some of it.
  • Use easily replaceable dummy artwork to prevent bottlenecks during rapid design iterations
Introduce flexibility into design activities:
  • Keep design documents simple. Try post-it notes stuck on a wall in a team area.
  • Use prototypes instead of design documents. If you can’t play a game mechanic, you are just waving your hands. This is often worse than useless since it can hide really bad mistakes for surprisingly long periods of time.
  • Rely on reusable game mechanics instead of one shot level design. Think football, not Disney rides.
  • Be very willing to cut scope. 80% of the designs that you suggest should not ship. Reevaluate your design after everything iteration.
There will always be major features that are difficult to change, but these should be the exception, not the rule.

Myth: “A specialized workforce organized into functional silos is the key to productivity”
The heart of the concept of mass production is that complex system can be decomposed into a series of easily manufactured pieces. The production of these pieces can then be streamlined and created by a specialized workforce that sequentially processes each step of production. An underlying assumption is that if each one of those pieces is built in a high quality fashion, the assumption is that the system as a whole will be of high quality.

Many game developers embrace this strong division of labor. The game designers sit in one area of the office and plan the game. The programmers sit on another floor and implement tools and game systems. The artists are outsourced. Each group is managed based on meeting individual goals associated with their specialized task. The work then flows through each team in a regimented fashion with very narrow bandwidth communication between each group. The design documents and Gant charts describe who should pass off what materials when. And the whole system hums along like a giant clockwork machine.

This does not work. Developing each aspect of a game in a vacuum leads to the following:
  • A rigid inability to change. When an artist realizes that they can improve their process by changing up a few steps, there are often few channels of communication or incentives for communicating these changes to other groups. Often each silos will actively attempt to kill change in other silos in an attempt to “stick to the plan.”
  • A lack of an overall vision for the product. When change does occur (and it inevitably will), each silo begins to drift out of sync with one another. If the drift goes far enough, each group will end up with distinctly different visions of what the end product should be.
  • Isolated silos of workers protecting their own turf. With separate goals and visions comes conflict. Dominance games, unhealthy compromises and apathy are common.
  • Massive integration costs. Often games are integrated together at the very end of the production cycle. Many projects that are not playable in whole until only 20% of the schedule is left. The cost of shoehorning divergent systems and teams together after months of primarily independent development tends to bring up substantial technical and personnel challenges that no one predicted.
Having a team filled with skilled experts is a good thing. It ensures that you don’t end with jack of all trades, but master of none. But once you get those experts, you should seat them together and encourage cross training between disciplines. This ensures a shared vision and helps reduce sub-optimization.
  • Sit cross functional teams together. Being within shouting distance of your artist or your programmer increases the bandwidth that you have for communication by a factor of 1000. This means that the vision for the project is constantly reinforced. It also means that experts from each discipline can come together to solve very tricky problems in a relatively straightforward manner. You’ll come to decisions in 1/10th the time and your decisions will be more well rounded and better informed.
  • Make each team no larger than 10 people. When you get more than 10 people, communication suffers. Maintaining group cohesion requires more management and ape-like ‘social grooming’ time. Teams of around 5 to 10 typically have the highest per person productivity. String multiple teams together with a system like Scrum if need be.
  • Build working games, not isolated systems: Integrate early and often. This goes hand in hand with iterating rapidly and prototype driven design. Each cross functional team has everyone they need to make a complete working game from the start of development. By integrating early, you’ll exercise your development pipeline and you’ll encourage each discipline to being working together early in the project.
Myth: “There is one game designer who holds the vision for the project”
The artist of the previous century has been lionized as a lone creator who imagines a visual in their head and single handedly copies it onto paper, film or clay. On the traditional art project, single artiste owns the creative process from concept to execution.

Shakespeare, Picasso, Rodin dominate our art history. As tribal apes, our innate bias is to assign ownership and dominance to a few individuals at the top of the social pyramid. If the vast majority of publicly celebrated creative works of the past have been attributed to a single artist, then surely game design must follow the same model?

The only problem here is that most games are not created by a single person with genius level skills in a mature craft. They are team activities that involve the creation of complex, new-to-the-world interactive systems.
  • Games represent a class of problems that benefit greatly from collaborative problem solving and use of specialized skills. It is difficult (though not impossible) for a single person to make a modern game. Teams typically produce more enjoyable, more fully realized experiences.
  • Communications issues dominate the creative process, not individual creativity. It is more likely that 10 moderately creative people who can communicate will create a great game. A massively creative person who cannot communicate is outside the game design sweet spot.
  • The ability to solve new problems is more important than the mastery of craftsman-like skills. Game design involves exploring and manipulating complex system that have highly unpredictable results. Every day presents a new set of problems that no one in the entire history of the world has ever witnessed. This is very different than a person getting to spend ten years working in a stable medium such as oils or clay that haven’t changed in the last century.
These are big beefy differences between game design and traditional art that have a deep impact on the process of creating a game. When your team insists on following the model of a single grand designer, expect the following:
  • Communication issues come to a boil: Team conflict increases as people feel they are not being heard. Talented team members may leave the team.
  • Artistic quality is low: When one person makes all the decisions, they tend to ignore the expertise that is inherent in all the other team members. A thousand little decision that could have been made with expert knowledge are left up to a single person who cannot possible understand all the nuances. The result is Star Wars Episode One.
So when you get down to the practical matter of making games, the historical metaphor of the lone creator offers few if any practical lessons. Certainly, the tale of the lone creator is appealing and perhaps inspiring, but by no means does it represent the pragmatic sweet spot of modern game development. Instead consider the following:
  • Train everyone on the team in design. There can still be someone who champions design concepts, but everyone on the team should know the techniques, practices and philosophies of game design. If the lead designer is hit by a bus, the rest of the team should be able to quite merrily finish up the project.
  • Use a coaching model to lead the team. Instead of saying that there is a king figure from which all design flows, push out responsibility to the team members and use leadership positions to encourage learning and transfer of wisdom. The best game design ideas will come from the devs in the trenches. It is the leader’s job to unblock the flow of ideas from bottom, not push ideas onto the team from the top.
  • Reward the team, not just the leadership: Everyone on the team makes the game, not just a few leaders. It is easily to fall into the trap of ascribing success to the inspired leadership and failure to the team. Act against the biases inherent in our damned monkey genes to prevent stratification within the team.
What happened in the rest of the world
Much of this advice may seem counter intuitive or impractical. The majority comes from hard won experience trying to fix systems that were broken.

Just as software development was discovering the tenets of “Do it right the first time,” manufacturing was abandoning intensive upfront planning and design. About three decades ago, Japanese firms introduced the concept of lean manufacturing with an emphasis on strong team work, continuous innovation and just in time delivery. Decisions are made as late as possible when the most information is available. The workers at the lowest levels of the organization drive innovation, not planners detached from actual work conditions.

Lean manufacturing brought about a revolution in manufacturing efficiency. Quality and innovation increased while development times plummeted. The massive planning phases and risk avoidance of previous generations turned out to be more of a burden than a benefit. Those who did not adopt the new agile methods of production where driven out of business.

I expect a similar transition to occur in the game industry over the next decade or two. The market abhors waste and our industry is currently very wasteful of its development talent.

Lessons from the straw man
There are many game developers who no longer build their games using massive upfront design with regimented silos of specialized workers. Throughout the industry there are bright spots of individual developers doing great things to make the process of game design more agile and responsive to customer needs.
  • Valve is known for its cross functional Cabal system.
  • Spore is known for its strong prototype driven development and procedural content
  • High Moon is known for its agile software development techniques.
We are all trying to design a great game. It is worthwhile to note what does not work. More preproduction is not the answer. Bigger teams are not the answer. Finding the one right game designer is definitely not the answer. Game developers need it burned into their skulls that project that follow the “Get it right the first time” philosophy tends to be devoid of innovation, over budget and lacking creative cohesion.

The process of game design is undergoing a fundamental shift. As an industry, we moving beyond our primal fears of failing to complete a game and are beginning to ask “How do we build the right game?” In order to do so, we must throw away many of our borrowed practices.

So if game design is not the act of a creative genius passing down tablets to the team from on high, what is it?
  • Game design is about listening to customers and getting rapid feedback on working software, not writing fantastical design novelettes.
  • Game design happens throughout the development process, not just in the pre-production phase.
  • Game design is a collaborative team activity, not a solo activity.
Take care

Lean software development: An Agile Toolkit for Software Development Managers
This book is a good overview of how lean manufacturing concepts can be applied to software development. Of particular interest is the concept of ‘waste’. Highmoon claims that some of the exercises suggest a 50% reduction in cycle time is possible in their current development techniques. That is awesome.

Valve’s development process
Valve is a fascinating example of applying many of the principles mentioned in this article to a linear “Disney ride” FPS.

An illustrated explanation of reality of game design planning
I love these pictures. They are so spot on.

Agile development blogs