Modes Are Bad

This applies to computer/video games.

This comes from UI design. Back in the days of VI, you had an Edit Mode and an Insert Mode, and people who weren't used to it would constantly forget which mode they were in and type the wrong thing. Emacs came along and fixed that, and "No Modes!" became a mantra of sorts at Xerox PARC. (I forget where I read about this, it might have been in Brenda Laurel's *The Art Of Human/Computer Interface Design*)

If it's bad for text editors, it's bad for games, too. Mario Sunshine has the three kinds of water spouts; if you jump on a ledge ready to use your jump jet nozzle and discover you've left it in squirt nozzle you're screwed. Zelda's kind of the same deal.

Of course, these are great games, which goes to show that this rule is trumped by OrthogonalElements. With the limited number of buttons on the controller, the only way to get a large palette of player actions into your game is with modes.

One place you can avoid modes is when you have the choice between a toggle option and a hold-down option. Many people say "I hate holding the button down for so long" as an argument for a toggle sprint (Diablo II, which doesn't have enough buttons for a hold-down sprint) vs. a hold down sprint (most video games where you can move at two speeds.)

Caveat

Modes are a means to cleanly break up groups of functionality. They can't be all bad. One would hope that with clear and obvious feedback, in the form of user interface elements, the current mode will not be left to chance. For example, a big fat icon, a different colour, a focus ring, or other blatant sign of the current mode.

Emacs says it has no modes, but it is lying. Just by pressing the first control sequence in a double-control sequence, you have entered a mode. Using menus can be considered a means of switching between modes -- you can't access other menus when you're already in one.

If you use modes, make their current state blatant.

CategoryGoodIdea