Re: Scripting (Was First step or something)

["Adam D. Moss" <adam@gimp.org>]

Steve Baker wrote:
> The good thing about using scripting for AI is that you can edit the scripts
> while the game is running.  So if you are trying to make some critter do some
> particular thing, you can keep trying it out without having to reload the
> game (and possibly fight your way back to where this AI is used).

There are a couple of scripting considerations which I have
not seen discussed in this thread yet.

The first is a technical one -- it seems, to me, that a significant
advantage of a byte-compiled script over a .so is that you have
excellent control of how you manage the memory that constitutes
the script itself.  That is, you might typically allocate it from
the heap instead of the code being mapped into a virtual address-space
and demand-paged, so you know pretty much exactly how much memory the
code itself is taking and you can thus manage an LRU cache of
compiled scripts within very precise memory constraints.

That's a moderately academic issue under Linux where memory is
generally very plentiful and rather well-managed by the system
itself, but could be a significant issue when also targetting
less-well-endowed platforms.  Your actual script-loading code
also turns out to be a lot more portable than a dlopen() if
your script is just a file that you can read().

The second issue is one of content development versus engine
development.  Basically, regardless of how it's technically
linked to the game code it's an enormous time-sink for an engine
developer to have to write C logic for actual game content (game-
specific triggers, puzzles, environmental manipulation, basic AI).
If you can empower the level designers, artists, writers to enable
the use of their content within the code-base themselves instead of
having to go through a techie then... great.  The content developers
might know how to work wonders with their modellers, paint-programs
etc. and where to drop the resulting files into the development
tree, but would usually be quite lost in making that content walk-
and-talk in the correct context of the story if it involves writing
C (or even Python).  If they have a language that's syntactically
simple and only just powerful enough to achieve 95% of the
relatively simple things that they'd generally need to do then they
get to enable and tweak relevant parts of the game-specific logic
themselves and instant gratification of seeing their content
in-context -- and the engine programmers get bothered less,
and can just go in to tweak and improve the content-logic as
necessary.

--Adam
-- 
Adam D. Moss    . ,,^^    adam@gimp.org    http://www.foxbox.org/   co:3

"all cake everywhere has died"