Re: Scripting in games.

[Steve Baker <sjbaker1@airmail.net>]

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.

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

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

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

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.

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.

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

But I still need to write my 3D game - and I don't have a firm idea of
the 'level' of interface to put into the application.

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

Agreed - not *inside* PSL - but in my game's engine.

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

Definitely.

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

The PLIB package is a *BUNDLE* of libraries.  You install the entire bundle
but you'll find that PSL is an independent library in it's own right.

     -lplibpsl -lplibul

...is all you need (you need the 'util' library because it provides some basic
string handling, error messages, etc - it's a *TINY* library and if you've
installed PSL then you've also installed UL).

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

   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.

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

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

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