Directory of Posts

Lost Garden has turned into a rather substantial archive of game design thoughts. In order to help you find essays that you are interested in, I've finally performed a bit of house cleaning and tagged all 180+ posts. Go forth and explore!

Quest: Which essays are "Worth Reading"?
I'm looking for the essays that you found to be more influential on your thinking about games. I'd like to bubble those to the top of the site by marking a handful with the Worth Reading tag. I've tagged a few, but I'd love to hear your thoughts.

Popular

• Worth Reading: <-This is a good starting place if you are new to the site
  
• All Essays
• Free Game Graphics
• Game Prototyping Challenges
• Science of game design
  

Game Design Science

• Science of game design
• Skill chains
  
• Game genres
• Artificial emotions
• Test driven design
  
• Magic paintbrush
• Play styles
  

Game Design Craft

• Business
• Game applications
  
• Cost effective game design
• Indie
• Localization
  
• Prototyping techniques
  
• User pain
• Online games
• Serious Games
• User generated content
• Work life balance
  
• Sharing game designs
  

Game Prototyping Challenges

• Shade
  
• Play with your Peas
• CuteGod
• Celestial Music
  
• SpaceCute
  
• Secret Life of Aliens
• SpaceCrack
• Tree Story
  
• Help Wanted
• Crazy ideas
  

Resources

• Free game graphics
• Links
• Silverlight
  

Game Observations

• Game design reviews
• Wii
• PSP
• DS
  

Conferences and Articles

• GDC
• Project Horseshoe
• Gamaustra
  

Personal

• Personal posts
  
• Valentines
• Lost Garden

Feel free to send any comments or errors to danc [at] lostgarden [dot] com.

Read more!

Shade: A game prototyping challenge

As a redhead, there's a little game that I play every day in summertime called "Stay in the Shade". The rules are simple: make it to my destination as quickly as possible while avoiding all possible sunlight. This involves hopping from shade patch to shade patch. The cost of failure is the dread Irish Tan. These bizarre antics were inspiration for a game design called Shade.

As with any of the designs you find on this site, I heartily encourage you to prototype it and use it as a learning project. I know that there is a group of you itching to try out the latest 3D engines with sex-a-licious real-time shadows. This is your chance to finally use the technology in a way that produces meaningful game play.

I'll give out the much coveted Bronze, Silver, and Gold Lost Garden badges to anyone who creates a worthy prototype.

Basic gameplay
You play the part of a rugged mushroom rancher who must collect adorable sentient mushrooms living in the shade. All you need to do is run up to a planted mushroom and touch it. It will pop out of the ground and start following you around. Lead it back to the start location and you'll be awarded multiple point based off its size.

Unfortunately, it is a scorchingly hot day. You can meander about the landscape of giant grassy blocks with impunity due to your meglo-awesome wide brimmed hat, but the mushrooms wilt quickly in sunlight. To lead them back successfully, you'll need to keep to the shadows and plot the optimal path home.


Basic Elements

• Player: The player can move about on a 2D plane using the arrow keys or a joystick.
  
• Blocks: Strewn about the landscape are blocks that cast shadows.
  
• Planted mushrooms: In the shadows of the blocks, planted mushrooms will slowly spawn over time. If left alone they will slowly grow in size.
  
• Mushrooms: If the player runs into a Planted Mushroom, it will pop out of the ground and start following the player's motions exactly. If multiple mushrooms are collected, they will follow in a line behind the player. A mushroom can last in direct sunlight about a second before they expire. This amount of time is cumulative and is shown by slowly shrinking the mushroom as it is exposed to more sunlight.
  
• Homebase: This is a spot on the ground that you need to lead the mushrooms back to in order for them to be counted.
  
• Mushroom score: In the upper right hand corner of the screen is the HUD. The most important element is the Mushroom score that shows you how many mushrooms you've collected so far today.
  
• Day timer: The day slowly progresses from morning to evening over 15 minutes. The shadows change position as the day progresses.
  

Winning the game
The game is over at the end of the day. Total mushrooms collected is entered into a highscore table.

Technology
We've had lovely real time shadows for quite some time, but very few designs take advantage of the technology. Luckily there are an immense number of cheap 3D engines that can pump out real-time shadows. Some options:

• XNA: http://creators.xna.com/
  
• Unity: http://unity3d.com/unity/features/shadow-and-light

Not so long ago, this tech was the exclusive domain of techsperts like id and Epic. But now there are no excuses. And the very clever folks will figure that you can make this game in a 2D engine with a little finagling.

Art
Since this design is likely a 3D game, I'm not providing art assets. I recommend that you use cubes and other primitives for the various elements in the scene. They are inexpensive, highly effective and can always be replaced at a later point with more advanced models once you've proven out the gameplay.

With this type of game, a good amount of pleasure will come from the motion of the mushrooms following the player and the movement of the shadows over time. Slick graphics can enhance this, but they aren't necessary to find the fun. Again, no excuses.

Advanced gameplay
Once the basic gameplay is in place, there are immense opportunities for more interesting variations.

• Movable blocks: Blocks that you can push around allow you to create optimal paths for harvesting mushrooms.
  
• Muncher: Once a planted mushroom grows to a certain size and it is hit by the sun, it turns into an AI driven creature called a muncher. Munchers find a nearby green block (also known as a bush) and start munching on it. This reduces the size of the block and therefore the amount of shade it provides. Munchers can be stunned and killed by running into them repeatedly.
• Bush seed: A dead muncher turns into a Bush seed. A bush seed is an object that can be collected by running over it with the character. If you press a button, the bush seed is planted on that location and begins to grow.
• Multiple days in a row: What happens to the landscape if you let the world run for multiple days? With the inclusion of bushes and munchers, we have a self balancing ecosystem. As you plant more bushes, there is a greater chance that mushrooms will turn into munchers, which in turn reduce the bushes. Can you turn a simple landscape into a mushroom plantation?
  

Balancing
This is the sort of game that lives or dies based on balancing all the various elements. There are a number of variables that you'll need to mess about with

• Size of the blocks
• Number of blocks and shadow area
• Spawning rate of mushrooms
• Size of mushrooms
• Amount of sunlight to kill a mushroom.
  
• Speed of the character
• Size of the map.
  
• Size of the viewport onto the map.
  

I don't have the answers. You'll get the answers by iterating on the basic design dozens, if not hundreds of times. Keep me updated and I'm happy to provide feedback on works in progress.

The Lost Garden Awards
Once again I'm giving out the always desirable Lost Garden badges for any prototypes that result.

• Bronze Medal: You built an interesting software toy. If you make an attempt at a design and it is interesting to futz about with, you get the Bronze Medal. Most people never get a Bronze medal due to the simple fact that they prefer to sit around and think rather than make something. Simply by doing (instead of not doing), you join an elite club.
• Silver Medal: You found the fun. You've iterated on your design and have identified a few key elements that make the game enjoyable. There is at least 5 minutes of interesting play. It likely isn't polished and some of the higher order reward loops are broken, but the core is there. If past challenges are any indication, I'll give out only a handful of Silver Medals per challenge.
• Gold Medal: You made the fun repeatable. The game that you've built is entertaining enough that I'm willing to play it for 15 to 20 minutes. This is a hard level to reach and it is only populated by the most elite cadre of weekend warriors. An entire production team could be seeded by your efforts. To reach this level, you've made some critical design steps beyond the initial concept and built unique and sustainable gameplay based off dozens of game play iterations. To this day, no one has won a Gold Medal. You could be the first.

You need to post a public, playable version in order to be eligible. I'll issue the rewards about one month after the initial challenge is posted. If something comes in after the original deadline has passed, I'll add it retroactively to the award post. If you win a Bronze or Silver, you can still come back later and make an attempt at the Gold. Anyone who gets a Gold medal is an automatic rock star in my book.

