Portal

Many gamers routinely lose track of time while playing a computer game. For me, it has been years since it happened last.

When I finally sat down to play Portal, I finished the game thinking it was around 8 or 9PM, 10 at the latest. It was 2:30AM.

Some have complained that Portal was too short a game. Truth is, if it had been longer, I wouldn't have gotten any sleep that night!

Steve Williams has said most of what I would say about the game (all of it glowing praise). To his comments, I add the following:

If you are a game designer, or anyone curious about how designers make games, complete the Portal maps to unlock their Developer Commentary.

Listen to the Portal devs, and you'll see how they applied playtesting - and the principles of usability - to the game. In Portal and in Team Fortress 2 interviews, the developers have commented on how iterative design helped them make their games more usable.

Also, I think we'll be seeing a lot more songs written for/with computer games after the success of "Still Alive," the closing song to Portal, sung by voice actress Ellen McLain and composed by Jonathan Coulton.

Happy Portaling!

A Rule of Thumb from Rules of Play

Within Rules of Play, the authors advocate something so phenomenal, I am compelled to quote it:

"We have a straightforward rule of thumb regarding prototyping and playtesting games: a game prototype should be created and playtested, at the absolute latest, 20 percent of the way into a project schedule."

My heart grew three sizes when I read those words. Look at the rule another way: At least 80% of a game's development cycle should be testing, redoing, and polishing. at least.

Imagine what awesome games could be made if design teams were expected to take 80% or more of their development time refining and perfecting their prototypes.

There exists at least one such game - Puzzle Quest. Infinite Interactive had a playable prototype for Puzzle Quest up and running after only 2 months. Then they spent an additional 25 months tinkering with, adding content to, and polishing the game. Having a working prototype just 7.4% of the way into their project schedule allowed them to develop a fun, successful game.*

While I couldn't find precise numbers for World of Warcraft, we can infer that a large part of Blizzard's development cycle is spent on iterative design, given the high level of value they place on game polish.**

In my experience, games like these are the exception.

I'll be keeping my eye out for other examples of games that followed the <20/>80 rule of thumb during development. It would be an interesting chart to look at game success vs. how much time dev teams spent in the prototyping and iterative design phases.

References:
* The September 2007 issue of Game Developer has a comprehensive story on the development of Puzzle Quest.
** Rob Pardo's keynote speech for AGDC 2006 gives some hints on the amount of time Blizzard spends polishing.
I encourage all game designers to read Rules of Play, a game design textbook by Katie Salen and Eric Zimmerman.

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?