Directory of All Essays

Tuesday, July 08, 2008

Soul Bubbles: A classic game ill treated by expert reviewers


I wanted to turn your attention to a delightful little title called Soul Bubbles. I had a chance to play an early version of the game and was impressed by its lead designer, Olivier Lejade, careful attention to the difficulty level of the game.

When it finally launched, I was intrigued to see its aggregate reviewer score hovering at 77%. That is a middling score, but I expected better. Yet when I glanced at the user rating, it was pegged at an impressive 92%. From the user's perspective, we are talking about an instant classic, with a higher aggregate user ratings than either press favorites Halo 2 (91%) or Halo 3 (89%).

Why the disparity? When I looked closer, the professional reviews with lower scores almost all commented on the difficulty level, the one area I knew for a fact that the developers spent months polishing. Alex Sassoon Coby over at Gamespot intones ominously,"The shallow difficulty curve and lack of challenge in the main goals are the only things that let Soul Bubbles down."

Yet, users have the opposite reaction to the same exact features. One fellow gushes "It's very easy to get into thanks to the excellent tutorials, which introduce you effortlessly to the physics-based gameplay as you go along. The game's 40 levels will keep you busy for some time, but chances are you'll play the missions back to back only to be left craving for more!"

There's something odd happening here. Is Soul Bubbles a simplistic, middle of the road experience or is it a classic new game that deserves to be promoted as one of the more playable and innovative games of the year?

The answer tells us a lot about what it takes to make a great game and also happens to highlight one of the grand philosophical flaws in modern game criticism.


Games are about learning skills
First, a bit of background. Games, particularly one built around exploring innovative new game systems like Soul Bubbles, are all about learning new skills. There is a lot written on the topic, there are some articles at the end of this essay for you to peruse. The short of it is that learning new skills yields fun.

You can think of a game like Soul Bubbles as a bit sheet of bubble wrap. Each challenge is a little bubble of fun waiting to be popped. Most games are like this. However, once you've learned a particular challenge, doing it again is usually less exciting. By playing, you've been changed. You've learned the challenge and you'll never be able to revisit that challenge and relive the same emotion that you felt the first time through. You can't re-pop the bubble.

People who play a large number of games tend to rapidly morph into expert gamers. Reviewers, specifically, are almost by definition experts. In order to multiply their meager paychecks, they train themselves to quickly plow through dozens of games. They've crunched through so many levels, powerups, puzzles and collectibles that they are walking encyclopedias of game design techniques.

Since the act of learning is where a large amount of single player fun arises from, many expert gamers find it more and more difficult to derive pleasure from each new title. Games often reuse mechanics and the even an innovative game like Soul Bubbles starts feeling the same. It's like handing the reviewer a sheet of bubble wrap with all the bubbles already popped.

The result is that an initial game activity, such as a tutorial, that would delight a new user instead appear at rote obstacles that need to be skipped past as quickly as possible. Reviewers will use their impressive pre-existing mastery to zip past carefully constructed levels in the hope of find a challenge that will teach them something new. For most, this is subconscious behavior. They just know that they are looking for the thrill that they once experienced as child playing games for the first time. Due to the fact that they have changed, that they are now experts, only the most refined and challenging games still give them a hint of that sweet learning delight. Everything else is labeled 'crap.'

The Expertise Bias
This phenomenon is well understood in the game development community. Game developers also suffer from being experts. Not only do they have encyclopedic knowledge of exist game mechanics, they also have an intimate understanding of how their game is supposed to operate. Surely with such vast expertise, they would be the ideal critics.

Yet, because games are a learning activity, expert game developers often have surprising difficulty understanding how new users will react to their creation. Things they feel are incredibly important end up not mattering. Elements they dismiss as trivial annoyances end up stopping players dead in their tracks. The very fact that designer knows their game intimately makes them a poor critic.

Observation is the solution
The well documented work around for the expertise bias is to observe other people, who aren't experts, play the game. The best designers follow a simple process:
  • Observe target players
  • Take notes on potential issues.
  • Leverage their intimate knowledge of the game to come up with elegant solutions.
Valve does it, Nintendo does it, Microsoft does it. Admittedly, the process is time consuming and not always the easiest path. However, testing with real users is the only proven way to accurately ascertain a game's difficulty and balance.

By observing real people in your target audience learning for the first time, you can realign your heavily biased perception of the game to be more in sync with reality. It becomes readily apparent that 'obvious decisions' do in fact need improved tutorials. Entire systems that you thought were essential are often ignored as players telegraph their delight in simple things like picking up shiny coins.

Game developers have learned the hard way what happens when you ignore the practice of observation. Periodically, schedules become tight and the expensive act of observing real users ends up on the chopping block. Someone with more ego than wisdom stands up and proclaims that they can use their infinite expertise to balance the game using brain power alone. Inevitably their products suffer.

They are fighting the fundamental physics of our medium. Experts, in the absence of observation, make for heavily biased critics.

