I think that there are three aspects that provide the framework for the design of a computer game, all of which are connected to each other in various degrees of complexity.  My names for these aspects are:  1) idiom or pure design - what sort of system the player is going to be able manipulate, and to what extent, whether it be the reality-based universe of a game like Marathon, or a totally abstract world like that of Tetris; 2) technology, often referred to as the engine - the means of delivering the 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 uncover the storyline and its characters, which can range from Marathon's complex but totally linear storyline, to Odyssey's slightly more complex forked story-tree plot, or to Tetris' complete lack of a story. Few would argue about the status of idiom and technology as being key to all computer games, and it is certainly true that not all computer games have or need stories.  But I've included it above since it is a potential starting point for the creation of a computer game, though admittedly one that I think has been used very rarely to date.  But somewhere, I am certain, a designer  came up with a story - hopefully a non-linear one which allowed the player to make different choices which actually changed the story's outcome - and then tried to think up what the best idiom and technology combination to tell this story through a computer game would be. Somewhat different situations in which stories have been the basis for a game's creation exist with the Infocom text adventure authors or, more recently, the adventure game designers at LucasArts.  Both these groups were presented by their employers with, for all intents and purposes, complete idioms and technologies, and were told to make a story to fit with that.  Both Infocom and LucasArts had established technologies to be used in relatively similar form in all their games - Infocom's text adventure authoring system for the former and the SCUMM graphic adventure system for the latter - and as such the designer's only creative process was developing a story and telling it within the constrains of the idiom and technology they were handed. More often - and unfortunately in my opinion - games start out with the designers creating a technology and then cobbling together a game around that.  Wolfenstein 3D would be a likely example of this:  id developed fast texturing mapping code and a limited pseudo-3D world, then slammed the most obvious idiom possible onto it - "this is what you see, including your gun in front of you, with which you will shoot everything you see" - and didn't even bother with more than a two sentence story to support it.  Not that Wolfenstein isn't an entertaining game, and the idiom, though derived simply from earlier first person perspective role playing games like The Bard's Tale or Might & Magic, was very new for an action game and quite exciting.  But still, this was technology driving idiom, not the other way around.  Many great games have been created starting with an idiom, Tetris seemingly a good example of this.  Chances are good that Alexey Pajitnov, in inventing the game, did not first cook up a smooth technology for making pixels drop downward on the screen.  On the contrary, it seems likely he realized the interesting mathematical possibilities of trying to make rows out of odd-shaped blocks steadily falling into a constrained well, and then went about developing whatever technology was necessary to get his idiom to work. If one thinks about Tetris and Minesweeper, an even better example of idiom-over-all game design, idiom is what all computer games truly require, and some would say the essence of computer game design.  When working at a past job which provided me with an especially large amount of free time in front of a poor IBM X-terminal, I was able to cook up a text-based Minesweeper game in about twenty minutes.  This version of that classic game was, really, just as much fun and just as thought provoking as the many slicker ones available.  I had swiped an idiom, implemented trivial technology, and created a fun computer game; some technology was necessary, but it was trivial compared to the idiom.  Good technology can, of course, only make a game better, it cannot make it good. This is  an appropriate juncture at which to note the interconnection and interdependencies that surround idiom, technology, and story in games.  Suppose I want to write a story-centric adventure game where the player has completely realistic conversations with non-player characters.  This simply couldn't happen without the availability of sophisticated natural language processing code as well as less-than-trivial response generating algorithms, to prevent the conversations from seeming totally artificial.  Or what if the game I really wanted to design uses an idiom similar to Tetris':  do I really need texture mapping code for this?  The technology, idiom, and story one selects for a game are necessarily interdependent.  It's important to realize this from the outset of development, and to recognize what is and is not possible and/or necessary for your game to achieve your vision.  If you changed the engine in Marathon so that, instead of viewing the world from your character's perspective, you were looking over his shoulder, it might be impressive technologically but hurt gameplay at the same time, not to mention making you disassociate with the character you're supposed to be playing.  Thus a technological improvement would end up harming both idiom and story. What was the case with Damage Incorporated, then?  DI was special in 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, and also had an idea of what sort of game they wanted to be implemented from that engine.  "There's a little game, just out," they said in February of 1996, "called Command & Conquer.  We want you to get something like that working in a 3D engine.  Oh, and make it a present day military setting."  For me then, the technology was by and large set.  Though Alain Roy and I improved the engine somewhat by creating more interactive scenery objects and adding sliding and swinging doors, this hardly constitutes developing a new technology. It's worthwhile to take a moment here to comment that I think licensed technologies - 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 shared technologies amongst their line of games; Infocom is a prime example of this.  Their game creation was vastly accelerated by using the same technology in game after game.  Infocom even used virtually the same idiom for years and years, to great commercial and critical success.  (One of computer gaming's early brushes with mass acceptance was a review of Deadline in the May 8th, 1993 New York Time Book Review.  I doubt very much we'll see such a review in that publication ever again.)  It's only recently that companies have started selling their engines to other companies entirely - such as Bungie's license to MacSoft - and one need only look at id's rampant licensing of their Quake engine to see that many are eager to use someone else's technology - and often much of someone else's idiom as well - to create new games.  The more complex technologies used in games become, the longer and more expensive it will become for developers to make them themselves, and it will be, at least financially, safer to purchase what someone else has already perfected than to roll your own. Both Microsoft and Apple's game Software Development Kits - for Windows and the MacOS respectively, of course - are examples of very specific, much more basic tools being used by almost all developers to speed the development process.  As SDKs become more and more complex, they will become more and more like full game-ready technologies, as Quake is.  To utilize the over-used film-to-computer-games metaphor, redesigning your technology from the ground-up for each game is a bit like reinventing the movie camera, the editing table, and the projection system for each film you made.  Of course this means that developers spend the lion's share of their time working on hot new technologies rather than actually trying to invent new idioms or come up with compelling, non-linear, three dimensional stories.  And this has lead to the near-stagnation, artistically, that the computer gaming world has been in various states of since its birth more than two decades ago.  I'm optimistic that as game engines become licensed more and more, developers will actually feel the need to do something new and interesting with their idioms instead of just their technologies. In the case of Damage Incorporated, a significant portion of the idiom already existed, plopped in our laps in the form of the Marathon 2 engine:  "you are a humanoid, you move through a pseudo-three-dimensional world which bears some semblance to reality, forever pointing a gun ahead of you and shooting many things with it."  True, we could have stripped the Bungie engine down farther still, which might lead one to create a friendly 3D adventure game without any death in it whatsoever.  But this wasn't our goal for Damage Incorporated - this was to be a real-time model 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 somewhat more of their idiom in place than our sister licensers, the MacSoft in-house team that created Prime Target.  They hoped for more of a PC first person "shooter" feel, and hence changed much more in Marathon 2's engine then we saw fit to:  double triggers and double-fisted weapons are still 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 was left 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 Bungie had used for the Marathon games. But for Damage Incorporated we needed to create a way for the player to interact with and control troops.  Indeed, how many soldiers should the player be able to control?  In Command & Conquer it can be a hundred or more; was this viable for a game where the player is also a physical character?  It might be, but I decided the game would be more interesting if one were just controlling a few troops.  In part this decision was driven by my desire to include story elements in the game, namely giving all of the player's teammates their own distinct personalities, background, and voices.  Here one can see how desire for a certain time of story can and should change a game's idiom. Another early idiom decision was just what degree of control the player was to have over the teammates.  The idea was bandied about that one might want to control a teammate's exact movement:  "move one step north, two steps east."  Again, however, I was interested in the player having teammates who were actually people instead of just automatons, soldiers who you could issue orders to but who might, depending on their personality, react differently to different commands.  Watching Stanley Kubrick's out-and-out brilliant film Full Metal Jacket countless times lead me to decide which different commands one could possibly issue during combat, and I reduced these to a small enough set that I thought the player could manage it.  This was a more complex set of commands than was found in the Command & Conquer (where you can, in essence, only issue the command "you go there" or the subtle variation "you attack that"), but again we were working with a totally different idiom here than C&C's top-down God mode, hence a different set of commands was necessary. A final amusing idiom anecdote:  if you think about it, there's an odd similarity between what we tried to accomplish with DI and what Bungie is trying to accomplish with their forthcoming Myth.  Both try to merge 3D technology with real-time strategy; the key difference is the starting points.  Though I haven't discussed with Jason Jones how he came to want to make Myth, it seems likely he started hoping to do something derived from real-time strategy games like Warcraft or Command & Conquer, but incorporating 3D technology similar to what he had used in the Marathon games.  We, on the other hand, started from a 3D first person action game and tried to add strategy elements to that.  Jason started with an idiom of real-time strategy and added 3D technology to it, while we started with the idiom and technology of a first-person action game and tried to blend another idiom into the mix.  Of course, if you don't think of it in this design-conscious way, similarities between the 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 vague sense 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 Inside Mac Games.