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.   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 worldin which he can interact in various ways.  The interface through whichthe player performs actions and comes to understand the results thereofshould be as seamless and transparent as possible.  If you make atruly good interface for your game, only other game designers should reallynotice 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 perhapsfilm buffs - should notice the difference between the directorial stylesof Frank Capra and John Ford:  both were storytellers first and foremost,who dabbled in intricate camera movements and innovative editing stylesonly as a means to communicate their ideas, never letting the techniqueovershadow the story.   A good interface is so crucial to a game that really regardless ofhow good your graphics may be, how compelling your storyline, or how ground-breakingyour technology, without a seamless, mostly transparent interface for theplayer to interact with your game through, your game as a whole is lessthan the sum of its parts.  I remember reviewing Bullfrog's Populousfor the Macintosh a while back; regardless of what a good game might-wellhave been hidden in there, the Macintosh interface was so gawd-awful, itshideousness 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 communicatingto the player.  Game designers have been known to get either or bothwrong, but if either half doesn't quite function, the whole interface mustbe considered a failure.   For us, communicating the state of the world was largely already setforth by the technology and idiom borrow from Bungie's Marathon: you view the world as if you were walking through it, sometimes switchingto an overhead map for guidance.  We saw no need to change this styleof representing the world, it certainly having been accepted in any numberof "first person shooter" games that came before Damage Incorporated. Truth be told, the "world view" area of a game is not often what designersscrew up.  In fact, it's often the case that 95 percent of the designersefforts go into making that world view look just as beautiful and impressiveas possible, whether it be represented through a 3D texture-mapped viewas in Damage, a three-quarter top view as in Blizzard's Diablo (forthcomingfor the Macintosh), or the simple top down view used in Command & Conqueror even Space Invaders.  What designers so often neglect and fowlup is the rest of the screen, which communicates to the player how muchof their health remains, what weaponry they're currently armed with, or,in the case of Damage Incorporated, what the status of their teammatesis.   If there's anything that the popular triumph of a Macintosh style GraphicalUser Interface (GUI) over the older text-based parsers associated withthe Apple II, Unix, and DOS, is that people like to interact with picturesmore 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 overthe Mac's very pleasant GUI any day.  But I digress...)  As agame designer creating an interface for your game it's crucial to keepthis in mind as much as possible.  Whenever you feel tempted to communicateto the player some quantity they should be aware of - their remaining health,for instance - think to yourself:  could I represent this in someway other than a number? 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.