Educational Feature: A History and Analysis of Level Design in 3D Computer Games - Pt. 1

Designing game spaces is not a new phenomenon.  Children do it on a daily basis, constructing complicated games governed by rule sets that can change at the drop of a hat. The design of computer game spaces, on the other hand, has existed for only about 30 years and in that narrow timeframe has evolved dramatically.  The level design in most early titles was part and parcel of the game design itself; often the programmer was the person designing the gameplay, as was the case with many titles by Atari Corporation. One person could, much like an auteur, create an entire game alone, but as time went on and games grew more complex the division of labor required led to the creation of a new position; that of the “level designer.”

Defining Level Design & Level Designers

Level designers, or map designers, are the individuals responsible for constructing the game spaces in which the player competes. As such, the level designer is largely responsible for the implementation of the game play in a title.  The name “level designer” is something of a misnomer, at least for modern games. Originally, games were comprised of distinct levels of difficulty, beginning with Level One. Each level was more difficult than the last, providing steadily increasing level of difficulty, hence the term “level”. Modern titles follow this formula to a degree, but the levels are no longer as simple as they were in the mid 1970’s and early 1980’s. In most modern titles, the distinction between individual levels is subtle, with transitions happening relatively seamlessly. Alternately, individual levels can be extremely large and complex, with storyline tying the individual levels together. Indeed, the term “level” now refers less to the increasing difficulty of upcoming missions and more often to the next mission or gameplay area. The term “level designer,” then, is an inaccurate description of the job; a more accurate name for the position would be “game space designer.” In the computer game industry the term level designer has become both sufficiently entrenched and sufficiently broad in meaning that everyone understands what the job consists of.

In the context of this paper, “level design” refers to the creation of levels, missions, maps, game environments, stages and any other space wherein the player or their avatar interacts with the game world.  The primary focus of this paper will be on “first person shooter”, or FPS titles, though examination of non-FPS titles that made significant technical or gameplay advances is also possible. For those unfamiliar with the genre of FPS games, they can be most simply characterized as games wherein the view on the screen is designed to simulate the view of the player’s character or avatar inside the game world. Examples of traditional FPS’s would be games such as id Software’s Doom and Quake, Valve Software’s Half-Life and Bungie’s Halo. Additionally, other titles such as Lucasarts’ X-Wing and Tie Fighter, Parallax’s Descent and Origin’s Wing Commander could also be considered to be first person shooters, since they place the player in a first person perspective, albeit inside the cockpit of a vehicle.

It is important to note that level design is not unique to three dimensional games, but is an art that applies to all genres of computer games. The level design in a two-dimensional side scrolling strategy such as Psygnosis’ 1991 Lemmings requires a great deal of forethought and testing. The extra dimension present in a 3D title adds a significant amount of work to the level designer, who must now consider movement across all three axes of movement – x, y and z, instead of merely x and z.  Reaching the current state of the art in 3D was no easy task. Before there was Unreal Tournament, Doom 3, Half-Life 2, World of Warcraft, Serious Sam or F.E.A.R. there were countless small steps, casual games, labors of love and simple curiosity that laid the foundations for all the games to come.

The Beginning – 1974 to 1991

When contemplating what game represents the original first-person perspective 3D game, the answer is not immediately apparent. Depending on the age of the person being asked, some might state, that Battlezone was the first 3D computer game, whereas others might name Wolfenstein 3D, Doom, or even Quake. While these titles may be some of the best known examples of the genre, the first documented 3D first person game appears to be Spasim, a program written by Jim Bowery for the University of Illinois Urbana-Champaign’s PLATO network (Bowery). Bowery describes Spasim as follows:

“Spasim was a 32-player 3D networked game involving 4 planetary systems with up to 8 players per planetary system, flying around a space in which the players appeared to each other as wire-frame space ships and updated their positions about every second. (Bowery)”

