Feedback
Every
interactive process requires that communication be two-way. In computer
games, communication is structured under the master-slave paradigm:
we (the players) give orders, and the game must perform them, and return
us any info or result derived from our orders. Whenever the game returns
us info, we are talking about feedback.
Extensive
research has been done to study the different ways of feedbacking the
user in software applications. All studies agree on the following three
"rules of feedbacking," which should always be followed:
- Any
order sent by the user should be acknowledged immediately by the system,
to give a sense of control. A threshold of 50 milliseconds (0.05 seconds)
is traditionally considered the maximum time lapse between action
and acknowledgement.
- For
actions lasting up to 2-3 seconds, some kind of visual notification
(changing the mouse cursor, for example) should be presented while
the action lasts.
- For
actions lasting longer than that, it is assumed that the player will
probably forget about that action. So, some kind of signal should
indicate the moment when the action is finished, so that the user
may take control back from the system.
To integrate
easily these feedbacking messages into our games, one may use any media
available. Graphics indications are probably the most popular, but lately
many games have made great use of sound as a feedbacking tool. For example,
whenever you select a unit in a Real Time Strategy game, it answers
with a "Yes, sir?" kind of message, the main purpose of which
is to acknowledge the selection. Feedbacking in games does not need
to be in the form of the classic and boring hourglass; it can be integrated
into the script, and thus become an added value for the player.
Standards
Computer
games have been around for some time now, and have developed an extensive
knowledge base. This knowledge may come in the form of certain keyboard
commands (F1 means help, ESC means main menu, P means pause), dialog
styles, etc.
When designing
a brand-new title, it may be a good idea to follow trends that have
been accepted as de-facto standards by the gaming community. These trends
will probably be so deeply understood within your audience that keeping
them in mind while building your game will shorten the learning curve.
In this
section I am just going to give a short listing of common practices
which are widely used in game interface design. I encourage everyone
to send me more, and maybe we can make a follow-up article containing
interface design guidelines. Anyway, here is my initial contribution:
List
1. A Short List of Possible Interface Design Guidelines
|
- A single left button click over a selectable
item means "select".
- Control + Single left button click over a
selectable item means "add to selection".
- Left button + drag + Release over an area
means "select all inside area."
- A single left button click over an already
selected item means "deselect."
- Stopping the mouse cursor for a while over
a screen area (character, scenario) means "give me info
on this."
- A single right button click over a character
means "choose from options available for the selected item
(context menu)".
- Left click after selecting an action means
"action (according to what was selected with the right
click)"
- Whenever we have selected an action, and
are trying to perform it, the mouse cursor should reflect this
by changing its shape.
- Keyboard cursor arrows mean "move in
this direction."
- ESC means "stop action and go to menu
for saving, loading and exiting"
- F1 is the key to get global help.
- Ctrl-F1 is for context-sensitive help.
- P means pause.
- M means map.
- Good guys are Green. Bad guys are Red.
- Saturated, bright colors mean "this is
alive."
- Non-saturated, gray colors mean "this
item is dying."
- The selected items (characters, menu options,
etc.) should be highlighted in some way.
- The user must be able to save and load games
at any time.
- The user must be able to access game options
(graphics, sound, etc.) within a the game, with no need to restart
it afterwards.
|
Consistency
Consistency
is a property that defines a system whose subsystems are all designed
under the same guidelines, and thus constitute a homogeneous whole.
At first sight, it sounds quite easy to understand and implement. Still,
some games keep failing to offer consistency throughout their user interface.
The reason? Today's games are built by large teams, and thus different
interface areas may have been designed by different people, each one
with his/her own ideas.
Consistency
may be applied in many different areas. Here is a listing of the main
points you should check out:
- Color
schemes
- Typography
- Dialog
design
- Controls
Software
engineering tools and modern design methodologies are the best way to
ensure consistency in today's computer games. Object Oriented Programming,
for example, allows us to create abstract classes to define interface
elements (such as buttons, dialogs, text strings, etc.). Then we can
design each element as a descendant of the base class, sharing its abstract
properties.
This concept
was introduced some years ago with products such as the Microsoft Foundation
Classes, but the game development community has been reluctant to adopt
them for the sake of performance. The truth is that OO languages (such
as C++) tend to be a little slower than classical ones, and are also
harder to optimize. Still, with today's hardware technology, maybe the
small performance hit can be worth the extra robustness OO designs can
offer. Some years ago, we were all refining our assembly "putpixel"
routine. Now these low-level graphical tasks have been successfully
transferred to specialized hardware. The OOP vs. classical programming
issue is quite similar, and maybe it's time that some developers give
away some control, and get robustness in return.
As a final
note on how to get better consistency, game designers may be interested
in taking a look at a new trend in generic software engineering. It's
a design methodology based upon OOP, and it goes way beyond it. It is
called "design patterns," and its central idea is that some
problems have been around for quite a long time and appear frequently
in software engineering. So, brilliant software solutions have been
developed, and catalogued. These proven, successful solutions are called
"design patterns," which you may find in a design pattern
catalog and use whenever you encounter the same problem again. The design
patterns solve the problem by offering a set of OO classes which implement
the solution.
Okay,
so what does all this design pattern blurb have to do with user interfaces?
Simple. Many of the design patterns that have been developed deal with
user interfaces, as this area contains many lines of code, many complex
issues to handle, and many headaches for the programmer. If you grab
a design pattern textbook and take a look at the catalog, you will find
many great ideas that will tell you the way to build well laid-out user
interfaces, and get the consistency you need.
As a bibliographical
recommendation, you may be interested in taking a look at the classical
design pattern textbook, Design Patterns : Elements of Reusable Object-Oriented
Software (Addison-Wesley Professional Computing), by Erich Gamma,
Richard Helm, Ralph Johnson, John Vlissides, Grady Booch Keep in mind
this is not a product endorsement; the book specified above is one of
the few that deal adequately with design patterns, so you don't have
much of an option.