![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Lua development
Feb. 22nd, 2011 07:39 pmI recently discovered the advantages of Lua while doing research and doing some reading regarding ToME development. I've known about Lua in name only, but hadn't taken a long look at it until I noticed how much ToME relies on it.
It's an interesting approach and I'm excited about the capabilities to embed scripting abilities into Middlecrest. I've always envisioned the core of Middlecrest to be a library (or engine, of sorts) and this seems to be able to push the direction of the project more into that realm. I can also imagine that as Middlecrest grows, the sheer amount of source to compile will become an unwieldy time sink.
I've identified modules to begin scripting. Transitioning the code into a model where Lua becomes the logic of Middlecrest and C/C++ becomes the engine/driver of the lua modules will take some time. And I'm not sure I will be masterful enough with Lua to be able to convert everything over and compartmentalize things the way I want. I'm not sure enough bindings and support are available for Lua and the language itself is a little wonky.
Bindings for Lua and SQLite seem to be only partially implemented for version 3 (the best I've found so far is a project at 0.7) and seems to require a dll (trying to stay away from Windows-only setups for easier porting... I've been successful so far!). Lua is really high-level and so I'm not sure I will have such a fine control over the program as I have with C and C++, which limits me and I've been unsuccessful at being able to call C++ functions from Lua (which you should be able to... but, I'm still learning Lua). Tutorials are sparse, although documentation seems fair but spartan. And Lua has some wonky aspects to it that are interfering with the learning curve, like having to call the rng function twice on Windows machines, else no random number generation. Things like the rng issue aren't properly documented and probably only known to Lua gurus (or hours of googling and a lucky hit).
All these things may mean the ideal set-up of C/C++ (driver/engine), Lua (game logic), SQLite (data) may be more hybridized (C/C++ and Lua as the engine/driver and logic, and SQLite for data).
May have to see if there are other embeddable and interpreted languages out there for C++?
It's an interesting approach and I'm excited about the capabilities to embed scripting abilities into Middlecrest. I've always envisioned the core of Middlecrest to be a library (or engine, of sorts) and this seems to be able to push the direction of the project more into that realm. I can also imagine that as Middlecrest grows, the sheer amount of source to compile will become an unwieldy time sink.
I've identified modules to begin scripting. Transitioning the code into a model where Lua becomes the logic of Middlecrest and C/C++ becomes the engine/driver of the lua modules will take some time. And I'm not sure I will be masterful enough with Lua to be able to convert everything over and compartmentalize things the way I want. I'm not sure enough bindings and support are available for Lua and the language itself is a little wonky.
Bindings for Lua and SQLite seem to be only partially implemented for version 3 (the best I've found so far is a project at 0.7) and seems to require a dll (trying to stay away from Windows-only setups for easier porting... I've been successful so far!). Lua is really high-level and so I'm not sure I will have such a fine control over the program as I have with C and C++, which limits me and I've been unsuccessful at being able to call C++ functions from Lua (which you should be able to... but, I'm still learning Lua). Tutorials are sparse, although documentation seems fair but spartan. And Lua has some wonky aspects to it that are interfering with the learning curve, like having to call the rng function twice on Windows machines, else no random number generation. Things like the rng issue aren't properly documented and probably only known to Lua gurus (or hours of googling and a lucky hit).
All these things may mean the ideal set-up of C/C++ (driver/engine), Lua (game logic), SQLite (data) may be more hybridized (C/C++ and Lua as the engine/driver and logic, and SQLite for data).
May have to see if there are other embeddable and interpreted languages out there for C++?
