3 ms·

It's a few things really, dynamic languages have been used for a very long time. Even early computers had a bunch of games that ran on interpreters. * Computer

It's a few things really, dynamic languages have been used for a very long time. Even early computers had a bunch of games that ran on interpreters. * Computers are really, really fast. If you're not deliberately or unintentionally slowing them down even a dynamic language can do an awful lot of work. * JIT compilation is really good for a couple of languages. LuaJIT has been a popular embedded language for games for that reason for a while. JS JITs are also pretty incredible. * They're most commonly used for gameplay code which tends not to be the performance bottleneck of a game engine anyway. Where it is you usually have great interop and just rewrite the offending code in the native language. The interesting choice here is to run interpreter(s) on top of what seems to be a JavaScript (compiled from CoffeeScript) based engine. Although it does look like they want to translate the microScript code to JS.

ufo 5y ago
For game engines, point #3 is the most important. JIT compilers tend to do better when the entire codebase is in the same language, because they can't optimize code that is written in C/C++, and have a harder time optimizing code that calls C/C++. However, this is exactly the sort of thing at the core of a game engine. Another thing is that when making games a scripting language can be easier to use by members of the team who may be good at game design but not good at programming in C++. It is also convenient to be able to edit the scripts without needing to recompile and restart the game. In the case of Lua, one thing that makes it popular for games is that it is very small and also easy to embed. It was designed for ease of embedding.