Re: Lua For Game Scripting article (Was: Re: Lua x Python)

["Dan Partelly" <dan_partelly@...>]

The whole scripting story is also heavily dependant by the game engine
itself. Most of the games engine uses a single execution thread, and in this
scenario , even using multithreading support as Lua will implement in 5.0
it's close enough to what you say, since most of disptaching decisions
(mainly yield exec, and resume) on a script "thread" will have to
be took depending by Npc or whatever else game object state, and still you
will have to process events to take "script thread" dispatch decisions. You
wont have any real multithreading. You have chunks of script code executing
on every "game tick", sequencially.

The situation, however, can change if the game engine itself was initially
designed to be multithreaded.

The way I see this, it;s very close to using fibers vs threads (both those
objects are in fact "threads") on OSs which supports them.

Dan

----- Original Message -----
From: "Enrico Colombini" <erix@erix.it>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Friday, August 23, 2002 6:25 PM
Subject: RE: Lua For Game Scripting article (Was: Re: Lua x Python)


> >By making the script event driven. No "wait until this happens",
> >just a function called whenever it happens.
>
> Or [which may be considered to be the same from another point of view] by
> using state machines, where every NPC is a state machine that does just a
> 'small step' at every call from the main loop. Also, to make things
> simpler, actual action could be done only from the main loop.
> It is a bit more complex than having separate threads, but it usually is
> more robust and easier to debug (things always happen in a known order).
At
> least that's my experience with industrial control applications.
>
>   Enrico
>
>