RE: Game oriented usage of Lua?

[Bret Mogilefsky <mogul@...>]

Yeah, I don't see a problem with directing control from Lua, though some
would argue that it makes it harder to debug the game as a whole.  The idea
that the engine is just a collection of functions and it takes Lua to make
them meaningful is very interesting to me.  I'd thought about what it would
take to make a Unix shell replacement out of the Lua interpreter, just for
laughs, and it didn't seem too far-fetched.  So the same way you'd run a
perl script, you could run a Lua script, only the interpreter contains all
of your custom primitives.  (Of course, this is really possible with any
language, particularly perl and python... But since I'm using Lua for the
actual game anyway...)  Then I thought about giving the engine itself the
same command-line semantics as the interpreter, opening up the possibility
of having one general-purpose body of code that gets compiled for the game,
but also gets used for writing batch processing tools to operate on the
data, all in Lua.  That seemed excessive in this case, but I can see even
much smaller cases where it might be useful to think of things that way.
It's not much different really from what the engine does now... It's just
that the specific file of Lua code and function to be called are arbitrary
and can be set from the command line, and are not expected to launch the
game into the main loop.  

Hokey smokes, Bullwinkle, if my BOOT() function actually did work instead of
spawning off sub-tasks, the engine would quit when BOOT returned and no
tasks were running and I'd have this functionality as is!  Crazy stuff...
Geez, maybe I should leak those cheats!

Bret
-----Original Message-----
From: Dave Bollinger [mailto:DBollinger@compuserve.com]
Sent: Wednesday, May 26, 1999 6:28 PM
To: Multiple recipients of list
Subject: RE: Game oriented usage of Lua?


 >> Hope you enjoyed reading as much as I enjoyed sharing...

   At least as much!  :-)

   One of the design decisions I was wrestling with was "who keeps the main
'state' variable"?  In other words, should the host program try to maintain
state and call into Lua for specific discrete "events", or should every
frame update call into a more general Lua-based "director" routine and let
game-state be managed completely in Lua.  I was leaning towards the former,
you've taken the latter -- that at least opens up new "proven"
possibilities for me.  (will have to wait and see which is better for this
particular implementation)

   Some of that indecision may just be "cold feet" about entrusting TOO
much control to the scripting language.  However, I can actually foresee a
condition where I eventually prefer the Lua-side of things MORE than the
host-language engine stuff, so this balance may shift.  <grin>

   Again, thanks so much, very enlightening.  :)

   Cheers,

   Dave