[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scripting



Dmitry Samoyloff wrote:

> I want to use some scripting language (like TCL or Perl) in my
> 3D action game for a game logic and AI but I don't know yet how
> to do that. I read some articles on this topic but there was no
> deep technical description. Particularly I would like to know
> how to:
> 
> 1) call scripts from my C++ game engine
> 
> 2) call the engine's functions from the scripts
> 
> Any links and/or advices would be very appreciated!

It depends what exactly you need.  I've used Python scripting inside
C++ programs - it's very easy to do.  You link your game to the Python
engine (a library), call an initialisation function - then you can pass
the source code for the script into the Python interpreter and have it
interpret it with a second call.  You can also pass a table of C functions
that will be accessible from within Python scripts just as if they were
native Python functions.  On the C-side, you have to call special functions
in the interpreter to read the parameters to your function and to return
results back into Python.

I don't know about TCL or Perl - but I imagine they are similarly
organised.

That's OK - and very easy - but it may not be what you want.

If (for example) you want a script for a critter in your game, you'd
probably want to write things (in scripting language) like:

   while ( true )
   {
     walk_forwards ( 10 seconds )
     if ( player within 10 meters )
       turn_right ( 60 degrees )
     else
       turn_left ( 60 degrees )
   }

...then have 50 copies of this script running for your 50 monsters.

You can't do that with a simple Python script because the script has
to run to completion before you get control back again and you really
want all fifty scripts to run only far enough so your critter knows
what to do for the next 1/60th second.

What I think most games are doing is to convert their scripts into
a simple byte-code - simple enough to where you can write your own
interpreter.  Then you go and interpret a few instructions out of
each script every frame.

The alternative is to require each script to process exactly one
frame of decision-making and then return.  That's a fairly
unnatural way of working - you have to think in terms of state-machines.

If you expect non-experienced programmers to write these scripts,
that's not the way to go.

There are other ways (running each script in a separate thread) - but
this is what most pro-games are doing.

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