lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Here is a very high-level overview of what we do in our game:

- We wrote a simple object system for lua -- classes, instances,
single inheritance
- Most every renderable object (we call them Entity) has a Lua script
object (henceforth abbreviated LSO). Creating an Entity creates an
LSO, and creating an LSO constructor from within lua creates an Entity
(or the proper subclass of Entity; eg, the Lua class
global.props.Ladder will make a LadderEntity C++ side for itself). The
two objects always travel together.
- Scripts get periodic messages from the engine when interesting
things happen (collision, timer goes off, pushed, etc)
- Scripts also can assign themselves a "state" function, which can run
blocking code. If this state function calls Yield(), it stops
executing and continues there next frame. You can use threads for this
(kind of tricky, but allows you to yield from a C function) or
coroutines (available even in 4.0 with thatcher's patch)

So we use both the strategies you've described: events and thread-like
blocking code. I'll note that you don't actually to run your scripts
in parallel. We use threads only to keep state around while the script
is not executing. The main game loop goes something like:

 process animations, physics, etc (queueing up a bunch of messages for LSOs)
 process timer messages for LSOs
 process queued messages for LSOs
 for each LSO in a state, run its state code until it blocks
(typically there are few of these)

This is plenty of flexibility for our needs. We have quite a big game
-- hundreds and hundreds of script classes; the total LOC probably
exceeds that of the main engine :-)