Re: Scripting in games.

[Chris <chris@starforge.co.uk>]

On Sun, 22 Sep 2002 22:55:30 -0500
Steve Baker <sjbaker1@airmail.net> wrote:

<snip>

I'm in work so I don't have a lot of time to type: I'll try to give more
answers later.

> * How should the game handle collision detection for scripted objects?
>   Does
>    the script make collision detection queries and do the business of
>    stopping the motion when it hits something - or should the game
>    engine deal with the consequences of a collision and just inform
>    the script what hapened?

Event queries are possibly a bad idea - you could end up with all
manner of odd timing behaviours. One method you may want to try is to
let scripted objects register handlers that are called by the engine
when specific events are detected. So say that when a scripted object
hits a wall, its "on_scene_collision()" function is called. When it is
hit by a projectile its "on_projectile_hit()" is called... 

A possible plus to the event method is that you could have "default"
events, so that the engine can provide a bunch of default behaviours,
but the script writer can override the defaults if necessary.

> * How does the scripting interface deal with telling the script the
> position
>    of the player and other creatures?

One method you could use is to have a set of query functions 

get_named_object()
get_enemy_list()

or the like and give each object in the game a unique name. you could
use this to at least partially prevent rogue scripts mucking up your
enemy data. Or maybe just expose the object list and let the script deal
with looking at it - that's a grubbier option though.
 
> * Should scripts be able to communicate with each other?

If you have named objects, you could have a

send_message(object_name, message)

function. Give each object a queue of messages and send_message() adds
messages to the end of that queue. You could then use
a get_next_message() function to pull messages off the queue, or if
you're implementing engine-triggered events for collisions you could
even allow objects to register an "on_new_message()" event handler.
Or provide a get_next_message() function that is called from within an
on_new_message() handler to go through all the new messages in the
queue...


> How do existing games deal with this stuff?   Is there a 'classic'
> game somewhere with a scripting interface that's known for having "Got
> It Right" ? If so, where do I go to find out how it works?

One place to look would be the Quake and Quake2 source code, they'll
probably give you some good ideas to start with. I'd also really
recommend that you have a look at the sources and receptrons system in
the dark engine (Thief, Thief2, System Shock 2) which is an immensely
flexible system. Unfortunately the source isn't available - you'll need
to work out how they work by using them. There is some extensive
documentation on S&Rs on Dromed Central at

http://www.thief-thecircle.com/dromed/navsubject.asp?subVar=STIMU1

S&Rs combine event handling, messaging and a load of other tricks. If
you don't have Thief or Thief2 this probably won't be much use to you
though - you really need to play around with S&Rs to see what they can
do. There is also some stuff in both Game Programming Gems 1 and 2 (not
got my copy of 3 yet...) 

Chris