Bowery recalls that Spasim, short for Space Simulation, was originally released in March of 1974, but locating documentation of the exact dates for the release of many PLATO games is very difficult since little conclusive documentation exists. The reason for this is probably because these games were not seen as terribly serious endeavors, so little effort was made to record their creation and evolution. Users of the PLATO network likely had little idea that these titles would prove to be the genesis of entire genres of games. Bowery claims that Spasim is, at the very least, the “intellectual genesis” for a number of other 3D computer games, such as Silas Warner’s PLATO game Airace.  Airace later evolved into another PLATO game, Airfight, the creator of which is either Kevin Gorey or Brad Fortner. Bowery further asserts that Airfight eventually led to the development of a tank simulator for the US army. This tank simulator, Panzer (or Panzer PLATO), appeared on the PLATO network in 1977, and was apparently a highly detailed simulation for the time (Dunnigan, Ch. 6 paragraphs 7-8). Panzer was an evolution of an earlier PLATO game called Panther, programmed by John Edo Haefeli, which was also a tank simulator. Panther and Panzer would prove to be the inspiration for a game that would mark the appearance of polygon-based 3D graphics in both the arcade and the home: Atari’s Battlezone.

While Bowery claims to have the first documented 3D first person game, this claim does not go entirely unchallenged. Maze War, also known as The Maze Game, Maze and Maze Wars, was a program developed at the NASA/Ames research center in the summer of 1973 that could also be a contender for the title of  the first 3D first-person game. Maze War was aptly named, consisting of a maze constructed of polygon walls at 90 degree angles, through which a player could navigate and then shoot at other players (Thompson, slides 10-13). Maze Wars included technical innovations that were not present in many of the early PLATO titles. While the ships in Spasim were wire frame polygons that one could see through, the walls of the labyrinth in Maze War used a set of algorithms to eliminate any polygons that would not be visible to the player, lending an impression that the walls were solid (Thompson, slide 10). This is a technique that would not be seen again for some time, particularly not in the home computer market.

It is important to realize that as impressive as the technical achievements made in both PLATO games were, as well as in games developed on other networks, these systems were certainly not widely available to the public. In many cases, these computer systems were among the most powerful systems in the world at the time, and prohibitively expensive for all but institutional use. True mass-market innovation, and the creation of a more mainstream game industry, would have to wait for the emergence of a broader market in personal computers.

For personal computers, the history of level design for 3D computer games begins with the 1983 release of Battlezone for the Apple II and PC.  A “port”, or translation, of the 1980 coin-operated arcade game of the same name, Battlezone allowed players to take control of a tank tasked with destroying enemy tanks and avoiding missiles. Battlezone is significant because it represents the first use of polygonal environments and opponents combined on home computers, along with the ability to move through the gameplay space, at least on the X and Y axes of movement. The move into polygonal environments was the beginning of the transition from the two-dimensional sprite-based environments and into the world of full 3D. Battlezone represented the most basic of polygon environments, with all sides of a polygonal object being visible at all times. This served to enhance the futuristic setting of the title, but also meant that everything in the game appeared to be made of glass, since players could see through the wire frame models. Battlezone also continued the proud tradition of computer games using storyline to hide engine technical limitations; battles were fought “in a large valley completely surrounded by mountains and volcanoes” (Battlezone Operations Manual, p. 17), thus explaining why you couldn’t move beyond the area you began in. Regardless of these limitations, Battlezone was the first truly successful mass-market game played from a first person perspective.

The level design for Battlezone was relatively straightforward, in as much as it consisted of creating a game space (the “large valley surrounded by mountains”) in which the player could drive around and destroy targets for points. Essentially, the level design was that of a digital Roman arena, wherein the player could do battle, and it was a design that worked well for the limitations of the graphics engine, and provided enjoyable and novel gameplay for the arcade and home computer markets. Still, the gameplay was little removed from that of Battlezone’s PLATO forbears.

Not all attempts at 3D games involved the use of polygon-based 3D environments like those used in Battlezone; several games attempted to leverage other technology to provide an impression of a three-dimensional world. Notable efforts include Lucasfilm Games, now LucasArts, 1986 title Rescue on Fractalus!, a first-person title that used fractal generation technology to render the game world. The title is notable both for the use of a simulated 3D world, as well as for the first-person perspective. The player took the role of a pilot looking out from a cockpit, tasked with rescuing other pilots stranded on the surface of the planet Fractalus (Langston). The concept of a spacecraft based FPS would later return in LucasArts’ 1993 title X-Wing and 1994’s Tie Fighter space combat simulators, as well as Origin’s 1990 release of Wing Commander.  Rescue on Fractalus! was completed in May of 1984, but due to a number of exclusivity decisions the title did not become legitimately available for home computer systems until 1986 (Langston). According to Langston, however, an incomplete version of the game for home computers was widely pirated.

