Lua x Python

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua x Python

Andre Carregal
Hi there,

Gamasutra has an article by Bruce Dawson where he explains why he choosed
Python over Lua:

http://www.gamasutra.com/features/20020821/dawson_01.htm

The rationale was:

"Lua is smaller and probably easier to embed in an application, and has some
nice language constructs. However, at the time we were choosing a language
the documentation was a bit sketchy. This is probably because Lua is a newer
language than Python.

Python has more extension modules than Lua, more books written about it, and
stackless Python [Tismer01], which was a promising way of creating
micro-threads for object AI. We ended up not using the stackless version of
Python, but we did start using Python for writing automated build scripts
and this gave us momentum. We knew the syntax, we liked it, and so we chose
Python.

Both languages have been improved since we made our decision - Lua has
become stackless and Python has acquired generators, which allow some
similar functionality. Either language is a safe choice."

What if someone using Lua in game development wrote a similar article for
Gamasutra? Or if the Lua team submitted some Lua reference material to
Gamasutra? The site is very popular in the game development community.

Andre Carregal


pau
Reply | Threaded
Open this post in threaded view
|

Re: Lua x Python

pau
I guess Bruce Dawson is right in pointing out the reference
counting v.s. garbage collecting issue with Python. Lua's
GC still needs quite a lot of work before large chunk of Lua
code can be safely embeded into games without worry.

I've recently replaced Lua 4.0's garbage collector with Hans-J. 
Boehm's conservative C garbage collector. It sort of works,
but the result isn't good. Boehm's C collector slows down
the speed of Lua quite significantly (by 28% using the 
lua/test/life.lua as a test). And the substitution in my own
game resulted in nonstop growing memory usage when incremental 
GC is turned on for Boehm's C collector.

In my case, I've got 80k lines of Lua code in my game (50k
lines are data though), I'd call the result tolerable, but
definitely not satisfying, because I cannot achieve constant
frame rate.

I guess before Lua gets a generational collector and meets the
requirement of soft realtime, it isn't suitable for large
scale scripting in games.

Besides GC issues, I don't see any real advantage in choosing
Python over Lua. Lua does an exellent job at being embeded.

Regards,
liuhai

On Thu, Aug 22, 2002 at 10:52:17AM -0300, Andre Carregal wrote:
> Hi there,
> 
> Gamasutra has an article by Bruce Dawson where he explains why he choosed
> Python over Lua:
> 
> http://www.gamasutra.com/features/20020821/dawson_01.htm
> 
> The rationale was:
> 
> "Lua is smaller and probably easier to embed in an application, and has some
> nice language constructs. However, at the time we were choosing a language
> the documentation was a bit sketchy. This is probably because Lua is a newer
> language than Python.
> 
> Python has more extension modules than Lua, more books written about it, and
> stackless Python [Tismer01], which was a promising way of creating
> micro-threads for object AI. We ended up not using the stackless version of
> Python, but we did start using Python for writing automated build scripts
> and this gave us momentum. We knew the syntax, we liked it, and so we chose
> Python.
> 
> Both languages have been improved since we made our decision - Lua has
> become stackless and Python has acquired generators, which allow some
> similar functionality. Either language is a safe choice."
> 
> What if someone using Lua in game development wrote a similar article for
> Gamasutra? Or if the Lua team submitted some Lua reference material to
> Gamasutra? The site is very popular in the game development community.
> 
> Andre Carregal
> 

pau
Reply | Threaded
Open this post in threaded view
|

Re: Lua x Python

pau
In reply to this post by Andre Carregal
On Thu, Aug 22, 2002 at 11:38:33AM -0300, Luiz Henrique de Figueiredo wrote:
> 
> We intend to experiment with generational GC soon. Perhaps it will
> make it into 5.0 final. What are the "requirements of soft
> realtime"?

That is great news! 

Realtime means the execution is in a timely and predictable manner,
and soft realtime means occasional miss is tolerable but unwanted.
For example, if I have only 12 ms to the next frame, and if a call to
collectgarbage(12) will generally return within 12ms, then it is
already good enough, thus so-called soft realtime. 

It is hard to control the exact behavior of a garbage collector in
such a manner, but generational GC is definitely better than
mark-sweep.

Regards,
.paul.

Reply | Threaded
Open this post in threaded view
|

RE: Lua x Python

Joshua Jensen
> > We intend to experiment with generational GC soon. Perhaps it will 
> > make it into 5.0 final. What are the "requirements of soft 
> realtime"?
> 
> Realtime means the execution is in a timely and predictable 
> manner, and soft realtime means occasional miss is tolerable 
> but unwanted. For example, if I have only 12 ms to the next 
> frame, and if a call to
> collectgarbage(12) will generally return within 12ms, then it 
> is already good enough, thus so-called soft realtime. 