What do you get if you win? First off, you get the right to post a snazzy LostGarden medal on your website. Most importantly, you get that warm fuzzy feeling in your tippy-tip toes that stems from a job well done.

Conclusion
Shade is an interesting game design to me for the following reasons

• Exploration-based play: The joy is in exploring the ever changing landscape and finding mushrooms and interesting paths back home. It is more strategic than action oriented.
  
• Simple controls: All you need to play are directional controls and one button. It should be pretty easy to pickup.
  
• Non-violent: In general there is very little combat. I like this. I can imagine the title having a very meditative feel.
  
• Uses real-time shadows for some unique gameplay. Real-time shadows have been used for sneaking games, but little else. Surely it is time to expand the number of games that use this fascinating technology.
  

Enjoy! If anyone makes something and puts it online, I'm happy to discuss it on the website in a follow up post.

take care
Danc.

Past challenges

• Play with your Peas
• CuteGod
• SpaceCute

Mockup

• Adobe Illustrator (CS3) Mockup file
  

Read more!

What actitivies can be turned into games?

Techniques for designing consumer scales

Recently, my amazing wife picked up a copy of Wii Fit. No, this is not a review.

Here is something you may not know about my wife. For the past year, she's been dealing with a rather serious, debilitating illness. One side effect is considerable and undesirable weight loss. On the positive side, she has enjoyed shopping for a new wardrobe to match her more petite frame. On the less positive side, many stores no longer carry clothes that are small enough to fit.

So when the Wii Fit first booted up and cheerily prompted her to set a goal, she decided to try to get her BMI back up to the 'normal level'. Every day or so, she's been exercising, weighing herself and doing yoga. So far she has found the game to be convenient and highly motivational tool for helping her to track her weight.

We've had other exercise equipment around the house before, as well as gym memberships, yoga classes, etc. None of them has been as motivating as a simple set of exercises wrapped in a system of game-like rewards. My wife's experience with Wii Fit speaks volumes about games potential to turn an often mundane activity into entertainment that is delightful, exploratory and highly meaningful.

Thinking beyond scales
Yet, who would have ever thought that weighing yourself could be turned into a game? Miyamoto did, but then again he is widely considered to be an uber genius. The skeptical observer might imagine that successful cross-over games like Wii Fit are one-in-a-million success stories. Suppose it works for Wii Fit, but nothing else.

However, if the lessons of Wii Fit were broadly applicable, entire industries could be transformed. Games are a competitive advantage that can turn a commodity scale into one of the hottest consumer products of the year. In highly competitive markets, that is the sort of product design super power that lets innovative companies walk away with market share.

As I contemplate my wife's success with the Wii Fit, I'm struck by a multi-billion dollar question: What other activities can you turn into a game?

Almost anything
First, though there is no doubt that Miyamoto is a genius, what he does is reproducible by mere mortals. He is able to apply his game design skill (or at least his greenlighting abilities) to non-traditional games like Wii Fit because he understands game design at a very atomic level. Here is another way of looking at it. A craftsman builds tables the same way he was taught by his father and his grandfather can only build tables. But someone trained in mechanical engineering can use the fundamentals to build chairs, bridges, cars or even cathedrals. Similarly, by understanding the fundamental science behind traditional games, you can apply the theoretical tools of game design to transform wildly divergent activities into games. I've written about some of this in the past with essays on skill atoms.

It turns out that most learnable skills can be turned into a game. However, there are constraints. A skill must meet the following criteria before it can be turned into a game:

1. Decomposable into simpler skills
2. Skills can be nested
3. Skills can be arranged in a smooth learning curve
4. Skills are measurable
5. Performance can be rewarded
6. Skills are locally useful.

Let's look at these one by one.

1. Decomposable into simpler skills
Complex learnable skills can be broken down into sets of easily acquired core skills. Players can only learn so much at once and overly complex skills overwhelm all but the most persistent players. By breaking skills up into digestible chunks, you are now able to apply many of the basic techniques of game design.

In Wii Fit, the complex activity of "Becoming fit" is broken down into skills associated with using the board, testing balance, endurance activities and more.

2. Skills can be nested
Complex skills should build upon and reuse earlier skills. Advanced skills are best taught by the extension of existing skills, not introducing new metaphors.

Game design is built around the idea of core mechanics, skills that are exercised over and over again throughout the game experience. If you can't find a set of basic reusable skills that can be incorporated as the foundational elements of more complex skills, players will deem the activity shallow and lose interest.

In Wii Fit, the act of balancing while following rote exercises is used repeatedly throughout. It is an activity that is easy to learn, hard to master and contributes nicely to a wide range more advanced activities.

3. Skills can be arranged in a smooth learning curve
There is a smooth ramp from learning easier skills to learning more complex skills. Initial skills should take only seconds since they leverage existing skills. Afterwards, learning activities should build in complexity until they take minutes, then hours. If the initial learning ramp takes too long, players will be confused or bored and stop playing.

In Wii Fit, you can learn to use the board in seconds. Just step on it. However, more advanced games are slowly introduced until must spend hours of your time to unlock that last activity.

4. Skills are measurable
The game can detect when a skill is used correctly or incorrectly. Without this the game cannot provide timely feedback that pushes the player in the right direction.

The fact that Wii Fit is a giant sensor is perhaps to be expected. Within limits, it knows exactly what you are doing and when you doing something incorrectly. This is a dramatic difference from most exercise equipment or a workout video.

5. Performance is rewardable
The game can provide the player with a timely feedback and rewards. If the game provides feedback too late or in a manner that is disconnected from the original action, the player won’t learn.

Unlike traditional exercise equipment, Wii Fit judges your performance. It lets you know when you are doing poorly and it praises you when you are doing well. It is not a passive tool, but one that seeks to mold you. This is how games work and is an integral part of their success as a teaching tool.

6. Skills are locally useful
The skill can be exercised in a useful manner by the player in a variety of meaningful local contexts. If the skill isn’t useful, the behavior will extinguish.

Local utility is a tricky concept for many, especially those trained to think in terms of filling measurable customer needs. It basically means that the player finds an activity useful in the short term within the local context of the game. Grabbing a coin in Wii Fit may accomplish absolutely nothing in the grand scheme of the player's week. However, it does let the player unlock a new exercise. So for the moment, the player considers frantically gathering coins to be a completely utilitarian activity.

Skills that are eliminated by these constraints
What skills are eliminated by these constraints? Surprisingly few.

The biggest sticking point often ends up deciding how to measure complex skills. With Wii Fit, they needed to engineer an entirely new device. It is not uncommon to invest substantial amounts of effort just gathering the right data so that you can reward the proper skills accurately and in timely manner.

Machines alone have a limited understanding of many cultural human activities. In these situations, you need to build your games to use other human beings as measurement instruments. The rating techniques of sites like Hot or Not or Amazon.com are widely applicable.

The other constraints end up being easily worked around with a little bit of thought and prototyping to find what works.

Conclusion
When I look at our list of six constraints, it is obvious to me that there are a plethora of skills that are just waiting to be turned into games. Games like Wii Fit or Brain Training may seem exceptional strokes of genius, but in reality they are merely the tiny tip of an immense iceberg. Almost any human skill, be it physical, cultural, political or economic can be turned into a game that enlightens and enables.

As more leisure games emerge that mediate and accelerate the acquisition of skills, there is going to be a economic incentive to spread the science and craft of game design far beyond our tiny game industry. Game design is not just about games. It is a transformational new product development technique that can turn historically commoditized activities into economic blockbusters.

