RE: How much lua?

[Chris Chapman <Chris.chapman@...>]

We found that the loss of debugability was a major factor in how much we use
Lua. So much so that our AI programmers gave up trying to put high level
logic into the script and just found ways to restart/change logic faster. I
know we could hook up a debugger, but the lack of keyboard input and
difficulty of implementing has seemed too costly to consider at the moment.

However, for flexibility, we keep the engine side as unaware of game
specifics as possible - the engine code knows about character instances, but
there is a layer of initialisation and configuration scripts between that
and 'EvilMonsterTypeB'. When we have specific C code relating to logic
(which could technically be written in Lua), it is always hooked to the game
engine via a Lua script. All of the mission/game specifics are implemented
in Lua, using callbacks and event/message hooks. This has proved more than
flexible enough to use, and as such we haven't bothered looking at
co-routines/yields.

We found on the PS2 that use of Lua hammers the instruction cache in a
fairly unfriendly way, but that may be a side effect of the way we use Lua
(switching between C and Lua costs a fixed amount, in terms of firing up the
virtual machine).

-----Original Message-----
From: Adam D. Moss [mailto:adam@gimp.org]
Sent: 09 December 2003 10:15
To: Lua list
Subject: Re: How much lua?


Tham wrote:
> i'm part of ps2 development team that uses lua. The question i have is
this.
> 
> how much of the game should be in lua?
> 
> i know the answer is probably "it depends..." hehe but i'd like to hear if
> anyone here have been to either end of the rainbow and what its like
> there... what are the goods and bads...

Personally I try to move EVERYTHING non-time-critical into
lua.  This amounts, for me, to 100% of the game-specific logic,
and a generous pinch of reusable utility-layer.

The game engine itself is C and handles the scene-graph traversal,
physics, graphic rendering, I/O, audio rendering, etc -- usual
stuff.

Then I expose a fairly high-level API to the lua-side, mostly
oriented towards manipulating the scene-graph and some other
core engine-side structures that define the game world and
presentation.  The fairly raw C API calls I expose are then
wrapped at the lua-side into more friendly and logical 'objects'

A lua-side game-logic init-script is booted at engine startup
and registers its interest in certain arbitrary engine events (i.e.
frame-end, key-release, os-level app-quit, etc).  Engine events
cause synchronous callbacks in event observers through a system
that is language-agnostic and which can pass complex reflective
structures.  In this manner at no point does the core of the C
engine know or care that it is talking to a lua script.

Now the game logic typically asks for a callback every frame through
its 'tick' function and is happy with that.

This is working out fine so far -- 100% of the game-specific logic
in Lua, 100% of the engine core in C, and a fairly thin hand-rolled
interface gluing them.

Why am I doing it like this?
* Game-level fixes and improvements (and bugs!) are platform-
  neutral.  This definitely helps QA and, potentially, the rollout
  of fixes (modulo platform-specific installers and lua bytecode
  wordsize incompatabilities [fortunately we don't support 64-bit
  platforms yet]).
* Lua is generally more pleasant than C (or C++!) for high-level
  object-oriented logic.  It really helps that you can 'roll your
  own' object and module systems just how you like them on top of
  Lua's extensible semantics, though it takes some work.
* It's nice to have garbage collection.
* Can create (at the lua-side) and present an ultra-simplified
  scripting interface to non-programmers for scripting level-specific
  'switches and monsters' etc.

Now, a heavy disadvantage of moving logic to Lua is that Lua code
can be pretty tough to debug -- you lose the usefulness of the
development platform's logic-probing tools (i.e. gdb).  (Similar
situation with profiling i.e. gprof.)  These tools can be
reconstructed at the lua-side but that really takes a lot of
time (there are examples in the wiki but [last I checked] they're
very basic and also not ported to lua5).  Still, there's always
the old print[f] debugging method...

Regards,
--Adam
-- 
Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3
Consume Less, Live More