Re: Scripting

[Steve Baker <sjbaker1@airmail.net>]

Gregor Mueckl wrote:

> 1. Python is slow. I didn't do performance tests on Python before
> deciding to make this my scripting language of choice. I expected script
> code to be *way* slower than compiled code (esp. considering the
> complexity of the Python interpreter). But I had no idea how slow Python
> actually is.

Python is slow because it's a very full-featured language.

Most game's scripting requirements don't need anything like such a
sophisticated language.  Also (as I explained before), I think you
actually need to use a 'byte-code' approach so that you can interpret
a little out of each of dozens of programs each frame.

I've written a real simple parser to translate a C subset into a very
simple bytecode - it's not especially fast - but it seems good enough
for my needs.

> 2. I've planned to have much more Python script code (i.e. a much lower
> level interface to the engine) than realistically possible, given that
> your figures are not too far off from what I use Python for, Steve.
> Currently I start to think about making compiled plugins, which in turn
> could act as stubs to script interpreters. So the core engine can become
> extraordinarily generic while not suffering too much speed penalty by
> loading additional compiled code instead of slower scripts for those
> parts that are too slow to remain interpreted.

Yes.  If you allow '.so' plugins, they can either be pure C/C++ programs
or they can be stubs that call an interpreter to interpret Python or
whatever you need.
 
> Btw: Could it be that hard to write a JIT for a interpreted language
> when the script is already compiled into some bytecode (with preferably
> very few instructions)? It wouldn't have to really optimise things, but
> could avoid at least some of the overhead a bytecode interpreter needs.
> So what thit comes down to is to generate asm code junks for each of the
> instructions, which are then patched and concatenated together. I just
> don't understand why this could be so hard to do.

The main problem (as far as I'm concerned) is that you kill any hope of
portability if you generate machine-code.  That's why I use a simple
byte-code.  It's slower - but not unacceptably so for the relatively
simple things I expect interpreted code to do in my games.

I don't anticipate interpreting thousands of lines of code per
frame for each script - I rather expect to execute just a few
dozen bytecodes for each one.

But it all depends on what you expect your scripts to be used for.

I just want behaviours such as:

 * If you hit the "use" command while pointing at the light
   switch, the light turns on or off.

 * If you hit the "use" command while pointing at a door, the
   door will only open if you own the appropriate key.

...that kind of thing.  Hence, most scripts would be less than a
dozen lines of code - but there would hundreds or perhaps thousands
of them in a typical game.

There is also the idea of using scripts for AI - but in that case,
I envision lots of high level functionality being placed into C/C++
code with the scripts just linking them together in some way that's
different for each critter in the game.  These scripts would also
be just a few dozen lines long - with only a handful of those lines
being executed every frame of the game.

----------------------------- 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