This morning, my wife came back from her morning Wii Fit session and proudly announced to me that she just worked her way back to her normal weight range. She is still on the light side and this odd little game was by no means the only source of her success. But it had its place as a tool that measured, encouraged and rewarded progress. As such it was worth every single penny.

When I look at Wii Fit and I hear the delight in my wife's voice, it is apparent that game design is again breaking out into the broader market. Obviously it isn't happening quite in the way many have predicted. The harbinger of game's ascendancy to all aspect of the modern life is not some piece of evocative art or Citizen Kane-a-like. Instead, our future appears in the form of a glorified bathroom scale. Still, if we can improve people's lives with a bathroom scale, just imagine how games can transform the rest of our world.

take care
Danc.

Read more!

Lostgarden looking for brilliant programmer in Seattle

a mystery project

Summer project time! I've got an intriguing new design that is best explored by the sort of in-person rapid prototyping that I love. To that end, I'm looking to team up with a talented programmer or two from Seattle/Redmond. It's a bit like getting a band together.

My dream is to meet up every Sunday at a local coffee shop, riff about what we've done that week and come away energized and ready to build some more.

• Location: Seattle/Puget Sound area is a must. (Otherwise, it is hard to do the coffee shop thing)
• Skills: Solid Flash, Flex or Silverlight skills. Previous experience with Java, C++, or C# is great as long as you are willing to learn Flex. Back end skills are also helpful. The project is 'technically interesting' and is best tackled by someone who is more of a programmer than a scripter.
• Time commitment: 10 hours a week for about three months. Anything less I've found doesn't make it worth your time.
  

I'd contribute art, design and Cheetos (organic or radioactive). If you are interested, drop me a note at Danc [at] Lostgarden [dot] com. Send along a portolio if you've got one and tell me a little bit about yourself.

Take care,
Danc.

Read more!

Improving Bug Triage with User Pain

The traditional bug triage process is miserably inefficient. Over my decade in this industry, I’ve spent months of my life sitting in windowless offices manually reviewing (and re-reviewing) thousands of bugs. Often times, there are three or four folks on the triage team, typically the most skilled people on the team, sitting about and bickering for hours over the finer points of obscure bugs. Politics, boredom and arbitrary decisions are unfortunately common. The result is wasted time and poorly managed bugs.

So we came up with a better way.

User Pain is a technique I’ve been using for many releases across multiple teams. It involves sorting bugs on a single unified scale called User Pain that takes into account common bug ranking criteria. I’ve found that it can reduce the cost of triage, help teams ship on time and greatly clarify which bugs you should be fixing right now. This essay describes how User Pain works and some best practices for implementing it on your team.


Problems with current bug triage
Traditional bug triaging is a time consuming and tedious process. Bugs come into a bug database with little prioritization, the team leads sort and rate each problem and then assign them to the appropriate members of the team. This process tends to run into several issues:

• Lack of shared criteria: Different people often value different aspects of a bug, which leads to unhealthy disagreement. A designer might think a usability issue is a critical fix, while a programmer might be concerned about a crash. With no common criteria, it is hard to build consensus quickly.
• Wasted time: Often the highest skilled team members are required to triage bugs. They spend hundreds of hours poring over mundane issues again and again. This is time that could be better spent improving the product.
• Bottlenecks: Bugs are often required to go through a review process so that precious developer time isn’t spent on bugs that would have otherwise been punted. The loop from the submitter to the triage team to the developer can cause delays for critical bugs.
• Big undifferentiated bins of bugs: Since the incoming rate of bugs is often higher than the fix rate, large piles of bugs will accumulate for each developer. If a developer has 50 bugs on their plate, they will fix them in a semi-random order or rely on micromanagement by the triage team. The first tactic means critical bugs are sometimes left to be fixed until the end. The second means more time is wasted on reviewing bugs.
• Triage burn out: After reviewing thousands of bugs, many triage teams stop caring or become fixated on a few bugs at the cost of reviewing others. The result is that some bugs are poorly triaged and the quality of bug ranking in the database is low.

These are the problems we want to solve with User Pain.

The basic system
User Pain is yet another technique inspirted by the world of Lean Manufacturing, the ancient mother of so many Agile practices. The technique was original developed in the 80’s as a method of efficiently classifying product defects on manufacturing lines. While some of the ideas are new to software development, the core concepts have been tested in intense product development situations for decades.

At with many agile techniques, User Pain isn’t all the complicated.

1. Rank each bug on several criteria
2. Combine those criteria into a single score called User Pain
3. Sort all bugs by User Pain into a public list
4. Start fixing the most painful bugs at the top of the list.

There is a distinct philosophy at work here. First, empower bug submitters to easily create well formed, well classified bugs. Next, give the team the tools and information necessary to make smart decisions about what to work on first. Finally, encourage practices that make it easy to put quality first. Instead of relying on expert managers, you rely on a well informed, empowered team. As a result, the User Pain system removes most of the need for a triage middleman.

Let’s dig into each step and explore the devil in the details.

Step 1: Rank each bug on several criteria
Bug submitters use a simplified bug submission page that clearly lists three factors: Type, Likelihood and Priority. Each factor has multiple values, listed in order of impact. At submission time, the bug submitter rates the bug.

Three bug rating factors
Here are the three factors that I’ve been using.

• Type: What type of bug is this? For example is it a crashing issue, a problem with localization or a matter of visual polish?
• Likelihood: How likely are users to experience the bug? For example, does everyone run into the issue or do only a few users run into it?
• Priority: Of the people who experience the bug, how badly does it affect their experience with the product?

These particular factors have been battle tested for many a release and were selected for the following reasons.

• Good coverage: These cover the range of concerns expressed by most stakeholders. Type includes business priorities while Likelihood and Priority help classify user impact.
• No overlap (aka orthogonal): A bug can be rated on one factor without affecting how you would rate the other factors. This allows you to rate each factor in isolation and greatly improves the objectivity of the results.
• Small number: There are few enough of them that they don’t overload the bug submitter. It is easy to add more factors for various edge cases, but typically this results in a cluttered and confusing bug submission form.

Use anchored scales
Now that we have our factors, each one needs a rating scale. At this point, we do something slightly tricky. Each point on the three scales is anchored to an objective description. Here are the anchored scales I prefer:

Type (What type of bug is this?)

• 7: Crash: Bug causes crash or data loss. Asserts in the Debug release.
• 6: Major usability: Impairs usability in key scenarios.
• 5: Minor usability: Impairs usability in secondary scenarios.
• 4: Balancing: Enables degenerate usage strategies that harm the experience.
• 3: Visual and Sound Polish: Aesthetic issues
• 2: Localization:
• 1: Documentation: A documentation issue

Priority (How will those affected feel about the bug?)

• 5: Blocking further progress on the daily build.
• 4: A User would return the product. Cannot RTM. The Team would hold the release for this bug.
  
• 3: A User would likely not purchase the product. Will show up in review. Clearly a noticeable issue.
• 2: A Pain – users won’t like this once they notice it. A moderate number of users won’t buy.
• 1: Nuisance – not a big deal but noticeable. Extremely unlikely to affect sales.

Likelihood (Who will be affected by this bug)

• 5: Will affect all users.
• 4: Will affect most users.
• 3: Will affect average number of users.
• 2: Will only affect a few users.
• 1: Will affect almost no one.

An anchored scale describes each point on the scale with specific, objective criteria. As long as the item being rated meets the criteria, you know what value it should be assigned. An anchored scale is preferred over a relative scale (ex: Please rate this problem from 1 to 10) since there is less subjective judgment involved in assigning the value.

Display the anchored scales prominently on the UI where bugs are entered
Anchored scales are only useful if the team can see the descriptions.

