Re: Scripting

[Steve Baker <sjbaker1@airmail.net>]

Chris wrote:
 
> Jorrit Tyberghein wrote:

> > Also doing the compiler is not very fast.

g++ on my 750Mhz PC compiles at about 1000 lines per second.
I think that's plenty fast.
 
> There are trade-offs everywhere. The four big problems with scripting via
> linked libraries are (IMO):
> 
> - if you change the code, you need to type
> 
>    make nameoflib
> 
>    and wait the handful of seconds it takes to recompile the library, then
>    you need to bring up the console in the game and tell it
> 
>    cs_reload nameoflib   (or whatever)
> 
>    Whereas, if you're using an interpreted scripting engine then you edit the
>    code and tell the game to reload it. However, you pay for not compiling
>    the code as it now has an intepretation overhead.

Well, since you're only going to need this while developing, it's easy to
bind a GUI element or a key on the keyboard to run:

    dlclose ( the_library ) ;
    system ( "make the_library.so" ) ;
    the_library = dlopen ( "the_library.so" ) ;
    ...lots of dlsym calls...

...then you can recompile "the_library" and have it reloaded into the
game with a single keystroke.  The time taken by the compiler to chew
through something of the limited complexity of a typical AI or behaviour
should be pretty minimal on any machine that a developer would be likely
to have.

So I don't think it's too inconvenient to do that - but I'd still recommend
using a byte-coded script simply because of the ease of doing lightweight
threading.

> - debugging can be a pain unless you have a rigid set of rules about
>    checking pre and post conditions, a custom version of assert that
>    prints out file and line numbers, function names, descriptions and
>    a stack trace - I have code to do this if anyone is interested -
>    a well documented interface to the engine and a set of functions for
>    handling things like allocating memory, accessing files and so on.
>    Unlike interpreted scripting where there is a clear division between
>    problems in script and bugs in the engine (assuming a correct
>    interpreter..) using libraries means everything is one big piece of
>    code and picking out which bit is going wrong can be trickier...

Yes...but it depends a lot on who you think will be writing the scripts.

I don't make programming errors  ;-)

> - It is harder for non-coders to pick up. Although if you do it right, it
>    isn't as bad as some people would claim - with the use of example or
>    "fill in the blanks" code, macros to hide more complicated operations
>    and by avoiding the more complex programming concepts it is no harder to
>    program your stuff in C++ than it is in python (it is certainly easier,
>    or at least more understandable than doing them in perl!!)

Yes.
 
> - interpreters can check access, restrict the code to a sandbox and do
>    array bounds checking and so on. When you're using libraries you don't
>    get any of this - whether this is a problem or not depends on the
>    situation. The scope for malicious tinkering is greater in libs than in
>    interpreted scripts, but how much of a problem that is is up to you...

If your goal is to have end-users writing (and distributing) scripts then
it's not so much defense against malicious tinkering as it is being able
to attribute bugs to something they wrote rather than to the core of the
game code.

If someone says that the game isn't working and the symptom is:

   ERROR: Bytecode interpreter says the script is broken.

...then you can punt the problem back to whoever wrote the script. However,
if scripting is in C/C++ then it's very hard to distinguish an end-user-induced
error from a genuine error in the game engine itself.
 
> *To me* these four significant problems are outweighed by the increased
> speed (and hence scope for greater complexity) and flexability that libs
> offer. To someone else, who needs the increased security of a script
> sandbox, doesn't mind about the interpretation overhead or needs 100%
> guaranteed portability, these four points may be too much.

On the idea of transmitting behaviours over the net during game play, I'd
have to say that it would be a horrible mistake to transmit C/C++ programs
and compile them in the target machine.  That's the kind of dumb thing that
Microsoft would think of.  Just think of the possibilities for Virus writers!

It would be highly irresponsible to implement a system like that.

Even sending scripts during the game is dangerous - unless your scripting
engine is really meticulous about sandboxing the interpreted code.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net