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

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

Paul,

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 mention that a
scripted charachter
can break the script, go into AI controled mode, then resume script
execution (classic example would be "Npc A follows the player, opening doors
and planting mines , as a script slave. Enemy is spotted, script execution
is break, NPC A goes to AI and start eliminating enemys(this cant really be
scripted, since it requires dynamic evaluations),  then goes back to
continue its script). Now add to this the fact that maybe the NPC A has to
be able to talk to the player and has a scripted dialog, and must be able to
respond to external events .

I wonder how you do this with a single script , using a single thread. Even
for a simple

Action1 NpcA->MoveToNextPathPoint;
Action2 NpcA->FacePlayer;
Acrtion3 NpcA->PlayAnim(GREET_PLAYER);

you either have to build a queue of actions, filling it from the script then
dequeue actions,  either yield
script execution untill ActionA is ready , then resume te script execution ,
and so on. More or less, this reduces to a form of implementing a form of
script mulithreading, and script execution control.

I really dont see how you can control complex wrolds with a single script ,
using a simple thread.
But maybe Im blind or I misunderstood what you said. Please, explain me your
implementation so I can see what you mean. Or if you wrote something about
your expereinces whith controling game wrolds with your approach, I would be
happy to read it so I can understand your concepts.

Regards, Dan









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


> On Fri, Aug 23, 2002 at 01:58:58PM +0300, Dan Partelly wrote:
> >
> > It's extremly seldom in games where you control everything through a
> > single script using a single scripting "execution thread".  In fact, I
> > think that such a designed is flawed from start, and wont work for
> > anything but extremly simple scenarios.
>
> I happen to think the opposite. Although by nature of most games,
> things happen all over the places and multi-threading seems to
> be the natural choice. But really, if you can organize them into
> a single thread, just go ahead and it'll cost you much less
> trouble at debugging, especially when more than 2 people work
> on the same code base.
>
> I learnt the lesson the hard way, and I'd stick to single thread
> whenever possible. It is not about how sane single thread programming
> could be, but that human errors usually doubles with the introduction
> of a new thread, which is a sad but true fact of today's programmers
> on the market.
>
> Regards,
> .paul.
>