On one team, we only displayed values 1 to 5 in a drop down list and asked submitters to remember what each value meant. This wasn’t very effective. People treated each factor as a relative scale and would rate items by ‘feel’ initially instead of referring to the definitions of each value. The end result was that bug ratings were heavily influenced by personal preference.

Instead, build a bug submission UI that lets the submitter read the descriptions as they rate the bug. Radio buttons work wonderfully since you can place all the descriptions right in front of the user. A drop down that contains the descriptions is also feasible.

This may seems like a minor issue, but people are usually in a hurry. If you don’t make the rating process painless, they’ll happily toss random data into your bug database. Improving the clarity of your bug submission UI is the single cheapest thing you can do to improve the quality of your bugs.

Who enters bugs
This system is intended to be used by members of the development team. Artists, testers, developers, designers, project managers and producers all should be able to understand the criteria and enter well rated bugs. They'll need an understanding of the core scenarios and the target user. The better that you educate the team on what you are doing and who you are doing it for, the better your bugs will be.

This system does not work well for bug submissions by external users. They don’t understand the terminology and tend to create bugs that are poorly formed. A good solution is for a tester to reenter the user bugs with the proper ratings and format. It is a form of triage, but is a relatively minor cost in the grand scheme of things.

Benefits
Using anchored scaled for rating bugs upon submission has the following benefits.

• Less reliance on personal opinion: A tester who has some domain knowledge can quickly classify the bug into one of the buckets without relying overly much on their personal opinion. The result is that even when multiple people independently rate the same bug, the final user pain tends to cluster very tightly around the same values.
• Harder to game the system: Anchored scales also make it harder to simply ‘bump the pain’ up for a bug that has become a hot topic. Due to the clarity of the rating categories, poorly rated bugs are usually flagged by the next person who looks at them.
• Push triage to the submitter: When you can trust the ratings set by bug submitters, you can eliminate a large portion of the triage process. Provided that your submitters have basic domain expertise, 80-90% of the values that they set during the initial submission stay the same throughout the life of the bug. This means that there is less need for reviews to reset random values.

Step 2: Combine those criteria into a single score called user pain
Once a bug is ranked on all three factors, you multiply the numbers together to get the User Pain score. User Pain is a single value that can be used to compare widely divergent bugs. User pain deals with the gray area in which most bugs live.

• Obvious fixes: A bug that the users hate, blocks major user scenarios and affects everyone causes a big hit to perceived product quality. So it receives a very high pain score.
• Hard calls: A bug that occurs all the time, despite the fact that it blocks only minor scenarios, still receives a moderately high score.
• Tricky punts: A crash that is never seen by anyone receives a low score.

The basic equation for calculating User Pain is as follows:

• User Pain = Type * Likelihood * Priority / Max Possible Score

User pain is auto calculated when the bug is entered and whenever the bug changes. After you calculate user pain for a set of bugs, you’ll find that you have a smooth spectrum of bugs ranked from 1 to 100% Pain.

Benefits

• One value for comparing different bugs: Instead of forcing users to juggle multiple different criteria when comparing bugs, they only need to look at one. This means quicker judgments and easier sorting.
• Fewer big bug buckets: No longer do you need to deal with huge swathes of undifferentiated bugs. Instead of dealing with 300 priority 2 issues, you typically will see much more manageable clumps of 3 to 5 bugs with the same pain rating. Bug Maturity, as described in the Appendix also helps spread out the bugs.

Step 3: Sort all bugs by User Pain into a public list
Once you have your list of bugs complete with user pain, you need to display them to your team in an easy to understand manner. I’ve dabbled with custom queries inside bug tracking tools, but my favorite technique is to create the world’s simplest bug dashboard.

The Pain List
The Pain List is a webpage that lists all the active bugs in order of User Pain. You put the highest pain bugs at the top of the list and you make each bug a hyper link that takes you to the bug details in your bug database. Be sure to auto reload the list every 10 seconds or so the data is fresh and reliable.

The Pain List becomes your central dashboard for daily bug management. I’ve gone so far as to make it the homepage on my web browser.

Quality bars
The team can use the Pain List to set easy-to-understand quality bars as exit criteria for your milestones. For example, they can say “In order to release, we want no bugs greater than 30 pain.” At the 30 pain threshold on the Pain List, you draw a line. Anything above the line needs to be fixed. Anything below the line you can ship with.

Quality bars can be more meaningful than traditional bug counts since you are implicitly taking into account the final user experience. Meeting this bar means that you’ve fixed all crashing and unpleasant bugs and the only issues that are left are minor cosmetic ones that are rarely seen by users.

Since you have a finely incremented spectrum of bugs, you can also precisely adjust quality bars based on your place in the release cycle. You could set a high pain threshold if you are dealing with new features. You can tighten the quality bar further for subsequent releases.

Benefits

• One view: One view shared by everyone, including both testers and developers. You don’t have to worry about juggling divergent database queries.
• Simple to understand for all parties involved. There are no specialized tools or incomprehensible graphs. Even management can know where you are at just by glancing at the list.
• Clear understanding of status: If there are bugs above the quality bar, you need to start fixing bugs.

Step 4: Start fixing the most painful bugs at the top of the list
Now that we have the Pain List, we can finally put it to use. Developers check the Pain List daily and fix the highest pain bugs on the list. If there are no bugs left above the current quality bar, they work on feature work. This basic heuristic is a surprisingly efficient method for managing quality.

Assigning bugs
All bugs are assigned to Active upon submission, not a particular developer. When a developer sees a high pain bug that they want to work on, they assign it to themselves. The bug then goes through the standard process of being fixed, tested, and closed by the submitter. In general, developers should have no more than a half dozen bugs assigned at once. They pop items off the list, fix them and go back for more. Hoarding is highly discouraged. So is assigning bugs based on feature area.

Fixing bugs before feature work
All bugs above the quality bar should be fixed before new feature work is started. If you follow this practice, you should exit each sprint with no more high pain bugs than you entered the sprint. Bug debt doesn’t accumulate.

This practice helps you build quality in as you develop. When this practice is paired with solid automated tests, you enter into a whole new world of high quality development.

My bugs
At the top of the Pain List is a section that lists the current user’s assigned bugs. This both helps devs treat the Pain List as their entry into the bug database and it reminds them that they should finish the items on their plate before taking on new work. Since this list is short, it rarely interferes with browsing the Pain List.

Benefits

• Developers always know what to fix: All they need to do is look at the top of the list and there is almost always a bug waiting for them to grab. As a result, developers never need to juggle multiple criteria in their head when deciding what to work on next. Nor do they have to wait on leads or managers to assign them bugs.
• Promotes shared code ownership: The rule ‘fix from the top’ rarely correspond with ‘fix the code that I developed’. Short term, this is less efficient since developers may need to ask questions of the original developer about an area of the code. Long term, the broad knowledge of the code base that comes from fixing bugs outside area of expertise results in higher overall productivity and team flexibility.
• Bugs that prevent you from shipping don't accumulate: The benefits of fixing bugs before features are numerous. The pain of shipping is greatly reduced. Testing is more effective since they don’t need to constantly juggle workarounds to problems that won’t be fixed for months. Finally, the team feels better because they know they are always building a high quality product.

Pitfalls
There are a few pitfalls that emerge when you first try to implement a User Pain system.

Training the team
There are likely people on your team that have been dealing with bugs for decades. Changing the bug tracking system will require retraining before you see positive results.

In my experience, new teams initially rank 80% of the bugs incorrectly because they A) do not use the rating scale or B) do not understand the target user. To fix this issue, keep making the anchored scales highly visible and keep promoting the major scenarios and target user. After people get the chance to enter a few dozen bugs, their pain ratings will become far more reliable.

