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

[paul@...]

On Fri, Aug 23, 2002 at 01:48:26PM +0100, Vincent Penquerc'h wrote:
> > given 20 NPC charachetrs in a game map, each acting as a 
> > "script slave"
> > please tell me how
> > do you see them drivern by a single script thread ? Not to 
> 
> By making the script event driven. No "wait until this happens",
> just a function called whenever it happens. While I do agree that
> it complicates the code substantially, it is still well adapted
> to the existing versions of Lua. And, more importantly, it is
> easily extendable: just replace some of the event handlers with
> other ones, and you have a slightly different behavior, all from
> the same base script.
> A specific type of event is the "finishing" of a scheduled action
> (which can be anything from a basic one (face this direction) to
> a complex one (kill this NPC, finding a path and following him if
> necessary)), which can be failed or succeeded.

Yes, I'd agree with Vincent. It is actually no magic but an event
queue simulation. If you can make every event executes in "no time",
(which means, they don't sleep or do extensive I/O), you are 
guarranteed with a fine simulation model. And yes, it can be
regarded as a overly simplified implementation of "threads".

In fact, the good old popular MudOS (which was used to implement a 
lot of multi-user games) is a single thread, and yet some MUD is
able to handle over 1000 concurrent users, not to mention that
about 70% of them are some automated robots keep flooding commands
to the server for immediate execution.

I'm not dismissing multi-threading pactice in general, and 
sometimes multi-threading is obviously beneficial and necessary,
e.g., when you can not avoid I/O delays, or when you are doing
tasks which are completely unrelated to one another.

I'm just saying single thread is able to handle most simulations 
in game very well, and with some very "real world" advantanges:

    1. you never worry about data safty between threads and

    2. you never run into race condition/dead lock under wierd
       situations.

And yes, a flawless system needs not to worry about them, but,
to err is just human nature ;-)

To quote you with our own experience, in our previous MMOG game, 
we 4 engineers spent months just to re-create a very wierd bug 
that rarely but sometimes happened to our battle simutation, and
finally realized it was caused by a race condition, which was
then fixed within an hour. We may be very stupid to have the bug
in the first place (which is arguable), but one thing for sure
is, that was a really painful debugging exercise.

Regards,
.paul.