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.   As game designers, we are first and foremost making games, not interfaces: the point of our work is to represent the player in an artificial world in which he can interact in various ways.  The interface through which the player performs actions and comes to understand the results thereof should be as seamless and transparent as possible.  If you make a truly good interface for your game, only other game designers should really notice it, as they will look at it and marvel at its brilliance.  Think of this in the same way that only other film directors - or perhaps film buffs - should notice the difference between the directorial styles of Frank Capra and John Ford:  both were storytellers first and foremost, who dabbled in intricate camera movements and innovative editing styles only as a means to communicate their ideas, never letting the technique overshadow the story.   A good interface is so crucial to a game that really regardless of how good your graphics may be, how compelling your storyline, or how ground-breaking your technology, without a seamless, mostly transparent interface for the player to interact with your game through, your game as a whole is less than the sum of its parts.  I remember reviewing Bullfrog's Populous for the Macintosh a while back; regardless of what a good game might-well have been hidden in there, the Macintosh interface was so gawd-awful, its hideousness was all I talked about in my review.   Interface is necessarily broken into two ying-yang like halves:  the player communicating to the computer, and the computer communicating to the player.  Game designers have been known to get either or both wrong, but if either half doesn't quite function, the whole interface must be considered a failure.   For us, communicating the state of the world was largely already set forth by the technology and idiom borrow from Bungie's Marathon:  you view the world as if you were walking through it, sometimes switching to an overhead map for guidance.  We saw no need to change this style of representing the world, it certainly having been accepted in any number of "first person shooter" games that came before Damage Incorporated.  Truth be told, the "world view" area of a game is not often what designers screw up.  In fact, it's often the case that 95 percent of the designers efforts go into making that world view look just as beautiful and impressive as possible, whether it be represented through a 3D texture-mapped view as in Damage, a three-quarter top view as in Blizzard's Diablo (forthcoming for the Macintosh), or the simple top down view used in Command & Conquer or even Space Invaders.  What designers so often neglect and fowl up is the rest of the screen, which communicates to the player how much of their health remains, what weaponry they're currently armed with, or, in the case of Damage Incorporated, what the status of their teammates is.   If there's anything that the popular triumph of a Macintosh style Graphical User Interface (GUI) over the older text-based parsers associated with the Apple II, Unix, and DOS, is that people like to interact with pictures more than they like to interact with text.  (For the record, however, I'm not one of these people:  give me a nice powerful Unix shell over the Mac's very pleasant GUI any day.  But I digress...)  As a game designer creating an interface for your game it's crucial to keep this in mind as much as possible.  Whenever you feel tempted to communicate to the player some quantity they should be aware of - their remaining health, for instance - think to yourself:  could I represent this in some way other than a number? 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 Mac Games.