Polygon based engines, however, remained the most popular and effective way of delivering 3D gameplay, and as computing power increased throughout the late 1980’s designers improved the technology. A PC port of the BBC micro and Acorn computer title Elite, Elite Plus was a complex trading and combat simulation, wherein the player was given a spaceship and a small amount of funds then tasked with traveling to various star systems and earning money. Firebird Software’s 1987 release of Elite Plus represents one of the first documented implementations of filled polygons (Rollings, 516-517), a technique that solved the “glass enemies” issues of Battlezone by calculating and removing lines that would be blocked in a solid object. By combining these calculations with the ability to fill the polygons that made up the enemy ships with color, Elite Plus created enemies that had the illusion of a solid construction. This was a crucial step towards realism. Elite Plus also featured an impressive amount of gameplay for its time, with eight galaxies and thousands of planets. Even today, having a designer specifically craft such a universe would be a daunting task, so the authors of the software chose to use a technique of pseudo-random generation of the worlds, allowing a complex universe in a relatively small amount of space with a minimum of design effort.

The id Software title Wolfenstein 3D, released in 1992, is generally accepted as the start of the “First-Person Shooter” genre of 3D games, but id software was not the first to experiment with texture mapped 3D games.  That honor goes to the now-defunct Looking Glass Technologies for their March 1992 title Ultima Underworld: The Stygian Abyss, which was also the first Role Playing Game, or RPG, to feature first-person action in a 3D environment. All 3D RPG titles from Morrowwind to World of Warcraft share Ultima Underworld as a common ancestor, both graphically and spiritually, though World of Warcraft utilizes a slightly different third person perspective. For better or for worse, Underworld moved the text-based RPG out of the realm of imagination and into the third dimension.

Ultima Underworld: The Stygian Abyss featured an extremely advanced graphical engine, far more advanced than what the better known Wolfenstein 3D would support. Underworld could support a number of features that would not appear again until the release of Doom on December 10th, 1993 and, in at least one case, the release of Duke Nukem 3D years later on January 29th, 1996. While Wolfenstein would consist of a world with only 90 degree angles and ceilings all of the same height, Underworld allowed the use of varying height ceilings, and walls at 45 degree angles, allowing for much more complex and realistic architecture. Further, while id software’s Doom and Apogee’s Rise of the Triad would introduce stairs, it would not be until Duke Nukem 3D that a major title from a company other than Looking Glass would feature inclined surfaces, allowing ramps and other effects.  All of these elements were in place in 1992 for Ultima Underworld and David Kusner states in “Masters of Doom” that id software only contemplated the idea of applying texture mapping after designer John Romero was informed of what Looking Glass was doing with Ultima Underworld.  Id software’s lead programmer, John Carmack, admits that id’s game Catacombs 3D, a dungeon-based title that beat Ultima Underworld to market by 6 months, was motivated primarily by Romero’s interest in having id attempt a game with texture mapping. (Kusner, 89; Kent, 458).

The texture mapping that Carmack added to Catacombs 3D was a significant innovation over previous titles. The texture maps were simple, consisting mostly of stone walls with moss or vines across them, but combined with the black ceiling texture it helped to enhance the feeling of being outside (in certain levels) or trapped deep beneath the earth. In an e-mail to the author, former id game designer and creative director on Catacombs 3D,Tom Hall, stated that the texture mapping in Catacombs was “… the Wolfenstein technology, but in EGA”. Catacombs 3D also introduced a now-familiar element of many first-person shooter games; a visible weapon in the bottom center of the screen. In Catacombs 3D, that visible weapon was one’s hand, from which a variety of magical spells could be projected to slay enemies. Again, level design and layout were relatively simple, but the addition of the texture maps went a long way to deepening the immersion of the game.

Catacombs 3D itself was an evolution of an earlier id title called Hovertank 3D, wherein the player drove around in a hovering tank, destroying enemies with its main gun and rescuing trapped people. The gameplay was relatively straightforward, but it was the engine that was something new.  Id software’s head programmer, John Carmack, was bothered by what he saw as excessively slow gameplay in flight simulator titles like Wing Commander and sought to create a faster 3D engine (Kushner 81-82). Carmack utilized a technique known as ray casting, allowing the computer to essentially draw only what the viewer could see. This meant that the first id game based on this technology, Hovertank 3D, and its successor, Catacombs 3D, were much faster than any other 3D rendered game of the time. This emphasis on speed, however, meant less complexity in the levels, at least as compared to Ultima. Since both Hovertank 3D and Catacombs 3D made it to market before Ultima, though, players were unaware of the difference. The third id game featuring the technology, Wolfenstein 3D, would prove to be a genre-defining smash title.

