[MUD-Dev] Kuro5hin: What can games teach us about human-computer interaction?

[J C Lawrence]

From:

  http://www.kuro5hin.org/?op=displaystory;sid=2001/4/15/503/20814

--<cut>--
What can games teach us about human-computer interaction? (Technology)

By Puchitao
Sun Apr 15th, 2001 at 05:59:40 PM EST
[Software]

There are countless details that go into the creation of a
game. Characters, worlds, 2D or 3D graphics engines... sometimes
even plot! But an unusable interface can do more to ruin a game than
poor characterization, grainy sprites, or a hokey plot. We play
games to have fun; no one is forcing us to play them. I can deal
with -- I have to deal with, in some cases -- the mammoth complexity
of, say, a badly designed IDE. But when manipulating a game world
becomes a chore rather than a diversion, I'll sooner chuck the thing
than continue playing...

 Many discussions of interface-design focus almost entirely on the
 Mac/Windows "desktop" metaphor, as if folders, drop-down menus,
 dialogue boxes, and button-widgets were the alpha and omega of
 human-computer interaction. When discussing the history of graphics
 user interfaces, the progression goes something like Xerox,
 Macintosh, Windows. I suppose NeXT is in there somewhere to, and
 the KDE/GNOME "wars" somewhere towards the end. What is often
 ignored is the fact that video games, for example, have been giving
 us GUIs for two decades now, and have evolved some of their own
 idioms and metaphors to deal with their specific issues.

My question is: what can designers of "productivity" software
interfaces learn from the game industry? In this article, I'll look
at three genres of games and suggest ways that their interface
designs might inform the designs of "real-world" projects like
shells, programming environments, and desktop environments.

TEXT ADVENTURES

The text adventure era was a little before my time; I was alive,
yes, but the games were generally too hard for my little mind. Even
so, some of my earliest memories of computers were trying to figure
out how to kill some stupid alien in a cave on Mars before he killed
me or my oxygen ran out. I'm sure many of you have similar memories:

    > kill alien
    Be more specific.
    > shoot alien
    I do not understand "shoot".
    (after looking though the list of actions) > blast alien
    Blast alien with what?
    > blast alien with gun
    I do not understand "gun".
    > run away
    To where do you want to run?
    The alien's hideously long claws puncture your spacesuit. Your
    oxygen supply quickly escapes into the thin Martian
    atmosphere. More importantly, so does much of your blood supply
    and several of your internal organs.
    You have died. Your score is 8.

Anyone who has played text adventures probably has memories like
this. But these memories aren't exclusive to text gamers; watch your
average computer user struggle with the command line and flashbacks
of Martian Adventure (or whatever that stupid game was called)
appear unbidden. In many ways, text adventures were easier; at least
the commands (and, importantly, the error messages) were in English!

