# 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.

## 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 on other sites
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 on other sites
Heh, I just went back through my code and discovered that is in fact not the way we did it.

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 on other sites

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

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 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 on other sites
Alright I'll just implement it. Thanks for the help.

##### 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 on other sites
Yeah, I'm seperating the scripts from each other. I want a system just like Unity's that's what I'm trying to get.

##### 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.

1. 1
2. 2
Rutin
22
3. 3
4. 4
frob
16
5. 5

• 9
• 33
• 13
• 13
• 10
• ### Forum Statistics

• Total Topics
632580
• Total Posts
3007188

×