Evolution of the Engines

Wolfenstein 3D was a remake of Castle Wolfenstein, a title programmed by the late Silas Warner and originally created for the Apple II computer in 1981 (Kent, 458). Castle Wolfenstein was subsequently ported to the Commodore 64 in 1983 and finally to DOS in 1984. The Wolfenstein 3D game engine was based on the same principles as that of Hovertank and Catacombs but with some major additions made by John Carmack. Catacombs 3D’s engine supported EGA graphics, meaning that it could only display 16 colors, far from the millions of colors the human eye can discern in real life. Wolf3D also supported 16 color graphics, but included support for the VGA standard, allowing for 256 colors, a major step up (Kushner, 97). VGA also allowed for Wolfenstein to feature higher resolutions. These graphical upgrades, combined with the speed of John Carmack’s improved rendering engine, achieved a level of immersion that surpassed anything id had done before.

The emphasis on speed, however, again led to limitations on how detailed the world was. Like Hovertank and Catacombs, the Wolf3D engine would draw just the walls, leaving the floors and ceiling a flat color (Kushner, 95; Hall). In a game set completely indoors in a Nazi castle this was a decision that ultimately had little impact on immersion, but it served to limit the flexibility of the engine. Texture mapped floors and ceilings would have to wait until id’s next project.

Interactivity in Wolf3D was relatively limited, with the player having only two ways to interact with the world; shooting things to kill them  and opening doors by pressing the spacebar, a universal “use” key. Wolf3D upped the ante, though, by adding in “push walls”. These walls appeared like any of the normal solid walls in the game, but if a user hit the spacebar in front of them, the wall would slowly slide back, revealing a hidden room (Kushner, 108). Hidden rooms and secret levels would play a major part in future id games, and First-Person Shooters in general. The push walls were another innovation by Tom Hall, who served as the director of Wolfenstein 3D (Kushner, 108-112), and served to reward the player for thoroughly exploring the game world. It was an interesting gameplay mechanic, and one that grew out of a tradition in the video game industry for including secrets, or “Easter eggs” for players to find (Kent 188-189). While many would consider these “Easter eggs” to be afterthoughts, they present an important opportunity for level designers to maximize player investment and interest in the game world. Additionally, the careful placement of such Easter eggs or bonus areas can confer additional replay value to a title, as well as providing significant benefit to the curious player. Armor, medical kits and additional weaponry or ammunition are traditionally found concealed in such hidden rooms, though later FPS titles such as Duke Nukem 3D added in secret rooms that contained little benefit to the player but gave insight into the minds and interests of the game and level designers.

Wolfenstein 3D also expanded on the weapon choices available to the player. In keeping with the style established by Catacombs 3D, the player’s chosen weapon was visible at the center of the bottom of the screen. This helped both with aiming and adding a sense of actually seeing the world from your avatar’s perspective. This technique has become a standard immersive device in First Person Shooters, and later titles have expanded on the functionality, with some titles actually adding the ability so see the players own feet when they look down. DreamWorks Interactive’s 1998 First Person Shooter Trespasser, based on the Jurassic Park license, took the concept to the extreme, with the player being able to look down and see the female avatar’s ample bosom. The player avatar had a heart tattoo on the upper part of the left breast which served as a health indicator, removing the need for a health indicator in the player view.

The design of the levels in Wolf3D was accomplished using a proprietary program, called TED5, developed by John Romero (Romero; Hall). TED5 was an evolution of earlier tile-based editing programs that id used on Hovertank 3D and Catacombs 3D (Hall). The levels were designed from a top-down perspective which was simple to do since all ceilings and walls had the same height in the Wolf3D engine (Romero). Designing what Romero referred to as a “high quality level” in TED5 for Wolf3D could take “a few hours”. Romero also observes that “Back then, it didn't take much to do a Wolf3D level since it was all abstractly represented by tiles - what you saw on the screen in the editor is not what you saw on the screen in the game.” In terms of pre-production, the designers would start by laying out the episodes, general themes and enemies first, then start designing levels that the level designer themselves found to be fun. There were few if any paper sketches of levels made, since the simplicity and speed of the editor made it more time-efficient to simply create levels on the fly, versus doing extensive pre-planning. Again, such simplicity was a direct result of the limited state of the 3D presented in these early id software titles. In effect, the games were not truly three dimensional, but could better be referred to as pseudo-three dimensional, since the player did not have full range of movement, and all rooms were of a fixed height. There were no stairs in Wolf3D, no ramps, and no way to change the players’ altitude.

