Scripting Languages and Object Behaviors
It seems to have become the norm for games to use a system where designers can set up and balance the enemy, weapon, and other game behaviors exactly as they need them, without involving a programmer. Many games now include scripting languages which, though relatively simple, allow for complex entity creation without requiring the game engine itself to be recompiled. These scripting languages provide many benefits to game development. Probably most important is that they encourage the creation of more unique behaviors in the game, whether these are reusable in-game entities such as NPCs or unique behaviors and events for different levels, such as NPCs carrying on a particular conversation while the player watches, ala Half-Life.
One great benefit of a properly designed scripting system is that it is completely portable to other systems. This means that when the game is ported from the PC to the Dreamcast, for instance, all of the enemy behaviors that have been scripted and debugged on the PC will be equally functional on the Dreamcast, provided the script interpreter and its associated functions are properly ported as well. In that vein, a robust scripting language is also more stable to work with than programming in C. The scripting language gives the script's author less opportunity to thoroughly crash the game, and when a script does something illegal the game can spit out a properly informative message instead of just locking up. Often the scripting languages are not as complex as actual C programming, and thereby allow designers with some programming savvy to take on the creation of unique world behaviors, thus freeing up harder-to-find programmers for more complex tasks. In most systems scripts can also be loaded on demand, which means only the scripts that a particular section of the game uses will need to resident in memory, thus freeing up more code overhead. An added bonus of a game having a scripting language is that it allows for complex user-modification of that game. A well designed and appropriately powerful scripting system will empower motivated players to make their own "mods" for the game for distribution to friends.
But scripting languages have their down side as well. First is the time involved in implementing a scripting system. If the language is to be actually useful to the game as described above, it will need to be very stable and provide its user with a lot of power, which is certainly non-trivial to implement. Debugging a problematic script can also be quite a lot of trouble, since no game developer is going to have the time to implement a symbolic debugger as nice as the one that comes with Visual Studio or CodeWarrior. Most of the time, the scripts are compiled at run-time, and as a result can be significantly slower than C/C++ code. Again, no matter what the developer does in terms of optimizing performance of the scripts, he will not be able to match the compiling power of the C++ compilers made by Watcom, Microsoft, or Metrowerks. And finally, though one of the big advantages to scripting languages is supposed to be that they can be used by non-programmers, it often turns out that, if the scripting language is actually powerful enough to create AI for an NPC, the scripting language is going to be so complex that it requires a programmer to use it effectively. And if a programmer's time is being tied up in the creation of scripts, why stop her from just doing her coding work in C?
Of course one of the great advantages of scripts is that they greatly simplify the balancing of gameplay. Instead of a programmer tweaking a number in the code and then waiting for the game to recompile, a designer can adjust a value in a script and just run the game. But what if one wants achieve this benefit of scripts without having to implement a scripting system. What if, instead, the designer were able to adjust behavior parameters in the level editor itself? This is the approach taken by Surreal Software's Riot Engine. In Surreal's level editor, designers are given access to all the settings or "behavior variables" for a given AI, weapon, or other game-world entity. The behaviors themselves are coded in C++, with the programmers leaving "hooks" to all the crucial settings that determine how the game-world object will behave: how fast it moves, what its detect radius is, what objects it turns into when it is destroyed, and so forth. This provides much of the game-balancing benefit of scripting languages by empowering the designers to endlessly tweak the game while still taking advantage of the speed of a powerful C++ compiler and debugger. This functionality makes the level editor not just a tool for modifying the game's levels, but makes it more of a gameplay editor, where the designer is able to change much of the game's content on the fly.
Surreal Software's Riot Engine Level Editor
allows the designer to tweak all sorts of
settings for different game-world entities,
here for the game Drakan.
"Scripted events" in levels are another thing that game scripting languages do well. Each level in the game can have a unique script which sets up and triggers various unique behaviors on that level. Having complex, unique behaviors has recently become a much bigger concern of game developers, especially after Valve used scripted events to such great effect in Half-Life. Instead of involving a separately compiled, text-based scripting language, level editors can include the ability to empower designers to set up complex game-events. Starcraft's Campaign Editor is an especially good example of this sort of functionality. Its "Triggers" editor allows designers to use a very familiar point and click interface to set up complex scripted events. Pop-up menus provide lists of all the commands available, and then further pop-ups show the designer all of the different parameters that can be passed to those commands. The whole system is easily comprehended by someone looking at it for the first time, with commands written in plain English. Thus, the Campaign Editor allows unique events to occur in Starcraft levels without involving the overhead of a full blown scripting language.
It's 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 loathe 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 will be used by ten, perhaps twenty people. When a programmer's friends ask her what she worked on while she was at that wacky game company, most programmers do not want to have to answer "I worked on the tools." There is just no 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 much time 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 which facilitates the designer's work. The programmer responsible for a well conceived and implemented level editor which greatly facilitates the creation of beautiful levels should feel that she 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. And 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 her efforts.
At one point I added a texturing feature to the Riot Engine Level Editor. The Riot Engine employs 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 six years ago, 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. Before I added the feature, the level designers at Surreal had needed to pick by hand the transition texture that was called for. 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, I am much more likely to keep adding nifty features to the editor.
Blizzard's Starcraft Campaign Editor
automatically does transitions between
different types of landscape textures, thereby saving the designer a lot of work.
But 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 where that editor is lacking. Indeed, what a programmer may see as a cool feature turns 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 them. "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. This programmer can then become quite familiar with the workings of the tool and can take pride in what a good application it is. Of course, if the programmer assigned to working on the tool really wishes they were 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 tool, and can finally understand what the designers have been complaining about for so many weeks. Without actually having to sit down and fully use the application they are creating, the programmer is likely to conclude that the designers are over-emphasizing the problems with the editor (known in industry parlance as "whining"). But by actually having to use the tool she is working on, a programmer is likely to easily identify what shortcomings the editor has which can be trivially 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 near-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 which will fully consume an individual developer's time, and the days of the designer/programmer often seem to be a thing of the past.
A Level Editor for All Seasons
A level editor does not actually need to be bug free. Bug free software is the stuff one buys in stores, if one is lucky. Really great in-house tools can have plenty of bugs in them. What is important is that these tools be buggy in predictable ways. The bugs should occur in patterns that the designers can learn how to predict and teach themselves to avoid. Once a designer becomes adept at the tools she will know what not to do and will be able to easily work around the trouble spots. Proprietary level editor tools are one place in software development where the old joke "Doctor, it hurts when I do this!" "Then don't do that!" really rings true.
Of course if the tools used on a project are good enough, marketing may catch on and can come up with the bright idea "Hey, we can release the tools with the game!" For this to happen, the tools really will need to be relatively bug free, or at least much more stable than they were when only in-house team members were working with them. Shipping a game with its level editor is quite common these days and is a popular decision among hard-core fans since it allows them to make "mods" for the game to circulate among their friends or the general public. The possibility of releasing the level editor to the fans should function as an incentive to encourage the programming team to create the best tools possible.
It all comes down to what should be recognized as an axiom in the gaming industry: a game can only be as good as the tools used in its creation. A well conceived level design tool can make the difference between a great game and a mediocre one. One can think of the ideal level editor as a place where the designer has total control of the game-world: of its architecture (where the player can go), of its aesthetic appearance (lighting, texturing, and sounds), and of its gameplay (NPC, item, and other entity placement, movement, and behavior). Of course the best level editor in the world is not going to make up for a sub-par engine, a fundamentally flawed game design, or a demoralized development team. But those are topics for another day.
Richard Rouse III is a designer and programmer at Surreal Software (http://www.surreal.com), where he both uses the Riot Engine Level Editor and contributes to its coding. Before coming to Surreal he was a designer/programmer on the games Centipede 3D, Damage Incorporated, and Odyssey - The Legend of Nemesis. This article is excerpted from Richard's forthcoming book about game design, currently titled Computer Game Design: Theory and Practice (ISBN# 1-55622-735-3) , to be published by year's end by Wordware Publishing, http://www.wordware.com. You can read more of his errant ramblings about game design at his web site, www.paranoidproductions.com. Your feedback to this article is encouraged at [email protected].