Toiling with Tools
by Richard Rouse III

Since 1994, when I started working professionally in game development, a world of change has come about in the tools developers use to create games. The main impetus behind this change has been the transition of game engines from 2D to 3D. As the 3D engines in modern games have become orders of magnitude more complex than their 2D brethren of five years ago, so too have game development tools become major development undertakings. These days, many game development teams find that they have to allocate one programmer primarily to tools creation, if not multiple personnel in the early stages of a project. And when it comes to game-world design the quality of the tools a game designer has at their disposal will be directly proportional to the quality of levels they are able to create. Generally speaking, game creation tools are not so extensive and all encompassing and powerful that a team can discard their copies of 3D Studio Max or Softimage. When developing the tools, the team is face with a quandary. Practically speaking, no amount of time spent working on a modeling tool is going to make it as nice and feature rich as an off-the-shelf package like 3D Studio Max. But then at the same time, there are many advantages to working with a tool which is tailored not to the creation of 3D art in general but to game levels in particular. Specifically in a level editor, the ability to see the game-world the designer is creating using the actual 3D technology that will render it in the game (the game's own rendering engine instead of an art package's) while working on the level results in greatly simplified world creation. And in the final analysis simplified world creation leads to better levels in the game, as designers have more time to make their levels fun instead of just making them work. Furthermore, being able to quickly jump into the game and test out sections of a level while editing it, a function many of the best level editors include, has a significant payoff in terms of well-balanced gameplay. Each of the four projects I've been involved with has used an established technology and tool-set that existed before I started working with them. In some cases the technology was licensed, in others the company I started working with had developed the technology prior to my arrival. So I've never gotten the chance to design my idea of the perfect level-editor. But one might ask would I have known what the perfect editor was? Certainly when I started working in gaming I had no idea what an editor should do to make for the most pleasant level design experience possible. Even now, having used four different level editors, I'm still not sure I could make the perfect tool set. But I have a better idea, and looking back on the four projects I can get a sense of what each tool did right as well as where each was lacking. 2D Beginnings: Odyssey My first project was Odyssey - The Legend of Nemesis, a 2D role playing game with a classic Ultima style view of the world. For those who might not know what "Ultima style" is, in that classic computer role playing game the player sees the world from a bird's eye, top-down view. Not even three-quarter or isometric, but strictly top down. The technological origins of Odyssey lay with another game, Minotaur: The Labyrinths of Crete, one of the first published games from a very young company called Bungie Software. They were hoping to turn Minotaur (which had been a network-only dungeon battle game) into a full blown RPG. But when other, more promising opportunities presented themselves the company put the RPG on the back-burner. I happened along and was eager to finish the game for them. At this point the level-editor had already been created. Though I made some additions to it as I worked on the project, these were minor. Before writing this article, I looked at the Odyssey editor, called Zoner, and was astonished how simple it was. After years of working with 3D level editors, I was amazed at how easy it was to create a top-down, 2D level. The world of Odyssey is made up of a set of tiling textures on a grid, with special transition textures between different types of terrain, such as from grass to sand, or from sand to water. The editor is smart enough to automatically transition between these different types of terrain, so making levels is as easy as painting with some grass, then clicking and dragging with the mountain tool. The game automatically knows which type of materials the player can walk over and at what speed: full speed on grass and slow over mountains, with water being impassable. So there's no need for the level-designer using the Zoner tool to specify where the player can and cannot go: it's already set up by the terrain they lay down. The game also features "overlays" which can be placed on the landscape. Items such as chairs, trunks, or bushes can be plopped down over the terrain to spice up the player's environment. Though 2D games are far less prevalent than they were when Odyssey was in development, many games still use 2D worlds, such as the recent hit strategy game Starcraft. (The colossal commercial success of which suggests that maybe gamers don't care that much if a game is 3D or not. But that's a topic for another day.) And setting up the architecture for these levels is still really easy compared to creating a 3D environment. That's not to say that making a level that's going to be fun, well balanced, and appropriately challenging is trivial, merely that the level designer has to worry a lot less about the level's physical architecture. First Step into 3D: Damage Incorporated Damage Incorporated was my first 3D project, and made use of the Marathon technology, also licensed from Bungie, which at that point had been used in their games Marathon and Marathon 2, and would later be used in Marathon Infinity and a number of other licensed games. At the time I remember being blown away by how impressive the editor was. Called Vulcan, the editor was good enough to be released in a commercial incarnation called Forge along with Marathon Infinity. (I remember talking to the programmer who was responsible for getting Vulcan "good enough" to sell to the public, and he commented on how much of the code had to be rewritten to get the bugs out. What was supposed to be a simple undertaking had sucked up months of time. One thing about proprietary tools in the gaming industry is that they're often riddled with bugs, and until the level designers learn to work around the crash-bugs their work will be severely hindered. Of course bugs that can't be worked around end up getting fixed. But why fix a particular problem if all the designers can just agree not to do whatever it is that causes the crash? The public, however, expects better quality software than professional game designers. Which is maybe backwards, if you think about it.) Levels in the Marathon engine consisted of a collection of lines making up convex polygons. Each polygon has a floor and a ceiling height. Players could then move between polygons that shared a line and whose floor and ceiling heights lined up appropriately. Any structure that appeared to be solid in the game-world, such as a girder in the middle of a room, actually consisted of space where there wasn't a polygon, so I always thought of designing a level as working with "negative space" to create structures. The technology was limited in that one couldn't have a structure such as a bridge, where a player could go both under and over it. All of the objects one would see in the world that weren't made up of these polygons were sprites. These included weapons, enemies, pieces of furniture, and other decorative objects. In order to not look funny as the player walked around them, these sprite objects had to be cylindrical. This resulted in lots of light bulbs sticking out of the ceiling, trash cans, and barstools. Objects that moved, such as the enemies the player battled, could be drawn from multiple viewpoints, and the engine would then switch to whichever viewpoint best accommodated the angle the player was looking at them from. The Marathon engine is quite similar to the technology used by the mega-hit game Doom and its sequels. The Vulcan editor provided nice tools for creating and manipulating lines and "filling" them to become polygons, all from a top-down view. The top-down view couldn't be rotated in any way (so as to provide a side-view, for instance). Since there was the potential for polygons at one elevation on top of others at different elevations in the top-down view, Vulcan allowed the user to show only the polygons within a given height range. In the top-down view one could also see the placement of all the aforementioned sprite-objects: scenery, monsters, or items. The best aspect of the Vulcan editor was its ability to let the designer jump right into the level and navigate it as they would in the game. Though the user couldn't battle the monsters or fire their weaponry from this "View Mode," they could run around the levels as they would in the game, using the same physics the player would experience during gameplay. This allowed the designer to test out jumps and to really get a feel for how the level would play. From this 3D view the user was also able to place textures from a texture-palette. As with Odyssey, the textures were still square, tiling textures, and could be applied to walls and ceilings, and then dragged around with the mouse so the designer could line them up exactly as they wanted. The one major drawback here was that one couldn't manipulate the 2D top-down view of the level while in the 3D view, merely because the editor was never designed to handle that functionality. Outdoor Environments: Centipede 3D When I came on board at Leaping Lizard Software to work on Centipede 3D, the rendering technology and editor were largely completed, and not much changed technology-wise during my tenure on the project. The technology had been used in a previous game called Raider and was thereby called the Raider engine, with the editor remaining unnamed and just called "the editor." The Raider technology had many differences from my prior experience with the Marathon engine, as Raider and Centipede were set in outdoor environments, while Marathon and Damage Incorporated were what is commonly referred to as "corridor" games, since most of the gameplay takes place in small, confined, interior locations. The Raider technology was also fully 3D, allowing for all of the ambient objects and enemies one found in the game to be arbitrary 3D Studio Max created models. As a result of the outdoor nature of the technology, creating the geometry found in the levels in Centipede 3D was a wholly different experience from Damage Incorporated. The geometry for all of the levels in Centipede were made by 32 x 32, 256 shade grayscale height-maps. Each pixel on these height-maps represented a vertex on the landscape, which was made entirely of triangles. If one had four pixels in a square on the height-map, all at the same height one would see a square, flat plateau in the game. If two adjacent heights differed, one would see a slope between them. This technology allowed for a continuous flowing terrain. This terrain was then enhanced by the objects the artists would create in 3D Studio Max and which could then be imported into the game. Bridges, plants, houses, and all manner of architectural objects were incorporated into the game-world in this way. The engine and editor also supported limited "instancing" of these objects, which allowed them to be scaled and rotated in various ways. This meant that, though there might be only one flower model being used in the level, the player would perceive a wide variety of different flowers. A very nice feature of the Raider editor allowed the user to see a top-down view of the level they were editing on their main monitor, while they could see a 3D view of the level on their second, 3D-accelerated video card powered monitor. One could then make changes in the 2D view and instantly see them reflected in the 3D world. Another plus was being able to hit the "Go" button and instantly be playing the game from the 3D view. Since the monsters and other active objects in the world moved around while one was playing, the state of the level would change so that you couldn't save it any more, since the monsters and other objects would no longer be in their proper starting locations. If the designer wanted to make changes after having clicked "Go," they would have to quit the editor and rerun it, reloading the level in the process. Fortunately this was a fairly quick process, and didn't prove to be unduly frustrating. An interesting note is that when the Centipede 3D project was started, the height-maps used by the landscape were not actually editable in the editor. They were created in Photoshop, and then the designer could run the editor to see how the height-map looked in the game. Midway through the project the functionality to edit the height-maps was added to the editor, and the maps began looking better almost immediately. One can really tell the difference between the early, flat, and somewhat more blocky levels, and the smoothly undulating terrain of the later levels, which were made after designers could easily massage the terrain in the editor. Here is a case where, though a designer could technically make a level without the ability to edit the height-map in the editor, the absence of this feature had the direct result of making the levels worse. Since a designer could still make levels without this feature, this removed the urgency of having the feature added to the editor, which explains why it was so long before it was finally implemented. The Raider engine is the only system I've worked with that did not involve tiling texture sets. Instead, a Raider engine level used a giant texture map which is stretched over the entire terrain. This has the tremendous benefit of allowing for any sort of customizing of the landscape texture that the designer had in mind, including unique winding paths and completely non-repeating textures. The disadvantage is that, due to a limited amount of memory, Raider engine levels can't be very big before the texture gets stretched, blurry, and unattractive. As a result, all of the levels in Centipede 3D were on a 32x32 height grid, though the engine could support any power-of-two square (64x64, 128x128, and so on). This texture map was not created in the editor however. Designers and artists had to work on these outside of the editor in Photoshop, and then run the editor to see if they had lined up the texture to the terrain properly. They could then go back to Photoshop to make adjustments as necessary. Techniques were developed by the team for simplifying this process, and surely implementing a texture editing system with anywhere near the robustness of Photoshop would be a daunting task and perhaps even a foolhardy undertaking. A Very Sophisticated Tool-Set: The Riot Engine In June of this year I started working at Surreal Software. Surreal completed their first game, the 3D dragon-riding action-adventure Drakan in August. The technology that game uses is titled the Riot engine, which includes the Riot level editor, and the Riot modeler. I was hired as a designer on their next original project, which is still a secret and won't be done for at least a year, so I can't discuss it specifically. I can say that my project will use a new revision of the Riot engine, including many added features and improved functionality. In the time I've been at Surreal I've become quite familiar with the technology and its editor, even though I haven't yet finished a game using the tools. The Riot engine is, like the Raider technology, an outdoor engine, designed to create rolling terrains. The concept of a height-map and its correlation to the terrain one sees in the game is actually quite similar to that found in the Raider engine, but the Riot engine takes it one step farther. In a Riot engine level, you can have as many layers of arbitrary dimensions as you would like, and as a result the levels don't have to be square. Furthermore, multiple layers allows for ceilings as well as floors, allowing for the creation of caves and other enclosed spaces. By stacking layers on top of each other vertically, designers can create complex architecture, including such tricky structures as spiral staircases. What's particularly impressive is the massive tool-set available for sculpting the terrain into whatever the level designer envisions. Many of these different sculpting tools aren't used very often or by all of the members of the design team, but one can't help but be awed at the range of brushes and options the Riot editor provides for molding the landscape. The texturing is again done with tiling texture sets, making it significantly different from the Raider engine, lacking the unique customizability of a Centipede 3D landscape texture. But, on the other hand, the levels in the Riot Engine can grow to be enormous without exhausting the texture memory. When I arrived at Surreal, the textures did not automatically transition from one terrain type to another, as the old Zoner editor for Odyssey did. At my suggestion, I was given the task of adding that functionality to the editor, and now texturing a level is a quite simple process. What's telling here is that, though at first glance the Zoner editor is completely out of date and the features contained in it would seem inapplicable to creating a 3D world, in all this time the texturing techniques used are the same. I was able to take something the Zoner did well and apply it to the vastly more sophisticated Riot Level Editor. The Riot engine is probably the most professional looking in-house tool-set I've ever seen, and is in such good shape that Surreal was able to release it to the public to allow fans to make add-on levels for Drakan. Similar to the Raider level editor, designers are presented with a top-down view of their level, along with a 3D view from a camera position, which they can easily move to whatever part of the level they like. Unlike the Raider engine, the Riot engine only makes use of one monitor, and shows both the 3D view and the top-down view on the designer's main monitor . The 3D view is fully 3D accelerated (indeed, Drakan requires 3D hardware acceleration), and in order for the 3D card to simultaneously draw the top down view and the 3D view, the designer has to have a very powerful 3D card in their machine. The Riot engine level editor doesn't have the "Go" functionality of the Raider engine's editor; instead designers can hit a hot-key which runs the game and automatically loads the level they are working on. This is a fast enough process that it's just as practical as the Raider engine method, but saves the designer the trouble of having to quit and re-load their level. The drawback of the Riot Engine in its current incarnation is that designers are limited to creating layer geometry. This is fine for creating a rolling landscape, but doesn't allow for the creation of right-angled structures like man-made buildings or their interiors. Basically, everything that the Marathon engine does well (corridors), the Riot engine doesn't do at all. Currently, all buildings and interior structures are created in 3D Studio Max by artists following a designer's specification, and then imported into the editor by way of the Riot engine modeler. This problem is currently being addressed as one of the technology improvements, and soon designers will be able to create all of their levels' gameplay areas in the editor itself. Of course, importing 3D Studio Max models will still be available and necessary for creating a fully detailed level. Outdoor vs. Indoor The difference between creating indoor and outdoor environments is almost more of an engine issue than a level editor one. For real-time rendering of a 3D environment on PCs or console gaming systems, in order to get the speed necessary for fast-action gameplay, the game engine needs to know what type of environments it will be rendering and be optimized accordingly. A recently released game in which the developers wanted both indoor and outdoor environments, Descent 3 ended up actually using two separate rendering engines for the different types environments found in the gameplay. Descent 3, interestingly enough, also allowed the designers to create their levels in 3D Studio Max or other 3D packages first, and then import them into the game's editor where they could be further manipulated. This gave the designers the ability to access the rich feature set of professional modeling packages, while still allowing them to tweak the levels in a proprietary tool which would give them a better sense of how the level would play in the game. Of course the danger is that someone will come up with the bright idea that, hey, you don't really need an editor, you can probably do everything in 3D Studio. This person will probably be a programmer, most likely one who's trying to get out of some work. (Being a programmer myself, I can say that.) A surprising number of development teams have tried to dodge having to make a level editor, but for more complex games this can lead to truly disastrous results. Just look at Trespasser, a game that is widely hailed as one of the worst in recent memory. The development team on that game were stuck with using 3D Studio as their only world-creation tool, and in the amount of time they spent overcoming bugs associated with using a modeler as their level editor, they could have written their own tool, and probably ended up with better levels as a result. (If you want to read about the Trespasser development team's arduous trials and tribulations while creating that game, go read the game's "Post Mortem" for the game published on the Gamasutra web site, http://www.gamasutra.com.) The Final Analysis As the tools necessary to create a "cutting edge" game become that much more sophisticated, the motivation to license engines becomes even greater. Usually with licensed technology one can expect a fairly robust, well-debugged editor, which will greatly facilitate game creation, and get production on your game up-and-running almost immediately. The number of companies who have licensed the Quake or Unreal engines is amazing, especially considering that five years ago nearly everyone was still "rolling their own." A company called Multigen will even sell you their Multigen Creator package, which provides you not with an entire engine but just with a sophisticated 3D-world editing tool. Their ad testifies to the fact that a significant number of console developers for the Nintendo 64 and Sony PlayStation have been using Creator for the majority of their games. Looking back over the various level editing tools I've used, two rules of thumb seem to present themselves. First, level editors are most important because they allow designers to set up their levels while keeping track of how they will look and play in the game. The better editors will allow users to move objects in 2D while seeing their movement in a 3D world, and will allow the designer to quickly try out a section of a game to see how it will play. Second, putting features into the editor directly correlates to better levels in the final game. Often programmers don't want to spend their valuable programming time on the tools, since the tools won't actually make it to the end-user, and are thereby seen as less important. But if the levels get better because of a more sophisticated and easy to use tool, the person who made that tool work so well should be able to feel a certain authorship role in the superior levels it generated.