A tale of Soul Bubbles
Mekensleep, the developers of Soul Bubble, are enlightened developers. They spent months polishing and balancing the difficulty of their game. They held playtests, they observed real users playing for the first time and they fixed the problems that they ran into. They knew that that Soul Bubbles featured some very unique movement and herding mechanics, so they were under no assumptions that they could use their expertise to predict a user's initial reactions.

In the process they learned a lot about how their customers wanted to play Soul Bubbles. Their target player picks up a few games a year and plays in short burst for a long period of time. Many are not looking for intense competition or a massive challenge. Instead, they want a way to relax and explore a delightful world.

As a result Soul Bubbles targets exploratory and easy fun play styles. These feel very different than the traditional hard fun that is the mainstay of many titles played by the core. Yet they are equally enjoyable and often more profitable. Much of the game is about peacefully exploring with the levels designed so that around every corners there is something new to learn or play with.

Through a rigorous and iterative process that involved going to real users, they nailed the difficulty level. That is why the aggregate user ratings are up at 92%.

The flaw of expert reviewers
The reviewers of Soul Bubbles didn't observe real users. Instead, they reacted to the game as expert gamers. The tutorials were a bore, the game could be 'beat' in a short amount of time and the number of times they were forced restart were low. So reviewers told their audience that they should not buy the game on the assumption that the player would likely feel the same thing that the reviewer felt. This represents a basic philosophical approach to game criticism.

I read a short essay by Andrew Doull that sums up this philosophy with the gem of a quote "Fundamentally, the process of being a game critic is the same as being a game designer (is the same as being a game player). That is, it involves the exploration of a possible game space, and trying to validate whether that game space is interesting."

To me, this represents a fallacy of epic proportions that results in badly designed games and inaccurate reviews.

Due to the fact that games are learning systems, good game critique requires two elements.
  1. An expert understanding of the game: Playing the game, knowing mechanics, player psychology, design patterns gives the critic powerful tools for understanding and reacting to what they are witnessing.
  2. Observation of representative users: Expert knowledge biases the priorities of most players, so it is critical to see how real users react to a title in order to get actual target audience data. Having sat through hundreds of hours of observing users, you don't actually know how the virgin value of an inactive system until you see others use it.

Game reviewers only follow one half of this unified process. Since most reviews eschew observation of others (often for timeliness), there is nothing to counter balance their expert bias.

Games are not movies. Please repeat...again and again and again.
There are good historical reasons why experts fail to incorporate player observation into their game reviews. The concept of a review comes from reviewing movies, books and plays. These are what I think of as 'empathetic media'. The process of enjoying these works follows a clear psychological pathway.
  • The viewer observes a universal stimuli, such as a pretty girl in a movie,
  • They empathize with her situation based off their extensive memories of related situations
  • Finally they recall and synthesize an emotional response.
The best works of linear media deal with broadly identifiable stimuli, archetypes of human experiences. Most people have experience with loneliness or the boy winning the lovely girl. Empathetic media gains its mass appeal by dealing in universal truths.

When a reviewer watches a movie, they are asking themselves the question "Do I, as a passable representative of humanity, react strongly to the stimuli in this movie? If so, there is a great chance that others will as well." There is very little expertise bias involved in this exercise. It asks the reviewer to empathize with the stimuli like any other person would.

There is a big question if games work well as empathic media. Their stories are weak, characters flimsy and their exploration of universal truths are usually laughable. Instead, games tend to be strongest when they focus on learning, exploration and first time experiences. Games, more than any other media, are less about reacting and more about changing who we are.

Because the deep, underlying theme of games is change and learning, you need to take into account your level of mastery and the level of mastery of the target audience in your criticism. Otherwise, you end up, like in the case of Soul Bubbles, being the PhD student claiming that Physics 101 is a waste of time because you've 'been and done that' already.

Traditional reviewing techniques taken from the world of empathic media are ill suited for critiquing games. They lack the essential observational techniques that working game designers have found to be so important.

Looking into the future
So, yes, the current game reviewing system is broken. As is often the case with games, we've adopted wholesale the techniques of movies and literature without asking if they even make sense in the context of our brilliantly vibrant new media. I'm certainly not the first to say this.

Yet with single player games, the hack still almost works. Single player games have generally followed a linear path padded with cutscenes, where a reviewer will typically have a similar experience to that of most other players. As such, the expertise bias usually only throws off scores by 10 to 20%. Long term, this practice shrinks the gaming community and it has certainly caused a few developers to miss out on royalty bonuses, but overall it clunks along.

Yet, the world is changing once more. As you introduce multiplayer games into the mix, social dynamics take over and who you play with has as much impact on the experience as which quests you take on. The types of learning and the experiential paths that each player takes are exploding. One player's experience playing with his new girlfriend will be radically different than that of a old school guild settling into the game as a respite from World of Warcraft. An empathetic expert reviewer will not be able to speak for everyone in a convincing fashion.

