3

I'm in the design/skeleton coding phase of my C++ game with Lua scripting, but I have run into a design issue:

The game will have many copies of the same kind of entities, with behavior controlled by the same script. Is there a straightforward way I can share the script between entities of the same type in a single lua_state? I have only been able to find this question asked a couple of times on the Internet; I have read mixed feedback on whether or not it's a good idea to load the same script in different lua_state's, and not in-depth feedback on alternatives.

It's simple and bullet-proof, but I think loading, compiling, and storing addition copies of the same byte code with each instance of the same entity type created is a tragic waste, so I would like to figure out a smarter solution.

These are the two solutions I have thought of. I'm not new to programming or C or OO concepts but I am still learning when it comes to Lua and especially the Lua/C API. I think my ideas are sound but I am not even sure how I would go about implementing them.:

  1. Implement OO in the Lua script and have each entity be represented by a Lua object; all the Lua logic would act on the object. This would also have the benefit (or the "benefit") of allowing the global environment to be changed by anything single entity.

  2. Encapsulate each entity in its own environment using setfenv and copy references of all of the functions from the global space. As I understand it the env is just a different table than the default global, but I've looked into setfenv but I don't know how I would do that.

stands2reason
  • 672
  • 2
  • 7
  • 18

1 Answers1

4

1 and 2 are just different sides of the same coin, more or less. It's simply a matter of where the object goes. In type 1, the object is an explicit part of the Lua script. Which means the script decides how it wants to set up its objects.

In type 2, the object is the environment. It is still a Lua table, but one created for it by the external code. The script cannot break free of the confines of this object, except in the ways that the external code allows.

The easiest way for me to implement type 1 would be with Luabind. I'd have an AI object as a C++ class, which Lua would be able to derive from. Running the "main script" for that AI would create an instance of that class. You would pass the script parameters, like the name of the entity it controls, maybe a reference it can use to control it, etc.

Type 2 is fairly simple. First, you create the new environment by creating an empty table and populating it with the global variables that you want the user to be able to have access to. These would be for things like talking to game-state (find other objects in the scene, etc), ways to move the entity in question around, and so forth. There are metatable tricks you can play to effectively make these values immutable and constant, so the user can't modify them later.

Then, you load the script with lua_loadstring or lua_loadfile. This puts a function on the Lua stack that represents that Lua script. Then you apply this table as that script function's environment with lua_setfenv. You can then run that script, passing whatever variables you wish (the name of the entity, etc).

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • I like idea 2 better. I would like the script to avoid having to see multiple objects. Can you explain the metatable magic necessary to set up an environment for each copy of the script running? Also I don't understand why you want to use lua_loadfile. As I understand it, it just compiles the script without running it, so things like function declarations aren't evaluated. – stands2reason Nov 04 '11 at 01:49
  • 1
    @stands2reason: And that's exactly why you do call it instead of `lua_dofile`. Because you can't `lua_dofile` and provide an environment. Remember: the script itself is just a function. You want that function to be executed within the environment. And you can only attach an environment to a function on the stack. So you must load the function onto the stack with `lua_loadfile`, then attach the environment to it, then execute the function. – Nicol Bolas Nov 04 '11 at 01:56
  • So to clarify, the setfenv takes a table on the stack and makes it the new _G for what's about to run. If you are using a metatable though, wouoldn't this just be an empty table to start with? And can you explain how I would set up a metatable to share the functions? – stands2reason Nov 04 '11 at 01:57
  • Wait, nevermind, I think I got it now. Here is my sample lua_newtable(L); lua_setfenv(L, -2); – stands2reason Nov 04 '11 at 02:12
  • Wait, nevermind, I think I got it now. Here is my sample
    First you create the invariant table: lua_State * L = lua_open();
    luaL_loadfile(L, "scripts/test.lua");     lua_newtable(L);
    lua_setfenv(L, -2);     – stands2reason Nov 04 '11 at 02:21
  • OK, so apparently formatting works totally differently in comments. I think I understand you now though. What I'm still unclear on, when you have the new table environment, how you do you save it between runs? Will the table still be on the stack, below any return values of pcall()? – stands2reason Nov 04 '11 at 02:46
  • @stands2reason: Lua has [extensive documentation](http://www.lua.org/manual/5.1/). According to it, `lua_setfenv` pops the table off the stack. So if you haven't saved it anywhere, then you can only get it back by using `lua_getfenv` from the function you set it on. And `lua_pcall` pops the function off the stack too, so if you call both, you can't get it back (easily). If you want to save something in Lua, use the [Lua registry](http://www.lua.org/manual/5.1/manual.html#3.5). That's what it's there for. – Nicol Bolas Nov 04 '11 at 03:39