> The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me.

As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive the behavior.

This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints.

But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.

It's such a bizarro world after a bunch of UE discussions to suddenly see people dismiss scripting concerns with "well just write that code in C++. Blueprints is slow". I'm usually the one saying that, but that's as a professional developer who needs to optimize all that stuff (and TBH the blueprint code tends to have some bad performance choices even before discussing the BP perf loss).

Hearing people dismiss the performance of something as basic as a raycast with "well just code in C++", while many people (including this founder) say that Godot focuses on simplicity sounds counter-intuitive. So is GDScript a lie for anything slightly intensive (and again, raycast. I'm using "intense" in the loosest of words) and I should simply make my whole game an engine module? But I keep hearing that "I should just try GDScript it's really easy and you come around to it!"

Feels like a motte and bailey.

What i wrote wasn't making your whole game an engine module (i.e. writing everything in C++) but writing your intensive code in C++ and using scripting (be it blueprints, GDScript or whatever) to drive that intensive code.

There is nothing counterintutive in that, it is right in the name of scripting languages: they're meant to script behavior.

And the dismissal isn't about having a raycast being slow, but about using too many raycast queries in script to do something reusable that should be in native code in the first place. If your scripting language ends up in your performance profile chances are you are using it wrong.

The occasional raycast query in scripts to make a decision is fine, doing thousands of individual raycast queries from scripts is not - if nothing else, make an API that accepts multiple raycast queries at once, performs it in C++ in a single call (so you only get the scripting overhead for that single call) and gives the result back.

But IMO if, as mentioned in the article, you are going to make a controller that is to be used by multiple entities in the game, then you should make it in C++ - potentially with script hooks to customize the behavior, if needed.

What i wrote isn't that you can't write C++ in Unity, what i wrote was that you do not have the C++ source for Unity that would help you address performance issues. Since you mentioned UE blueprints, i have worked with UE and faced the need for better performance: being able to have (and modify) the C++ source (including the blueprint VM and codegen) code was something that helped and at the same time being able to turn blueprints to C++ wasn't a panacea nor the performance was anything close to what you'd get with writing the code in proper C++ in the first place (which is what we ended up doing for some parts).

Tight loops mean:develope one specialized function call which gets a field of data and works on it.. Resurfacing after the job is done.

You may even invert direction, handing over a pure script language function (no context) + the data, so the c++ engine may crunch the data at least in parallel small script vms without stack, similar to a shader.