Jumping into the Game
For games where the player is 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 the player will see in the game, it can be quite useful to allow the designer to actually maneuver in this view as she would in the actual game. With this sort of addition, the designer is able to test whether the player will be able to make a certain jump, how it will feel to navigate a particular "S" curve, and whether or not the player's character moves smoothly up a set of stairs. In addition to this "gameplay" mode, the level editor should still allow the designer to navigate the world in a "flight" mode, where she is not constrained by collisions or physics variables as the player will when he plays 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 the player 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. 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.
Bungie's Forge level editor for the Marathon Engine included a "Visual Mode" where the designer could actually maneuver through her level exactly as a player would in the game.
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 the player begins the level. For instance, an aggressive Troll might run toward the player 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 play-testing, 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 allowing him to 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 re-test the playability of his level. If the designer has to wait a minute or longer to play-test, he will not be able to try as many different changes to the level before he runs out of time. 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 a large part of whether a game succeeds or fails is dependent on how well it is play-tested and balanced. Even the most brilliant initial game design can be completely destroyed if the implemented game is not play-tested thoroughly. And I do not mean just for bugs, but for gameplay, for how the game feels to play, for how it captivates the player. Play-testing is an iterative process which 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 play-testing 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 the designer to jump into the game, the more likely she is to repeat the play-testing cycle again and again until the game is as perfect as possible. And if the level editor does not facilitate such testing, the designer is likely to become frustrated or simply not have the time she needs 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 to use of each 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 the 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. This cannot lead to good levels. 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 she can test out her modifications, she will certainly be discouraged from making too many "tweaks" to the geometry. As a direct result, the geometry will not look as good in the final game, if it is playable at all. Not allowing a designer to edit the level's gameplay critical architecture in the editor itself is tantamount to tying one arm behind her back. And 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 pixels square. Each pixel therein represented a height value on the landscape. These height-maps could be created in Photoshop or any other pixel-pushing tool, which was a good way to create an initial version of a level's geometry. But, unfortunately, at the start of the project that was the only place the height-maps could be modified; 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 what the level will end up looking like. As a result, the levels that were created early in he 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, the 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. But after that first pass 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. And 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 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, after which they can 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 is a key ingredient in a bearable game development experience.