Thoughts on adding a second modding language Lua (luajit)

[leitoso]

Hi !

I am considering introducing Lua (luajit) as a second modding language, alongside JavaScript. Here’s why:

• performance: Lua is fast, especially for CPU-heavy mods (AI, simulations, etc.), which is critical for large-scale RTS battles.
• simplicity: Lua’s lightweight syntax and C/C++ integration make it easier to expose engine features directly to modders.
• ecosystem: Lua is widely used in gaming (e.g., World of Warcraft, Roblox) and has robust tooling for debugging and profiling.
• sandboxing: Lua’s simplicity allows for tighter security controls, reducing risks of crashes or exploits.

this isn’t a replacement for JavaScript.

javascript mods will continue to work! The goal is to add options, not remove them. Lua could become the preferred language for performance-critical mods, while JS remains great for UI/scripted events.

what this means for modders:

• gradual rollout: Lua support would be phased in, starting with experimental access to core APIs.
• tooling: we'd provide Lua-specific documentation, debuggers, and compatibility layers for JS ↔ Lua interop.

points for discussion:

• are there existing JS workflows we would struggle to replicate in Lua?
• is there any other integrations like this one done in the past or abandoned we have notice of, can we learn from it ?
• where to start, is there any tips for a unexperienced 0ad "core" dev like me or others wanting to help that we can start learning from ?
• other topics of discussion ... please feel free to add and help ?

[Seleucids]

There is some JavaScript logic going on in gui and simulation/ components folders. They work by calling exposed JS functions in the engine, which are defined in a script interface.cpp in the engine source code. 

To implement lua, we probably need to change the definitions in scripting.cpp to adapt for lua calls. Then the mods side js needs to be replaced with lua language.

A solution to not overwite completely is to add a parallel list of exposed lua functions at the end of the current scripting.cpp file then call them using lua scripts in the mod folder where necessary 

[Genava55]

 

Edited April 21 by Genava55

[Genava55]

2 hours ago, leitoso said:

Lua could become the preferred language for performance-critical mods, while JS remains great for UI/scripted events.

Is JavaScript really the bottleneck? Are there specific cases where JavaScript is the definite cause of a lack of performance in a mod?

[Deicide4u]

14 minutes ago, Genava55 said:

Is JavaScript really the bottleneck? 

In my experience in games vs the AI, I don't think it is. On medium and above difficulties, the AI is strong if left unchecked.

That said, I'm mostly playing 1vs1 games. Not sure how performant would team games be.

[leitoso]

20 hours ago, Genava55 said:

 

thanks for this reference @Genava55, I think I have read in the past, looking now I see the same stuff, correct me if am I wrong, but it was basically a developers preference of language, which I agree in part, but the simplicity of Lua is so good that we can build our own conventions, and the scripting part of a game should be simpler, not a bloated object language like JS, and now TS which build complexity over the top of things.

I like the remark of @Stan` 

Quote

Yeah it was said that JS could handle 230 calls in a turn LUA 550 and c++ 8000

and I believe he is talking about vanilla Lua, luajit I believe could be more closer to c/c++ performance once optimized and jit enabled.

as you were talking about bottleneck, I cant see any with proof in hands but I see a lot of issues with 0ad open for hours and you start to see a lot of memory issues and warnings popping out in the logs, idk for sure if it is related to JS integration and leaking stuff but I think in the long run Lua could be more lighter and well rounded with memory and stuff - ffs Lua source and documentation is a little over 1 mb hehehe

but I think I will finish my remarks about language wars here, I was much more interested in push a support for Lua in the "core" and these others things we can discuss in the future when we have more material proof to discuss.

thanks @Seleucidsfor the tips, I will start there and put remarks and failures here so we can proceed with development

thanks !

[Stan`]

1 hour ago, leitoso said:

and I believe he is talking about vanilla Lua, luajit I believe could be more closer to c/c++ performance once optimized and jit enabled.

Indeed, luajit did not exist at the time. Might have some more info here too
 

There are some gains to be had with better datastructures https://code.wildfiregames.com/D1739  and more threading => https://gitea.wildfiregames.com/0ad/0ad/issues/5874

There are about 100k loc of JS and rewriting them would be a huge undertaking (Source I tried)

But there is no silver bullet the reason js is slow is that there is a lot of computations happening at the same time, iirc gathering and the attack logic were the worst offenders.

You can probably find some recent js profiling in gitea. And you can run the game under perf to see hotpath, IIRC one of the thing we spend the most time is rbtree_increment which is just a std::map code. There is also the ISQRT function, which performs fixed point square root computations. (That can't be replaced easily, else the game will quickly go out of sync on many platforms)

EDIT: One of the big advantages I see about JS is that a lot of people know it. Whereas lua is a niche language unless you're a gamedev. There are many JS crash courses. Lua not so much.

[sarcoma]

Great idea, leitoso.
Luanti is a good example of a c++ engine with Lua modding interface.
https://docs.luanti.org/for-engine-devs/script-engine/

[Genava55]

1 hour ago, leitoso said:

but I see a lot of issues with 0ad open for hours and you start to see a lot of memory issues and warnings popping out in the logs

This issue could happen with LuaJIT as well no? It uses a garbage collector too. Although it is right there is a limitation per process.

43 minutes ago, Stan` said:

Indeed, luajit did not exist at the time. Might have some more info here too

LuaJIT also had issues with memory limitations and 64bit adresses in the past. It became mature only recently.

49 minutes ago, Stan` said:

There are some gains to be had with better datastructures https://code.wildfiregames.com/D1739  and more threading => https://gitea.wildfiregames.com/0ad/0ad/issues/5874

I know web-browsers and a few web apps are putting a lot of energy into WebAssembly. Is there any consideration for AssemblyScript to speed up a few calculations without removing the whole easy-to-mod philosophy?

[Stan`]

 

 

18 minutes ago, Genava55 said:

I know web-browsers and a few web apps are putting a lot of energy into WebAssembly. Is there any consideration for AssemblyScript to speed up a few calculations without removing the whole easy-to-mod philosophy?

Hmm strange I thought I linked the POC by wraitii for WASM. The problem is while it would speed up some of the code the bottleneck is the interrop between JS and C++ and WASM takes the same time.

https://code.wildfiregames.com/D4653

18 minutes ago, Genava55 said:

LuaJIT also had issues with memory limitations and 64bit adresses in the past. It became mature only recently.

I've also heard packagers complaining about LUA being a pain, not sure why (probably not worse than spidermonkey) maybe @vv221 would know.

 

[wraitii]

Overall a 2x faster scripting language wouldn't really "fix" the game - some of it is overhead, but most of the time is spent in C++.
 

WASM is interesting, but unfortunately not actually super easy to use. I'd rather not do assembly script but write in some other compiled language for it tbh.

[asterix]

On 22/04/2025 at 2:38 PM, Stan` said:

I've also heard packagers complaining about LUA being a pain, not sure why (probably not worse than spidermonkey) maybe @vv221 would know.

As one of the examples see discussion in Gimp issue https://gitlab.gnome.org/GNOME/gimp/-/issues/11895#note_2225885 , what are the main packaging problems.

[Stan`]

Hmm those benchmarks are interesting https://programming-language-benchmarks.vercel.app/lua-vs-javascript they look a bit the same as the ones that were used to choose the language.