|
|
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
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.
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.
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 rr3@paranoidproductions.com. ________________________________________________________ |
|
|
Features
