Usability is Usability Everywhere

On Next Generation, Blake Snow wrote an article called Videogame Usability 101: Ten Features Every Videogame Designer Should Embrace.

Having worked as an information architect, I noticed some similarities between Blake's 'features' and Jakob Nielsen's ten general principles for user interface design.

And why not? A lot of what makes a game is its UI. I'll quote both authors here in tandem to tease out the similarities between their two lists, and add some of my own commentary.

Nielsen's heuristics are listed in order, with Snow's analogous features beneath each. My own words are in italics.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

5. Never let a camera get too close to a player or bump into a wall.

Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

This usually isn't much of a problem in games, since the player audience - and thus the language they understand best - is identified early in production.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

4. Always let players skip cut scenes no matter how important they are to the story.

10. Always let gamers get in and out of gameplay as they desire (otherwise they'll just turn the console off).

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

MMOs are so new, conventions are still being debated on. The industry could stand to nail these down. For example, I never know which slash command logs me out of an MMO. Is it /camp, /quit, or /exit? Why not support all three?

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

1. Never ask a player if they want to save their game.

8. Never use insipid, indefensible enemy attacks.

Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

2. Always say "press any button" to start a game.

Flexibility and efficiency of use

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

3. Always let players remap controller buttons to suit their preferences.

7. Always give players full control of accessiblity options.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

6. Never make use of every controller button just because you can.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Games do this with gestures more often than words. For example, when you enter a room, the camera glances up at the object you need to interact with to solve the puzzle. Or, key features of the game environment will move in a particular way, or change their appearance on mouseover. Features like these suggest solutions before problems arise, leading to less player frustration.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

9. Always present in-game tutorials, FAQs, and help menus for newbie gamers.

Peggle vs. God of War

In my quest to learn more about game design, I decided to play God of War this past weekend.

I enjoyed the character, Kratos, and had a great time spinning his Blades of Chaos with Apollo's Ascension to hack enemies to bits. Then I came to the Rooftops of Athens, where I promptly got stuck. The room is like this: archers shoot at you while you jump from one vine-covered pillar to the next, then onto a platform.

Easy enough, right? I jumped over and killed the archers, then hopped nimbly back onto the vine-covered pillars. I could jump between the pillars easily, but the jump to the platform was simply impossible. I tried it dozens of times, and even recruited a gamer friend to help out. He just kept falling, too. Neither of us could figure out the catch.

I looked up three different online walkthroughs, and none of them spoke of that jump as being difficult at all. I went back and tried the jump another several times, then gave up in frustration.

Eager to feel some sense of success, I decided to give in and download the Peggle trial that Cuppycake suggested. The juxtaposition of genres nearly broke my soul.

After I won a few games, and got over the rainbows, woodland animals, and flashing colors, I found myself playing with the main menu. That's right. The main menu. I discovered that each of the buttons plays a different note on mouseover. There are eight buttons, one for each note of the scale.

Of course, the first song I played on my new Peggle xylophone was Ode to Joy, the music that plays when you win a game of Peggle. And I couldn't stop laughing, because that's exactly what the designers of Peggle must have been thinking when they assigned mouseover sounds.

On that note, it reminded me how important it is to include little things in your game that allow players to not only play in the game, but play with the game.

The other design lesson of the day is to not make jump puzzles so hard that the average player can't make it after several tries.

As for me, I'd love to see a Peggle interface mod with God of War graphics and sound. Can you imagine Kratos shedding a tear as you mouseover the Quit button?

Writing for Quests

Attending Jess Lebow's panel at AGDC, I was reminded of just how difficult it is to write quests for MMOs.

Jess spoke of the differences in approach that designers and writers take to quest writing.

Typical designers often just want to get the instructions across to the player, like so:
"Take Spike's club to the Ulbroth foothills. Ask an attendant of the Great Gates where Ulbroth Graveyard is. Go to the Graveyard and search for Spike's gravestone, then right-click Spike's club to activate it at his gravestone."

Typical writers often just want to tell the player a story, like so:
"The great ogre, Spike, once wielded this very club. He smashed more giants than any other ogre at the battle of Ulbroth, where the ogres fought the giants for control over the Ulbroth foothills. This battle meant everything to both factions, for Ulbroth is a land rich in both iron ore and peasants waiting to be turned into slaves..." (writer hits text character limit)

My experience indicates that a third kind of quest writer exists - the 'hardcore' quest writer.

These 'hardcore' quest writers intentionally omit key details from their quests because they want players to figure out the quest for themselves, like so:
"All that is left of the great ogre, Spike, is this club. Some legends speak of him fighting giants."

And, I must admit, depending on the complexity of the game you're writing for, sometimes a puzzling quest is a welcome diversion.

So what's the ultimate goal? Ideally, quest writers must balance all three of these needs (instructions, story, and puzzle) within the context of the game they're working on. They have to give the player enough of a clue to figure out how to resolve the quest, tell enough of a story to keep up the player's emotional interest, and generate enough of a puzzle to keep the player's mind engaged... and do it all within the text character limit constraints of the game.

It's not easy.

Accessibility Matters

/rant

So, I cracked open BioShock the other day. I installed it without any problems, and started up a new game. The intro played smoothly, and already I was wrapped up in my character, destined to do great things.

Then, it dumped me into the game. Blackness filled the screen as large white squares spun before my eyes. Orange blurs smeared across the screen every now and again as I panned the mouse around. I tried moving - WASD - and heard some sloshing and gurgling noises. I couldn't tell where I was, or what I was doing. Just blackness, white squares, and orange blurs.

What's wrong here?

Well, obviously, my Radeon 9800 Pro wasn't up to the job - but that's not really the problem. The issue is that I made it that far into the game without knowing that I didn't meet the system requirements.

One of my pet peeves is the lack of courtesy that some games have towards their players. It would have been courteous if BioShock had warned me I couldn't play before it let me get sucked into the story. Back in the day, video games wouldn't let you install them if you didn't meet the system requirements. They'd often even let you know what you were missing. This is a feature that every game needs - and it needs to be up front.

You might ask, "Aren't the system requirements written right on the box?" Well, after reading the box, two of my game developer friends and I thought my machine would run the game just fine. The truth is, system requirements paragraphs have gotten to be about as mumbo-jumbo as EULAs.

You might say that that's why we have readme files. Well, after the game didn't work, trust me, the readme file was straight where I went. Here is what it says I need - "Video Card: Pixel Shader 3.0 compliant video card with 128 Meg Ram and floating point frame buffer blending." Like the average player knows whether or not their video card has those things!

It was only after some googling that I found a raging community of would-be BioShock players, all of them with video cards lacking in Pixel Shader 3.0 compliance, and all of them just as upset as me.

This brings me to my second point, which is, when you are making a game that won't work with a large percentage of potential players' graphics cards, consider making your game compliant with those graphics cards. BioShock is a great example - it only takes a few user-made files to get the game to run (albeit only passably) with a pixel shader 2.0 card. It wouldn't have taken too much more effort on the developers' part to make BioShock to run well with those cards.

As Gordon Walton said, "This is not about getting some more customers -- this the opportunity to get lots more. Like 4-10x more. There is maybe one game a year that drives hardware sales... they get a lot of hype, but look at their numbers. How much do they sell?"

/rant

New Toy!

I was going to write a nice serious post tonight, but I've been thoroughly side-tracked by Game Maker.

It's a fun little game-building tool that I was introduced to at AGDC. If you haven't played with it yet, give it a shot!

Transportation vs. Travel

In my last two posts, I've been careful to use the word 'transportation' instead of 'travel,' and with good reason: My goal is to highlight the gameplay differences between the two.

Transportation lets players move among places they've already been. In some cases, transportation lets players move among places that their characters would have had easy access to - even if the player is new to the place.

Players travel when they go somewhere new. When players successfully travel through a new area, they often earn new modes of transportation.


However, the line gets blurred fairly easily. For example, when players choose to take 'the long way' or 'fight their way' through an area they've already been, I would say that the players are traveling.

Another blurry line appears when players use their own mounts or vehicles. If players can whiz by content that would put them in danger if they weren't on their mount/vehicle, then I'd say that's transportation. However, if the use of the mount/vehicle only causes players to encounter danger more frequently, then I'd call that travel.

Links to my other posts on the subject:
Meaningful Transportation
Beautiful Transportation

Beautiful Transportation

So, let's run with the idea that transportation in MMOs doesn't need to generate fiero. This still leaves designers with a variety of emotional options.

My two favorites are delight and wonder - the twin joys of beauty and discovery. No matter what the medium (running, teleportation, vehicle-on-rails, etc.), transportation gives designers the perfect opportunity to bring about these emotions in players. It fits because players can be shown things they don't often see, and because the experience doesn't last long. Wonder is a brief emotion, just like transportation in MMOs must be a brief experience. On top of all that, there's a real-world connection: wonder and delight are emotions of fun that you experience while traveling in the real world.

Taking players to places they don't often go is a great way to generate wonder. In WoW, for example, the griffon flies over places that are inaccessible to players, and each different griffon route shows players another piece of Azeroth they would never have otherwise seen. Taking players over these areas encourages them to piece together the world and discover its connectivity. This is a refreshing mental exercise in WoW, since the main play experience has players spending their time in walled-off zones.

Viewing enjoyable artwork generates delight, and moving through an artistic landscape heightens that delight. Artists who know their trade can work with designers to put together amazing transportation paths that elicit delight at every hill, lake, or turn. Vehicles and mounts should be artistically engaging, if not detailed; players are likely to watch their mount or vehicle more than their own avatars during travel. Even in a teleportation situation, the means of teleportation can be made delightful with the skillful use of particle effects, animations, or cut scenes.

Possibly the most important fun emotion related to travel is the visceral pleasure of movement, which can be represented in games by animations.

If 'run' animations for avatars, pets, vehicles, and mounts are crisp, clean, smooth, and exaggerated correctly, it can give players an enjoyable sense of movement. If those animations include some sort of whimsy (like the cat ears that swivel in WoW), all the better. As someone who has studied birds, I'm something of a connoisseur of flight animations. It's more enjoyable to watch strong, flexible wings that pull you through the air with each downstroke than it is to watch stiff wings with plain up-and-down movement. Well-made animations can make earning a mount (or any form of travel) worth the hassle.

So, looking at these emotions (delight, wonder, and pleasure of movement) as the requirements for fun travel, we can evaluate the types of travel found in games.