Desired Functionality

So what sort of functionality should a level editor include? Many might suggest an important part of any level editor is having hot keys hooked up to all the important functionality. Others would recommend plenty of configurable settings that allow different designers to turn on and off the features they prefer, when they need to use them. It goes without saying that a level editor should be stable enough that a designer can use it for a number of hours without it locking up. But these suggestions are all obvious; they are the bare minimum that an editor should do to be useful. What sorts of features should be included to allow an editor to truly shine , to empower designers to do the best work possible?

Visualizing the Level

The most important objective for a world creation tool must be to allow the designer to see the world he is creating while simultaneously enabling him to make modifications to it. This is often called What You See Is What You Get (WYSIWYG) in the domain of word processors and desktop publishing packages, but is not something that level editors are universally good at. I will call such a WYSIWYG view the player s view since it represents what players will see when they play the game. The world the designer is crafting should be seen in this player s view window using the same rendering engine the game itself will employ , whether this means 2D or 3D, sprites or models, software driven or hardware accelerated. This seems to be the most important feature of any level editor. How can a designer hope to create a good looking world if he must first tweak the world s settings in the editor and then run a separate application to see how it looks in the game?

The designer should be easily able to move the camera in this player s view so that he can quickly maneuver it to whatever section of the map he needs to see in order to work on the level. This movement is probably best accomplished with a simple flight mode in which the designer can control the camera s position using simple movement and turning keys. In this mode the camera should move without colliding with geometry or other game-world objects. Though one may also want to provide a mode for the player s view where the designer can maneuver through the game-world as players will in the final game, the editor should always allow the designer to move around the level unconstrained. In order to finely edit a level, the designer must be able to look closely at whatever he wants without having to worry that a tree blocks his way.

Every difference that exists in what the designer sees in the editor and what will show up in the game will make the levels look that much worse . Suppose only the unlit view is available in the editor, while the game itself has fancy lighting that creates pronounced shadows. This will create frustration for the designer, since he will not be able to easily tell how the level will appear in the game. Sure, the level looks great when playing, but while in the editor he has to guess what the lighting will be like and how the changes he makes will affect the final level. A limitation like this would be especially unacceptable if the gameplay relied more on lighting and shadows.

Of course, the world as it will appear in the game is not always the best view from which to edit that world. For this reason, level editors often need to include an editing view in addition to the player s view. The editing view is often top-down, but may also consist of a rotatable wire-frame view or multiple views. The last option is particularly useful for the editing of 3D game- worlds . For instance, the popular Quake engine editing tool Worldcraft, which was used to create all the levels in Half-Life, provides the designer with the popular tri-view setup, with which the designer can see top-down (along the Y axis), from one side (along the X axis), and from another side (along the Z axis) simultaneously in three separate windows . The three side views appear in addition to a 3D player s view window. Having multiple views is of particular importance for editing complex, overlapping 3D architecture, such as one finds in Quake levels. In contrast to the player s view window, which exists in order to show the designer exactly what the level will look like in the game, the editing view s purpose is to allow the designer to easily modify and shape what he sees in the player s view window. Of course, the editor should allow editing views and a player s view to be all up on the screen simultaneously, and the changes made in one window should be instantly reflected in all the views. Also, just because I refer to one view as the player s view and one as the editing view does not mean users shouldn t be able to edit all the game content in all the views.

The view provided in the Zoner level editor for Odyssey was perfectly suited to editing a 2D world.

In some cases there may not be a need for separate editor and player views. For instance, in a 2D world such as was found in my first game, Odyssey: The Legend of Nemesis , the player s view of the world may be perfectly suited to editing the levels. While I worked on the many levels for that game, not once did I wish for another view of the game-world. Similarly, in StarCraft, the representation of the world as it appears in the game is sufficiently clear to allow the designer to make modifications to it directly. For this reason, the StarCraft Campaign Editor provides only a player s view window for the designer to edit in. However, for the StarCraft editor, it might have been beneficial to provide a separate editing view. Because of the isometric view the game uses, a view which can sometimes be confusing to look at, a strictly top-down view in which the designer could edit his level could have been quite useful in the placing and manipulating of units and other game elements. The StarCraft Campaign Editor does include a top-down mini-map of the level being created, but the designer cannot actually change the level using that view, nor is the mini-map large enough to allow for easy editing.

