Alain Roy and I, with input from MacSoft, had decided what we hopedto accomplish with Damage Incorporated: a cross between a Marathon-stylefirst person action game and a real-time strategy affair like Command &Conquer. Our technology was set-up for us by the licensed Marathon2 engine MacSoft had paid a pretty penny for. We had determined the shapeof 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 wellas how they were to control their squad members. As we started actualwork on our game-to-be, the notion of the story that would work for ourgame was beginning to gestate in the back of my brain: I picked upa copy of Morris Dees' Gathering Storm as a starting place for my studieson 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 interfaceas "the place at which independent systems meet and act on or communicatewith each other." (Interestingly enough, my Oxford English Dictionary(1955) has no definition for "interface" at all, and my Random House Dictionaryof the English Dictionary (1971) defines "interface" only as the placeof contract between two distinct bodies, such as oil and water. Thisshows us how, indeed, our computer-oriented usage of "interface" was modifiedto suit the interaction between man and machine which has only enteredthe common vernacular in the last decade or two.) So our interfaceallows the player to communicate with the computer, acting as a translatorof what each wants to say into a language the other can understand.
I believe that the human brain functions primarily through images, andthat the brain can translate visual input in graphical form quicker thanit can the written word, which must go through another level of translationto be fully understood. Hence, in a time-critical situation suchas in the midst of an arcade game, the brain can more quickly understandhealth communicated graphically than communicated numerically.
I've always thought a particularly brilliant example of graphical representationis the human head which appears at the bottom of the Wolfenstein 3D/Doom/Quakecycle from id Software. As one plays the game and is shot by enemyforces, your health decreases. This is represented in part by a percentageat the bottom of the screen. But, more importantly, as you take moredamage the head becomes bloodier and bloodier. As the player goesthrough the game, an extremely quick glance at the head at the head atthe bottom of the screen will graphically communicate to the player whatstate their character is in, and they'll then know whether they shouldrun in terror from the approaching Big Bad Guy or charge into the breech.
The Marathon games and Damage Incorporated both use health bars to communicatehealth graphically, which I've always though is not quite as brillianta solution as the id head. But still, health bars do a much betterjob than games such as Duke Nukem which only communicate the player's currenthealth through a numerical value at the bottom of the screen.
I always liked how Marathon communicated how much ammo the player hasavailable graphically, by actually representing the ammo through a lineof bullets representing how much is left in your gun's clip, a method Ishamelessly swiped for use in Damage Incorporated. This is betterthan the number displayed by almost every other first-person action gamefor the same reason the id head is better than a displayed health percentage: the player can process the data quicker and more intuitively, hence makingthe gameplay more transparent. Of course Marathon and Damage Incorporatedfail in that in order to find out how many clips you have left for yourweapon one must peruse an inventory displayed in words and numbers, exactlywhat we want to get away from.
Furthermore, Damage Incorporated fails to represent other crucial playerinformation graphically; all of the commands you issue to your teammatesin the game, as well as the status of said teammates is displayed in textinstead of using some sort of iconic fashion. Co-designer Alain Royand I actually mulled over this problem. Should we replace the text-basedcommand menus with some sort of iconic system, where the player would clickon, for example, an arrow instead of the word "Go To?" We decidedthat making icons that obviously represented the different commands andwhich would be completely intuitive to the player was not something whichwe could count on achieving. A designer must realize that, despite"the graphics are better than words" interface rule, it will often be thecase that a one word command can be interpreted by the player quicker thanan unintuitive icon, and so in some cases words are simply better thanicons. Warcraft, for instance, uses nicely conceived icons to representdifferent commands the player issues to their Orcs or Humans, but at thesame time, what the icons exactly meant was never intuitive to me. Warcraft's designers were smart enough to accompany the icons with textdescription of the command ("Build," for instance), which one can readwhen uncertain what the icon means; unfortunately, this nearly defeatsthe point of having an icon in the first place.
Of course, my discussion of the importance of icons over text here appliesmainly to games where reaction time is essential to success, whether thegame is Marathon or Command & Conquer. For turn based games,or adventure games icons are less crucial. I would certainly be thelast to argue that the Infocom classics would be any better with a purelygraphical interface, in fact any sort of graphical interface would almostcertainly ruin them.
I've mentioned Westwood's Command & Conquer a number of times inthis ramble for the simple reason that I think it's a fantastic game, andthat we designers could all learn a lot by studying it closely. Inparticular, its almost entirely graphical and iconic yet extremely intuitiveinterface is truly beautiful. The world is represented to the playerin a simple top-down view, but as I mentioned earlier this is the partmost developers spend the majority of their time making look nice. But the interface bar on the right-half of the screen, displaying all thedata about the structures you're building, is the perfect combination oftext and graphics. Intuitive graphical buttons represent the differentstructures you can build or troops you can recruit, icons quite well conceivedin the DOS version but even better on the slick Macintosh port by TotallyHip Software. The amount of time remaining until a structure is builtis represented in pie-graphs superimposed over these icons, and one canscroll 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 buttonsis less time-crucial than knowing how long until your new troops arrive,and it would be tricky to make a completely intuitive iconic button foran 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 transparentlyas possible. Having the player communicate with the computer in themost seamless and transparent way possible is, of course, extremely importantand is a whole 'nother can of worms, to be opened and consumed in a latercolumn.
This column was originally printed in InsideMac Games.