Many of these engine limitations would soon be overcome, however, when id software released Doom in December of 1993. Doom fundamentally altered the First-Person Shooter genre, cementing many of the innovations in Hovertank 3D and Wolfenstein 3D as fundamental elements for any FPS. Fast paced gameplay, a variety of powerful weaponry and detailed, realistic environments became hallmarks of FPS’s subsequent to the release of Doom (Kent, 459). Indeed, Doom was such a watershed moment that most of the First-Person Shooters that followed its release were referred to, somewhat derisively, as Doom clones.

The Doom engine supported a number of new features that finally made realistic and interactive environments possible. Instead of merely featuring doors that could be opened, Doom featured the ability to alter the game world by using in-game switches and “triggers” to activate events. These events could range from a set of stairs rising out of the ground to unsealing a room full of ravenous near-invisible monsters to bridges emerging out of toxic slime. Additionally, Doom added in lifts, which could raise players to different levels inside the game world or, if used slightly differently, could act as pistons and crush players against a ceiling. Further, the Doom engine’s support of variable height floors and ceilings also meant that in addition to being able to move on all three axes, more complex architecture could also be created. Tables, altars, platforms, low hallways, ascending and descending stairs, spacious caverns and other objects could all be created using geometry.

The ability to trigger events that could release monsters or alter geometry led level designers to create a number of surprisingly complex traps for players to uncover as they played through the game, from rapidly rising floors to bridges that would sink into toxic sludge if players moved too slowly. A frequent occurrence in Doom would be players being penalized somewhat for grabbing caches of equipment and ammunition; frequently, if a number of valuable items were left in plain view and easy access, approaching them would unleash an attack. This gameplay mechanic was present in both the 1994 release of Doom II and the 2004 release of Doom 3, though some players in 2004 were notably less amused. However, for Doom players, this was interactivity and detail that they had never seen before.

Doom’s support of variable height ceilings and floors meant that players were now free to move up and down in the game world, but not withoutlimitations. Due to the implementations of the engine technology, the game could not support rooms over rooms, which meant that level designers could not have a second floor directly over the first floor, as is common in architecture. Nevertheless, this was not a significant limitation, and the ability to move around on all three axes was a major technical achievement. With careful attention to detail, level designers could deceive players into thinking the architecture was more complex.

The increasing architectural complexity was not limited merely to height changes, as the Doom engine also supported walls that were at angles other than 90 degrees (Kushner, 135). This was one of the most visible changes from the architecture present in Wolfenstein, allowing much more realistic shapes. The engine supported only horizontally sloped surfaces, however, and did not support vertically sloped surfaces. This meant that walls could have an angle to them, but that ramps and other vertically sloped surfaces were not possible. As a consequence, all floors and ceilings in Doom were completely flat.

John Carmack also used the Doom engine to greatly expand upon the previous implementations of texture mapping, now allowing textures to the ceilings and the floors, making for an improved appearance. Doom also supported a texture that could be projected onto the “sky”. This meant that when players looked outside or, as was often the case, traveled outside, they could see an image of the sky and the surrounding terrain. These textures could be changed, depending on what episode of the game, or level, the player was in. The appearance of the sky textures was a subtle confirmation that until now the majority of 3D First-Person Shooters had been confined to narrow internal corridors, with no acknowledgement of an outside world.

In addition to architectural advances, Doom also added the ability to alter the light levels in a level. All levels in Wolfenstein 3D and earlier titles were lit at the same level throughout, with no variations. This led to a very artificial appearance, since areas hundreds of virtual feet away were lit identically to areas just a few feet from the player. In Doom, however, level designers could alter the lighting of certain areas, or even add simulated dynamic lighting, such as flickering lights. In many cases, the ability to alter the lighting level was used to plunge the player into darkness at highly inopportune moments, leading to players panicking as they were attacked by nearly unseen opponents, desperately searching for a switch or trigger that would reactivate the lights. This use of actual sources of light would be expanded upon further as game engines advanced.

