Alain Roy and I, with input from MacSoft, had decided what we hoped to accomplish with Damage Incorporated: a cross between a Marathon-style first person action game and a real-time strategy affair like Command & Conquer. Our technology was set-up for us by the licensed Marathon 2 engine MacSoft had paid a pretty penny for. We had determined the shape of our idiom: what sort of control the player has over himself - in our case very similar to that found in Marathon and its ilk - as well as how they were to control their squad members. As we started actual work on our game-to-be, the notion of the story that would work for our game was beginning to gestate in the back of my brain: I picked up a copy of Morris Dees' Gathering Storm as a starting place for my studies on the modern militia movement in the United States.
Trying to figure out how the interface would work was our next big task,
and a crucial part of any game design that is all-too-often overlooked.
My copy of Webster's Ninth New Collegiate Dictionary defines interface
as "the place at which independent systems meet and act on or communicate
with each other." (Interestingly enough, my Oxford English Dictionary
(1955) has no definition for "interface" at all, and my Random House Dictionary
of the English Dictionary (1971) defines "interface" only as the place
of contract between two distinct bodies, such as oil and water. This
shows us how, indeed, our computer-oriented usage of "interface" was modified
to suit the interaction between man and machine which has only entered
the common vernacular in the last decade or two.) So our interface
allows the player to communicate with the computer, acting as a translator
of what each wants to say into a language the other can understand.
I believe that the human brain functions primarily through images, and that the brain can translate visual input in graphical form quicker than it can the written word, which must go through another level of translation to be fully understood. Hence, in a time-critical situation such as in the midst of an arcade game, the brain can more quickly understand health communicated graphically than communicated numerically.
I've always thought a particularly brilliant example of graphical representation is the human head which appears at the bottom of the Wolfenstein 3D/Doom/Quake cycle from id Software. As one plays the game and is shot by enemy forces, your health decreases. This is represented in part by a percentage at the bottom of the screen. But, more importantly, as you take more damage the head becomes bloodier and bloodier. As the player goes through the game, an extremely quick glance at the head at the head at the bottom of the screen will graphically communicate to the player what state their character is in, and they'll then know whether they should run in terror from the approaching Big Bad Guy or charge into the breech.
The Marathon games and Damage Incorporated both use health bars to communicate health graphically, which I've always though is not quite as brilliant a solution as the id head. But still, health bars do a much better job than games such as Duke Nukem which only communicate the player's current health through a numerical value at the bottom of the screen.
I always liked how Marathon communicated how much ammo the player has available graphically, by actually representing the ammo through a line of bullets representing how much is left in your gun's clip, a method I shamelessly swiped for use in Damage Incorporated. This is better than the number displayed by almost every other first-person action game for the same reason the id head is better than a displayed health percentage: the player can process the data quicker and more intuitively, hence making the gameplay more transparent. Of course Marathon and Damage Incorporated fail in that in order to find out how many clips you have left for your weapon one must peruse an inventory displayed in words and numbers, exactly what we want to get away from.
Furthermore, Damage Incorporated fails to represent other crucial player information graphically; all of the commands you issue to your teammates in the game, as well as the status of said teammates is displayed in text instead of using some sort of iconic fashion. Co-designer Alain Roy and I actually mulled over this problem. Should we replace the text-based command menus with some sort of iconic system, where the player would click on, for example, an arrow instead of the word "Go To?" We decided that making icons that obviously represented the different commands and which would be completely intuitive to the player was not something which we could count on achieving. A designer must realize that, despite "the graphics are better than words" interface rule, it will often be the case that a one word command can be interpreted by the player quicker than an unintuitive icon, and so in some cases words are simply better than icons. Warcraft, for instance, uses nicely conceived icons to represent different commands the player issues to their Orcs or Humans, but at the same time, what the icons exactly meant was never intuitive to me. Warcraft's designers were smart enough to accompany the icons with text description of the command ("Build," for instance), which one can read when uncertain what the icon means; unfortunately, this nearly defeats the point of having an icon in the first place.
Of course, my discussion of the importance of icons over text here applies mainly to games where reaction time is essential to success, whether the game is Marathon or Command & Conquer. For turn based games, or adventure games icons are less crucial. I would certainly be the last to argue that the Infocom classics would be any better with a purely graphical interface, in fact any sort of graphical interface would almost certainly ruin them.
I've mentioned Westwood's Command & Conquer a number of times in this ramble for the simple reason that I think it's a fantastic game, and that we designers could all learn a lot by studying it closely. In particular, its almost entirely graphical and iconic yet extremely intuitive interface is truly beautiful. The world is represented to the player in a simple top-down view, but as I mentioned earlier this is the part most developers spend the majority of their time making look nice. But the interface bar on the right-half of the screen, displaying all the data about the structures you're building, is the perfect combination of text and graphics. Intuitive graphical buttons represent the different structures you can build or troops you can recruit, icons quite well conceived in the DOS version but even better on the slick Macintosh port by Totally Hip Software. The amount of time remaining until a structure is built is represented in pie-graphs superimposed over these icons, and one can scroll up and down through the different structures using arrow buttons. But Westwood was smart enough not to make everything iconic: "buy" and "repair" buttons, for instance, are simply spelled out as such. Text is fine here, since understanding the functionality of these buttons is less time-crucial than knowing how long until your new troops arrive, and it would be tricky to make a completely intuitive iconic button for an action such as "selling."
In this ramble I've talked only about one half of the interface challenge: having the computer communicate with the player as quickly and transparently as possible. Having the player communicate with the computer in the most seamless and transparent way possible is, of course, extremely important and is a whole 'nother can of worms, to be opened and consumed in a later column.
This column was originally printed in Inside