[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: LUA and AI
- From: Christophe Gimenez <chris@...>
- Date: Tue, 28 Mar 2000 11:32:40 +0200
Thanks alot for your answers !!
De: Ashley Fryer [SMTP:email@example.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
--> 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
--> Can you explain further please ? What do you mean by "Each iteration of
the loop is another
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...