The level designs for Doom were accomplished using much more advanced tools than previous id titles. Romero wrote an engine-specific level editing program called DoomEd, which ran on the NeXTSTEP operating system, which was light-years more advanced than DOS, the then-current standard PC operating system or the newly developed Microsoft Windows (Romero). Developed by NeXT Computers, a company founded by ousted Apple Computer co-founder Steve Jobs, the NeXTSTEP operating system and NeXT hardware was a powerful development tool for software designers, and provided a perfect medium for John Carmack to develop the next-generation engine that would power Doom. That meant, however, that all development had to be done on NeXT systems, and then ported over to the PC. This, combined with the new complexity of designing worlds in a three-dimensional editor meant that the days of a simple tile-based editor to create levels were over.

Despite the increasedrealism that Doom allowed, from a design perspective the levels were still more suggestive of a locale than representative. The levels could be detailed in a way that gave the impression of a military base or demonic setting, but the limitations of the engines prevented more detailed representations of the environments. Doom did represent a major step forward in level design complexity and innovation, but it proved to be an even better illustration of the potential of the First-Person Shooter to actually simulate real-life locations. Doom also illustrates that levels do not have to be based on easily recognizable locations in order for players to enjoy them, nor do they have to conform to preconceptions of what an environment should look like. Few would argue that the levels in Doom accurately represent what a research facility on an alien world would look like; indeed, the fact that the world is simultaneously familiar and abstract (Kushner, 136) may be a fundamental part of the charm of the game. The emphasis in Doom was not in levels that were recognizable, but in levels that were fun to play.

The emphasis on playability, the ephemeral “fun factor” is an important aspect of level design. Early Doom levels focused heavily on replicating the appearance of an actual military facility (Kushner, 136), but the fact is that most real-life locations are poorly suited to serve as game environments A variety of factors conspire against the level designer that seeks to use actual buildings and spaces in a simulation, but the primary issue is that most real world locations are not designed to be played in, making for an unmemorable experience. The key goal of a good level design is to balance setting with flow, the balance between exploration and moving through a plausible game world and interacting with the inhabitants and items in that world. Early Doom levels were likely accurate in terms of architectural style and function (Kushner, 136), but were lacking in two distinct areas. First, the levels failed to highlight the innovations of such a groundbreaking engine. Second, the levels failed to provide compelling or innovative gameplay to the player, a cardinal sin in level design. Recognizing the problem, later level designs emphasized the fast paced “run and gun” nature of the game, and also served to showcase the technical advantages of the engine.

A later iteration of the Doom series, id software’s 2004 release of Doom 3, took a much different approach to level design, laying out highly detailed environments that looked very much like what one would expect a base on Mars to resemble. However, designers chose to take a progressive approach, wherein early levels appeared hyper-real, but as players proceeded further into the facility, the levels grew increasingly abstract, laced with pseudo-organic structures and, eventually, bringing the player into a gothic nightmare vision of Hell itself.  With an additional 11 years of technology, perhaps level designers were now better able to bring the original vision of Doom to life. Conversely, the progression into more complex and inventive levels later in Doom 3 may be an example of level designers becoming more comfortable with their tools and the game engine as development continues. Such a trend is certainly not limited to Doom 3, and is surprisingly common in game development. In several cases, levels designed early in a project are later revisited and improved upon by level designers that are now much more comfortable with their tools. In some certain cases, such as 1998 release of Valve Software’s Half-Life, the development team may completely scrap earlier level designs and start anew, though financial constraints usually prevent such drastic steps.

Despite the many technological advances that Doom displayed, there were still some sacrifices made in the name of speed. Just as with Wolfenstein 3D, enemies and many objects in Doom were not constructed of polygons, and thus not actual 3D objects. Instead, the game rendered enemies, items and many decorative objects as sprites, simple two-dimensional graphics. The advantages of sprites are that they require little processing power to generate, and sprite-based characters could be designed relatively quickly. For Wolfenstein, characters were manually drawn by artists, but for Doom several characters were created as clay models, and then digitally photographed in various poses. These digital images were then adjusted and used as the various character attack and movement animations (Kushner, 134-135). This approach reduced overhead while improving the quality of the animations. One of the major downsides to using sprites, however, is that they are two dimensional, meaning that they don’t actually look like part of the game world, but instead like moving paper cut-outs. While this could be compensated for to some degree, it meant that dead enemies and objects lying on the ground would always appear to be facing the player, even if the player did a full circle around the objects. Essentially, the objects appeared to have only one side, and the player could never see the sides or back of these objects. While annoying, the fast pace of Doom meant that this was not a priority issue, and would eventually be dealt with when engines became fully three-dimensional.

