RE: LUA and AI

[Christophe Gimenez <chris@...>]

Thanks alot for your answers !!

-----Message d'origine-----
De:	Ashley Fryer [SMTP:lua@bmarket.com]
Date:	lundi 27 mars 2000 23:45
A:	Multiple recipients of list
Objet:	RE: LUA and AI


It looks like you are planning to use an event-driven approach, which is
good.

--> Yes and here is THE rule : "never handle immediatly a message that have 
been fired by a response to a message"
I will use a "one turn" handling event method. If a message fire another 
event this message will be put in the queue of the pending events.

Some additional event-hooks you might use:

Time-based callbacks:  on_Time(who)
This allows you to write loops.  Each iteration of the loop is another
callback.  This keeps the other scripts from hanging while the loop is 
going
on.

--> Can you explain further please ? What do you mean by "Each iteration of 
the loop is another
callback."
I thought that each script function (on_xxx) would never contain any loop 
to avoid blocking the game. As I don't want to use any kind of 
multithreading (too hard for me).
Please explain, I think I'm missing something !!

Pathfinding callbacks: on_GoalSuccess(who), on_GoalFail(who)
This calls the object back when the path-finding engine stops moving it.

Animation callbacks: on_AnimationFinished(who)
This calls the object when its one-time animation is finished.  This is
important if you want to string a series of animated behaviors together.

--> Okay... I thought it was useless but that could be a good idea

Input callbacks: on_KeyDown, on_MouseMove, etc.
This lets objects track user input.  If you have NPCs which can have dialog
with the user, you'll need some way for the NPC to get input.

--> Honnestly I would prefer to avoid handling direcly the input of the 
user... (not yet defined how the dialog will be handled)

About implementing callbacks... work out a way for each callback to carry
extra data from the object.  For example, suppose you would normally
register a pathing callback with:

    WalkTo( who, goal_x, goal_y )

Allow the caller to attach optional extra data to the callback with:

    WalkTo( who, goal_x, goal_y, EXTRA_DATA )

Then when the callback occurs:

    on_GoalSuccess( who, EXTRA_DATA )

The object's data is passed back.  There are millions of situations where
this comes in handy, and it can simplify your code.

--> Yes good idea too !

For the rest of your NPC programming, take a look at finite state machines.
The behavior of your NPCs can be modelled as FSMs, where each state
transition is triggered by one of the on_Events.  Lua's tables and
function-objects make it a good language for implementing this.

--> I've tried to find information about FSM but never found a document 
that was really easy to understand...

Regards,
ashley