Hacker News Reader

Comment by charlieyu1 | Hacker News Reader

Now I’m curious how a game engine can handle the performance penalty of using a dynamic typed language

I'm going to ask a different question: so what if it doesn't handle it? Some of the hardware resources would be spent on dynamic shenanigans instead of the actual game content. In contrast a game running on the same hardware but implemented in C++ would be able to handle/offer more of the content of the game.

But then again 5 years ago hardware was worse; 10 years ago even worse; 20 etc etc. Games had less content but there were still good games, as good as modern ones. Game enjoyability doesn't depend that much on the scale of its content. If a dynamic language pulls the resources down to what they were 5-10 years ago you can still make enjoyable games.

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.

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.

Judging by Godot and the few other dynamically typed languages and how performance isn't much of a concern with them, apparently its not much of a penalty.

That being said, for peace of mind, I do wish engines like Godot had chosen a strongly typed language. I use Godot myself and much prefer it to other engines I've used, but I can't shake the feeling the GDScript sacrifices performance for ease of learning, even if it happens to not be true. I know theres Godot C# as well but that still doesn't feel like first class supported, though maybe I'm wrong

let me tell you about how we used to type in listings from magazines back in the 80s

Lua has been used in games for decades

Also, I didn't think "In microStudio, the core language is JavaScript and JavaScript in the browser is insanely fast." statements like this were true, but hey.

Reply on news.ycombinator.com