The Big Picture

I have argued that it is important for a game s level editor to allow the designer to see the level exactly as he will see it in the final game, but the player s view window does not always need to represent exactly what players will see. It can be quite useful if the level editor can also show the designer various extra information about the level that will assist in that level s creation. For instance, suppose that the game being developed involves various monsters maneuvering the level on predetermined paths. Being able to see exactly where these paths go is key to understanding how the level functions and to making sure the paths are set up properly.

In many level editors, this sort of level functionality information is communicated in the editing view but not in the player s view, but it makes sense to display this data in both places. Certainly the player s view window should not always be filled up with this sort of level functionality information, but the ability to turn on and off the rendering of different data can be quite useful in setting up the level s behaviors. This is especially true for 3D games . Returning to the path example, why should the designer have to extrapolate in his head from the 2D top-down or side editing view exactly where a path will end up in the 3D view? Instead, the editor should just draw it for him, so there is no guesswork.

When working on Centipede 3D , a programmer was adding code that would prevent players from traveling up slopes that were too steep. In order to debug this new slope-restriction code, he added functionality to the level editor that allowed it to toggle on and off lines that separated the different triangles that made up the landscape. These lines would change color depending on whether or not a given edge could be crossed by players. The triangles themselves were marked with a red X if they were too steep for players to rest on. The programmer added this functionality primarily to aid in his debugging of the slope-restriction code, never realizing what a boon it would be to the level designers. Now the designers could see exactly where players could and could not travel on the level. An even better side effect was the rendering of the triangle boundaries, which created a sort of wire-frame view of the landscape, functionality that had not previously been available in the editor. This then vastly simplified the editing of geometry, for now the designers could see exactly which triangles created which slopes and then modify the level accordingly . The addition of the wire-frame view and the slope-restriction markers led directly to better, more refined geometry in the final game. And the beauty of this functionality was that it could be turned on and off in the editor, so if the designer wanted to see how the level looked he could turn it off, and if he wanted to see how it functioned he could turn it on.

As with paths, it may also be useful if the designer can turn on and off the rendering of objects such as triggers and other normally invisible objects. Similarly, it can be enormously helpful to display the bounding information for the objects in the world (which often does not exactly match the visual composition of the object s sprite or model), so the designer can easily observe how the bounding information will impact the ability of players and NPCs to navigate the game-world. Marking off where players can and cannot go can be quite useful as well. And again, each part of this functionality data should be easily toggled on or off via hot key, menu, or button, so that the designer has the choice of seeing exactly the data he needs for the problem he is working on. And the data should absolutely be rendered in the player s view window in addition to the editing view, so that the designer can see exactly how the trigger, path, slope restriction, or other object is placed in the game-world, without having to guess from a top-down view. By using a visually authentic view of the game-world that can also display game behavior data, the designer is able to work on a level s aesthetic qualities just as well as its gameplay attributes.

Jumping into the Game

For games where players are manipulating a character through a world, it is important for the designer to be easily able to know how the level feels to navigate. To this end, in addition to having the player s view of the world represent what players will see in the game, it can be quite useful to allow the designer to actually maneuver in this view as he would in the actual game. With this sort of addition, the designer is able to test whether players will be able to make a certain jump, how it will feel to navigate a particular S curve, and whether or not the players character moves smoothly up a set of stairs. In addition to this gameplay mode, the level editor should retain the unconstrained flight mode I mentioned previously.

Bungie s Forge level editor for the Marathon engine included a visual mode where the designer could actually maneuver through his level exactly as a player would in the game.