The temptation to assign ‘cost’
You’ll notice that there is no place for ‘cost’ or technical risk of fixing a bug anywhere in the pain score. This is one factor that most developers immediately request. Despite the temptation, I recommend leaving it out.

• It requires extra effort: 8 times out of 10 the developer actually needs to dig into the code to figure out what is causing the bug before they know how much it will take to fix. If you require ‘cost’ to be figured into the User Pain calculation, you bog down the entire system.
• 99% of the time it doesn’t matter. The cost of fixing bugs tends to fall on an exponential distribution. Many bugs are one or two line fixes. Others rarely take more than a couple of days. Only a very few are truly killer bugs. Flag the exceptions and use a generic bug velocity to track the rest and your results will be just as predictable as if you had costed each and every bug.

The temptation to automate exceptions
The User Pain system is about automating triage. There is a temptation to attempt to automate everything. What about the 1% of the bugs that have the potential to push your release into the next century? When you do stumble upon a bug that will take more than a week to fix, flag it as a ‘killer’ bug. Killer bugs show up in red on the Pain List and an email is sent to the team.

It is now the responsibility of the team leaders to find a solution. They can design around it, postpone it, or even fix it. Now that they’ve been freed of the burden of triage, they have the time to attack the hard problems with great vigor.

The pain score helps keep killer bugs in perspective so that panic is kept to a minimum. There will be Killer issues that are very low pain. It probably isn’t worth delaying the product to fix these. On the other hand, a Killer issue that has high pain is likely to have a serious impact on schedule and should be addressed immediately.

There is a small lesson here. Never build a system, especially one involving people, that aims to handle every exception. You'll destroy what value the process adds by building in all the edge cases. Instead, allow people to raise an alarm so that smart minds can deal with the exception in a timely fashion.

Conclusion
User Pain remains simple despite all the detail I’ve tossed your way. The team submits and ranks bugs. The system calculates user pain and pumps out a fresh list of prioritized bugs for everyone to see. The team fixes the bugs from the top of the list. Those are the essentials.

Teams thrive under this bug process. There is less thrashing and ambiguity. There is a lot less need for micromanaging every single little bug (and every single developer). With User Pain, the responsibility for creating a quality product is placed clearly in the hands of the team. They triage the bugs. They fix the most important ones early. The process exists to give them all the tools they need to make the right decisions. Again, it is about empowering people, not managing them.

User Pain doesn’t work for every team. Nor does it completely eliminate triaging. Anyone who thinks process is a panacea hasn’t worked in this industry very long. However, with your heart in the right place, User Pain is a substantial improvement over sitting in a room and manually reviewing hundreds of bugs. It makes the team more efficient, helps people make better decisions and focuses the team on building quality into the product.

Take care,
Danc


Appendixes

Bug Maturity
Setting quality bar is great for fixing high pain bugs. However, over time you will build up hundreds of older low pain bugs. Since you are triaging less often, the quality of such bugs can be quite low.

You can alleviate this issue is to add a Bug Maturity factor to the pain score. For every day that passes once a bug is entered, you increment its user pain by .2 points. Over time, old bugs slowly rise to the top of the pain list. You can adjust the rate of bug maturation to match the needs of your particular project.

This has two effects

• Old bugs are slowly removed from the system: Either you decide to never fix them or you fix them.
• Small bugs are fixed slowly: Instead of indefinitely leaving small bugs in your product, you end up fixing them in order to meet your quality bars. This helps prevent the accumulation of code cruft.

Tracking Charts

A basic line chart that tracks the number of bugs above your various quality bars works well for tracking bugs. You can compare this to your total bug count as a reference. The ideal trend is that your high priority bugs drop quickly. Warning signs include the following:

• Focusing too much on feature work: The bug count across the board keeps rising.
• Poorly directed bug fixing: The overall bug count is dropping, but the high pain bugs stays relatively constant.

Other metrics of interest include:

• Total Pain: This represents the accumulated impact on the user of all the bugs in the system. Some teams use this as an additional gate to determine if the product should be released or not. It is another way of ensuring that the team doesn't ship with hundreds of small issues that end up causing the user substantial grief. This value is far more meaningful than bug count, but serves a similar purpose.
  
• Average Pain: You can get a sense of the general instability of your product simply by looking at the Average Pain across all bugs. A high average pain, especially one near your quality bar, means that you have a lot of work left to do.
  

Read more!

The Scary List

In every project, there are issues that that frighten the bejesus out of the team. They are so frightening that no one wants to talk about them publicly. The schedule might be impossible. There might be the lurking suspicion that Management does not believe in the project. More commonly, there is a major technical flaw that no one is handling.

Such problems linger over the team. A handful of people hold hushed conversations in hallways or behind closed doors. Secrecy reigns due to fear. There's fear of upsetting team morale. There's fear of losing face with management. There's fear of forcing the project to be killed.

Fear is contagious
Team members are not stupid. A good development team works hand in hand with one another 8 hours a day. People observe body language. They take note when conversation stops when someone walks in the room. They become suspicious and wary.

Fear becomes contagious. Lack of information breeds rumor mongering as others step up to fill in the blanks with conjecture, often wild, about imagined consequences. Blame is bandied about as frightened people attempt to find comforting answers to imaginary scenarios. All the while, the problems do not go away. Instead, they fester, turning healthy teams into a paranoid self destructive wrecks.

It doesn't have to be this way. Nine times out of ten, the scary issues that cause so much panic are completely solvable. They simply need the harsh bright light of public acknowledgment shone upon them.

The Scary List
Here's a technique that I've used on various agile teams to good effect. Every day, we have our team meeting and on one of the walls is a white board containing the heading 'Scary List'. When someone catches whiff of a problem or rumor that could potentially sink the projects, we jot it on the list.

Sometimes, this is enough. Just publicly acknowledging the issue and giving it a name can clear the air. It becomes okay to talk about it out loud. By naming your problem, it is no longer an amorphous mysterious rumor. Instead the team is faced with a defined problem. The ideas start flowing between team members. People discover the sort of solutions that only appear when everyone puts their heads together. Many times, individuals will quietly grok the issue and adjust course to correct it.

Other times, the problem is pressing and needs to be driven to a conclusion sooner, rather than later. At this point, someone volunteers to drive a solution for it. Every day, at the standup, the champion lets the team know how progress on the problem is coming along. In short order, most problems stop being quite so frightening.

Some problems are extra scary because the team feels like they are out of their control. For example, the team might get axed if some other group fails to deliver a particular component. Have a five minute discussion about what is under your control for a particular issue and what isn't. Again just making the assumptions public does wonders.

Next focus on those issues that you can control. Are there contingencies? Can the team flow like water around immovable obstacles? It's that crazy empowerment thang and it works.

When an issue is no longer scary, remove it from the list. It doesn't need to be complete. It doesn't need to be fully planned out. However, if the team no longer fears the problem, then it should be wiped away and converted into more mundane backlog items or tasks on the board. Otherwise, the list loses its impact. No one likes unnecessary fear mongering, even in the form of a process meant to manage fear.

The scary list is:

• Simple: It is a hand written list. It takes five minutes to create and manage.
• Public: The list is displayed in a large format in a public area frequented by the team. You can't miss it.
• Fresh: Only currently scary items are on the list.
• Actionable: You are either turning the scary items into less scary problems or you are removing items from the list.

Courage
In the very first Agile book I read, there was a large section on 'Courage'. I must admit that I didn't really understand why it was there. The word 'Courage' seemed like such a fluffy bit of New Age nonsense that didn't belong in the crisp world of software engineering.

The Scary List is a simple technique, but it only works on a team where people have the courage to talk about their fears. You need the right cultural environment for this to occur.

