All games need the ability for designers and developers to edit the content used to make the game world. In many (if not most) games, the content editor is one or more purely external tools. There are however numerous advantages to using an in-game editor, not least of which is a potentially huge increase in designer productivity. Any poorly implemented tool will slow designers down, in-game or not, so there are a number of things to strive for and avoid when working on an in-game editor. In some cases, having both an in-game editor and an external editor may be preferable, as the two different tools may have different sets of strengths.
Perhaps the most common game content editors are the large graphics packages such as <a href=”http://usa.autodesk.com/adsk/servlet/pc/index?siteID=123112&id=13577897”Maya</a> or </a>Blender. These packages have an immense amount of functionality and flexibility which artists and level designers need in order to build today’s blockbuster games. Most of these tools also have excellent extension systems, allowing game developers to integrate export tools to their game’s internal level and model formats. Duplicating software like Maya within a game is not possible with satisfactory results.
The first step in deciding how to implement an in-game editor is to simply decide what the editor’s purpose is. Complex geometry editing and modeling are probably out of scope. Quite a few other options are available. The simplest additions to make are features like editing the properties of game objects, such as altering the AI state of an enemy or toggling particle engine tweakables on a campfire. The tool AntTweakBar has gained quite a bit of popularity for making that sort of in-game editing easy to implement.
Many game engines do not really take advantage of these capabilities, unfortunately. If they implement in-game editing at all, it is often very transient in nature. The designer can change an enemy’s properties, but those properties are not saved back to the original level file. In order to make a set of changes permanent, the designer must go back to the external tool and change values, then re-export the level and load it back into the game. This is not an optimal work flow.
There are two major hurdles to jump if a developer wants to make in-game editing work. The first problem is that most external tools do not natively work in the same level formats that the game engine does. When the designer saves a level in Maya, he is generally running it through an exporter, either as a Maya plugin or via a second external tool. In order for the game to make changes that are reflected back in the external tools, the format barrier must be breached. This means that the game must be capable of saving and loading a Maya native format, or that an import filter must be written to match whatever export filter is being used. This is not a particularly difficult task, but it is an extra step that is often skipped in content pipelines for games without in-game editors.
The second problem with writing an in-game editor is ensuring that the game can differentiate between current game state and initial game state. This in particular was the issue I ran into with my Sophomore game project that led to this article. If a level is loaded, and the enemies move around, the designer edits some of the enemy AI properties, and then the designer tells the game to save the level, the designer probably doesn’t want the enemy’s current locations to be saved into the level – he wants the enemy’s original, spawned locations to be saved. The designer wants the enemy’s starting properties to be saved as well, not the properties of the enemy’s current state.
Finding a solution to this second problem is less straight forward than solving the issue of format import/export. There are a number of considerations to make regarding the desired user interface and interaction with the engine code. Some games have a relatively natural solution presented to them already, in that they make use of scripts, procedural generation, or explicit spawn points to create enemies and other objects. Other games have things a bit tougher as enemies are placed in the level and simply activate once the level is loaded.
Perhaps the most obvious first step in adding an in-game editor UI is to create spawn points for enemies as game objects, with all the selection and property editing capabilities of actual enemy game objects. Once that is in place, the basics of in-game editing are pretty much done. Designers will be able to select spawn points, move them, delete them, create them, and edit the properties of the game objects they spawn. Combined with a quick level restart button, designers will be able to work on levels with much greater efficiency than if they had to use an external tool for such things.
There are improvements that can be made, depending on the game’s specific details. Each active enemy can contain a reference to its spawn point, making it easier to find and tweak the spawn location of a given game object. Enemies may have the ability to “reset” to the initial properties specified by their spawn point. If the game makes use of enemy templates or archetypes, large numbers of active enemies can be tweaked at the same time.
For our sophomore game project, I have found that a combination of simple spawn point game objects, a built-in tile map editor, and a reset button are all that’s needed to provide all the level editing tools necessary right inside the game itself. We are also planning to implement the ability to spawn an external text editor for script files and then allow loading them back in with a level restart, making the entire level content edit cycle as seamless as possible.</div>