embedding strategies for beginners

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

embedding strategies for beginners

D Barski
I am studying Lua to learn how to make more flexible games and systems.  It looks very promising.

At first, I have concentrated on the fundamentals of the C API so I could call Lua->C and C->Lua and create new types with userdata in my samples.  Mechanically i feel okay.  My bigger struggle is how to best use Lua to get the most benefit.  This is where I found littler information, samples and discussions.

In one case I could use Lua scripts to handle events at very predefined spots in my code; maybe it is too limiting.  In another case I thought of running Lua script like an applet in a separate interpreter in a separate thread.  But, I wonder how/if I can call a Lua script callback from another thread.

Are their any good links on strategies and architectures for a beginner to learn.  I like to see study some successful uses.  Thank you ahead of time.





-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm



Reply | Threaded
Open this post in threaded view
|

Re: embedding strategies for beginners

Paul Du Bois
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 :-)

p

Reply | Threaded
Open this post in threaded view
|

Re: embedding strategies for beginners

Adrian Sietsma
In reply to this post by D Barski
We (www.spinifex.net) are using Lua for manging our windows help engine.
All help entries are in a manually-edited lua file, and the app calls the lua interpreter to return the appropriate help text.

This provides a flexible and easily modified help system - files can include other files; text can be generated on the fly; etc.

We also use Lua for dynamic menus (among other things).

Adrian

Reply | Threaded
Open this post in threaded view
|

Re: embedding strategies for beginners

D Barski
In reply to this post by D Barski
[hidden email] wrote:
> Here is a very high-level overview of what we do in our game

Thanks its great help for newbie.

> - Scripts get periodic messages from the engine when interesting
> things happen (collision, timer goes off, pushed, etc)

Does the periodic message mean just like a callback:

   -- Some LSO
   function onCollision()
      -- do sometihng
   end

or is it some bigger mechanism I am miss.

> - Scripts also can assign themselves a "state" function, which can run
> blocking code. If this state function calls Yield(), it stops

I imagine coroutines is one possible way.  I worry other project people do not like to rely on cooperation multitasking or to worry they take too much time.  So my prefered proach is to have an interpreter in one thread and from another thread to message them (a) please yield if you can or (b) please yield no matter what.  And if they do not respond to make the interpreter stop.

To force the interpreter to stop I think I can use the lua_sethook() functionality.  But, I like to have the chance to pass message into one interpreter from C and for some other Lua interpreter.  Any idea? 


> 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 :-)

And how can you debug problemed lua scripts?



-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm