Jump to content
  • Advertisement
Sign in to follow this  
3DModelerMan

Unity Cost of multiple LUA states

This topic is 2663 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm going to use SWIG and LUA for my game's scripting system, and I ran into a design barrier. I want my script system to work like Unity3D's, how the code outside functions is where variables go, and the update, fixedupdate, awake, etc functions are called at certain times by the application. The way I could think of to do this would be to have one LUA state per game object/actor/entity, would that take up too much memory? Are there any games that actually do that? Or is there a way to do it with one global LUA state object, and call multiple functions that all have the same name, but for different objects?
Thanks for any help.

Share this post


Link to post
Share on other sites
Advertisement
No, you do not want to have a Lua state for each individual whatever. That's just silly. Not because of the memory usage (Lua has a small footprint, but if you have a thousand states those are going to add up), but because it doesn't make sense. I'm unfamiliar with SWIG so I can't comment on its capabilities. I use Luabind with my project and it works great.

  • We have one global state
  • We have hundreds of C++ functions, classes, enums, and other objects bounded to Lua
  • We have functions that have the same name, but use a different signature (may be that they are either on a different class, or their parameter list/return values differ)
    I think that's pretty much the way you want to go. You want to have one state so you can share data, functions, etc. across all your different script files.

Share this post


Link to post
Share on other sites
Heh, I just went back through my code and discovered that is in fact not the way we did it. :P


We do have multiple Lua states. It looks like we create a new Lua state for each open file, and there's also a global Lua state. I think the way it works is we bind all of our code to the global state, and each new state we create is a thread that inherits from that state or something. I honestly can't remember; Its been years since I looked through this code. Its open source though, so if you want to take a look through it and see how we did things go ahead. The code is well-commented.

Web-browsable script engine source


There's also documentation at our wiki, although I think its more intended to explain how to use the engine and not how the internals of the engine function.

Script engine documentation

Share this post


Link to post
Share on other sites

Heh, I just went back through my code and discovered that is in fact not the way we did it. :P


We do have multiple Lua states. It looks like we create a new Lua state for each open file, and there's also a global Lua state. I think the way it works is we bind all of our code to the global state, and each new state we create is a thread that inherits from that state or something. I honestly can't remember; Its been years since I looked through this code. Its open source though, so if you want to take a look through it and see how we did things go ahead. The code is well-commented.

Web-browsable script engine source


There's also documentation at our wiki, although I think its more intended to explain how to use the engine and not how the internals of the engine function.

Script engine documentation





A LUA state for each file would probably work. But wouldn't that add up if there were a lot of scripts? The main problem I have is that if I have an object with a script that defines the "update" function, and another one that defines a different "update" function with the same parameters. Ineed to call the right update function for the attached object. If I had a script class that managed the LUA states for each file that would work well. How much memory does a single LUA state take on average? With all the libraries loaded?


Share this post


Link to post
Share on other sites

A LUA state for each file would probably work. But wouldn't that add up if there were a lot of scripts? The main problem I have is that if I have an object with a script that defines the "update" function, and another one that defines a different "update" function with the same parameters. Ineed to call the right update function for the attached object. If I had a script class that managed the LUA states for each file that would work well. How much memory does a single LUA state take on average? With all the libraries loaded?


Of course it would add up if there were a lot of scripts. The idea is to only open the scripts that you need and close them when you no longer need them. I'd estimate we have about 10 scripts open at a time in our game currently, and I'm sure we could handle many more. If you have two update functions for the same object with the same parameters, obviously you'll have to give the functions different names (UpdateA, UpdateB) and bind both to Lua. They'd have to be different names in C++ as well, since the function signatures would be identical.

I have no idea of the memory size that a Lua state takes. That would be something that you would have to measure yourself, perhaps with a memory profiler or making a simple stand-alone application that opens a Lua state and nothing more. Unless you're developing for an embedded system (phone, handheld console) I don't think that the majority of your memory is going to be consumed by Lua though.

The key is to make your Lua files represent a large amount of related information, rather than having a ton of small files that each represent a small piece of something. For example, a single Lua file for us represents one of the following.

- Initial attributes of all characters
- Attributes for a set of 100 enemies
- A single map
- All battle actions for a type of skill (attack, defend, etc)
- All status effects
- A tileset definition file (defines the properties of tiles for a composite image that are then used to create a map)


Sometimes you just have to dive in and start getting your hands dirty before any of this makes sense. Its difficult to plan everything first and then go do it when you don't have the experience, and usually you'll find things you forgot to take into account and you have to change your plan anyway. I'd recommend you work on implementing something that is roughly what you think that you want, see how it works, then make adjustments as needed when you find you need something to be changed.

Share this post


Link to post
Share on other sites

I'm going to use SWIG and LUA for my game's scripting system, and I ran into a design barrier. I want my script system to work like Unity3D's, how the code outside functions is where variables go, and the update, fixedupdate, awake, etc functions are called at certain times by the application. The way I could think of to do this would be to have one LUA state per game object/actor/entity, would that take up too much memory? Are there any games that actually do that? Or is there a way to do it with one global LUA state object, and call multiple functions that all have the same name, but for different objects?
Thanks for any help.


It sounds like you are after something more like this: (very roughly translated from my own code ...)


function update_entity( entity, delta_time )
...
end

function awake_entity( entity )
...
end

function create_entity( stats )
local new_entity = {}
new_entity.stats = stats
new_entity.on_update = update_entity
new_entity.on_awake = awake_entity
return new_entity
end

function update_boss( entity, delta_time )
...
end

function awake_boss( entity )
...
end

function create_boss( stats )
local new_boss= create_entity( stats )
new_boss.on_update = update_boss
new_boss.on_awake = awake_boss
return new_boss
end




-- called from application

function init_scene( level_description )
for i, entity_description in pairs( level_description.entities ) do
...
local entity_id = ...
local entity = create_entity( entity_description.stats )
entities[entity_id] = entity
end
...
end


function update_scene( delta_time )
for i, entity in pairs( entities ) do
entity.on_update( entity, delta_time )
end
end


function awake_entity( entity_id )
entities[entity_id].on_awake( entities[entity_id] )
end


It is perfectly fine to organise your scripts into separate files, but I think that you should only really start using multiple lua states when you have a good reason to; ie. to run them on separate threads, to separate scripting layers, etc. Suggest also checking out http://lua-users.org...impleLuaClasses (and the rest of the wiki ;)) for ideas on organising your game scripts.

Share this post


Link to post
Share on other sites
Sorry for the late response. I know of at least one working MMO which holds well over a hundred lua_states in memory at all times. It's workable. But as has been adequately noted above, this is not at all needed for a system where you just want to poll many individual NPCs periodically - you can do that with one state.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!