Friday, December 29, 2006

Escapist article on 'Boutique MMORPG'

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

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

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

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

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

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

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

take care

Wednesday, December 27, 2006

The Wii Help Cat: A lesson in interaction design

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

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

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

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

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

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

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

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

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

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

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

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

User achievement tracking

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

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

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

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

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

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

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

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

take care

Mastery-based interaction design

Atomic Game Mechanics

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

Sunday, December 10, 2006

Building fun into your software designs

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

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

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

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

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

A dash of theory

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

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

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

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

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


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

Food for thought,

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

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

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

Monday, December 4, 2006

Sprawl: The world's first public Silverlight game

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

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

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

take care

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

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