Invisible
Interfaces
Thinking
broadly, computer games are about fun and immersion. We (game developers)
try to make them (players) have a good time and escape from everyday
life for a while. Under these rules, a visible and obstructing interface
may break the sense of immersion, and thus spoil the experience as a
whole. Take, for example, the first-person shooter genre. In Quake,
the game is laid out as a collection of levels. Between levels, the
game is interrupted and the classical "Loading..." page appears.
Now compare this to Valve's Half-Life (built on top of the same
Quake engine). Here, the game is a continuous whole, and loading
sequences are avoided by caching map sections.
When the
user is playing Quake, we have him (or her) immersed completely
in the gaming environment. To sum up, he's having a real good time.
So, when the "loading level" screen appears, we are deceiving
him, by breaking the sense of immersion. Interface interruptions should
be avoided whenever possible, by integrating them into the game. Some
interruptions may be easier to handle than others (integrating a CD-ROM
swap into the script of a medieval RPG would be quite hard). Still,
we must try to keep the player immersed in the game as much as possible.
The idea
of integrating interface aspects into the game to improve immersion
is quite powerful, and not necesarily limited to hiding level loading
sequences: it can be applied in many other situations as a global strategy.
The X-Files game, for example, did a fine job hiding its own
user interface under the storyline. Our player (an FBI agent) carries
a series of typical special agent items (a PDA, a flashlight, a cellular
phone, etc.) which allow him to interact with the game. The PDA (one
of those portable electronic agendas), for example, serves as game map,
inventory manager, etc. This makes the game very intuitive and easy
to pick up. Blade Runner, from Westwood, followed a similar approach:
since our character was a futuristic special agent, it seemed logical
that he carrieed a personal computer, where most of the interface functionality
was integrated.
So, we
can build a non-intrusive interface by basically encapsulating its functionality
into the game itself. Still, we must not forget the other principles
of interface design I have been outlining - for example, the screen
layout principle that tells us to keep relevant controls visible at
all time. Making invisible interfaces does not mean taking buttons and
commands away from the screen, as doing so would make the game hard
to play. A better goal would be to substitute every control that can
break the game's sense of immersion with an adequate metaphor. If the
metaphor we choose integrates nicely within the game environment (as
the PDA in the X-Files game, for example), the game atmosphere
will be greatly improved.
Customization
When it
comes to playing games, people are more different than one might think.
Some are left-handed, others right-handed. Some are aggressive, others
are more strategic. If we are all so different, how come many games
offer little or no customization at all?
Customization
may come in a variety of ways. As a first step, one may offer control
customization. This includes the basic keyboard-remapping routines,
joystick and mouse configuration, etc. The need for such features can
be demonstrated with an obvious example: as a left-handed person, I
feel much more comfortable playing with the left area of my keyboard
than with the usual right side cursors.
Still,
there's more to customization than keyboard remapping. For example,
a game should provide a way to record new commands, and encapsulate
several low-level actions under certain keystrokes. This may be very
helpful in medium-to-complex games, such as simulations or RPGs. Just
imagine the potential of a well designed macro language in a Real Time
Strategy title: the user would be able to record something like:
- Stay
on guard until someone gets close enough
- If
he's an enemy:
- If
he's stronger, run away in the opposite direction
- If
you are stronger, attack
These
simple scripts would allow the user to automate character behavior,
and may be helpful to improve performance, especially in the steady
state of the time vs. knowledge graph.
Some games
offer this kind of functionality right now. Baldur's Gate, for
example, allows the user to assign "behavior scripts" to your
characters. This way you don't have to control every reaction, but allow
the system to follow the behavior guidelines you outline. As an example,
see the script below, borrowed from Sean Woodcock's great AI article:
Code
Listing 1. A script borrowed from Sean Woodcock.
|
IF
// If my nearest enemy
is not within 3Range
(NearestEnemyOf(Myself),3)
// and is within 8Range
(NearestEnemyOf(Myself),8)
THEN
// 1/3 of the time
RESPONSE #40
// Equip my best melee
weapon
EquipMostDamagingMelee()
// and attack my nearest
enemy,
// checking every 60 ticks to make sure he is
// still the nearest
AttackReevalutate(NearestEnemyOf(Myself),60)
// 2/3 of the time
RESPONSE #80
// Equip a ranged weapon
EquipRanged()
// and attack my nearest
enemy, checking every 30
// ticks to make sure he is still the nearest
|
Sean used
this as an example of extensible AI, and he was right. Still, to me
it looks also like a nice interface feature: the ability to automate
tasks which would become boring and repetitive.
As a first
step, this feature is brave and brilliant. However, these advanced options
are usually hidden in some obscure configuration files, and are thus
unfriendly and hard to use. Future games should allow this customization
to be performed in a simple way, from inside the main game engine, as
easily as you change your weapon.