The Vulcan editor for Bungie s Marathon engine was particularly well suited to allowing the designer to test the feel of the level while constructing it. The Marathon technology was similar but a bit better than Doom s, and was licensed for use in a number of other games, including my game Damage Incorporated. Vulcan was subsequently revised, renamed Forge, and released with the final game in the series, Marathon Infinity . Vulcan/Forge allowed for a visual mode, which functioned as a player s view window. In visual mode the designer could navigate the world just as players would in the final game. The shortcoming of this was that the designer was unable to edit the world, aside from texture and lighting placement, while in this view. This was no doubt due to the speed of processors available when the editor was created, and the comparatively small size of affordable monitors at the time. Today, it would definitely be expected that this view could be opened simultaneously with other views, allowing users to switch back and forth from it trivially with a mouse click or hot key press.

Similarly, designers would expect to be able to edit more than just the lighting and texturing in this view. Nonetheless, the visual mode in Vulcan was quite useful, and the switch from editing mode to gameplay mode was fast enough to allow the designer to make a change, see how it felt, and then switch back to make more changes as necessary.

Of course, one might conclude that the next logical step is to allow the designer to actually play the game in the player s view. In this way the designer can see how well different mechanisms function, and what sort of a challenge different adversaries will present. However, this opens the programmer up to a large amount of implementation difficulties. In order for game-world objects to function as they do in the game, many objects will move from the position they start out in when players begin the level. For instance, an aggressive troll might run toward the player character and attack. Do these moving objects then actually move in the level editor as well? And what happens if the designer saves the level in this new state? Surely that is a bad idea, since all of the locations in which the entities have been carefully placed will be changed. What a designer wants is to be able to quickly test a level at any given location, and once he is done playtesting have the level revert to its unplayed state. This may best be accomplished by allowing the designer to quickly enter a test mode and then exit it just as quickly, instantly returning him to level editor functionality. The quicker this transition the better, for the faster and easier it is, the more likely the designer will want to go back and forth to test and retest the playability of his level. If the designer has to wait a minute or longer to playtest , he will not be able to try as many different changes to the level before he gets behind schedule. For this reason, it makes sense to have a programmer focus on smoothing out and speeding up this transition as much as possible.

Any seasoned game designer will tell you that whether a game succeeds or fails is largely dependent on how well it is playtested and balanced. Even the most brilliant initial game design can be completely destroyed if the implemented game is not playtested thoroughly. I do not mean just for bugs , but for gameplay ” for how the game feels to play and for how it captivates players. Playtesting is an iterative process that involves trying a type of gameplay, then modifying it, then trying it again, and repeating this loop until the game is fun. It can be very hard, then, to properly iterate through playtesting if the level editor does not facilitate the modification of the game s levels, and then easily allow the designer to try out what has been changed. The easier it is for designers to jump into the game, try something, jump back out of the game, make a content change, and then jump back in again, the more likely they are to repeat the playtesting cycle again and again until the game is as perfect as possible. If the level editor does not facilitate such testing, designers are likely to become frustrated or simply not have the time they need to sufficiently balance the game.

Editing the World

The best development tools for a game are composed of a delicate mix of off-the-shelf programs and proprietary editors. A good team will know just how much of each to use so that they are neither wasting the time of their programmers by having them develop overly sophisticated tools when a good commercial package is better suited, nor unreasonably restraining the efforts of their designers by not allowing them to refine the game s content from within a custom level editor. Though no team should be forced to develop a game without a level editor, it is equally foolhardy to force the team to do all of the game s content creation from within proprietary tools.