• No retribution against the person who brings up a sensitive issue.
• The problem, once raised, becomes the team's problem, not an individuals.
• The exercise is about solving the problem, not placing blame.

This doesn't happen naturally for most teams. They need to practice. You need to lead by example. If blame starts being thrown about, redirect the conversation to the problem at hand. If people claim that they can't do anything, identify the pieces that they can change. Eventually, people will experience success by using the Scary List. With that success comes the confidence to face the problems that frighten them.

Courage, you see, is also contagious.

take care
Danc.

Read more!

The joy of 2D avatars

I've been looking at 2D avatars lately. It's been a fascinating trip into a wierd little area of game art that I haven't dabbled in before. Like quite a bit of game art, there is a very obvious craft involved in the creation of 2D avatars. It reminds me a lot of the techniques that went into old school pixel art or tile creation. You build your pieces just so according to a very particular set of rules. Align the hand, align the head and voila, the end result look like a unique character.



I ran across a couple classes of 2D avatars that are worth describing. This list is by no means exhaustive and what you ultimately end up using completely depends on the type of game you are making. The different styles can be classified by:

• Perspective: What view is the avatar seen from?
  
• Construction technique: How is the avatar assembled?
  
• Animation: How is the avatar animated?
  

Perspective
Front view: A frontal view of the character. The benefit here is that the character is often symmetrical which reduces the skill needed to draw a character. The downside is that the character is almost always looking straight out at the viewer. May PlanetCute characters are a good example of this perspective.

Partial side view: A partial side view of the character where the character is rotated 45 degrees to the left or right. The example above is such a character. This character can interact with objects in the environment, but with subtle (and cheap!) animation of the eyes, look at the viewer. You can make avatars with this perpective move left, right in a believable fashion by simply flipping the avatar. Climbing ladders is less than compelling. :-)

4 (or 8) directions: For each of the cardinal directions you draw a new version of the avatar. The characters in Diablo are a nice example of this style. Having multiple directions is more realistic and allows you to show the general direction that a character is pointing. However, it is again more expensive. If you have an interchangable item on the character, you need to draw 3 different versions for 4 directions and 5 different versions for 8 directions. This multiplies your art expenses.

Isometric: This is similar the partial side view, but usually seen a bit more from the top. This is almost always done with multiple directions.


Construction

Interchangable parts: Most avatars are made out of interchangeable parts. You can swap out a shirt for another shirt. This allows for a vast range of different characters, but They all tend to be built from the same basic mold. Luckily, so does most of humanity, so this system tends to work well for humans.

One piece: Whirled and most single player games uses characters that do not have interchangable parts. All the animation is built into the character. The upside is that you can have great unique animations that really fit the character. Your dragon can breath fire and your balloon beast can float merrily along. The downside is that you need to make unique animations. This is expensive.


Animation

No animation: This is the simplest and is quite common with web-based games. If you can get away with it do so!

Cell animation: The whole avatar or the pieces of the avatar are animated by flipping through a series of frames. This tends to be a specialized skill and good 2D animators are hard to come by. Cell animation is highly evocative and has been the animation technique of choice for ages. The downside is that if you are using interchangeable parts, each part needs to be animated through all the possible animations. This means that the number of animations that your avatar supports is likely to be small since you don't want to bloat the cost of creating each item.

Vector animation: Each piece of the avatar is mapped onto a simple 2D vector rectangle that can be smoothly rotated, scaled and squashed. Add a simple skeletal animation system (the foot bone is connected to the leg bone which is connected to the hip bone) and you can do some reasonable effective animation. The characters in Book Worm Adventures are a great example of this style. If done correctly, this method lets you animate just the base skeleton and swap in parts as desired. The upside is that you can have a huge range of animations with the same basic art assets.


Little lessons learned

Optimize for ease of object creation, not richness of animation or immersiveness: If you are going for virtual item sales, your incremental profits can be broken down to # of items sold * price of items - production cost. You want lots of item variety and you want to keep your item cost down.

With this in mind, the format of your avatar begins to matter a lot. Animation is expensive and makes object creation even more expensive. Multiple directions for your avatar are cool, but are they really worth increasing your content costs by 500%?

Most items are made out of at least two pieces, not one: When you build hair for a character, you have a section of hair that goes behind the avatar's head and a section that goes in front. I've been sketching it all out as a single piece and then chopping it up as needed during the cleanup stage.

Use flat shading or indistinct light sources if you are using vector animation: Since your pieces can be rotated in all sorts of directions, highlights will often look strange when rotated.

The number of slots in your avatar represent sales opportunities: A character composed of a head and torso presents very little opportunity for players to customize their look and feel. After purchasing a couple of items, they are done. By allowing for tiaras, jewelry, wings, thought bubbles and other items, you win by creating additional sales opportunities. The player wins by having more ways of making their character unique.

Style matters: I dress like the guy in The Fly. My closets is filled with row upon row of identical pragmatic clothes. I wouldn't know the difference between a cardigan and a camisole if my life depended on it (I actually had to look it up.)

Yet many avatars, especially those in online games, are ultimately about fashion and style. The cut of the fabric is important. The patterns matter. The colors...don't even get me started on the colors. It is no surprise that some online game companies (like StarDolls) build up such an expertise in fashion that they are launching their own real world clothing lines. So I've been reading women's fashion mags. It's a whole different world out there.


Next Steps
I'll continue dabbling with these sketches. My character drawing skills are not the best, so at the very least this will be good practice.

Which style should I use? I'm leaning towards a side-view avatar with interchangeable parts that uses simple vector animation. The cost of production is low and the style seems to be the best fit for some of the game design ideas I've been mulling over. The current template has spots for custom headgear, a head, eyes, mouth, nose, top, bottom, feet and items held in left or right hand.

Here is one last sketch. Comments and critiques are welcome!


take care
Danc.

References

• Gaia Dream Avatars: http://www.tektek.org/dream/dream.php
• Stardolls: http://www.stardoll.com/en/
• 100 virtual worlds: If you want to see the full range of avatars out there, this is a great start. http://www.virtualworldsmanagement.com/2008/youthworlds.html
  

Read more!

A Services Strategy for Casual Games

Gamasutra posted up an article that has been bouncing around in my documents folder for a little while. The original title was "A Services Strategy for Casual Games", but the new one is a bit more punchy.

One response that I've heard quite a bit is that portals will never allow user data to be released back to developers. This is quite true for most established portals that have traditionally focused on selling packaged goods online. However, middlemen adapt and markets flow around stupidity. More sophisticated variations on sites like http://www.mmoportal.com/ are bound to emerge. If a dozen portals don't want your business, find the one that does. Given time and a exclusive supply of successful games, they'll grow into a bigger fish that can help feed your team.

The portals are engaging in a kneejerk reaction to changing business models. In the long run, do they really think they can keep customer data away from developers when the games that players want are online services? Such companies just end up being a roadbump in the way of progress. A portal that gets irritable about giving up customer data guarantees that their cut of the pie is zero. This is their loss, not yours.

take care
Danc.

Read more!

The Translation Game

The Rosetta Stone: I18N's early best friend

Online games have become an international business. In order to compete in the global marketplace, your game needs to appeal to players in countries ranging from America to Japan to China to Poland. None of these cultures speak the same languages, have the same cultural values or even celebrate the same holidays. If you are starting an online game company it is wise to starting contemplating the monumental task of localizing your service as early as possible.

There are two truths about localization for online games. One, it can dramatically multiply the number of customers that you reach. Two, it is more trouble than you might imagine. In this essay I look at how we might use we use techniques from game design to streamline this exciting, yet expensive opportunity.


