Modding: Lua scripting implementation

[XenonLab-Studio]

Flare Engine is awesome! but making a project using .ini files is not very convenient. Flare is a project inspired by the first Diablo, which uses 2D graphics, written in C++, so to make modding easier and more comfortable (even to distribute one's projects to the community), it's a good idea to implement Lua. There are some important things, in my opinion, to consider:

• Develop a simple API that uses functional procedural programming without an oop hybrid (it serves absolutely nothing, only to make things complicated).

• Every action, movement, event can be easily managed through pre-built functions where the user enters parameters related to coordinates, variables to define time, speed, amount of exp for level up, parameters for items, weapons, armor, and more.

• Implementing Lua does not compromise the current modding system. When the new APIs for Lua are complete and tested, the current modding system is replaced with the new one. For the current mods I think it's easy to port from .ini to Lua. In practice it is the same system, only that it is simpler, more comfortable and definitely more useful for making games that take advantage of this engine, don't you think?

• Implementing Lua allows you to take advantage of new Flare engine features, simplify gui customization, button placement, game title and more. In addition to this, you can extend the APIs in the future by keeping the main engine separate with the mods. The documentation will be easier because currently the system with .ini files is purely mnemonic, while with Lua we can make extensions for vscode, ZeroBrain Studio and other text editors and ide (for vscode I can do it myself, for ZeroBrane Studio also).

Have you already thought about this possibility? according to me it would also increase the performance, I noticed that starting a new game with Empyrean campaign the game tends to hang for 2 seconds before showing the initial level (maybe it is solvable with a pre-loading of the resources?).

I'd be curious to read your opinion. I have been following the project for years, and in the past I have also contributed to the project. I would like to dedicate myself to creating my game based on a fantasy story that I wrote years ago.

Thanks to all of you, and a big hello to Dorkster ;)

[dorkster]

FYI, some discussion on introducing a script layer (Lua or otherwise) to Flare can be found here.

Scripting would indeed open up a lot of possibilities for modders. It's true that the current Flare configuration is very specialized, and each file sort of lives in its own island. A more generic scripting system could introduce some interoperability to the system.

Of course, there are pros and cons. Starting with the cons, Lua is another dependency for the engine. I think the desktop releases would be fine, but what about the Android and Emscripten ports? Also, there's no way it would be faster than the existing pure C++ engine. The only speed gain I can think of would be the lack of integer math, as modern cpus are generally better with floating point math. But there's nothing stopping us from switching to all floats across the C++ codebase, either. Granted, most if not all of the speed-critical code will remain C++, anyway.

One good point you brought up is the idea of having the Lua layer in parallel with the existing modding system. I think most of the talk so far has been about completely tossing the old API and starting from scratch, which is unrealistic. I think a good way to start introducing a script layer would be to take one part of the engine (maybe a menu?) and make it so that all the initialization & logic is controlled by a Lua script. The script would re-implement the existing behavior, right down to loading the settings from the INI file. These shims could be put together as a compatibility layer for when the engine doesn't load any INI files itself. That way, old mods could still work with the new system while allowing new games to bypass loading any INI file altogether.

---

I noticed that starting a new game with Empyrean campaign the game tends to hang for 2 seconds before showing the initial level (maybe it is solvable with a pre-loading of the resources?)

That pause is definitely due to loading resources. Flare is single-threaded, so when a resource is being loaded, the engine logic is blocked. Making resource loading multi-threaded would probably be the biggest gain here. Disk access is some of the time spent, but there is also conversion done with the CPU when the files are loaded.

[XenonLab-Studio]

@dorkster Thank you for your dorkster answer, you are as kind as I remembered you.

Lua is a very small language, a language designed to be embedded and therefore to be integrated in one's own projects (interpete and compiler are about 350 kb in total). For android I have no experience but I think it's not a problem with Lua, for android you used wrappers (I assume) because the project is designed for desktops.

Lua is really very small, fast and allows it to be shaped completely.

additional dependencies? the Lua library (liblua, really a few kb, and ease of use even when compiling for users). The flare engine is in procedural C++, which makes it pleasant and easy to understand. The only addiction is SDL2 so I don't think it's a Lua problem. No other dependencies are needed for this project.

For multi-threaded I guess it's more delicate (rewriting much of the code using sdl2?).

If that's okay with you, contact two developers I know who are interested in my idea. Together with them I defined the first design phases to create a simple and well integrated API.

I'm in contact with artists and developers, because many users don't know about flare engines, and some believe it's the 3-year-old project. So I contacted people interested in donating artistic content (permissive licenses, possibility of modifications, distribution and more, creative commons, artistic and other similar licenses).

In addition to this I am updating the "polymorphable" mod, abandoned for years but extremely beautiful and interesting. I use it to experiment with ideas and make it complete and usable even with future versions. it's a real shame to see some good work thrown away.

I also went off-topic, but I had no other place to write you everything. Thank you so much.

[dorkster]

I don't doubt that Lua is small and possible of being fast. On Android, Flare is built with the Android NDK as a native C++ app. I think AndroLua could be the solution for getting Lua working with an NDK C++ app. I don't think there's such a solution for Emscripten, but maybe we could just drop the whole interpreter into our project. It's MIT licensed and small enough, so we could do that, and likely support building Flare with an external Lua lib.

---

Multi-threading is a whole other can of worms. Personally, I think the load times in Flare are fast enough, so I'd rather avoid the added complexity.

---

As for contributing art, all that's required is that it's compatible with CC-BY-SA 3.0 (i.e. the same or more permissive). Of course, keep in mind that the art included with Flare is curated based on how well it fits with our style/vision/etc.

[ernierasta]

I would love to see HDcore (or even fullhd) mod to be taken into account if new assets are created.

IMHO lua scripting would be great and f.e. enemy/NPC AI would benefit from it. There are few examples how it could be implemented, but as for game close to Flare - Sulis (it is written in Rust) has done it well IMO.

[XenonLab-Studio]

We have a modding system that uses .ini files, with Lua it would be interesting to create a data-driven modding system? you have the game framework "orx engine" written in C, which uses .ini files to define the behavior of all objects in your 2d game, while C is used only to define and call functions, variables and more. It greatly simplifies resource management (pre-loaded), and makes everything decidedly intuitive. I hadn't thought of this, it should also simplify the implementation in Lua and the new scripting system, because the management of mods through .ini files is already existing in flare, so the new API in Lua will be very small, simple and easy to use for everyone.

I am in the testing phase, I want to experiment with some things I have noted.

For the use of Flare maps use .tmx (Tiled) files, this editor can export the description of the maps in various ways, even in Lua and JSON code, this probably makes things easier and lightens the loading of resources? load the maps in .tmx format which is however a data description file, but with the exported Lua code I can make LuaJIT go to process all the code of my mod, increasing the performance and making everything more logical and orderly.

The important thing is to define the work well, make it easy for everyone, and write the documentation at every stage of design to ensure complete learning material and also addressed to designers, enthusiasts and not just to experienced programmers.

@dorkster Well! AndroLua, I did not know this project, but as I wrote above I already knew that there was a wrapper, a library, or anything magical that could do for us.

Emscripten is the right port for the web? but Flare with Emscripten has decidedly low performance, I personally believe that Flare Engine has great potential for use on desktop and mobile platforms. How many game engines are there dedicated to designing Diablo inspired RPGs? nobody! this is what makes this project fantastic, really well done, and with endless possibilities.