It is again instructive to observe how developers are using an observation-based understanding of the game to create a proper practice of game criticism. Right now there are hundreds of teams building complex metrics and logging systems that track their player's experiences on a minute level of detail. The best have psychographic and business dashboards that tell them how people are reacting and where problems are emerging. In the future, developers will be observing, tracking and improving the experience of individual guilds and social groups. Practical game criticism, the sort performed by actual game design teams, will be even futher fueled by deep observation and timely intervention.

Unfortunately, these tools are not available to most reviewers. In the coming years, developers will have a vastly superior understanding of how customers are reacting to their game than reviewers will. This is already the case for many titles, such as Soul Bubbles, and the trend will only continue.

What is the future role of professional reviewers?
What role does the expert reviewer have in this situation? As the audience for games broaden, as the benefits of a single expert judging an entire game diminish as their opinions become even more divorced from the actual experiences of real players. The air of objectivity dissipates and the reviewer becomes no more than yet another guy with an intricately detailed, heavily biased opinion.

This represents an intriguing crisis in game criticism. There are many paths for the ex-reviewer to wander down:
  • The news announcements: The factual (though still flavorful) announcements of new games, events and updates. The goals is to let people know that something is happening.
  • The analysts: The elitist community that uses their expertise to deconstruct games according to various theoretical frameworks. The goal is a deeper philosophical understanding of games (and strutting rights within their small incestuous circle.) This is my world. :-)
  • The tourists: Every Man players who approach writing about a game like a travel journalist on a safari. The goal is to evoke the emotions that the individual reporter experienced, not to predict what everyone's experience might be. They succeed if they provide simple entertainment.
  • The opinion mavens: The high energy personality who crystalize the trends and fashions of their target culture. The goal is to pick hits in a heavily biased but entertaining fashion and enhance the maven's personal brand.
  • Ranking sites: Sites like gamerankings are still of questionable value, but over time sites that use a broader range of data will emerge. The goal is to provide a public thermometer that, with reasonable accuracy, states if the game is worth trying.
I already see this evolution occurring. I've given up on reading reviews and instead find myself frequenting gaming blogs, the news portals of our age. Many traditional reviewers are popping up in more experientially-focused sites like The Escapist or Rock, Paper, Shotgun. Even next generation ranking sites are appearing in the form of portals like Kongregate. And what is Zero Punctuation if not our very own flavorful equivalent of Oprah the Opinion Maven?

Closing thoughts
Go out and try Soul Bubbles. It is a great example of what happens when a developer balances their title for their target audience and not the expert reviewer. If you are an expert reviewer, play it with an eye towards seeing how a first time user might experience it. It is an interesting and remarkably difficult exercise. Then give the game to someone who isn't an expert gamer and watch them play it. I suspect that they'll highlight elements that you didn't even realize were important.

If you are serious about providing objective insight into a game, either a title you are building or one your are reviewing, your expertise is not enough. In fact, your vast mastery of game related skills is mostly likely causing a giant bias in your judgments. You need to fight this bias by observing other players over and over again. They will do things with the game that are a source of wondrous insight. Your expertise becomes a tool for making great changes based off these insights, not one for predicting a priori exactly how all users will react to the game.

As for the current review industry, it is built on the unstable foundation of expert opinion in the absence of actual player observation. As games evolve and become ever more about first time learning experiences, the traditional game review will become increasingly irrelevant. It is arguable that they've already stopped informing most buying decisions and now serve as little more than entertainment for the hardcore niche. As the value proposition of reviews falter, the vast, churning, capitalist forces of creative destruction will replace them with a much richer set of game criticism that offers real value to its readers.

It's a beautiful day outside, so I'm off to pop a bit more bubble wrap,
Danc.

References


Labels: ,


Read more!

posted by Danc at 12:12 AM 24 comments

Saturday, July 05, 2008

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
Game Design Science Game Design Craft Game Prototyping Challenges
Resources
Game Observations
Conferences and Articles
Personal Feel free to send any comments or errors to danc [at] lostgarden [dot] com.

Labels: ,


Read more!

posted by Danc at 10:43 PM 6 comments

Saturday, June 28, 2008

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:
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
Mockup


Labels: , ,


Read more!

posted by Danc at 12:24 PM 31 comments

Saturday, June 14, 2008

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.

Labels: , , ,


Read more!

posted by Danc at 11:57 AM 16 comments

Tuesday, May 27, 2008

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.

Labels: , , , , , ,


Read more!

posted by Danc at 7:01 PM 4 comments

Monday, May 19, 2008

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.



Labels: , ,


Read more!

posted by Danc at 10:47 PM 14 comments

Sunday, May 11, 2008

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.

Labels: ,


Read more!

posted by Danc at 10:47 AM 7 comments

Sunday, April 13, 2008

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


Labels: , , ,


Read more!

posted by Danc at 12:10 PM 9 comments

Wednesday, April 09, 2008

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.

Labels: , , , , ,


Read more!

posted by Danc at 4:26 PM 4 comments

Sunday, March 30, 2008

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 b