The good and the bad The majority of players populating online games like Legend of Sherwood, Travian or World of Warcraft are from outside the United States. We have a solid 300 million potential customers, but the rest of the world has billions. After the core game is complete, localization can help you double or quadrupal your install base for a cost far lower than developing the game afresh. This is highly attractive to those folks with dollar signs for eyeballs.

Yet localization and globalization ends up being far more than a onetime cost for translating a few text strings. Popular games pump out an ongoing stream of new content that must be rolled out across multiple languages. The original team likely doesn’t even speak the language of the targeted countries so quality control is a huge issue. Even worse, most teams have little experience with the culture of the new country they are targeting. An expansion pack that celebrates Christmas as a family event may not translate well to your Japanese users who traditionally see Christmas as a holiday for lovers.

Larger companies end up creating comprehensive localization and globalization groups that can act as a giant drag on the software development process. Localization often ends up in its own silo with radically different organization and values than the main development team.

Help (for hire)
Whenever there is a difficult problem that falls outside the core competency of a game development team, outside companies will emerge to help them solve the problem. For a fee, of course.

At the most basic end of the spectrum are translation services. These take your table of text strings and translate them into a variety of languages. Quality varies dramatically and there is typically the need to re-edit the text afterwards. Many companies start by just translating their strings and then realize that bringing their games to other countries is far more complex than a simple data manipulation problem.

At the other end of the spectrum is the full service operator. An operator is a company that takes an existing game, typically from a traditionally inward looking market like Korea or China, and runs a localized version of that game in another country such as Japan or the United States. Depending on the company, the operator will handle everything from localization, to handling foreign currency, to running foreign language support. Many will run the local servers for your game. OutSpark is a good example of an operator.

Rolling your own?
Every time you deal with middlemen, even ones as innocuous as a translation service, you need to ask the question: What is the opportunity cost of rolling my own?

• On one end of the equation are the operators that will take a percentage of your revenue for the lifetime of the game in return for expanding your market substantially. Woot, “free” money.
• On the other end of the equation is a custom solution. If you can reduce costs, you might come out ahead. But what if it dilutes your focus as a company? What if you end up missing out on the economies of scale and experience that come from being a company focused solely on localization?

This decision is particularly tricky since middlemen make it their business to provide you with a very clear value proposition when you are examining their services. There is rarely anyone who can put hard figures on the benefits of rolling your own. The easy solution often becomes the outsourced solution promoted by the smiling salesman.

So this got me thinking: What would it take to roll your own localization service for an online game?

Constraints
There are some constraints to this little thought experiment:

• Inexpensive: The solution needs to cheaper than going with an outsourced group.
• Leverages game development skills: Ideally we can leverage our core skills as a game development company. This means using game design to solve our problems, not hiring a mass of translators.
• Doesn’t rely on building up services that other people could do better: We need to be wary about spreading the company too thin by turning into an operator in our own right. Though there may be some benefits from vertical integration, internally replicating systems that are already run efficiently by third parties is something to be approached with great care and a skeptical eye.

Research clues
At GDC, I ran across two clues that point to a solution.

• Leverage the community: I caught some offhand comments from the fine folks over at Three Rings about alternative ways of leveraging the community in order to avoid entering into partnerships with operators. What they’ll end up doing, I have no idea. Still the seed was planted in my little monkey brain.
• Wikipedia as a game: Elonka Dunin gave a lovely talk on how Wikipedia can be viewed like a giant MMO. The mechanics happen to focus on user generated articles instead of killing monsters, but the fundamental rewards for writing articles is fundamentally game-like. The pertinent detail here is that Wikipedia users also translate articles on a regular basis. Wikipedia is one of the most comprehensively localized websites in the entire world and all of it is due to the user’s efforts.

User generated translation driven by game mechanics
Let’s build a game that rewards multi-lingual players for localizing the text in our product. We’ve got all the necessary ingredients in your typical game:

• Passionate players who speak a variety of different languages
• In game reward systems that have already proven attractive to the player.
• A mediated environment that allows us to pose tasks and record the results.

Instead of hiring expensive middlemen, we harness the volunteer efforts of our passionate players. Instead of managing the process manually, we create an automated system of empowering tools and reward systems that encourage players to do the right thing. Above all, we make the process repeatable so that we can run it over and over again at almost zero incremental cost. We are building an engine whose mechanical structure is derived from the physics of human psychology and whose brightly burning fuel is a steady stream of fun seeking players.

The reviewer pattern
Here’s a basic structure of our translation game.

1. Identify: Identify players with base level skills are capable of performing a desired task.
2. Action: The players perform actions using in-game tools in the hope of receiving a reward.
3. Review: The game independently verifies the actions using other players for tasks that require human computation.
4. Reward: The game rewards the person performing the original action based off the verification process.
5. Repeat: High scoring people get more tasks of that type and greater rewards. Low scoring people get fewer tasks of that type.

This reviewer pattern is quite flexible and can be used for wide variety of tasks that are much broader than mere translation. It is particularly useful when you need to judge the quality of your player’s efforts and “quality” is determined by strong aesthetic or cultural factors. Language is an obvious example of this, but art, fashion, moral judgment and other classic human endeavors fall under this umbrella as well.

Let’s apply the pattern to the process of translating text.

1. Identifying players with the right skills
Our imaginary game has persistent characters with extensive profiles. People can declare their real world skills including which languages they seek. Let’s say for a moment that we want to translate between English and Japanese. We would search the profiles of our thousands of users and find ones where players claimed proficiency in both languages. These users are tagged as potential translators.

2. Performing the task
The next time the player approaches a quest giver, the game substitutes a translation quest for their typical “Kill 5 rats” quest. There are numerous framing stories one could use ranging from the scholar seeking to translate a mysterious scroll to a warlord needing an intercepted spy message translated so they can prevent an attack.

Promise of a reward: The player is told that if they complete the task they’ll get a certain amount of gold. If they complete the task well, they’ll be inducted into the secret Guild of Translators.

Task specific tools: If the player accepts the task they are presented with a screen that shows them the original text and a space where they can translate it into Japanese. They type in a translation, hit submit and get the basic translation rate. They are informed that qualified reviewers will be looking at their translation and we’ll let them know if they make it into the secret Guild.

On the backend, every text string of every object can be pulled from a set of string tables that have slots for all supported languages. You need a system that supports multi-byte characters, various text orientations, IME input and all the rest of the glorious minutia that goes into localizing simple strings.

To generate the quest, we look at popular items that aren’t translated into languages for which we have translators available. A few strings, such as the name or the description are bundled up and given to the player as the source material they need to translate.

3. Review the results
The vast majority of translations will be of poor quality. This is the reality of free labor done as an idle hobby. We want to separate the truly talented reviewers from the masses so that we can ultimately put them on a pedestal as an example for everyone to strive towards. In the process of tagging our translators, we also tagged people who spoke Japanese.

Again, we give these tagged users quests. This time they need to read the text and rate it quality on a 7 point scale. There is also a small text field where they can type in comments. They are also told that they’ll get a bit of money for doing the task, but they’ll get even more money if they do it well.

Unbeknownst to the individual reviewer, we also give the same text to 10 others to review. We collect all the scores, lop off any outliers and calculate the average score. This is the rating for the translated text.

Translations that get ratings above a certain threshold (such a 6 out of 7), are automatically published to the world at large.

4. Reward the translators and reviewers
Translator rewards: Once the final score for the translation is determined, the original translator receives a message that contains a quality reward. If they scored 6’s and 7’s, they get huge rewards and are inducted into the Guild of Translators. They get a special cloak, and are promised future awards if they continue to do such a wonderful job translating. If they score lower, they get lesser rewards and may not be invested into the Guild. They are given a second chance as well as access to the comments that were left by the reviewers.