So it comes as no surprise that folks have tried to create CLI
(command line interface) shells with Adventure-like interfaces. The
most famous of these are advsh, the Adventure shell by John Coker,
and a bash-script version by Doug Gwyn. (I'd pick up Gwyn's; I hear
that Coker's won't compile on a modern *N?X without
hand-modification, although I haven't personally tried.) A similar
project is the MUDShell, which simulates the interfaces of MU*s.

Do these projects succeed? As with nearly everything, in some ways
they do and some they don't. Like any good interface, they introduce
some useful metaphors. For example, directories are rooms, and
special permissions might be "magical artifacts" or "keys" that some
users possess and others don't. Moving a file consists of literally
"picking it up", carrying it around, and dropping it in some other
room. On the other hand, the idioms for doing things can be
unnecessarily verbose. Walking from room to room is intuitive, but
takes much more typing than a simple "cd". Likewise, both the "room"
and the "file folder" metaphors for directories are equally valid,
but it's a lot quicker to move "papers" from folder to folder in a
Mac/Windows interface than to pick up "objects" and carry them to
their destination. (Maybe "throwing" these objects to distant rooms
would be a suitable metaphor; at least that way you can stay in the
same place.)

The biggest problem, in my opinion, lies not in any fault of these
shells but in the intended userbase. These days, anybody who's
familiar with the various of text adventures and MU*s is already
pretty comfortable with a completely textual environment. I've never
met a MU*er who claimed that a shell was too difficult. I'm sure
most of the downloads of these shells are former (or current) text
gamers who play around with it briefly for nostalgia's sake, rather
than true newbies looking to learn about CLI. Adventure shells are a
bit friendlier than sh, but to the modern, GUI-fed newbie, the
difference is negligible.

But even if there are some difficulties with these particular
shells, there are still some lessons to be learned from
adventure-style CLIs. For one, English is a bit wordy, but it's a
lot easier for a newbie to understand than cryptic UNIX
monosyllables. Also, never discard a good metaphor; the
"files/folders" metaphor may reign on the desktop, but "people and
objects in rooms" is useful, too. (Chat rooms, anyone?)

Can an Adventure-CLI paradigm be applied to any other applications,
other than shells? Perhaps interactive command-line programming
environments might benefit from a (limited) dose. I've always been a
big proponent of interactive programming environments like you might
find for LISP, Forth, Python, Haskell, etc. I cannot speak for
anyone other than myself, but I always notice much higher
productivity when such an environment is available. Incremental
development and testing help me find more bugs sooner, and these
sorts of environments support these practices in spades. (Decades
before the term "silver bullet" was coined, Forth zealots were
reporting doubled productivity... and I doubt that Forth's beautiful
syntax is the cause. ;)

I can picture several (mild) applications of the "objects/rooms"
metaphor. Modules are rooms, linked by "include/import"
dependencies, and can be explored like rooms. Classes, objects, and
functions are objects: Examining a class or object gives you, say,
its member data/functions; and "looking" at anything (a class, a
function, an object, a module) displays whatever commentary is
associated with it. Maybe spiderweb filaments between objects
indicate functional dependencies. ;) Essentially, something similar
in functionality to the class browsers popular in graphical IDEs,
seen through the metaphor of objects in rooms. Something like this
would be great for introducing certain programming concepts
(especially OO) to programming neophytes. Objects are objects;
Classes are blueprints for objects. Functions are... umm... maybe
friendly NPCs who do specific things for you: Constructors who make
objects, Accessors who tell you what's inside an object, Mutators
who modify an object, etc.

CONSOLE RPGS

The design of console-RPG interfaces was informed by one specific
problem: How to navigate lots of options and data with only a
"primitive" controller, containing at the very least a directional
pad and two buttons. This problem exists for console games of all
genres, of course, but the problem is most evident in RPGs, since
they tend (to a fault, sometimes!) to provide the greatest amount of
options and data to peruse. (Many console sports games are similar,
but it's not a genre with which I'm familiar.)

The usual solution offered is the obvious one: many mostly linear
menus navigated by the player by means of the directional pad, with
the primary button indicating "confirm" and the secondary,
"cancel". These menus are usually brought up by a third button
(start or select, for example) which, in many cases, is used only
for this purpose. Granted, there's nothing particular "clever" about
this interface -- it's an obvious solution -- but it has served the
genre for many years.