It is important that the level editor actually allow the designer to modify all gameplay-critical aspects of a level. This would seem to me to be an obvious prerequisite for an editor, but I have heard so many stories of teams working with 3D Studio MAX and entity editors that it bears mentioning. Often teams think they can get away with using an off-the-shelf tool such as MAX to create all of their world geometry, and then create a level editor only for importing the meshes from MAX and positioning the items, NPCs, and other game-world entities. Though this is workable given enough time and tenacity, it will not lead to as good levels as will a fully featured editor. As the designer is placing creatures in the map, he needs to be able to simultaneously change the geometry to fit the placement of that creature. If a designer must exit the editor and then run a 3D modeling application (which are seldom known for their speed), modify the geometry in that program, and then re-import the level into the proprietary editor before he can test out his modifications, he will certainly be discouraged from making too many tweaks to the geometry. As a direct result, the geometry will not look as good or play as well in the final game. Not allowing a designer to edit the level s gameplay-critical architecture in the editor itself is tantamount to tying one armbehind his back. It is my experience that designers work best with both hands free.

When I started working on Centipede 3D , the level editor we had was really more of a game entity manipulator than a proper level editor. The geometry for a given level was derived from a grayscale, square height-map , with those used in Centipede 3D all consisting of 32 x 32 pixels. Each pixel therein represented a height value on the landscape. These height-maps, which could be created in Photoshop or any other pixel-pushing tool, were a good way to create an initial version of a level s geometry. Unfortunately, in the version of the editor used at the start of the project, the height-maps could only be modified in a paint program; they could not be edited in the editor itself. This was a shame, since looking at a top-down 2D representation of a 3D level is not exactly the best way to get an idea of how the level will end up looking. As a result, the levels that were created early in the project were simple and a bit flat. It was not that the level designers were not working hard to make the levels attractive, merely that there was only so much that could be accomplished with the tools provided.

However, midway through the project, functionality was added to the tool to allow the designer to edit the height-maps while in the level editor. The height-maps could still be created in Photoshop and brought into the game, and this remained the best way to make a first pass on the level s architecture. After that first pass, however, the geometry was easily manipulated in the level editor, where the designer was able to see the level in 3D while modifying the height-map. As a result, the designers were able to tweak the geometry until it was perfect. The change in the quality of the levels was dramatic. As always, time did not allow for us to go back and redo the earlier levels. Since the levels were made in the order they appeared in the game, anyone playing Centipede 3D will be able to tell at what point the level designers were given the new and improved tool. It was not that the designers could not create levels with the previous incarnation of the editor, it was just that level editing was so much more difficult that the levels failed to look as good as the designers wanted.

There is a lot to be said for being able to create fancy level geometry in a fully featured 3D package, and even level editors with sophisticated geometry editing capabilities would benefit from the ability to import externally created architecture. The key to creating quality game art assets, whether they are 2D sprites or 3D models, is being able to import from commercial packages. I do not know that anyone was ever forced to create 2D sprite artwork for a game using only an in-house tool. Yet, it seems that many unfortunate artists have only been allowed to model characters or other objects using proprietary modeling tools. I have discussed how important it is to allow the level designers to manipulate a level s architecture in the editor. But certainly forcing game designers or artists to model every game-world element in the level editor is a big mistake. Artists should be able to create game-world objects such as trees, weapons, or trash cans in their favorite modeling package and import them into the game. Simply put, there is no way a game s programming team is going to be able to code up an art editing package with all the power, robustness, and stability of a Photoshop, 3D Studio MAX, Maya, Softimage, or any of a number of other popular off-the-shelf products. Without the many features found in these packages, artists will simply be unable to create the best quality art possible. Furthermore, most artists are already familiar with one or more of these packages, and so when they come on to the project they will be that much closer to being up to speed.

At the same time, the team will need to be able to manipulate this art using proprietary tools. Having an in-house editor with which to set up animations, nodes on a skeleton, collision data, or other information is essential to making the art function properly within the game. Teams who attempt to avoid setting up any sort of art editing software will frustrate their artists, designers, or whoever gets stuck with configuring the art and its animations to work in the game. A proprietary art manipulation tool that does exactly what the game engine needs it to do is a key ingredient in a bearable game development experience.