[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Multiple Lua states
- From: Thatcher Ulrich <tu@...>
- Date: Wed, 10 Jul 2002 01:23:15 -0400
On Jul 10, 2002 at 12:22 -0400, Tim Conkling wrote:
> I have still have yet to figure out how to have different Lua scripts
> control different subsystems of a game engine I'm interested in writing
> (though I'll admit I haven't had the time to give it a whole lot of thought,
> and I am definitely a Lua-newbie).
> In the game there will be different C++ objects representing different
> systems, which will call Lua functions in response to events that occur in
> the game world. Each script should probably only be able to access the
> member functions of one particular object, since many objects will be of the
> same class but will need to have their own unique behaviors. For example,
> each enemy in the game might be an instance of a Sprite class, and its
> scripts will define its unique movement and behavior by calling manipulating
> member variables through mutator functions, etc. It seems that the only way
> to do this is by using multiple Lua states, one for each subsystem. There
> could potentially be dozens of sprites in a level (each requiring its own
> Lua state), not to mention sectors and other objects that would also be
> script-driven. Would having this many states slow things down in a big way?
> If so, is there another way to attack the problem?
Yes -- pass an object to the script which represents the subsystem.
The script can call methods on that object to do its work. If you're
worried about security, you can set a specially cleared-out globals
table before calling the script, so the script doesn't have any way to
access objects other than the ones you pass in. I think having
separate lua_States is overkill for your situation.