Reviewer rewards: We also reward reviewers based off the quality of their reviews. Those players scoring closest to the average score get mega points and an increase in their reviewer level. Those players that scored furthest from the average get no points and their reviewer level can even drop. Over time, competent reviewers whose opinions reflect the majority should rise to the top. When we calculate average scores for a particular bit of text, we can use weighted averages that take into account the level of the reviewers involved.

5. Repeat the process
Whenever text is added to the system, the translation system jumps to action. Translation quests are generated, translators translate them and reviewers review the results. Over time the text of the game is slowly but surely translated into other languages, driven by the demand and passion of the users.

The system is built to constantly improve the results. The highly rated translators and reviewers are showered with in game gifts and rewards. They gain levels, get new outfits and are given kudos by NPCs. We feed them stats on how many people use their translations and look for ways to promote their efforts to the larger community. Each of these rewards is automated and repeatable. In return for these social glories, the system gives highly rated translators more translation tasks. We want the best of the best handling most of the translation.
As time passes, many users will try translation and find that it isn’t for them. That’s alright as long as there is a core group of people that latch onto the job and make it into a fundamental part of their online identity. The system is built to support this natural winnowing process in order to build up an elite core. A dozen or so passionate users can translate hundreds, even thousands of pieces of text in relatively short order.

Popular pieces of text with lower scores are resubmitted to elite translators for another pass. As time goes on, the quality of the translations throughout the game continues to improve.

Benefits
This is a complex system, but it comes with some intriguing benefits.

• Focus on core competency of game design: It is a reasonable amount of work building this localization system, but it leaves your company with a very solid reward system that can be leveraged for other areas of the game. You are investing in game design and player entertainment, both of which are core competencies for any game company.
• Serve smaller cultures at low cost: There exist numerous cultures in the world that speak languages other than English, French, German, Spanish, Chinese or Japanese. Dozens of nations like Poland or Brazil can contribute hundreds of thousands of users to your game. By allowing players to translate the game into their own language, you can reach these niche cultures at a very low cost.
• Adapt your text to each culture: Many concepts don’t translate well between cultures. By having the users perform the translation, they will often smooth over rough edges. If a particular joke or phrase doesn’t work, users will reword it to something that fits their culture. Often, users will take liberties and incorporate references to their own mythology or culture into the translations. It is an interesting trade off. You give up a small amount of authorial control in return for a translation that seems as if it was written by native speakers.
• Highly scalable: Once a community of translators is in place you can release content in one language and watch it quickly and cost effectively be translated into other languages. The cost of localizing an additional piece of content goes to almost zero.

Limitations
This system is not without some pretty serious limitations.

• Requires a large number of people: To get to those few dozen people who are interested in translating your game, you’ll need a population of thousands, perhaps hundreds of thousands. Only a very small number of people will be interested in playing your translation game.
• High startup cost: You need to develop and balance this system. That is expensive and will likely require dozens of iterations on the design.
• Questionable translation quality: There is a very good chance that the majority of your early translations are incorrect, confusing or insulting. You won’t be able to tell since you don’t speak the target language. This means that when the system isn’t balanced just right, your users may have bad experiences. Also, as mentioned above, you are giving up a certain amount of authorial control. Your epic bodice ripper about the Monks of Ra may turn into a joke gag about Swedish meatballs. C’est la vie.
• The process moves at the pace of the players: If the players don’t find translation quests interesting or there aren’t many multi-lingual people on your service, translation will lag.

Other pieces
As stated earlier translating text strings is only a piece of the puzzle. To solve the whole puzzle, we can repurpose some of the systems that we created for the tranlation game.

Pieces to own: These are items that you should try to maintain control over.

• Culture specific events: Combining the review system with tools that let users create their own events is one way to go. This moves you down the path of user generated content, which is a giant can of worms, but again has substantial benefits if you can pull it off. This would likely follow the same review pattern we saw with translation, except instead of translating text, you are asked to build something grand.
• Culture specific support: Griefing, bugs, currency issues are all best dealt with by a support team that speaks the player’s native language. There has already been some solid work done with volunteer judges and moderators and it makes a lot of sense to invest in this further in the future. Giving player judges the ability to review past grievances, render judgment and then have their judgment reviewed by a jury of randomly selected peers is an obvious profession worth creating. It would likely appeal to a substantial minority of the player population since it involves direct power over others. Again, problem tickets are handled as quests and we slowly give people more power based on the quality of their previous efforts.

Pieces to outsource: Some things like payment systems and local servers, you’ll likely have to outsource to middlemen. Yet out of all the middlemen activities offered by operators, I’m most willing to let them take on these two. Why? Because they both becoming more commoditized by the year. Costs of running servers all around the world are going down, while reliability is going up. As cloud computing and virtualization become more dominant, the last place you want to be investing your valuable cash is in replicating the core business of the likes of Amazon, Microsoft, Google, Sun and a half dozen other future cloud computing behemoths.

There’s a rule of thumb here. Let the middlemen handle the commoditized plumbing, but don’t let them near your customer relationships. Your community and your addicting game design is your unique competitive advantage.

Conclusion
Ultimately, building something like a translation game for your service is a business decision. I believe that you should treat the decision to create a utilitarian social game system in a similar fashion to how you would treat the decision to make a capital investment in your company. It resembles a classic business problem: choose the proper mix of the following:

1. High variable costs with low capital investment: You rely heavily on manual labor to make each widget. You don’t have much in the way of equipment so it costs you an arm and a leg to build each widget.
2. Lower variable cost with high capital investment: Alternatively, you can invest in capital expenditures like beefy factory equipment. Capital investments cost a lot of money upfront. However, longer term, they can dramatically reduce your variable costs.

Building systems such as our translation game are remarkably similar to capital investments from the ancient age of manufacturing. They are expensive to develop and balance. They have a significant maintenance cost. Yet, they dramatically reduce the costs of servicing another customer in a foreign country. Instead of paying 30 to 60% of a customer’s revenue to a middleman, you instead end up paying a few pennies for bandwidth.

In the case of a game development company, the building of the equipment that reduces your costs also happens to be your core competency. You are good at manipulating players to volunteer their time and energy to complete obscure tasks. You are good at building enjoyable software and task oriented tools that facilitate the creation of these tasks. It is time to put these assets to work.

So what happens when you use game design to improve the way your run your business? The future online game is a complex digital factory filled with powerful social engines that chug and churn throughout the night. The workers funnel in one end, and out the other comes the high quality fruits of their carefully guided labor. This is no dystopia. The workers are volunteers and the factory is a playground. If they become bored, the players leave. But most do not, for the machine knows too well to their subtle human weaknesses. And, you, the builder of the great machines that measure and prod and coddle humanity in endless loop upon loop, sleep soundly as the money rolls on in.

Take care,
Danc.

References

• Human-based computation: http://en.wikipedia.org/wiki/Human-based_computation
• How Wikipedia is like an online game: https://www.cmpevents.com/GD08/a.asp?option=C&V=11&SessID=6428
• Three Rings' Whirled.com: http://whirled.com/
• Localization, Globalization, Internationalization: I've used the term 'localization' rather loosely throughout this essay. For a very brief overview of what's actually involved see http://en.wikipedia.org/wiki/Internationalization_and_localization.

Read more!

The Randomly Reinforced Lost Garden Prototyping Awards

What a whirlwind of a month it has been. GDC was crazy fun, the latest beta of Expression Design came out at MIX, and I decided to take a leap and start in a new position at work. In the meantime, some great games were created in the last prototyping challenge.


Let's reward awesome developers
You know what? I think it is time for an award ceremony. I've been meaning to do this for a while, but never got around to it with the previous prototyping challenges. Here are the awards and how they are handed out:

• Bronze Medal: You built an interesting software toy. If you make an a