Re: Scripting in games.

[Gregor Mückl <GregorMueckl@gmx.de>]

Steve Baker wrote:
> 
> I don't have a lot of experience with making scripting systems for 
> games...but
> I want to learn - and I learn best by doing.
> 
> OK - so I've added a lightweight C-like scripting language to my 3D game 
> engine
> and it lets you run hundreds of tiny little interpreted C programs in 
> parallel
> without consuming too much CPU time.  (You can download it as a part of 
> my PLIB
> library suite - but you'll need to get it from CVS since it's not 
> released yet
> - the language is called 'PSL').
> 

I've fetched the code. After analyzing it for a few minutes I must say 
that I quite like it. However, there are some points I want to comment here:

* OPCODE_LINE_NUMBER is not really necessary, is it? All it does is to
update the line number information inside the VM. A presumeably better 
way to do it is to store the line number with the instructions 
themselves. At least I was seriously thinking about this approach when I 
tried to do almost exactly the same thing (unfortunately I lost all that 
work because of a disk crash; otherwise I would probably have my own 
script language by now - with a similar VM :(.

* pslExtension shouldn't take a function pointer but a regular virtual 
member function instead. This is safer and can be optimized by the 
compiler lot better.

I like the ability to step the interpreter instruction by instruction. 
This comes in quite handy for complex scripts. However, coming up with 
appropriate scheduling code for the scripts is an entirely different 
story (I'll need a lot more than 1 instruction/frame ;).

> So now (in principle) I can write behaviors for all sorts of animate and
> inanimate objects using *LOTS* of little scripts.  Woohoo!
> 
> Clearly there needs to be some set of procedures in the scripting language
> that can make things happen in the game world - and functions to query
> things from inside the game so that the script can react to events in 
> the game.
> 

This interface is entirely game specific. A simulation or strategy game 
would use a totally different interface than a flight sim or a first 
person shooter. Please don't provide more than a standard library of 
helpers inside the psl implementation. Everything else must then be 
registered to it from the outside.

> My scripting language provides ways for the host application (the game) 
> to expose
> functions written in C++ so that the scripts can call them. But what 
> functions
> are needed in order to be able to write good scripts?
> 

This depends a lot on the type of game. I would not define any interface 
at all inside psl. Especially since the current implementation is not 
specific to a certain game type (yet?). Please, please keep it like that.

Actually I'd like to see psl as an independent library. I'd love to rip 
it out of that source tree and make it a stand-alone library. It would 
be much more useful for other projects (including mine, of course ;) 
without its dependency on your util library.

I feel that it is too early to rip the code out of plib on my own, 
though. So I'd like to make the following deal: I will help you 
developing psl further if you promise me to remove the dependency on the 
util library (in other words: make it a seperate project).

Gregor

PS: Am I selfish today? ;)