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

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

>> Yes, I'd agree with Vincent. It is actually no magic but an event  queue
simulation

True. No comments. Its widely used in many games scripting engines.

>> "no time" ... as a overly simplified implementation of "threads".

I think for 99% of cases you can make events happen in "no time". Maybe I
should have
used myself "threads" instead of  threads.

>> 1. you never worry about data safty between threads and

True again.  I am not minimizing the problems which can be raised by
multithreading.
I just happen to think thats a powerfull tool.

Ciao , Dan




----- Original Message -----
From: <paul@theV.net>
To: "Multiple recipients of list" <lua-l@tecgraf.puc-rio.br>
Sent: Friday, August 23, 2002 4:45 PM
Subject: Re: Lua For Game Scripting article (Was: Re: Lua x Python)


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