RE: Game oriented usage of Lua?

[Dave Bollinger <DBollinger@...>]

 >> though some would argue that it makes it harder to debug

   Yep, this potential drawback of all scripting languages was just pointed
out to me in another forum.  But that's OK, I had already planned to do
some of my own reinventing of the debugger wheel.  In fact, one of my
wishlist criteria for a scriplang was good debugging hooks and enough
"introspective" abilities to do something like a watch window.
   Perhaps the "patch at run time" ability also makes up for part of it.  I
had implemented the same type thing with a Scheme interpreter a while ago,
simply pop up an "Immediate" window and redefine the offending function
(cut/paste/modify/eval).  I'm looking forward to that ability with Lua as
well.

 >> but also gets used for writing batch processing tools to operate on the
data

   Have you perused the "Abuse" LISP source?  They're doing this kind of
wacky stuff:  like building the game engine with LISP scripts which are
interpreted by the game engine itself.  <grin>  It really blurs the lines
between shell and game.

 >> if my BOOT() function actually did work 

   Go on... take it to its logical extreme:  bind with something like tkLua
for the windowing functions, and your custom game routines, and you can
make Lua the "host" program!  That way you can turn your shell interpreter
into the game itself!  (Flipping the paradigm from "C as host, Lua as
extension" that us games types probably tend to think about, to the "Lua as
host, C as extension" model typical of shell programming.  More a trick of
perception than reality, though, since Lua is still "really" the embedded
language.)

 >> Geez, maybe I should leak those cheats!

   Er, you're trying to keep yourself from getting fired, remember?  ;-)


   Status report:  Finally bit the bullet and launched MSVC5.  (been
playing with Lua on AIX so far)  Awk'd and manually hacked together a quick
.def file for the main API and built myself a DLL.  Geesh, no problem at
all!  :->  Still have to try it with full errors/warnings on, and integrate
the optional libraries, and investigate that external state variable, but
the DLL works!  :->  Then, just to torture it, I wrote a minimal import
spec for Delphi (pascal) and called the DLL from there, made a little
expression evaluator via lua_dostring, and everything worked yet again! 
:->
   Ok, my cheeks are getting sore from smiling so much, I'm going to stop
now.

   Anyone here care to share any other already-known "gotchas" with the DLL
approach?


   Cheers,

   Dave