Game Design: Theory and Practice (2nd Edition) (Wordware Game Developers Library)
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 events for a specific level such as NPCs carrying on a particular conversation while the player watches in 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 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 be 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 .
Scripting languages have their downside 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 byWatcom, 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, it 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 him from just doing his coding work in C?
Of course, one of the main 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 to achieve this benefit of scripts without having to implement a scripting system? What if, instead, the designers 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, such as how fast it moves, what its detect radius is, what it does 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 turns it into more of a gameplay editor, where the designer is able to change much of the game s content on the fly. Of course, you don t always need a fancy editor to pull off easily tweakable variables; many games have allowed designers to modify gameplay values via text files that can be edited in any text editor and that are then read in by the game at run time. Of course maintaining a number of text files can be less user friendly than an editor specifically designed for modifying this type of data. But at the same time, if you don t have enough time to invest in your tools, editing text files may be preferable to data that is only modifiable in an especially clunky or broken editor.
Scripted events in levels are another thing that game scripting languages do well. Each level in the game can have a unique script that sets up and triggers various unique behaviors on that level. Having complex, unique behaviors has recently become a much bigger concern of game developers. An early and influential example was Valve s excellent use of scripted events integrated into the more dynamic gameplay proper in Half-Life. Of course, there is a key difference between scripted events and the scripting language one uses to set them up. Half-Life had great scripted events, but apparently a difficult-to-use method for setting them up. Creating a solid and simple scripting system is the best way to ensure that the designers will make use of it. Instead of involving a separately compiled, text-based scripting language, level editors can include the ability to empower designers to easily set up complex game events. Surreal Software s STOMP editor, used in the Drakan games as well as The Suffering , though not the most bug-free piece of software ever written, allows designers and animators to set up complex scripted sequences relatively easily in the editor and view them in real-time 3D as they are built. The sequences, which can be used both as cut-scenes and in-game scripted events, can be easily edited in real-time using an interface reminiscent of Adobe Premiere. StarCraft s Campaign Editor is an especially good example of a more gameplay-oriented scripting system with a well-conceived and user-friendly interface. 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 comprehensible to 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.