Re: Scripting in games.

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

Steve Baker wrote:
> Gregor Mückl wrote:
> 
>> Steve Baker wrote:
> 
> 
>> 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 :(.
> 
> 
> That opcode is *only* generated if you turn on the PSL_TRACE shell
> variable.  It's mostly there to help me debug the interpreter - but I
> may someday wire it into a PSL debugger of some kind.
> 

Having line number information is quite useful for debugging scripts. 
However, such an instruction would slow down the script with debugging 
turned on and this may be quite counter-productive if you want to track 
down a problem that is actually related to incorrect timing inside your 
scripts (it'd be like those nasty cases where the bug just won't show up 
inside gdb...). But because the instructions you store are CISC-like and 
embedded in a bytestream it's quite hard to find a way to encode the 
line number without hitting performance during normal execution.

>> * 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 guess - I havn't spent a lot of time on the integration of the scripting
> into the application - which is why I asked the questions of this mailing
> list.
> 

Well, as I wrote a little testbed for this interpreter last night I 
discovered that with function pointers there is no need to derive a new 
class each time a new function is needed. And if I think it through to 
the end the virtual function approach would use at least a chain of 
three pointers until the target function can be called whereas the 
function pointer approach needs to access only two pointers. So the 
insecurity might pay itself off with less code (a lot of objects would 
need to be created in the other case) which might even be faster.

>> I like the ability to step the interpreter instruction by instruction. 
> 
> 
> That's the single reason why I wrote PSL rather than picking up (say)
> Python.
> 

That's why I wanted my own interpreter as well ;). It's been a result of 
our last discussion of game scripting, I think.

>> 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 ;).
> 
> 
> The idea isn't to run one instruction per frame.  (I guess you need to
> read the documentation - which describes this in detail).
> 

This was only meant to be ironic, Steve :).

> There is a special PSL reserved word 'pause' - which allows you to 
> implement
> non-preemptive scheduling by calling the 'step' function in a tight loop
> until it hits that pause instruction.
> 

Hm... could the interpreter be forced to pause state by callback 
functions as well? In other words: could the return code of 
pslProgram::step() be manipulated by callback functions? I'm too lazy to 
look at the sources and figure it out right now (I've had a hard day at 
work :(. But this would allow scripts to do a blocking wait for events, 
for example. I can think of other useful things, too.

> However, you can easily implement a scheme that runs a set number of 
> opcodes
> or for a set amount of time - or which runs important scripts faster than
> non-important ones...that's *entirely* up to the application - which was
> THE major reason for not just picking up a standard scripting language.
> 

I feel quite uncomfortable with an interpreter that you can only call 
and wait until it returns - if it returns at all (greetings to all 
infinite loops out there!). This way stable frame rates and accurate 
timing go down the drain very fast.

But with the ability to accurately schedule multiple VMs the situation 
improves vastly. Or at least you've got one appology less for jittery 
framerates ;).

>> 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.
> 
> 
> Agreed - the standard PSL implementation will contain some simple
> I/O routines (mainly to help people debug their PSL scripts by sticking
> print statements in them) - and also sin/cos/tan/atan2/sqrt, etc - perhaps
> some vector/matrix routines.  PSL is 50 to 100 times slower than C++ so
> it's desirable to take as many common operations out of PSL and into C++
> as is reasonably possible.
> 

Right. There are actually two concequences of this rule:

1. Provide as many C++ routines in your standard library as possible.
2. Don't hesitate to add new VM opcodes to simplify and shorten the 
bytecode. The shorter the compiled code is the faster it will run.

The third concequence, providing user-defined callbacks, is already there.

>> Especially since the current implementation is not specific to a 
>> certain game type (yet?). Please, please keep it like that.
> 
> 
> Definitely.
> 

Thanks.

>> 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).
> 
> 
> A generous offer - but I have to decline:
> 
>   1) I don't particularly want to separate it from the rest of PLIB because
>      I have a fanatical desire to minimise the dependancies in the games I
>      write and I'd rather depend on just PLIB (and OpenGL) rather than
>      PLIB, OpenGL *and* PSL.
> 

After looking at my game engine's hand-crafted makefiles I find that I 
don't need to care about yet another dependency ;). Already there is 
Python (to be kicked soon), SDL and OpenGL with it's own set of 
dependencies here and Ogg, Vorbis and lzo still to come when the 
corresponding code is integrated (prototyped components are already 
there). So one other dependency doesn't actually change much.

>   2) I don't really need a whole lot of help. There isn't much work left to
>      do in PSL itself.  It needs structures and some kind of JAVA-like
>      mechanism to pass structures into functions without using pointers...
>      ...then I'm done.   I'm having fun writing it - and I'm learning along
>      the way.
> 

I must admit that I would not have found a way to parse expressions. 
That has given me serious headaches and hasn't been that much fun to me.

> PSL is *really* simple - I wrote it in under two weeks of odd evenings - 
> 50 hours
> tops.
> 

But it is quite good after all. I've been able to write a little program 
that seeks prime numbers in less than 10 minutes. So it's a quite handy 
language.

> If you passionately needed to fork the code base, you could (it's released
> under LGPL) - but I really don't see the need.
> 

Me neither at the moment. But I'll probably fork an own version off just 
before I release my game engine to make compilation of this beast a bit 
easier.

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

Gregor