19. Rotary Sensitive

Representative game: WarioWare Twisted (Nintendo/Intelligent Systems, GBA)

Control description:

The rotation of the portable console itself is detected, using special inertia-sensing hardware included within the game cartridge, and translated into in-game motion. Usage of a button is optionally supported in some minigames.

Adaptability:

Extremely poor. Even the Game Boy Player, a special Gamecube attachment that allows for playing GBA games on a TV screen by the inclusion of the full system chipset, disallows playing this game -- unless you want to lift and spin your Gamecube. It simply requires a portable system to play.

The scheme in use:

Since the original game, Nintendo and Intelligent Systems have wasted little effort in cashing in on the unexpected popularity of the WarioWare series. Each uses controls unique to that version: the original a control pad and one button, the DS installment uses that system's touch screen and microphone, and the Wii version makes use of motion control and pointing functionality. By most measures, this is the best of the lot.

The decision to base a game off of a rotation sensor is not an obvious choice. A tilt sensor, maybe... that's just a pair of rotation sensors rotated 90 degrees, after all. But WarioWare Twisted has just one, and it makes no use of the control pad or any buttons other than 'A' at all. It's a tribute to the ingenuity of the minigame creators that this, the simplest control style of all the WarioWare titles, doesn't get old as fast as the styles in Smooth Moves.

How does Intelligent Systems overcome the inevitable approach of ennui for so long? First, by including quite an accurate sensor with the game so that it can distinguish between tiny movements as well as broad ones, and utilizing that range by giving most of the minigames their own distinct movement patterns. Second, by mixing up the traditional WarioWare game structure a bit with the inclusion of random, sudden "revolution" rounds that are much faster than even the customary five-second time frame. And third, because the act of spinning the controller around -- sometimes fast enough that one feels like tossing it in the air, sometimes slowly and to the extent that the system is often held upside-down -- is just silly fun.

Design lesson:

And silly fun, in the end, is what the series is about. A rotation sensor would probably not be enough input to sustain a full game, were the game anything besides WarioWare. The controls match the game. One can be strange because the other is too. Abstract, comical games are looked down upon by some in the player community, but they serve an important role: it is a lot easier to get away with casual, spurious, joyful innovation in a game where the player is just messing around for a few minutes than if he's trying to save the world from the evil Demogorgon with +5 swords of slaying and AI pathfinding quick event limit break tension gauge active time alternate costume battle combo systems.

Uncatagorized Cases

20. vi-like Movement & "Everything has a key" Commands

Representative games: Roguelikes (independent developers, many systems)

Control description:

The "hjkl" keys move on the cardinal directions, the same movement keys as in the venerable Unix text editor vi. The "yubn" keys move on the diagonals. Beyond that, there's about a dozen other standardized keys with assigned functions, then depending on the game another dozen keys that do other things.

Adaptability:

Extremely low. Most console adaptations of roguelikes get around it with control pads for movement and inventory-based, context-sensitive action menus for object manipulation, in keeping with RPG conventions.

The scheme in use:

The roguelike control method seems to be an anachronism. Many recent roguelike releases, both independent (the norm for roguelikes) and commercial shy away from it, opting for more context-driven menus. And there is something to be said, when it comes to it, for simplicity in control schemes, unless for reasons of realism the game actually needs to be complex. A flight simulator game -- now that can be reasonably expected to be complicated, because flying real planes is complicated. Meanwhile there seems to be something fundamentally odd about playing a fantasy game where you can be like Conan the Barbarian, when Robert Howard's muscleman would have taken an axe to anything resembling a keyboard.

I said the roguelike control system seems to be outdated. It should be obvious from my choice of words that I don't think it is. Well, actually, in some ways, it can be overwrought. Control style is the single biggest thing that drives players away from playing roguelikes, more than graphics, more than randomness, more than permanent death -- even more than difficulty.

One might think that there's a bit of elitism in the refusal of these games to adapt to more modern control concepts. Reading the roguelike Usenet groups doesn't help to dismiss this impression. Among some long-time players, there is even a belief that the chance of typographical errors should be part of the game -- and they will cheerfully blame you for your character's death if you hit the wrong key, claiming it's part of the game. Just so we're clear on this: it is an important job of the game designer(s) to make sure controls are easy to understand, difficult to confuse, and appropriate to the game.

But there are important advantages granted by the roguelike control style. For example, its similarity to the controls of the venerable Unix text editor vi made the game infinitely easier to pick up back in the days of Rogue, when computer games were played on terminals more than anything else, the presence of numeric keypads was not guaranteed, and most players could be expected to know vi. And these controls add an undeniable elegance to the game. In Nethack, if you want to perform some action ten times, you actually type the number 10 then the key of the command you want to do, just as in vi!

But the biggest thing that roguelike controls brings does for the genre is that it institutionalizes obscurity of object function. Er, sorry. Let me break that down. It makes less obvious the fact that items found in the game have multiple functions. In Rogue, the fact that potions can be thrown at point-blank range to affect monsters is important to the game, but this feature is intentionally obscure: it's meant to be a secret to be discovered by attentive players. If the player could bring up an item menu on a potion and see the "throw" option there, it would be a bit of a giveaway.

There are times when Microsoft has been known to make hay over the "discoverability" of their user interface. If the user poked around, so the thinking went, and right-clicked on some icon they wished to do something with, then on the menu that appeared there should be the obvious choices, and maybe some unobvious ones too. In a way, then, the menu itself is documentation. That's fine, yes... unless a feature is supposed to be undocumented. Roguelike games are not as "discoverable" in that they force the player to pick command first then item, and even when the game is asked for a list of relevant items from inventory for the command to apply to, sometimes things are left off the list in purpose.

One of the most complex roguelike games, Nethack, takes this idea to extremes. Sometimes it seems like items have more undocumented features than documented ones. It's obvious that the player should be able to drink potions, but throw them? Dip items into them? Mix them? (A)pply a potion of oil and throw it as a bomb? How about breaking wands, eating rings and amulets, writing on scrolls, rubbing lamps, or charging lanterns? And by keeping these options semi-secret, it helps to reduce interface clutter. There are actually few circumstances in the game where the player might want to break a wand, so it's fitting that this feature is not constantly visible.

Design lesson:

The trend for managing inventory in game interfaces is object first, action second, with a visible list of objects. Most roguelikes, by contrast, go action first, which helps to keep secret item functions obscure to players who don't know about them, while not restricting their use to players who do. Is throwing a potion actually useful? Could be... why doesn't the player try it?