Contents

The Learning Curve / Analogy Learning Pictographic Information / Screen Layout Techniques Feedback, Standards, and Consistency Invisible Interfaces and Customization Unique Interfaces and A Look at the Future

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.

Invisible Interfaces and Customization