This is the Godot way of doing it. It encourages just getting your hands dirty if you need the engine to do something very specific. The architecture is made with the understanding that you eventually want to transition from script implementations to native ones, but that you'll ship with the game being somewhere in between. And the architecture has been set up with generous amounts of glue(which is the overhead encountered in OP) to make the transition uneventful.

And while it's desirable to optimize the glue and make scripting fast, that's also a much larger engineering project; Unity did it by spending big.

You don't need to spend big though to address the issues author highlighted.

Pretty straightforward API changes. After a design is decided on just some tedious typing work. Heck, it could be dog piled easy enough.

C# strikes the balance between speed and dynamic features IMHO. Especially for games that need mod support (which is not that uncommon at all), using C# allows for the modders to easily interface with existing code, while still getting near-native performance thanks to the type system and JIT. C++ code in such case would be too rigid to be modified and hard to interface wth.

>if I ever need performance I'll probably just go straight for C++.

if that's my go to solution, why am I using Godot instead of Unreal? Or even a more mature C++ renderer framework like bgfx, or even Ogre3D? In the context of a decent 3D game, I'll need that performance the lion's share of the time, only scripting to move GO's/Actors around the scene.

> if that's my go to solution, why am I using Godot instead of Unreal?

No revenue split would probably the biggest reason. Also Unreal could still pull a Unity since it is not FOSS (unlikely, but still).

Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.

> even a more mature C++ renderer framework like bgfx, or even Ogre3D?

IMO this is actually the way to go & it is probably the way I'd do it if I had the time to build editor-like tools by myself. But these days content is the hard & time-consuming part of building games. Which means you want non-coder gamedev to be able to do as much as they can, which implies a powerful editor. Godot & Unity have the advantage of pushing the game development to the editor instead of the code.

>Godot & Unity have the advantage of pushing the game development to the editor instead of the code.

Indeed, but even Unity isn't known for its high performance 3D titles. It COULD viable do them, but not without a lot of work.

That was supposed to be something that DOTS would address, to take out "a lot of work" and make that performance almost be taken for granted. But... well, I don't want to go on that rant again. You can excuse some performance and optimize later, but the sounds of things from this article (with general sentiments even from diehard Godot fans that Godot isn't ready or serious 3D development) makes it sound like that optimizing will in fact exceed the content creation time.

I've seen enough of the guts to know that Godot will likely never make its own DOTS. At least, not its own Burst compiler to get around the c# issues. Likely not IL2CPP either. Fortunately, you don't need that and can get maybe 80% of the performance by simply following some data oriented principles. More than enough for all but the most lofty AAA games (think GTA6 levels of scale).

----

>Mind you, Godot people are working on optimizing engine performance (see my other comment) because they kind of rushed Godot 4 release.

that's good to hear, and I get it (Unity rushed out tons of features itself. Including DOTS). I hope I can one day contribute to that effort myself. Would make my future game dev life much easier and would be a good way to give back.

The author of the article seems to say that even the c++ api version is a heap allocated dictionary, so you would still take the perf hit

Except that is the whole point of languages like C#, being able to be productive in high level code, and not needing to write C++ when performance is called for by providing all the features for low level code, unless in very niche caches where those features still aren't enough.

I think this is correct... you can even go with Rust instead of C++