like them, you must put them in front of players to see how well they work in practice
instead of theory. Trying out brave new control styles is a noble endeavor, but you will need to make sure players actually prefer them to more traditional methods. And as you gather their feedback, long-term iteration is all but unavoidable. One example of this happened on my game The Suffering. The game was a shooter and we wanted to make it as console- friendly as possible, and thereby took Devil May Cry as a source of inspiration. At the same time, we wanted players to have the freedom to move through the environment and position and orient their camera like in first-person shooters or, specifically, Syphon Filter and our own Drakan: The Ancients’ Gates. So we developed a hybrid targeting system that provided players with intuitive movement through the world with a single thumb stick, but then allowed for simple targeting of enemies. We spent a long time developing this system and iterating on it, and felt we had done a pretty good job. Then we started hearing
grumblings from fellow developers we showed the game to that the controls seemed odd.
When we finally put the game in front of players their feedback almost universally
mentioned the controls as what they liked least about the game. We tried tweaking it a bit more, showed it to some more players, and found that the controls still seemed odd. At this point we were fairly far into development and realized that the innovative control scheme we had attempted simply was not working out. Since it was the control system we were having a problem with, we decided it made the most sense to imitate some existing control
schemes. We wanted something powerful that we knew players would be familiar with, so we copied the two-analog-stick scheme that most of the other current console shooters, including Max Payne and Halo, were using. At this point we were imitating instead of
innovating, but when we put the game in front of players again with our new control scheme they almost all praised the quality of our controls and then were able to focus their
complaints on other aspects of the game.
Particularly in action games, when your controls are perfect, the wall separating players from the game-world will disappear and they will start to feel like they truly are the game- world character. This is the ultimate sign of an immersive game, and achieving this effect is impossible without strong controls. In a game where that level of immersion is possible, the controls must be completely invisible to players. This can be frustrating to a designer. Why work so hard on something that, if implemented perfectly, will be completely invisible? The designer must realize that it is the transparency of controls that allows players to enjoy the rest of what the game has to offer.
system.
Consider a strategy game in which players have a number of units scattered all over a large map. The map is so large that only a small portion of it can fit on the screen at once. If a group of the players’ units happen to be off-screen and are attacked but players are not made aware of it by the game, players will become irritated. Consider an RPG where each member of the players’ party needs to be fed regularly, but the game does not provide any clear way of easily communicating how hungry their characters are. Then, if one of the
party members suddenly keels over from starvation, the players will become frustrated, and rightly so. Why should players have to guess at or go digging for such game-critical
information? In an action game, if players have to kill an enemy by shooting it in a particular location of its body, say its eye, they need to receive positive feedback when they
successfully land a blow. Perhaps the enemy reels back in pain or screams in agony once an attack damages him. If players do not receive such feedback, how are they supposed to know they are on the right track? Of course, all computer games conceal a certain amount of information from players, and cannot possibly communicate all of the information they have about the game-world to players. But they must communicate what is reasonable and important for the players to know, and communicate that data effectively.
Almost all games present players with a view of the game-world as the central part of their output system. Through this view players see the object they are currently controlling and its location and state in the game-world. Your game should try to communicate as much information through this view as possible. Consider a third-person 3D action game.
Certainly players see the environment and position of their game-world surrogate, but what about the condition of the player character? Perhaps as its health goes down, the
character’s animations change to a limp or hobble instead of moving normally. Similarly, the strength of the current armor can be represented by texture changes on that character, with the armor appearing more and more deteriorated as it takes damage and nears
destruction. The game can represent the character’s current weapon by showing that weapon equipped on the character. If players have a spell of protection currently in effect on their character, perhaps the character should emit a certain glow to easily communicate that. Though the designer may also want to include this data in a heads up display (HUD) of some sort, communicating it through the game’s primary game-world view makes it that much more transparent and easy for players to understand.
What the game-world view cannot represent is typically contained in some sort of a GUI, which usually borders the game-world view or is overlaid on top of it like a HUD. This GUI may be simple, such as the high-score and lives remaining display on Centipede, the small potion-health display at the bottom of the screen in the original Prince of Persia, or the score/moves display in almost any Infocom game. For more complicated games, the GUI is also more complex, such as the button bars used in any of Maxis’ Sim games, the
elaborate status display in the original System Shock, or the extensive party data provided in many RPGs, such as the Bard’s Tale games. Many GUIs in older games were created in order to block off a large portion of the screen. This was not because of any sort of design
decision, but instead because the game’s engine was not fast enough to handle rendering the game-world full screen. As engine technology has improved, games have attempted to make the game-world view take up the majority of the screen, with the GUI minimized as much as possible.
Oddworld: Abe’s Oddysee did away with an in-game GUI entirely, giving the player an unobstructed view of the gameworld.
A few games try to work without any GUI whatsoever. Crash Bandicoot, for instance, only displays the lives remaining GUI if players press a button to bring it on the screen;
otherwise a completely unobstructed view of the world is displayed. Another example is Oddworld: Abe’s Oddysee. The game’s director, Lorne Lanning, felt very strongly that any sort of GUI would distance players from the game-world. As a result, Abe’s health is
communicated to players through the way he animates. Since the game grants players infinite lives, there was no need for a lives remaining display that so many console
platformer games of the time included as their only HUD element. Certainly, as technology has allowed it, the trend has been to get away from on-screen HUDs as much as possible, allowing the game-world view to take over the screen. The advantages of the immersion gained by a minimized GUI are obvious, and if the game-world can effectively communicate all of the information the players need to play, there is sometimes no reason to use a GUI at all.
On the other hand, it is important to not go too far in the quest to eliminate a GUI. In general, a small, unobtrusive HUD is a game convention that players have grown
accustomed to and thus are very unlikely to be bothered by. Though having no HUD worked pretty well in the Oddworld games, The Getaway is an otherwise fun game that suffered because of the developer’s decision to avoid a HUD. Driving around London was needlessly difficult because, instead of having a map HUD, players were forced to navigate to their destination by making turns based on hints from the blinking turn signals on their car. This was a particularly imperfect and infuriating system when navigating the labyrinthine streets of London. Similarly, the game has no health meter, and players are required to use a considerably less precise and quite subtle player texture change to figure out their
character’s health status. Given the game’s shooting and driving mechanics, leaving out the HUD hurt the gameplay far beyond the immersion that was gained.
The most important part of designing a GUI is to try to keep it as visual as possible. In fast- paced action games in particular, the GUI is designed to communicate information to the players very quickly, whether this is the players’ current health, ammo available, or nearby monsters (through some sort of radar). If anything, the ascendancy of the graphical user interface as the dominant mode of controlling a computer, first through the Macintosh and subsequently through Windows, shows that most people think visually instead of in numbers or words. As a result, a well-designed graphical HUD in your game will be easier for
players to glance at and understand than one that contains a lot of numbers or words. This explains the superiority of the health bar over a health number or percentage. The artists will like a graphical HUD as well, since a health bar can look a lot more attractive than a big, ugly number. Though some amount of fine precision will be lost with a less precise health bar, players are willing to sacrifice this because the bar is so much easier to read quickly.
The head at the bottom of the screen in Doom is a well-designed interface element because it communicates the player’s current health visually.
A game element that is particularly well designed is the “head” used in Doom and Quake.
This face, which appears at the center of the bottom of the screen, represents the players’
approximate health completely visually. The face starts out healthy and snarling, ready to take on the world. As the players progress and they lose health, the head starts to look bruised and bloodied, eventually looking all but dead when players have almost run out of health. At any point during the game players are able to glance down at the head and instantly get a sense of how much health they have remaining. If the health had been represented instead by a number, it would have been much more difficult for players to comprehend their current health level just by glancing at it. The difference in time may be milliseconds, but in a fast-action game, that may be the difference between life and death.
Of course, the visual representation of data can also have a negative side effect if that representation is too obtuse for players to easily understand. For instance, in WarCraft, the buttons for the different actions that a unit can perform are all represented by icons, which I would generally encourage. However, some of the buttons can be a little difficult to figure out at first. Fortunately, the game also displays text at the bottom of the screen when the
players’ mouse cursor hovers over a particular button, communicating what that button will do if clicked. What would have been even better is if the icons on the buttons were just a bit more obvious. Admittedly, representing a real-world action such as “guard” through a 32 x 32 icon can be quite a challenge. The GUI for your game needs to balance the superiority of visual representation with the clarity of text, possibly using a combination of both as needed.
Audio output as a communication device to players is something that is often underused in games. Not all of the information about the game-world needs to be communicated to players through visual stimuli. For instance, in The Sims, players gain a good sense of whether their character is enjoying a particular conversation based on the tone of the participants’ voices. In Command & Conquer, players know that a unit has received a particular order by an audio cue provided by that unit: “I’ll get right on it!” Similarly, when units off-screen are being attacked, the game communicates this to players by saying “Unit attacked” or “Unit lost.” Audio cues can provide an excellent supplement to on-screen
information, or can work quite effectively as the sole way of communicating critical information.
A good output system for a game is both powerful and intuitive. It allows players to jump right into the game and understand what is happening in the game-world, but it also
provides expert players with all the information they need to play the game effectively. Over time, the data the game communicates to the players should become transparent, just as the players’ controls should become invisible once players are familiar with them. Players should not have to think about understanding the state of the world; they should just retrieve what they need by quickly looking at the screen, and then be able to react to it just as
quickly through intuitive and responsive controls. As I have stated before, it is important not to get too creative in developing your input/output systems. The dominant paradigms from other games are often dominant for a reason: they work. The expression that “good artists borrow but great artists steal” is nowhere more true than in I/O design in games.