I think that there are three aspects that provide the framework forthe design of a computer game, all of which are connected to each otherin various degrees of complexity.  My names for these aspects are: 1) idiom or pure design - what sort of system the player is going to beable manipulate, and to what extent, whether it be the reality-based universeof a game like Marathon, or a totally abstract world like that of Tetris;2) technology, often referred to as the engine - the means of deliveringthe idiom to the player, which can be anything from the texture-mapped,2.5D engine of Marathon or the flat, bit-mapped 2D graphics of Tetris;and 3) story - not only a plot-line as one would find in a book, play,or film, but also to what degree and in what way the player will uncoverthe storyline and its characters, which can range from Marathon's complexbut totally linear storyline, to Odyssey's slightly more complex forkedstory-tree plot, or to Tetris' complete lack of a story. Few would argue about the status of idiom and technology as being keyto all computer games, and it is certainly true that not all computer gameshave or need stories.  But I've included it above since it is a potentialstarting point for the creation of a computer game, though admittedly onethat I think has been used very rarely to date.  But somewhere, Iam certain, a designer  came up with a story - hopefully a non-linearone which allowed the player to make different choices which actually changedthe story's outcome - and then tried to think up what the best idiom andtechnology combination to tell this story through a computer game wouldbe. Somewhat different situations in which stories have been the basis fora game's creation exist with the Infocom text adventure authors or, morerecently, the adventure game designers at LucasArts.  Both these groupswere presented by their employers with, for all intents and purposes, completeidioms and technologies, and were told to make a story to fit with that. Both Infocom and LucasArts had established technologies to be used in relativelysimilar form in all their games - Infocom's text adventure authoring systemfor the former and the SCUMM graphic adventure system for the latter -and as such the designer's only creative process was developing a storyand telling it within the constrains of the idiom and technology they werehanded. More often - and unfortunately in my opinion - games start out withthe designers creating a technology and then cobbling together a game aroundthat.  Wolfenstein 3D would be a likely example of this:  iddeveloped fast texturing mapping code and a limited pseudo-3D world, thenslammed the most obvious idiom possible onto it - "this is what you see,including your gun in front of you, with which you will shoot everythingyou see" - and didn't even bother with more than a two sentence story tosupport it.  Not that Wolfenstein isn't an entertaining game, andthe idiom, though derived simply from earlier first person perspectiverole playing games like The Bard's Tale or Might & Magic, was verynew for an action game and quite exciting.  But still, this was technologydriving idiom, not the other way around.  Many great games have been created starting with an idiom, Tetrisseemingly a good example of this.  Chances are good that Alexey Pajitnov,in inventing the game, did not first cook up a smooth technology for makingpixels drop downward on the screen.  On the contrary, it seems likelyhe realized the interesting mathematical possibilities of trying to makerows out of odd-shaped blocks steadily falling into a constrained well,and then went about developing whatever technology was necessary to gethis idiom to work. If one thinks about Tetris and Minesweeper, an even better example ofidiom-over-all game design, idiom is what all computer games truly require,and some would say the essence of computer game design.  When workingat a past job which provided me with an especially large amount of freetime in front of a poor IBM X-terminal, I was able to cook up a text-basedMinesweeper game in about twenty minutes.  This version of that classicgame was, really, just as much fun and just as thought provoking as themany slicker ones available.  I had swiped an idiom, implemented trivialtechnology, and created a fun computer game; some technology was necessary,but it was trivial compared to the idiom.  Good technology can, ofcourse, only make a game better, it cannot make it good. This is  an appropriate juncture at which to note the interconnectionand interdependencies that surround idiom, technology, and story in games. Suppose I want to write a story-centric adventure game where the playerhas completely realistic conversations with non-player characters. This simply couldn't happen without the availability of sophisticated naturallanguage processing code as well as less-than-trivial response generatingalgorithms, to prevent the conversations from seeming totally artificial. Or what if the game I really wanted to design uses an idiom similar toTetris':  do I really need texture mapping code for this?  Thetechnology, idiom, and story one selects for a game are necessarily interdependent. It's important to realize this from the outset of development, and to recognizewhat is and is not possible and/or necessary for your game to achieve yourvision.  If you changed the engine in Marathon so that, instead ofviewing the world from your character's perspective, you were looking overhis shoulder, it might be impressive technologically but hurt gameplayat the same time, not to mention making you disassociate with the characteryou're supposed to be playing.  Thus a technological improvement wouldend up harming both idiom and story. What was the case with Damage Incorporated, then?  DI was specialin many ways, in that the publisher who contracted me to create it, MacSoft,had already acquired the rights to use Bungie's Marathon 2 engine, andalso had an idea of what sort of game they wanted to be implemented fromthat engine.  "There's a little game, just out," they said in Februaryof 1996, "called Command & Conquer.  We want you to get somethinglike that working in a 3D engine.  Oh, and make it a present day militarysetting."  For me then, the technology was by and large set. Though Alain Roy and I improved the engine somewhat by creating more interactivescenery objects and adding sliding and swinging doors, this hardly constitutesdeveloping a new technology. It's worthwhile to take a moment here to comment that I think licensedtechnologies - such as Bungie's licensing of their Marathon 2 engine -are truly the proverbial wave of the future for game development. Since computer game companies have existed they have been using sharedtechnologies amongst their line of games; Infocom is a prime example ofthis.  Their game creation was vastly accelerated by using the sametechnology in game after game.  Infocom even used virtually the sameidiom for years and years, to great commercial and critical success. (One of computer gaming's early brushes with mass acceptance was a reviewof Deadline in the May 8th, 1993 New York Time Book Review.  I doubtvery much we'll see such a review in that publication ever again.) It's only recently that companies have started selling their engines toother companies entirely - such as Bungie's license to MacSoft - and oneneed only look at id's rampant licensing of their Quake engine to see thatmany are eager to use someone else's technology - and often much of someoneelse's idiom as well - to create new games.  The more complex technologiesused in games become, the longer and more expensive it will become fordevelopers to make them themselves, and it will be, at least financially,safer to purchase what someone else has already perfected than to rollyour own. Both Microsoft and Apple's game Software Development Kits - for Windowsand the MacOS respectively, of course - are examples of very specific,much more basic tools being used by almost all developers to speed thedevelopment process.  As SDKs become more and more complex, they willbecome more and more like full game-ready technologies, as Quake is. To utilize the over-used film-to-computer-games metaphor, redesigning yourtechnology from the ground-up for each game is a bit like reinventing themovie camera, the editing table, and the projection system for each filmyou made.  Of course this means that developers spend the lion's shareof their time working on hot new technologies rather than actually tryingto invent new idioms or come up with compelling, non-linear, three dimensionalstories.  And this has lead to the near-stagnation, artistically,that the computer gaming world has been in various states of since itsbirth more than two decades ago.  I'm optimistic that as game enginesbecome licensed more and more, developers will actually feel the need todo something new and interesting with their idioms instead of just theirtechnologies. In the case of Damage Incorporated, a significant portion of the idiomalready existed, plopped in our laps in the form of the Marathon 2 engine: "you are a humanoid, you move through a pseudo-three-dimensional worldwhich bears some semblance to reality, forever pointing a gun ahead ofyou and shooting many things with it."  True, we could have strippedthe Bungie engine down farther still, which might lead one to create afriendly 3D adventure game without any death in it whatsoever.  Butthis wasn't our goal for Damage Incorporated - this was to be a real-timemodel of warfare, after all - so we left much of Bungie's idiom in place.  In fact, it might be interesting to note that we left somewhatmore of their idiom in place than our sister licensers, the MacSoft in-houseteam that created Prime Target.  They hoped for more of a PC firstperson "shooter" feel, and hence changed much more in Marathon 2's enginethen we saw fit to:  double triggers and double-fisted weapons arestill available in DI while they were removed from PT; the movement speed,though increased somewhat for both games, was bumped up much more for PT;and the complex physics model was simplified a bit for PT, while it wasleft nearly identical to Bungie's for DI.  But these are all, in essence,minor changes which didn't really change all that much of the idiom Bungiehad used for the Marathon games. But for Damage Incorporated we needed to create a way for the playerto interact with and control troops.  Indeed, how many soldiers shouldthe player be able to control?  In Command & Conquer it can bea hundred or more; was this viable for a game where the player is alsoa physical character?  It might be, but I decided the game would bemore interesting if one were just controlling a few troops.  In partthis decision was driven by my desire to include story elements in thegame, namely giving all of the player's teammates their own distinct personalities,background, and voices.  Here one can see how desire for a certaintime of story can and should change a game's idiom. Another early idiom decision was just what degree of control the playerwas to have over the teammates.  The idea was bandied about that onemight want to control a teammate's exact movement:  "move one stepnorth, two steps east."  Again, however, I was interested in the playerhaving teammates who were actually people instead of just automatons, soldierswho you could issue orders to but who might, depending on their personality,react differently to different commands.  Watching Stanley Kubrick'sout-and-out brilliant film Full Metal Jacket countless times lead me todecide which different commands one could possibly issue during combat,and I reduced these to a small enough set that I thought the player couldmanage it.  This was a more complex set of commands than was foundin the Command & Conquer (where you can, in essence, only issue thecommand "you go there" or the subtle variation "you attack that"), butagain we were working with a totally different idiom here than C&C'stop-down God mode, hence a different set of commands was necessary. A final amusing idiom anecdote:  if you think about it, there'san odd similarity between what we tried to accomplish with DI and whatBungie is trying to accomplish with their forthcoming Myth.  Bothtry to merge 3D technology with real-time strategy; the key differenceis the starting points.  Though I haven't discussed with Jason Joneshow he came to want to make Myth, it seems likely he started hoping todo something derived from real-time strategy games like Warcraft or Command& Conquer, but incorporating 3D technology similar to what he had usedin the Marathon games.  We, on the other hand, started from a 3D firstperson action game and tried to add strategy elements to that.  Jasonstarted with an idiom of real-time strategy and added 3D technology toit, while we started with the idiom and technology of a first-person actiongame and tried to blend another idiom into the mix.  Of course, ifyou don't think of it in this design-conscious way, similarities betweenthe two games are hard to find. At this point, for Damage Incorporated we had a locked-down technology,the bear minimum decisions of how the idiom should work, and some vaguesense of what sort of story-telling aspects we would be able to have. Of course this was just the beginning. This column was originally printed in InsideMac Games.