DesignAday

Game Design for Designers

Richard Saul Wurman explained his approach to teaching in an interview with GK VanPatter:

The epiphany [that] occurred in the first day of class was: Do I teach about what I know or do I teach what I want to learn about? A fundamental bifurcation, and I chose the latter. I never teach from my knowledge. When I teach, which I did for many years, I always teach from my ignorance and what I want to learn about. Terrifying, but changes all teaching and consequently, all learning.

I came upon this when I was preparing to teach my first class at WVU in the Fall of 2005. I was constantly questioning my qualifications. Who was I to be teaching design theory? It really inspired me, and since then, I haven’t hesitated to teach any design-related subject, from typography and data visualization, to product innovation and service design. Next semester, it’s looking like I’ll have the opportunity to teach game design, another area that I have never actually practiced, but have a deep interest in, as well as a love for the end result. It’s a topic that I’ve been wanting to learn more about—what better way to learn than to teach?

The point of the course will not be to turn my students into professional game developers, but to give them another tool for general design use. Game design is becoming increasingly important in business, education, and the general consumer landscape. I believe it to be an extremely useful skill for any design specialty. And so, I have begun to hunt and gather resources. I want to select a textbook that the lesson plan will be loosely based on, and I’m leaning towards Jesse Schell’s The Art of Game Design: A Book of Lenses. I’m also thinking of picking up Challenges for Game Designers by Brenda Brathwaite as my own resource for examples and exercises.

If you have any suggestions, please make them in the comments.

Didget

There’s an interesting article up on BusinessWeek about a new product from Bayer. Didget is a blood glucose meter—you know, one of those things that people with diabetes prick their fingers with to monitor their blood sugar. It’s not one of those things that people enjoy doing, so you wouldn’t expect them to particularly like their meters. And while adults can suck it up and deal, you can imagine that a child would have less patience for the whole ordeal. Paul Wessel’s son Luke, who was four years old at the time, was the inspiration for the concept that would eventually find Paul working at Bayer and collaborating with Nintendo. You see, he realized the power of games. What sets Didget apart from other glucose meters is that it interfaces with a Nintendo DS and a game called Knock ’em Downs World’s Fair.

The program rewards players for performing a prescribed number of tests each day by bestowing points that speed the player through the game. Additional points are earned for staying within target blood-sugar ranges, which parents can program in. “There used to be days when I didn’t want to test,” says George Dove, 12, of Nottingham, U.K., who must use the meter as many as eight times a day. “Now, it’s fun.”

Read the full article here.

Practical Lessons from Games: Progressive Revelation

What would happen if, the first time you played a game, it was so difficult that you didn’t enjoy it in the slightest? Would you be likely to want to play it again? Well-designed games strike a very fine balance between being hard enough to be challenging, rather than boring, yet easy enough for you to learn the rules, begin to understand some strategy, and achieve some success. To maintain that balance, they increase in difficulty as a player increases in skill. In traditional board games, this can be accomplished by additional or modified rules and mechanics, complex strategies that take a long time to master, or the increasing skill of one’s opponents. Video games can increase the artificial intelligence.

Role-playing games are based on statistics that persist from one game session to the next. This is, perhaps, most akin to a person that is learning to use a piece of software. A game character gains experience by fighting, completing quests, or exploring new places. After a certain amount of experience is collected, the character “levels up”, typically increasing statistics such as strength, wisdom, and health, The increased statistics prepare it for success in higher-level areas of the game world. The world is typically split up into different regions, each of which is assigned a difficulty level. All of the contents of a region, from the virtual inhabitants, to the puzzles, to the items one can collect, are designed specifically for the level of difficulty assigned to the region. In this way, the world progressively reveals itself to the player, becoming more difficult as the player’s character, and consequently the player, become more experienced.

This concept of progressive revelation can be applied to applications of all kinds. Organize your functionality based on the experience level needed to use it. What will brand new users want to be able to do right off the bat? As their skill increases, what additional capabilities will they find most useful? What are the natural extensions to their current processes? What are the more complicated procedures? What are the prerequisites for using particular features? Then think about how you can design your application such that level 1 functionality is the first thing a user encounters. Build in bridges that make it easy to move into the level 2 features. There, you can sprinkle around some enticements to try out the advanced capabilities.

