Re: Scripting (Was First step or something)

[Al Riddoch <ajr@ecs.soton.ac.uk>]

On Sun, Jan 13, 2002 at 02:42:39PM +0000, Chris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> #Sunday 13 January 2002 14:19# Message from Adam D. Moss:
> 
> > 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.
> 
> The counter-argument to this is that, unless you're using a VERY (as in 
> practically english) simple scripting language, your content creators are 
> going to have to learn at least basic programming, and basic programming is 
> just about the same regardless of language. They're going to need to learn 
> ifs, elses, conditions, possible whiles, arrays...
> 

I don't agree that the level of skill required for basic programming is
the same at all. While the syntax of control structures is pretty similar
in most modern languages, handling data is far easier in a high level
scripting language than in C or C++. My experience has been that beginners
can pick up python pretty quickly, especially when given template code.
With an embedded interpreter, fatal runtime errors due to programming
bugs simply result in an error code being returned to the compiled
application, and the program can proceed. Compiled code written by
beginners is often full of bugs, usually caused by poor understanding,
many of which can result in a segmentation fault, which is dificult to
handle at best.

Unloading dynamic modules can also present a problem. Before a module can
be unloaded and replaced with a new version, you need to ensure that
none of the applications data objects refer to data or code in the module.
In a large complex game where game entities are using module code
for AI, this can be very difficult to achieve.

Over the last year I have witnessed a large game project that used a
dynamic module system reach the stage where it had to be abandoned because
the problems caused by the module handling code far outweighed the
advantages. The application had become very difficult to build and install,
almost impossible to debug, and hard to port. The replacement project
uses a single compiled executable with embedded scripting, and is so
far looking good, though it has yet to reach the level of functionality
of the application it replaces. It is easier to build, stable, and has
been successfully cross-compiled for Windows.

The nature of our project does not require the kind of performance required
by a twitch-response FPS, so we can afford the performance compromise that
scripting brings. I can see that there are entire classes of game where
this is not the case, but I do believe that the problems involved in
using dynamic modules mean that they do not bring the same level
of flexibility brought by embedded scripting.

Al Riddoch