On the subject of dropping Lua as a scripting engine


Due to difficulties with getting Lua to cooperate with D, such as:

  • values getting zeroed out in the interfacing functions for unknown reasons, 
  • Lua's documentation assuming you want to use the simplest solutions for everything and not telling you how to do things in the more complicated ways even at cost of loss of functionality, 
  • and now even a problem that was hard to track down due to the assumption of "it just should work" mentality wasn't documented reappeared (or at least a similar problem appeared),

I have decided to drop Lua as the main scripting language for the game engine, with no immediate replacement planned.

My options are:

  • Wait until the more friendly Lua binding to D updates its Lua support to 5.4, as 5.1 does not have integer support, which is needed for my game engine.
  • Look for some workable alternative, then write a binding for it.
  • Port the whole Lua library to D in its barely documented glory.
  • Write a new scripting engine from the ground up, which I've attempted in the past, but dropped due to lack of time.

I have nothing against Lua as a language. It's very well designed. I can't say the same thing about its stack-based ABI, which caused me the most headaches. If there were more C/C++ (or even a D) implementations of this language...

My closest other option currently is pkpy, which is a lightweight Python implementation, however it's a C++ header, which would complicate the build process at its best, and would contain multiple inheritance at worst (a thing D's C++ API isn't very happy with). However any other replacement candidate should follow the following criteria:

  • Small in footprint, since I don't want to include a 25+MB scripting library with all sorts of included standard libraries.
  • Have integer support as my engine depend on it. Yes, I've heard about rounding. I also heard about rounding errors and not being able to write in hexadecimal numbers (very useful). Using strings to handle integer and hexadecimal values is called software jank.
  • Must be able to be embedded into the engine with the proper C/C++ ABI way. Using files and/or command lines to pass data between an application is not only extremely janky, but is near unfeasible for real time applications like games.
  • Must be open source, but not the GPL kind.
  • Does not overcomplicate the build process. Dub is the best and most usable package manager/build tool so far, every other one suffer greatly from lack of usability.

Get PixelPerfectEngine

Leave a comment

Log in with itch.io to leave a comment.