Re: [GD-General] Scripting

[Thatcher U. <tu...@tu...>]

On Fri, 6 Dec 2002, Brian Hook wrote:

> If you enumerate the legitimate reasons that scripting is implemented, I
> would bet it's something like this:
>
> -  End user modifications that are safe (sandboxed VM), portable and
> free to develop
> -  Ease of extensibility for artists/designers
> -  Faster prototyping/development because the language is more dynamic
> and doesn't require rebuild
> - Rich data definition language

Good list.

I think data description (let alone "rich" data description) is reason
enough to use something like Lua (which started its life as a data
description language).  The costs are pretty low -- you need to get
your data into the engine somehow anyway, and the API is no worse than
any other data-importing API I've encountered (and better than most,
or at least more consistent and complete).  In the engine at work we
have four or five independent little ad-hoc parsers (and one nice big
fancy one) in different places.  It's just hard to prevent those
little parsers from getting written, because they're all doing crucial
work.  But if you standardize on a flexible data description language
from the get-go, coders are more likely to use the facilities at hand.

XML is probably the classic example here, although I've been exposed
to some god-awful parsers.

> The "ease of extensability" I think is overblown.  There's a common
> misconception that script languages are somehow more approachable to
> non-programmers than regular compiled languages, which I find to be
> hogwash.

I think you're taking on a couple separate issues here, 1) the
language itself, and 2) the development environment (i.e. the
mechanics of how you get your code into the running game).

> Sure, C can be pretty arcane syntactically, but I dare someone
> to tell me with a straight face that Scheme or Python or Perl are
> intrinsically easier to use than traditional compiled languages.

I can say that about Python (and Lua) with a straight face.  Although
"intrinsically easier" is pretty subjective, in the absence of user
studies.  I generally agree with your point that the "language" part
of "scripting language" is *not* the killer feature that makes it
worth doing.

IMO, in order to get designer friendliness and faster prototyping, the
key thing to focus on is the "development environment".  (And I don't
mean "IDE" per se; I mean whatever it is specifically that a designer
has to do to see her changes in the game, and all the little
mechanical details of how feedback comes out, and how you debug, etc.)

[snip]

> Of course, if your current project has 16 programmers and requires
> 1+ hour to do a full rebuild, then maybe scripting simply is
> required, period, to make development even feasible.  But then it's
> a case of scripting not being inherently useful, only that scripting
> is a band aid to another broken part of the development process.

I've never worked on a commerical game whose average edit-compile-run
turnaround was less than a minute (and usually it has been at least 2x
worse than that).  The script-whatever-run cycle has the *potential*
to be very quick, although it also tends to get bogged down by
suboptimal process, in my experience.  Like, scripting engines where
it's theoretically trivial to inject updated scripts into the running
game, but nobody exposed the functionality in a way that the designers
could use.  A simple "load(script)" command that you can trigger from
the console in the running game goes a long way.  In general, I think
using a scripting language for a console language is a handy thing.

So I think cycle-time is probably the number one thing to address in
terms of a scripting development environment, and after that, a
debugger.  Although I'm speaking in theoreticals here; I've never yet
worked on a commercial game where the scripting language had a working
graphical debugger.  But, the potential is just sitting there: all the
off-the-shelf languages that have been mentioned so far have graphical
debuggers.

> The rich data description I think is a good use of scripting, since
> you can have conditional data.  But that's typically using just a
> small subset of a script language, and I tend to think of it more as
> data definition than as scripting.  And in many cases, you can avoid
> this by simply making it more data driven (which, granted, incurs
> its own set of headaches, but is eminently doable).
>
> For example, if a certain door can only be unlocked by a red key,
> then you can either drive this with pure data:
>
> finalDoor = {
>    type = door,
>    key = redKey
> };
>
> or you can do some scripting thing, which feels "niftier", but I'm
> not sure if it's actually that much more powerful.  It has the
> potential to be far more expressive, but whether that's actually
> leveraged is often up in the air.  The ability to do something
> doesn't always translate to doing something:
>
> finalDoor inherits door
> {
>    bool canUnlock( key k )
>    {
>       if ( key == redKey )
>          return true;
>       return door::canUnlock( k );
>    }
> }

Well, you can do either of the above, or both at the same time, with a
scripting language.  (And, as I said, I think there are advantages to
using a scripting language's parser to digest your data.)

I think the "pure data" approach has a lot going for it.  One nice
(but also scary) thing about many scripting languages is that you can
jam little functions in with the data.  IME that can make some things
much clearer and simpler to set up.  For example:

finalDoor = {
  type = door,
  key = function(opener)
    if opener == evil_wizard then
      nil
    else
      redKey
    end
  end
}

So I've just made a door the Evil Wizard can't open, even if he has
the red key.  Bad example, I know... but I have used this kind of
pattern before, and it can make certain things much clearer than
putting the little functions somewhere else and referring to them by
name.

Anyway, I also struggle with the issues you raise.  I do think it's
very helpful to know about all the things that are wrong with
scripting languages before deciding to use one, and especially after
you're committed to using one.

-Thatcher