Re: Lua 4.1 release on <insert date here>...

[Bret Mogilefsky <mogul@...>]

On Mon, Jun 11, 2001 at 02:09:28PM -0700, David Jeske wrote:
> Heap-allocated stacks have their advantages, the most significant of
> which is reduced memory footprint for running lots of
> threads. However, they are also generally harder to interface with
> external C-code, which is one of the reasons Lua is not in a hurry to
> go stackless.

I have to say I understand this decision.  The semantics were fairly clear
in the specific case of Grim Fandango, but it would be hard to go stackless
in such a way that the restrictions would be easy to work with in general
situations.

> I'm not sure what Grim Fandango was doing with threads, perhaps
> someone can comment.

We used C level threads for things like audio/video streaming, but not much
else.  I don't doubt that a game engine such as David has described can do
everything it needs to using Lua callbacks for events.  In our case I think
it was the fact that it was an adventure in particular that made doing what
we did necessary... Blocking out a complex dialog between two characters
(reaction shots, punctuating dialog with animation, etc.) for example using
just callbacks would be pretty difficult.  I don't doubt that it's
possible, but doing it the way we did felt much more natural.  We did have
callbacks for events; it's just that the events were usually generated
elsewhere in the scripts.  For example, "call the event for 'use' of item
'foam-filled balloon' with 'pneumatic tube', or give the inherited default
response if there's no such action defined".  This might also come from the
fact that everyone who had worked on adventure games at LEC before had used
a language designed this way, and we were working from experience whereas
starting with no preconceived notion of how it should have been done might
have put us all in the event-driven callback frame of mind.

In general there'd be no more than, say, ten or so scripts running, but
often each contained logic that would have been cumbersome to program in
the engine.  There were simple things like the cameraman script that looked
for opportunities to change to a better camera angle, but not so often as
to be jumpy.  That could have been done in the engine with callbacks pretty
easily.  Then there are others like the script that ran the
giant-kitty-racetrack announcer. It was basically randomly generating and
narrating cat races for as long as you were within hearing range (yes,
really...) This was written in just a few minutes by a fairly new
programmer.  If it had required any specific engine callbacks or anything
other than a very straightforward procedural implementation, it might not
have been done.  However, in some sense having multiple scripts running
makes things much more object-oriented... This one script was totally
self-contained and didn't have to interact with anything else going on, so
it was nice that the code could be written the same way.

As always, there's more than one way to do it.  =)  I'm just happy that we
had the choice to hack Lua and do it the way that seemed natural to us.

Bret
-- 
Bret Mogilefsky * Mgr. SCEA Developer Support * mogul@gelatinous.com