[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Using multiple lua_States
- From: William Roper <lacutis@...>
- Date: Wed, 4 Aug 2004 09:30:46 -0700
I would take it a step further (and have). I would set up the tables
for each object type and the methods within. Then as I created the
scriptable objects in C++ I would call a function to create a userdata
and register it in a table to keep track of all the objects of that
type and then set the metatable to the appropriate script table that
you created.
If you can I would make a new method in lua and actually create the
objects in lua, its a lot easier to deal with them that way.
Theres probably a dozen different ways to handle it.
Ryan.
On Wed, 4 Aug 2004 03:40:37 +0100, Jamie Webb <j@jmawebb.cjb.net> wrote:
> On Tue, Aug 03, 2004 at 07:10:37PM -0700, Brenden Rheaume wrote:
> > I am beginning to imbed lua into a game project. One of the things
> > that I would like to do is, define general
> > functions(OnHit,OnDamaged,OnClick) for each object type in the game
> > (each enemy, ship type, weapon type, etc), which would be defined in
> > a lua script file for each type. What I need to know is how
> > expensive would be to use multiple lua_States for each type, loading
> > the lua script associated with each type, assumming there are quite
> > a few of them (50+).
>
> The memory overhead for each state is a few tens of kilobytes, plus
> whatever stuff you have to duplicate in each state in order to provide
> your API. The only CPU overhead is whatever duplicate work you have to
> do to register your API, etc.
>
> > If it would be really expensive (memory/cpu) to use that many
> > lua_States is there another convienent way to acheive the same
> > result?
>
> Basically, what you are wanting is to do object-oriented programming
> in Lua, i.e. to define a class for each object type with method
> implementations for each of your events. There's a fair amount of
> information about OOP in general on the lua-users.org wiki.
>
> In this instance, a simple approach is create some tables with names
> like BadGuy, MachineGun, whatever. Then your scripts contain code
> like this:
>
> function BadGuy:OnDamaged() ... end
>
> function MachineGun:OnClick() ... end
>
> etc.
>
> You just run all the scripts one after the other in the same state.
> Now to find the right event handler for a given type, you just look it
> up in the right table.
>
> Of course, that approach isn't very 'safe', in that it doesn't enforce
> where each event is defined, but it could well be adequate. For the
> more complex solution, where you do just define a bunch of functions
> in each file and they are all properly isolated, but still in only one
> state, search the list archives for 'sandboxing'.
>
> -- Jamie Webb
>