Lua integration into a game
I have yet a different perspective. I use Lua for everything except for the really performance critical stuff such as rendering, pathfinding and so forth. Even my main loop is in Lua. The C++ portion of Goblinson Crusoe exists only as a set of classes which can be instantiated from Lua to perform their tasks.
Do I expose the various GUI elements' member functions such as setPosition(x, y) to Lua, and then in the GUI's init method I run the Lua function that handles the positioning of these GUI controls? Or would it be a better approach to make the GUI's class (for example the MainMenu class) exposed to Lua and do everything in Lua instead?
Your first approach requires that you tightly couple your GUI element to Lua, so that it can't be used without modification if you decide to move away from Lua in the future. Your second approach is better, but comes with its own set of problems. How much of the interface should you expose to Lua? By exposing the interface, how many other userdatums must be exposed in order to be passed as arguments?
I personally look at my scripts completely differently than my engine code, exposing specifically tailored and simplified interfaces to Lua, rather than the lower level ones.
That was actually in response to acidleaf, who made it sound like he was hardcoding all of the script file refferences. Rather than do that, I merely hardcode init.lua, which has the ability to expand the library of lua functions however I or a modder sees fit.
Why would I recompile after adding a script?
Simply program main() to search for all files in the scripts folder and load each one in.[/quote]The problem I see there is with modding. If every file is read indescriminately, you cannot then have a moda.lua and a modb.lua in the scripts folder unless you want the user to always use both mods he has installed there. By using a file to describe each file seperately, you can neatly store all of the lua files for a specific mod in a scripts/modname/ folder, with only the scripts/modname_init.lua called in the scripts/init.lua file. Disabling a mod, then, is as simple as removing the modname_init.lua refference in init.lua.
I suppose you could run every modname_init.lua using your blanket method, but enabling and disabling mods would still require you to remove and replace the init file for no net benefit over the alternative. As an end user, I hate having to move files around (and dont trust programs moving them for me), and so I tend to design code that leaves files in place. Deleting and replacing one line is easy to write a mod manager for and involves less file moving. I don't suppose either design is objectively "better" but I always side with less moving files.
Currently I'm using a single state shared across multiple Lua scripts. On the C++ side, the 'mod' definition will register all the .lua files necessary for the game objects, these files contains a factory to create an object (table) inside the lua state, so I don't need a class Enemy or Ally on the C++ side, I just need an Entity providing a minimum interface and which invokes the Enemy or Ally factories from Lua.
The Lua objects communicate using message passing, the interaction is coordinated on the C++ side, using uid's. And since the queues are also in Lua I have freedom to send from int's to complex data structures, if necessary.
The Lua objects communicate using message passing, the interaction is coordinated on the C++ side, using uid's. And since the queues are also in Lua I have freedom to send from int's to complex data structures, if necessary.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement