Designing Design Tools

Contents

Visualizing the Level Jumping into the Game Scripting Languages and Object Behviours

"Man is a tool-using animal...  Without tools he is nothing, with tools he is all." - Thomas Carlyle

An integral part of developing a good game is creating compelling content for that game.  In order to create superior content, the design team will need to be equipped with well-designed, robust game creation tools.  Therefore, by the transitive property, designing a good game is about designing good game creation tools. 

Surprisingly, many development teams fail to invest enough programming time in making their tools as good as possible.  Usually teams have no idea what is standard in other tools used in the industry.  Frequently not enough time is invested in pre-planning and thoroughly designing how the level editor will work.  As a result of all of these factors it is often many months before the level design tools are reasonable to use.  Frequently a programmer is stuck with implementing or improving the level editor as "extra" work on an already-full schedule, and is forced to use the trusty "code like hell" method of implementation to get it done in time.  Often key time-saving features are not added until midway through a project, by which time the game's designers are already hopelessly behind in their own work. 

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 which allow different designers to turn on and off the features they prefer, when they need to use them.  And 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 the obvious ones, the bare minimum that an editor should do to be useful.  But 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 the player will see when they play the game.  The world the designer is crafting should be seen in this player's view window using the exact 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, where the player 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 the player 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 the view in the editor is only available using 3D hardware accelerated rendering, while the game itself must run in a software mode in addition to hardware.  This will create frustration for the designer, since he will not be able to easily tell how the level will appear in software.  Sure the level looks great with acceleration, but aliasing in the level's textures may be horrendous without the benefits of tri-linear filtering.  Certainly having a hardware accelerated view in the editor makes sense since it will run much faster than a software view and will thereby allow the designer to work faster.  But for games that need to run with and without 3D cards, the editor should be able to easily switch between an accelerated and unaccelerated view, so the designer can quickly and easily make sure the level looks good regardless of how it is rendered. 

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 player with the popular "tri-view" set-up, 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. 

Valve's Worldcraft editor for Quake engine games includes a "tri-view" in addition to a player's view.

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 directly to it.  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 her 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. 

I Want to See...  Beyond

I have argued that it is important for a game's level editor to allow the designer to see the level exactly as she will see it in the final game.  But the player's view window does not always need to represent exactly what the player 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 the 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 being able to see exactly where these paths lead in the world the player will be navigating is important 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 need be no guesswork. 

When working on Centipede 3D, a programmer was adding code that would prevent the player from traveling up slopes that were too steep.  In order to debug this new slope-restriction code, he added functionality to the level editor which allowed it to toggle on and off lines that separated the different triangles which made up the landscape.  These lines would change color depending on if a given edge could be crossed by the player or not.  The triangles themselves were marked with a red-X if they were too steep for the player 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 the player 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 which 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 adding of the wire-frame view and the slope-restriction markers lead 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.      

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

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 player can easily observe how the bounding information will impact the ability of the player and NPCs to navigate the game-world.  Marking off where the player 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 to 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, 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 which can also display game behavior data, the designer is able to work both on a level's aesthetic qualities just as well as its gameplay attributes. 

________________________________________________________

Jumping into the Game