Us Versus Them

Unfortunate as it may be, the development of the tools for a project often comes down to a battle between the programmers and the designers. Game programmers are often loath to work on tools for a variety of reasons. First, many of the programmers who wanted to get into gaming did so because they did not want to program databases, spreadsheets, or 3D modeling packages. They wanted to make games , and tools often seem too much like real programming. There s also a perception that getting one s code in the game is more important than getting it in the tools. If the title is a big hit, the game will be played by millions of people. The tools for a given project, however, will be used by perhaps ten or twenty people. When a programmer s friends ask him what he worked on while he was at that wacky game company, most programmers do not want to have to answer, I worked on the tools. There is a certain lack of glamour there.

Further complicating matters is the perception that a programmer s time is more valuable than a designer s. So if a designer has to spend five times as long making a level because a programmer does not have the time to make the level editor better, well, that s OK. The level still gets made, right?

As I have stated previously, game developers should not be asking themselves the question, Do the tools allow for the game s content to be created? Instead, they should ask, Do the tools allow for the game s content to be made well? If a designer is constantly fighting with the level creation tools, he is not going to be able to invest time into truly refining the level. In fact, he may be so irritated at perceived programmer laziness that he throws his hands up in disgust and does not work on the level as much as he might otherwise . A good level designer will be inspired by a good tool set to do the best work he can, because he can see direct results. The example I used before about the level design tool and the resultant quality of the levels in Centipede 3D is a good lesson for game developers. With the creation of a superior level editing tool, level quality will improve dramatically.

A tools programmer should be able to take pride in having worked on a really good tool that facilitates the designer s work. The programmer responsible for a well-conceived and well-implemented level editor that greatly facilitates the creation of beautiful levels should feel that he played a vital role in the creation of those levels. For without the features of the level editor, the designer would not have been able to create the landscapes or structures he did. The designer must always make it a point to remember the programmer who made possible the creation of such levels and be suitably appreciative of his efforts.

Blizzard s WarCraft III World Editor automatically sets up transitions between different types of landscape textures, thereby saving designers a lot of work.

At one point I added a texturing feature to the Riot Engine Level Editor. At the time, the Riot Engine employed tiling textures for its landscape, with transition textures available for when a grass texture meets a rock texture, for example. I added the functionality that allowed the editor to automatically place the proper transitions between two different texture types. Interestingly, this was a feature included in the level editor for my first published game of five years prior, Odyssey: The Legend of Nemesis . Indeed, this auto-transitioning functionality is found in many 2D terrain level editors, such as Blizzard s StarCraft Campaign Editor or WarCraft III World Editor. Before I added the feature, the level designers at Surreal had to pick by hand the transition texture that was needed. Certainly the auto-transitioning feature was not absolutely necessary for the creation of levels. All of the levels for the game Drakan had been made without the use of the auto-transitioning tool, and certainly they were very beautiful levels with transitions in all the right places. The key difference is that those transitions took a lot of designer time to set up. Once I added the auto-transitioning tool the designers were delighted , since now a large and tedious part of their jobs had been all but eliminated. One even said, Richard could take off the next month and we could keep paying him. He was appreciative of the feature I had added and was thoughtful enough to communicate his thanks to me. With praise like that, tools programmers are much more likely to keep adding nifty features to the editor.

The Best of Intentions

However, one must be careful. Sometimes when programmers are tasked with adding functionality to the editor, they may end up adding features that no one really needs. It is difficult for a programmer who, most of the time, does not make the game s levels and therefore does not spend a lot of time working with the level editor, to properly understand what that editor is lacking. Indeed, what a programmer may see as a cool feature can turn out to be functionality no designer will ever want to use. When a programmer goes to a lot of trouble to implement a feature for the editor and then the designers fail to use it, resentment tends to grow in the programmer. Then when a designer comes to the programmer requesting a more practical and necessary feature be added to the editor, the programmer is likely to ignore him, thinking, He never used the vertex-warping tool that I worked so hard on, so why should I work on this model-aligner for him? Forget it.

Anyone who has worked in the industry knows that, in a lot of ways, designers and programmers think differently. For this reason, it is very important for the designers and programmers to be in constant communication about what features the editor needs and how they can best be implemented. When developing an in-house tool set, the programmer has the tremendous advantage of having his user base down the hall. He does not have to guess what they want from the program; instead he can go ask them. Similarly, the designers have the advantage of being able to go to the editor s developer and make suggestions on how the tool should function. With a good flow of information between the parties involved, the tools cannot help but improve.

One possible technique for facilitating the creation of a good tool is to assign one programmer to be primarily responsible for the maintenance and improvement of the level editor, instead of passing editor tasks off to whoever has time. This one programmer can then become quite familiar with the workings of the tool and can take pride in what a good application it is. If one programmer does most of the editor work, the designers will know which programmer they can turn to with their suggestions for improvements to the tool. That programmer will get a better sense of what the designers like and do not like. Of course, if the programmer assigned to working on the tool really wishes he was working on lighting effects or AI, the tool is going to suffer as a result. Finding a programmer who really wants to work on the tool is important if this strategy is to succeed.

Another useful tactic is to actually have a programmer make a complete, simple level using the tool. That way, the programmer can easily spot areas for improvement in the editor, and can finally understand what the designers have been complaining about for so many weeks. If the level is of sufficient quality and fits the needs of the project, you may even want to consider shipping this programmer-created level with the game. But even if you don t, the understanding the programmer gains through using the editor as it is really used will be invaluable. Without actually having to sit down and fully use the application they are creating, the programmer is likely to conclude that the designers are overemphasizing the problems with the editor (known in industry parlance as whining ). But by actually having to use the tool he is working on, a programmer is likely to easily identify editor shortcomings that can be easily fixed through a few hours of coding. Designers frequently fail to understand the complexity of different programming tasks, and as a result make requests for nearly impossible features in the level editor, while thinking easily remedied problems are unfixable. Perhaps the best solution of all is to have a designer who is also a programmer, and thereby spends a lot of time working with the editor. This designer/programmer is directly motivated toward improving the tool he must work with every day, and is likely to do whatever he can to make it the best tool possible. Ten years ago I am sure this was not that uncommon, but for full-scale projects in development today it is fairly rare. Programming a level editor and designing levels have each become tasks that fully consume an individual developer s time, and unfortunately the days of the designer/programmer seem to be mostly a thing of the past.