Helping your users move easily from beginners—n00bz in gaming slang—to experts will engender satisfaction and loyalty. That’s beneficial to everyone except your competitors. It’s time to level up.

Practical Lessons from Games: Expansion

One of my family traditions is to play a lot of games together: board games, card games, whatever. This is the primary activity on New Year’s Eve. My brother is a game fanatic—I might even call him a game connoisseur. He has quite a collection and this year introduced us to Carcassone, a tile-based board game from Germany designed by Klaus-Jürgen Wrede.

I’m particularly fond of games in which the playing field is built or revealed as the game progresses. Players must adapt and change strategies as each player influences the environment in turn. Carcassone is such a game; it’s roads, rivers, fields, and towns expand in convoluted ways creating instances of both competition and cooperation among the players.

We all found the game to be a lot of fun to play. The game mechanics are very well designed. I found most interesting, however, the fact that there are numerous expansions available for purchase. The design of the game is extremely flexible, allowing for expansions to affect the gameplay in both subtle and drastic ways. Expansions can support additional players, add new mechanics that increase the complexity, or even completely replace the original rules while utilizing the same game pieces and changing the focus of gameplay. As a result, the game becomes infinitely more playable, providing new challenges as the owner masters the original. At the same time, it is much more profitable. Many computer games take the same tactic (note that I’m talking about expansions, not sequels—there’s a difference).

Can you apply similar tactics to your productivity-oriented applications? How could you provide and market additional capabilities targeted at specific needs of a subset of your total user base? Perhaps more of a challenge, you would have to design your product to be flexible enough to easily integrate new functionality. This is both an engineering challenge and a user interface design challenge.

Practical Lessons from Games: Quick Action Bars

Computer games feature beautiful artwork that immerses the player in a world. As such, graphical user interface components are usually kept to a minimum. However, games can be very complex with any number of actions that can be performed. The UI must provide some mechanism of selecting actions, and inventory items. Many games, from first-person shooters and MMORPGs to RTSs and adventure games, provide quick action bars to make commonly used actions and items easily accessible.

A common pattern is to have some type of repository, like a backpack or spell book, which contains all of the items or actions a player has. This is something that the player can open as a new screen or pop-up overlaying the gameplay screen. They can see everything they have, read descriptions of them, and activate them. But when a player is in the middle of the action, they don’t want to have to open a separate window, obscuring their view of events, to cast a spell. It takes too long, and it breaks their suspension of disbelief.

Quick action bars can be located along any edge of the screen, but tend to be along the bottom. Many games provide multiple bars in various locations. World of Warcraft, for example, provides two rows on the bottom and two more on the right-hand side. Bars are typically configurable, allowing the player to decide which actions and items they want immediate access to and how to order them. They can be activated with a single click.

This is one pattern that has been found in productivity software almost as long as in games. Most applications have some kind of tool bar that provides single-click buttons for common actions. Many applications allow toolbars to be configured, ranging from placement of the bars themselves to management of the individual buttons. Some applications have contextual tool bars that present functions based on the user’s context, such as the current selection.

When designing your application, consider what actions will be used most often. Consider the context in which actions will be performed. Will there be big enough differences between users to warrant a fully customizable set of tool bars? Or, will your application benefit from a reduction in complexity by not providing robust customization?

Of course, another useful pattern that works in concert with quick action bars is shortcut keys, but that’s a topic for another post.

Practical Lessons from Games: Inventory

One common feature of most adventure and roleplaying games is the inventory. This is where you store objects that you find and pick up throughout the game. When you need a particular item, you access your inventory, select the item, and then use it to interact with the game world in some way. Inventories are represented in a wide variety of metaphors, typically bags, briefcases, backpacks, and the like. They often include a representation of your character, allowing items, such as armor and weapons, to be equipped. They can be represented as pop-up windows, panels that slide out from the side of the screen, scrolling icons similar to the Mac OS X dock, etc. And there are a variety of methods for navigating the contents, such as pagination and scrolling. Sometimes the inventory is a completely separate screen that removes you from the game world. In other cases, it appears over top of the game world, and sometimes it is built into the “chrome” of the UI that is displayed at all times. All of these variations can be mixed and matched to provide many potential solutions.