Wow... you must not be running at high frame rates.  12 ms is 75% of the
frame time of a 60 fps game.  I'd love if all rendering, AI, GUI
updates, blah, blah, could be done in 4 ms.

In fact, I'd say it is unacceptable for a garbage collection during the
real-time loop to exceed a millisecond.  This shouldn't be too much of a
problem, especially if the garbage collection wasn't "perfect."  I'd
even be willing, for these "real-time" environments, to specify the
objects Lua should look at doing a "full" collection on.

-Josh


Reply | Threaded
Open this post in threaded view
|

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

Christopher S. Charabaruk
In reply to this post by Andre Carregal
Andre Carregal wrote:
What if someone using Lua in game development wrote a similar article for
Gamasutra? Or if the Lua team submitted some Lua reference material to
Gamasutra? The site is very popular in the game development community.

I've been working on writing an article on using Lua in games, though for how long I've been writing it, it hasn't gone very far. AFAIK there aren't too many article on embedding languages into games, more scripting articles focus on creating new scripting languages themselves.

I'd love to get my article reworked and rewritten for publishing in GDMag and Gamasutra, if for no other reason than to have something to boast about at a future Toronto IGDA chapter meeting. :) What's already written is available at this (somewhat long) URL:
   http://www.meldstar.com/ccharabaruk/writings/Using_Lua_In_Games.html

It's not too much, sadly, and I realize that I missed out on how to set up C/C++ functions for use in Lua. That's why I want to give it a complete restart.


--
Chris 'coldacid' Charabaruk <ccharabaruk [at] meldstar [dot] com>
Meldstar Studios <http://www.meldstar.com/> - Creation, cubed.


Reply | Threaded
Open this post in threaded view
|

Re: Lua x Python

io21
In reply to this post by pau
--> Thursday, August 22, 2002, 10:07:17 AM, you wrote:

> On Thu, Aug 22, 2002 at 11:38:33AM -0300, Luiz Henrique de Figueiredo wrote:
>> 
>> We intend to experiment with generational GC soon. Perhaps it will
>> make it into 5.0 final. What are the "requirements of soft
>> realtime"?

> It is hard to control the exact behavior of a garbage collector in
> such a manner, but generational GC is definitely better than
> mark-sweep.

Wow, I didn't realize Lua used mark & sweep GC... Change that. ;p


Reply | Threaded
Open this post in threaded view
|

RE: Lua x Python

Joshua Jensen
In reply to this post by Andre Carregal
I'd like to comment on a few points made in Bruce's article:

Lua's documentation: Agreed.  Just the continual set of messages we see
on the mailing list about interfacing a C++ object to Lua or "why
doesn't print() work?" should tell us better/clearer documentation is in
order.  Despite that, the lack of _complete_ documentation is not a good
reason not to use Lua.

Python's extension modules: While I would love the wide array of
Python's extension modules in a command-line Lua scripting environment,
I would never want the overhead in a game, and this is where Bruce is
coming from.  If Lua had Python's extension modules (and that would
require a de facto way of binary loading Lua extension libraries), then
I'd say Python has NOTHING on Lua.  As it stands, this is a pretty big
win for application development (but not games, at least, not with most
of the extension modules).  It would be FANTASTIC if somebody could
write a way to call Python extension modules, much like the LuaJava
thing.

Python exceptions: I know Lua is capable of "exception-like" behavior,
but I would like to see a sample Lua script which illustrated it.

Memory allocations: Ah, the worst thing I had to deal with in Amped.  It
wasn't a bad problem to fix, since I did some upfront work to ensure
others wouldn't use features of Lua that caused memory allocations, but
it still required some clean up at the end.  There could be NO memory
allocation performed during the real-time portion of the game, because
the garbage collection took too long.  Now, I'm unsure how long Python
takes to run a garbage collection, but I'd wager it is still too long.

Performance: A quick look at http://www.bagley.org/~doug/shootout/ and
http://dada.perl.it/shootout/ tells me all I need to know about
performance.  Lua does better than Python in almost every case.  Lua
isn't as fast as other languages, but it still does well.  Looking at
these benchmarks show parts of Lua that need a lot of optimization
(should you use the feature, of course).  In the end, Python just looks
SO SLOW to me.  Real world environments may prove otherwise.  As the
matrix multiplication benchmark of Pike shows, calling C functions is
the way to go for intensive operations, but I've always been one to make
sure I'm working in a somewhat optimal environment from the beginning...

Size: Python is huge.  The core DLL is 839-ish kilobytes.  How much can
be ripped out?  I don't know, but when I can link in a 70k Lua Release
build WITH parser into my application, everybody is much happier.