Before Doom, level design had centered on a single player experience. That is, levels were laid out only with one person in mind, the player, and how the player would progress through the level. Doom, however, added the now-common idea of multiplayer gaming into the mix, which it called DeathMatch. Designing levels for multiplayer requires a different set of priorities for level designers, depending on if the map being designed is for co-operative play or, more commonly, a map for players to do battle against one another, deathmatch-style. Level designers need to be aware of the size of the map and how many players they are designing the map for.   Too big a map and players may never find one another, but too small a map and all semblances of tactics and strategy is lost as whoever grabs the biggest weapon first will likely dominate. In modern titles, multiplayer maps are usually specifically designed for multiplayer play, though sometimes they are modifications or tweaks of levels found in the singleplayer game. More often the levels multiplayer levels are custom-designed for multiplayer play. In Doom, the single player levels did double-duty as multiplayer levels for deathmatch, as well as for the co-operative play. When designing for multiplayer, flow through the map is very important, as players should be able to quickly move from one place to another, particularly if being pursued.  Weapon and item placement are also extremely important in multiplayer games, as placing items such as armor or health replenishment too close to powerful weapons can again unbalance the game, particularly if a player decides to “camp” around these items and prevent other players from obtaining them. Several of the singleplayer Doom maps were extremely popular deathmatch levels, a testament to their excellent design. Doom also had another advantage over more modern titles.  Each of its maps was a stand alone map, not structurally linked to the map before or after it, allowing for a unified theme between maps but not requiring maps to directly flow into one another. More recent games such as Ritual’s SiN, Valve’s Half-Life and Half-Life 2 and id’s own Doom 3 features a unified level structure, where each level is a single portion of a contiguous whole. Such level architecture helps to create a feeling of being part of a larger world in the single player game but means that these levels, typically, are unsuitable for Deathmatch.

The emphasis on single player storytelling and plot structure has also led to a steep decline in the number of titles that allow cooperative play, since many of the techniques and missions that are appropriate in single player are unworkable in multiplayer. Further, since the emphasis in a single player is the individual player, there is often some form of puzzle solving in order to allow the player to proceed. In Doom, this typically consisted of finding a key or switch to open a locked door, but in newer games the puzzles or obstacles have increased in complexity. Puzzles are usually structured such that they work only if there is one person attempting to solve them, and the addition of anywhere from one to three additional players either renders the puzzles too simple or possibly breaks the game. As such, commercial designers typically do not create maps suitable for cooperative play as it is simply not time or cost effective.

Fortunately, Doom was also a leader in user-modifiable content. The game was essentially in two separate parts, with the engine being one part and content such as levels, sound effects, animations and music being contained in special files called WADs, or .wad files. By separating the content from the engine, it meant that individual users could modify the program by themselves, adding in new content (Kushner, 166). Players modifying games was not a new concept, since players had been developing content for text-based role playing games for years, not to mention hacking Wolfenstein 3D and other titles to change the content. Hacking the executable files, the program itself, was a concept that wasn’t embraced by the developers, since there was nothing to prevent people from distributing the hacked executable, and thus the game. That meant software piracy, which meant lost profits (Kushner, 166-167). By making the game easily modifiable, Carmack and id software hoped to prevent piracy while encouraging creativity.

The decision to make Doom easily modifiable led to an explosion of creativity. Users began creating their own level editing programs and their own levels, along with new music, new characters and entirely new textures. Drastic modifications, called Total Conversions, such as Aliens Total Conversion emerged, transforming the corridors of Doom into the Atmosphere processor or Med Labs from the James Cameron film Aliens, complete with facehuggers, Aliens and pulse rifles. Level editors such as Brendon Wyber’s Doom Editor Utility or DEU gave players a graphical interface allowing them to modify existing Doom levels or create them from scratch, while Greg Lewis’ DeHackEd, went far beyond the .wads and allowed alteration of the executable itself (Kushner, 168). This gave incredible power to the emerging modification, or mod, community, and this power was the key to enabling the total conversions. The mod community would come to be an important component of game development in the coming years, serving as a recruitment pool for the growing ranks of game developers.

Check back with Gamasutra Friday, April 28, 2006 for the second half of this feature!

[About the author: Sam Shahrani is an M.A. candidate at Indiana University in the Master’s in Immersive Mediated Environments program through the Department of Telecommunications. He can be reached via e-mail at [email protected]]