Looking for some Lua alternatives to be embedded in a game engine
Looking for some Lua alternatives to be embedded in a game engine
Since I'm having untracable issues with Lua due to its API and lackluster documentation, I've decided to drop it from my game engine (PixelPerfectEngine) in favor of some easier to use alternatives.
What I need is:
- open source
- small footprint even if it at the cost of some complexity (I need it as a scripting engine, not as a replacement for compiled application languages)
- integer support (I don't care if I could just round it on the backend)
- C or C++ ABI
- can be embedded into a software (yes, there are people that suggest you to use janky solutions like passing data in files and command line)
Even a better Lua implementation would suffice, and if I had the time, I would port the official one to D (my main language), while getting rid of the godawful stack method of control.
This is not a recommendation, but just a couple of days ago someone linked to this project, claiming similar goals to lua, great performance, and gradual typing:
I can't tell you what it's actually like though.
A more established, proven option is Haxe. Haxe has a lot of libraries but I think it's specifically designed to be batteries-optional. This Haxe VM in particular looks pretty impressive:
Haxe has the distinction of having been used to ship loads of successful games made by small teams with custom engines.
Another option designed for simplicity, low-complexity and easy embedding is wren:
Implementation is apparently only 4000 lines.
Permanently Deleted
I was going to suggest gdscript half jokingly but for real more FOSS engines adopting it would be cool. Probably too much hassle, though.
Permanently Deleted
I've used Squirrel a bit ages ago and it worked quite well. Similar to Lua, but OOP and more C-style syntax.
I'm surprised Lua isn't working out for you, though. It seems like such a simple language. Although I just admit I've never used it before.
The main issue with Lua isn't the language, but the API, which doesn't want to play nice with my program, and is poorly documented with the assumption that people only want to use the API in the simplest possible way, even at the cost of not using certain functionality.