Remote Debugging: I have a Lua Remote Debugger I've been using for about
two years now.  I was kind of hoping somebody else would release a good
one (so I could quit developing mine!), but I don't recall seeing any
announcements for it.  I'll see about releasing it this weekend.  The
debugger GUI only runs on Windows, though.

Consoles: Bruce's quote: "Python will end up wasting a bit of memory for
features that are not relevant on console games, but probably not enough
to worry about on the new generation of console machines, with their
minimum of 24Mbytes of memory."  Wow.  That's excellent that he had the
memory to lose.  I remember scrounging for every byte in Amped, and I
was on a 64 MB Xbox.

Legal wrangling: I had to deal with this with Lua.  With the previous
Lua license (pre-MIT), the _Microsoft_ legal department approved it.
Wow!

Disadvantages (No compile time type checking): This was the scariest
thing of all using Lua in Amped.  Of course, the realization didn't set
in until it was too late.  At one point, the end-to-end pipeline for
text display was Unicode, but over time, fell into a
Unicode->ANSI->Unicode conversion scenario.  This was bad for languages
like Japanese.  I used a modified Lua that supplied wide character
strings, and even though I didn't allow automatic ANSI-Unicode type
conversions, it took running EVERY SINGLE CASE to find all places where
ANSI strings were being used instead of Unicode.  Contrast this with the
C++ code where changing the base type automatically compile errored TONS
of code, since the ANSI-Unicode conversion had to be explicit.  This is
an extreme case for sure (and an obvious bad design), but when using a
typeless language, it takes a different mindset and an altogether
different set of error checking.  Train your programmers in this
mindset...

Lua pluses:

* Fantastic data description support.  XML should have never been
invented.  It should have been Lua instead!
* Decent C API.  It's not the best.  With my C++ wrapper, I've really
tried to shield programmers from stack management.  Having Lua stack
based at the API level does not help ease of use for programmers who
just want to use it and forget it.  (I'm sure others will disagree.)
* Speed.  For being typeless and hash-based, Lua's speed ROCKS.

Before anybody thinks I'm bashing Python, I'm not.  If it weren't for
Lua, I'd be a Python junkie.  It really is the "next best thing" for me.
Lua has a long way to go before it reaches Python's documentation level
and Python's extension libraries, but I really feel there is nothing
else about Python that is better than Lua for the things _I_ need it
for.

-Josh


Reply | Threaded
Open this post in threaded view
|

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

ashmatheso
In reply to this post by Christopher S. Charabaruk
Funny you should mention that.

I'm doing the same thing.   Want to co-write an article?  I've already
put forth a proposal to the guys at GD Mag.

-TheAsh
Programmer At Large


-----Original Message-----
From: [hidden email]
[[hidden email]] On Behalf Of Christopher S.
Charabaruk
Sent: August 22, 2002 11:08 PM
To: Multiple recipients of list
Subject: Lua For Game Scripting article (Was: Re: Lua x Python)

Andre Carregal wrote:
> What if someone using Lua in game development wrote a similar article
for
> Gamasutra? Or if the Lua team submitted some Lua reference material to
> Gamasutra? The site is very popular in the game development community.

I've been working on writing an article on using Lua in games, though 
for how long I've been writing it, it hasn't gone very far. AFAIK there 
aren't too many article on embedding languages into games, more 
scripting articles focus on creating new scripting languages themselves.

I'd love to get my article reworked and rewritten for publishing in 
GDMag and Gamasutra, if for no other reason than to have something to 
boast about at a future Toronto IGDA chapter meeting. :) What's already 
written is available at this (somewhat long) URL:
    http://www.meldstar.com/ccharabaruk/writings/Using_Lua_In_Games.html

It's not too much, sadly, and I realize that I missed out on how to set 
up C/C++ functions for use in Lua. That's why I want to give it a 
complete restart.


-- 
Chris 'coldacid' Charabaruk <ccharabaruk [at] meldstar [dot] com>
Meldstar Studios <http://www.meldstar.com/> - Creation, cubed.


Reply | Threaded
Open this post in threaded view
|

RE: Lua x Python

Nick Trout-4
In reply to this post by Andre Carregal


> I'd like to comment on a few points made in Bruce's article:


Hi Josh, I summerised my thoughts on a comparison of the 2 languages, feel
free to update the page: 
http://lua-users.org/wiki/LuaVersusPython

It would be interesting if people added some comparisons to other languages
here. I'd be interested in a comparison to Ruby.

Regards,
Nick



Reply | Threaded
Open this post in threaded view
|

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

Dan Partelly
In reply to this post by Christopher S. Charabaruk
>> up C/C++ functions for use in Lua.