There are a number of opportunities to utilize game inventories as inspiration for user interfaces that support similar activities in other software. Shopping online can be thought of as exploration, during which you find items that you want to buy. The shopping cart is a type of inventory, the main difference being that you never need to use the items you place there at a later point in the activity. Or, I should say, this isn’t part of the current shopping cart pattern. But what if you were able to easily perform side-by-side comparisons of items in your cart with other items you find in the store?

Authoring software, such as Flash, Director, and iMovie, allow you to collect items from your file system that you want to use in your project. They provide a type of inventory for storing the files you import. Director calls it the “Cast”, using a theater metaphor. Different options are provided for viewing, sorting, and finding items within the inventory, and when you are ready to use one, you drag it out of the inventory and into the workspace.

Do any of the software you design involve the management of items, be they photos or textual information? Consider some of the patterns found in computer game inventories.

It’s Hip to be Foursquare

The other day, I wrote about my disappointment with Booyah, the iPhone app that claims to be an achievement system for real life. I wasn’t very impressed with it. Foursquare, on the other hand, sounds a little closer to something interesting. I tried it out, but they don’t have a Pittsburgh edition, so I wasn’t really able to use it.

The idea is that you check in while at various locations around a city. Every time you check in, you earn points. Interesting check-ins earn badges, although I wasn’t able to figure out what constitutes “interesting”. I earned a “Newbie” badge for my first check-in. An example check-in would be something like, “@ IHOP eating a waffle”. In addition, you can track things that you want to do or have done around the city, but I wasn’t able to discern how or if this works into the scoring.

Foursquare has implemented a reward system that not only assigns badges, but ranks you against other players. Their website lists “mayors” for each city, so there is obviously some kind of competitive leader board mechanic. This has a lot of potential, but as far as I can tell, the goals are still too loosey-goosey. I expected to find a list of things to do already there. Then I could earn points by checking them off. Even if the list were built by the users, but shared, that would introduce a competitive aspect that is more than just counting the number of times you check in.

This is another very interesting example of game design being applied to “real life”, but it doesn’t seem to be as sophisticated yet as it could be.

Booyah? I say boo.

I got excited when I started reading about the new iPhone app Booyah Society. It’s a great example of a cross-over that brings aspects from computer gaming and applies them to other aspects of life. About a month ago, I wrote about incorporating a rewards system into productivity applications, and I specifically mentioned the Achievements system in World of Warcraft. Booyah claims to be an “achievement system for your life”.

The premise is that you record your activities in the application, and it rewards you for them. It gives you a way to “level up in life”. I immediately imagined a wide-ranging array of goals, categorized by type, such as “Travel to Australia,” “Receive a Promotion,” or “Take a 10 mile hike.” They would range from the extreme—“Climb Mt. Everest”—to the mundane—“Read a book.” The app is, somewhat surprisingly, free, so I downloaded it to try out.

First I customized my avatar. That bit seems completely unnecessary to me, but okay. Then I checked out the achievements.

• Food Flicker - Earn by writing 1 Food & Dining Post
• Food Firestarter - Earn by writing 3 Food & Wine Posts within 2 Days
• Food Torchbearer - Earn by writing 5 Food & Dining Posts within 3 Days

At this point, I realized that it is completely based on micro-blogging. You make inane posts to Twitter, Facebook, or just on Booyah about whatever you happen to be doing. The only goals set up are to make more posts and get comments from others.

I’m vastly disappointed by the direction they decided to go with this. This is one of the endeavors that received some of that venture capital Apple talked about when they first announced the SDK. They had the opportunity to do something really interesting here. It could have worked as motivation for people to lose weight, quit smoking, do volunteer work, get involved in good causes, see the world, etc. Instead, all it does is promote people writing more about stuff that doesn’t matter so much.

Now, that doesn’t mean that it won’t be hugely successful. I expect it would be very popular among people that already use Twitter. I’m obviously not their target audience. And, perhaps, they have plans to expand it to be a much grander game, as I have described. Or, maybe they’ve left an opportunity on the table for some other enterprising person to capitalize on.

Notable Notebook

Back in April, I posted about using “Training Wheels” to help users learn features which they haven’t yet tried. Just this weekend I began using Circus Ponies’ Notebook, and was pleasantly surprised by their implementation of training wheels.

Little tips like this one pop up the first time you encounter each feature. They fade away after several seconds. It’s an effective method of giving just-in-time training, familiarizing people with the UI as they use it.