Re: Scripting in games.

[Steve Baker <sjbaker1@airmail.net>]

J. Perkins wrote:
> I have a bit of experience here, so I'll take a crack at it...

Thanks!

>> * I could provide (for example) a function to position an object that  'belongs'
>>   to the script at a specified X,Y,Z,Heading,Pitch,Roll - but should I instead
>>   make the interface be Velocity+Direction and let the game do the  integration
>>   down to positions - or perhaps the interface should just be a place to head
>>   towards and a choice of several 'modes' of getting there?

> You'll probably all three approaches. A script might want to add a
> new static object to the world (1), or maybe apply forces to all
> dynamic objects to push them away from an explosion (2) or run a
> pathfinding algo to get from a to b (3). Pathfinding is generally
> too cpu-intensive to be coded in a script.

Hmm - OK.

>> * How should the game handle collision detection for scripted objects?   
> 
> Collision detection should happen in your C code (too slow for
> scripts, and script writers don't want to be bothered).

But if we give the script the power to set the absolute positions of
things (so they integrate velocities themselves, etc) - then the application
won't have good data for doing collision detection.

It's this tangling of levels that confuses me.   Seems like it would
be hard to maintain a clean system if I allowed access at all of these
levels at once.

> When a
> collision is detected call a hit() function or similar on the
> scripted object and pass it the object that it hit. The script
> can then determine what to do about the contact.

OK.

>> * How does the scripting interface deal with telling the script the 
>> position
>>   of the player and other creatures?
> 
> I have a FindEntity() that can locate another object by name.
> The script can store a reference to the entity in a variable, and
> then call GetPosition() etc. as needed. That is, the scripted
> object should ask for what it needs.

Yep. That's simple enough.

>> * Should scripts be able to communicate with each other?
>
> If you allow this, it should definitely be through some sort of
> indirection like messaging or an event system. That way a script
> can safely ignore events that it doesn't recognize. For game objects
> it's not too bad, because you can standardize the interface to
> a "thing", but for the AI logic it does get kind of fuzzy. The
> best bet is to keep object boundaries clear.

It seems like a generalized message passing system might be a good
idea - but with messages that the script isn't interested in being
cleanly and automatically ignorable.

>> 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" ?
> 
> It has been my experience that the *best* way to this stuff is via
> a plugin/component system. No matter how much stuff you give the
> scripters, there will always be something you didn't think of.

Wasn't that the idea of doing scripts in the first place?   The
scripts *are* the plugins.

Thanks for the hints.

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