Unfortunately, even with that , is only the tip of the iceberg. If you want
to get serious about this, you should ,I think, talk about implementing a
scripting engine arround Lua , where
you have to talk about implementing disptachers using 4.0 version of Lua, go
and talk about multithreading in 5.0 which will make your life easier with
respect to multiple scripts execution, talk about scripted action queues,
flushing & combining  action queues,  events and listener objects, entity
(game actors)  state control through scripting,  state serialization
(saving) of scripts running , which aint trivial, and so on, there is a
hughe list of things to talk about, ( or for that matter,  actualy design a
scripting engine using Lua, and implement it).

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.
Lua has a good manual, which explains how to set up Lua, call functions from
C , using it's advanced features,  I think there is no need to rewrite that
in an article called "Using Lua for games" or you can touch them extremly
briefly and durect the reader to Lua manual. Focus on real problems which
are encountered when building a game scripting engine arround Lua, youll
have enough to talk about, and the article will be much more usefull than an
article reprinting the obivious from the Lua manual.


just my 2 cents, Dan



----- Original Message -----
From: "Christopher S. Charabaruk" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
Sent: Friday, August 23, 2002 9:07 AM
Subject: Lua For Game Scripting article (Was: Re: Lua x Python)


> Andre Carregal wrote:
> > What if someone using Lua in game development wrote a similar article
for
> > Gamasutra? Or if the Lua team submitted some Lua reference material to
> > Gamasutra? The site is very popular in the game development community.
>
> I've been working on writing an article on using Lua in games, though
> for how long I've been writing it, it hasn't gone very far. AFAIK there
> aren't too many article on embedding languages into games, more
> scripting articles focus on creating new scripting languages themselves.
>
> I'd love to get my article reworked and rewritten for publishing in
> GDMag and Gamasutra, if for no other reason than to have something to
> boast about at a future Toronto IGDA chapter meeting. :) What's already
> written is available at this (somewhat long) URL:
>     http://www.meldstar.com/ccharabaruk/writings/Using_Lua_In_Games.html
>
> It's not too much, sadly, and I realize that I missed out on how to set
> up C/C++ functions for use in Lua. That's why I want to give it a
> complete restart.
>
>
> --
> Chris 'coldacid' Charabaruk <ccharabaruk [at] meldstar [dot] com>
> Meldstar Studios <http://www.meldstar.com/> - Creation, cubed.
>
>


pau
Reply | Threaded
Open this post in threaded view
|

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

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

Reply | Threaded
Open this post in threaded view
|

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

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: <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
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.
>


Reply | Threaded
Open this post in threaded view
|

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

Vincent Penquerc'h-4
In reply to this post by Christopher S. Charabaruk
Title: RE: Lua For Game Scripting article (Was: Re: Lua x Python)

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

--
Vincent Penquerc'h

Reply | Threaded
Open this post in threaded view
|

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

Dan Partelly
Title: RE: Lua For Game Scripting article (Was: Re: Lua x Python)
Vincent,
 
I completly agree with you that it can be done this way.
 
One of the things I want to avoid is to have mappers (which will script their NPC maps as well) to get lost into scripting.  Truth is Im not
aiming to implement game code in a scripted language, but to give mappers a way to easy put more life into their maps through scripting.
In the final implementation , the scripter should not even care what interpreter the underlieing scripting engine uses, nor make any assumptions
about what are its abilites. He should stick to the interface offered , and if he needs another script command he must ask us to implement it.
Keeping this in mind, I am aiming to implement event handling INSIDE the scripting engine code, and only allow a very narrow set of events
to be processed by a script thread (for example , a "thread" (function, method) whatever  ) to be called on NPC spawning , take pain, hurt 50% , etc). In rest , he should not care about an event such as "finished moving to new vector", he should not even know that such a event is processed inside the scripting engine.
 
Anyway, even such a method as yours can be looked as a a very particular case of a thread dispatcher. We have here "pseudo-threads" (methods to be called ) which are dispatched by scripting engine core on very specific events.
 
 
However, your post made me think that a paper talking about using Lua in games, or in general any other interpretor in a game , should talk
about different scripting engine designs for games as well. In fact I think is much more important to talk about designs and designs caveats
then about calling C++ from scripts.
 
Ciao, Dan
 
----- Original Message -----
Sent: Friday, August 23, 2002 3:48 PM
Subject: RE: Lua For Game Scripting article (Was: Re: Lua x Python)

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

--
Vincent Penquerc'h

pau
Reply | Threaded
Open this post in threaded view
|

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

pau
In reply to this post by Vincent Penquerc'h-4
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.

Reply | Threaded
Open this post in threaded view
|

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

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: <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
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.
>


Reply | Threaded
Open this post in threaded view
|

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

Enrico Colombini
In reply to this post by Vincent Penquerc'h-4
>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


Reply | Threaded
Open this post in threaded view
|

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

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" <[hidden email]>
To: "Multiple recipients of list" <[hidden email]>
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
>
>