There are good and bad aspects to this interface, each of which is
magnified immensely when considered as a computer UI interface. Even
the most limited of computers (say, a simple palm organizer) must
deal with far more data and many more options than even the most
baroque of RPGs. The bad points first:

    * Once tasks reach a certain complexity, this sort of interface
      rapidly becomes a hassle. Modern console RPGs are rapidly
      reaching this point; the player of, say, Final Fantasy VIII
      (the Windows Registry of the series) might have to root around
      in the menus for a half hour to properly configure his
      party. And if a six-character party is a hassle to configure,
      I would really hate to configure XEmacs this way.

    * The flexibility of this interface is limited; even though you
      could, say, configure what's in the menus through some sort of
      meta-configuration menu, there's really only so specific you
      can get. It would be difficult -- in the case of a shell with
      this sort of interface -- to pipeline procs, or to grep
      things. (Of course, this just says "Don't make a shell with
      this interface".)

Some good points... or, rather, one good point that is spread across
two bullets:

    * A pointing device is not needed; it doesn't require a mouse, a
      stylus, or a grubby finger mashing the screen. This is a
      bigger benefit than one might at first realize. Your desktop
      may have a mouse, but not every computer will; this paradigm
      is as applicable to your computer as it is to a mall kiosk, a
      video game, your fancy new VCR, or the armrest-controlled
      personal-entertainment-thingy you might find on a nice
      airplane.

    * And even when a pointer-device is available, you don't always
      want to use it. Anyone who does a lot of text-heavy work knows
      it's nice to have keyboard shortcuts to do common tasks than
      have to switch to the pointer device and select "save" from
      the toolbar menu. It's faster, and (at least in my experience)
      isn't as stressful on your hands. Sometimes the pointer device
      is awkward; I still have trouble doing any fine pointing with
      a laptop nipple mouse, and the touchpad on my current laptop
      took some getting used to (although I'm quite fond of it,
      now).

So how might this interface paradigm be used in general computing
tasks? Well, large parts of it already are... In many programs, if
you press <ALT-F>, there's a good chance a File menu will show up,
which you can navigate via the arrow keys if you so desire. So
there's nothing truly new here for the computer interface designer
to learn. There are, however, still good lessons to be learned:

    * These "arrow-key-menu" interfaces are good for tasks involving
      small numbers of options that must be accessed regularly. To
      give a Windows example, pressing and holding <ALT> and hitting
      <TAB> brings up a foreground-task-switcher that is much
      quicker to use than pointing the mouse at those taskbar tabs
      at the bottom of the screen.

    * However, menus with many items -- especially ones in which
      some of these items are themselves menus, can be quite
      frustrating. Once in awhile, no prob, but doing it regularly
      would be a big hassle.

A sample project using this sort of interface:

A classic example of (somewhat non-traditional) RPG menu design can
be found in Square's Secret of Mana, released for the SNES. It was
also used to good effect in the sequel, Seiken Densetsu III, but was
left out of the recent Legend of Mana for the PSX. It is also used
by the excellent Nintendo emulator FWNES.

While playing, pressing the (X) button darkened the screen and
brought up a transparent menu screen. Instead of the more tradition
vertical or horizontal box (with choices like Equip, Magic, Status,
Save, etc), a circle of icons would appear in the middle of the
screen. (Left) or (Right) would cycle through the icons, and (A)
(also the "attack" button") would select the highlighted icon. There
were four different circles: An "item" circle showed your current
inventory (luckily, the number of sorts of items in the game was
limited, or else this would have become quite cumbersome). A
"weapon" circle let you choose you current weapon. A "magic" circle
let you choose what sort of magic to use (i.e., water, stone,
wind...). The last circle was reserved for less-used options like
equipping armor, configuring your party's AI, etc.

To my taste, there were several virtues of this interface:

    * It didn't clutter the screen with menus (the usual "Fight",
      "Magic", "Item" suspects) which would have been out of place
      in an action RPG.

    * It was relatively painless to switch, say, weapons during a
      battle, or use an item or magic.

    * It would remember the last cycle you used; pressing (X) during
      play would bring you to that cycle. This was useful if you
      were, say, trying out different weapons against a boss, or
      casting spell after spell; you wouldn't have to wade through
      all the menus to get there.

    * Although this is purely a matter of personal taste, I found it
      more aesthetically pleasing than the blocky traditional menus.

What sort of computer tasks might this interface be good for? A
lightweight window manager might be able to make use of
it. Eliminate desktop icons, taskbars, "start" buttons, and related
clutter from the desktop. Keep the desktop free for
applications. Reserve a button to bring up the menus; something
useless like that "flying windows" button you often find on new
keyboards, or scroll lock. Upon pressing it, the foreground darkens
and a circle of icons pops up, along with a caption box. (The
circular orientation, of course, is purely cosmetic.) The various
circles might be:

    * Tasks: the applications (both visible and minimalized) that
      the user is running.

    * Shortcuts: one or more circles of commonly used
      programs/documents. One of these would always, of course, be
      an xterm or equivalent.

    * Recent: the most recently used documents and/or programs;
      maybe the last dozen by default.

    * Options: change your background, your screensaver, modify
      what's in the other circles, etc.  This would have several
      virtues: it would encapsulate the functionality of the start
      button, the taskbar, desktop shortcuts, etc, and furthermore
      it wouldn't clutter up the screen in doing so. It wouldn't
      require switching to the mouse to operate, either. Now,
      there's nothing revolutionary in its design -- in many WMs,
      you can get the same functionality by right-clicking on the
      desktop -- but I still think it's worth implementing, if only
      for aesthetic variety. (I had planned on maybe doing this as a
      pet/educational project, but I'm still too much of a *N?X
      newbie to roll my own WM just yet.)

GRAPHICAL ADVENTURE GAMES

There was a time when graphical adventure games -- now nearly
extinct -- ruled the roost. What contributed to their demise? 
3d-acceleration or other computing advances, maybe? The fact that,
after many years of inventory-based puzzling, game designers had to
resort to very counter-intuitive puzzles in order to have anything
new? I dunno; anyway, it's not the subject of this
article. (However, it is interesting to note that, in the
near-vacuum of inventory-adventures, console RPGs are making more
use of useable inventories of objects and more item-based
puzzles. Perhaps adventures and RPGs are finally reconverging?)

Much of what I said above under Text Adventures applies here, as
well; the "rooms/objects" metaphor remains unmodified. However, the
interfaces of Graphical Adventures have their own idioms and deserve
to be treated separately.

The first graphical adventures were pretty much just text adventures
with graphics; think of the early Sierra games or the Legend
classics. Later, they developed their own idioms, like LucasArts'
SCUMM system or Sierra's SCI . SCI games tended to use different
cursors for different actions, while games using the SCUMM (Story
Creation Utility for Maniac Mansion, IIRC) engine generally had a
list of verb-buttons along the bottom of the screen. Clicking on the
verb and then on an object in the game window (or an object in your
inventory) did the chosen action to the chosen object. Mid-period
SCUMM games like Indiana Jones and the Fate of Atlantis or Day of
the Tentacle managed to provide rich puzzles using a mere 9
verbs. Later SCUMM games had different takes: Sam 'N' Max Hit the
Road used a verb-cursor similar to that of Sierra's SCI, and Full
Throttle and The Curse of Monkey Island had the user right-click and
choose an action from a little pop-up kinda interface.

Why might this sort of interface be a useful in human-computer
interaction? For one, it maintains the "doing actions to objects"
metaphor of text adventures, but there's no CLI to frighten new
users. Several desktop environments, in fact, have used this
metaphor, although none that I've encountered do so
satisfactorily. Packard-Bell, for one, used to ship its PCs with a
program that made your computer interface look like a (very
yuppie-ish) house with which you interacted in a sterile, Myst-like
fashion. Its biggest flaw was the fact that you really couldn't do
anything with it, and it was about as lightweight, customizable, and
extensible as Stonehenge.

One might take the comparison between Myst and SCUMM/SCI a bit
further. Myst was extremely simple as regards object
interaction. For each object, one thing could be done with it. You
clicked on it, and it did something. What that something was was
outside of your control. On the other hand, each object in a more
traditional graphical adventure had several things you could do to
it (although some might not be valid for that object). Modern file
managers do a bit of both: most of your actions consist of clicking
on a file icon, and the file manager guessing what you want done
with it. But there's usually a way to circumvent this: right
clicking often gets you a menu of possibilities, limited though they
may be.

A proposal for a file manager with somewhat more complexity: Most
graphical file managers take very seriously the metaphor of
"objects"; the actions you can do to these objects, however, remains
limited. (This is why some people -- probably much of the k5
population -- prefer CLI shells; you are able, in a certain sense,
to "define your own actions".)

This file manager might consist mainly of two parts: An object-style
view of the file system, and a list of "verbs" (represented,
perhaps, as labeled icons.) How the file system is viewed isn't an
essential feature; you could have a tree-view a la Windows Explorer
and its relatives, a view of a room with object icons lying around,
a cushion treemap a la Sequoia View , a topological-view thingy with
files and directories as vertices, etc. By default, the "view" verb
is active -- perhaps the cursor assumes the aspect of an eye -- but
right clicking cycles the cursor through the verbs. Nothing here
that can't be done in any graphical file manager. However, a big
shortcoming of most file managers is the inability to "create new
verbs". One of the reasons I still use a command line is because you
can't "gcc <file>.c -o <file>.o | less" or something similar. There
is no real reason why you should be able to customize the verbs,
adding new verbs to your vocabulary (or forgetting ones you never
use) as your needs dictate. Behind those "verbs" could be simple
shell scripts in a simple shell language (or a full fledged one, if
need be). (BTW, if anyone knows of a graphical file manager that can
do such things, I'd really appreciate a link.)

-------------------------------------------------

The above lessons are, of course, not the only ones we can learn
from game UIs; they're simply the first that came to my mind. I've
only attacked three genres, after all. God games would, I imagine,
be a fruitful source for interface ideas. I haven't even touched 3D
games or VR interfaces. (For example, here's DOOM as a tool for
system administration.)

What lessons (good or bad) have you learned from the interfaces in
your favorite games?
--<cut>--

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev