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.

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 I've also heard packagers complaining about LUA being a pain, not sure why (probably not worse than spidermonkey) maybe @vv221 would know.  

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. LuaJIT also had issues with memory limitations and 64bit adresses in the past. It became mature only recently. 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?

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/

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.

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`  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 !

DE has player colored hero icons IIRC.