Than started to move alot of heavy logic to c++ simulation : tedious indeed but the results speak for themself.
Basically allows me to use godot for things like menus dialogues and similar stuff while running the true heavy work in a c++ simulation.
The other reason is that in my well closer circle i got quite some people that code c++ on a daily basis and i don't know (at least i think so) anyone doin C# actively, so i thought if i would get stuck i have people i can easily ask about my c++ problems.
So it wasn't a "i think c++ is better than c#" decision rather a what do i know and what resources i have available easily.
If you look more at Stride, you’ll see that even their physics engine is C# which is insane in the best possible way: https://doc.stride3d.net/4.3/en/Manual/physics/index.html and https://github.com/bepu/bepuphysics2
Very cool language and as much of a mainstay in gamedev like something like Lua.
It surprises me that Java never got similarly big despite their GC improvements, though jMonkeyEngine was a nice project last I looked.
The catch was that you had to use C# and XNA (which was a wrapper for gaming related APIs like DirectX, XAudio and XInput, generally considered to be very good). This meant there were a lot of hardcore libs made for C# gamedev (BEPU physics is from that era, and there were things like very good UI frameworks).
Tons of games were made with XNA, and its open source ofshoots, MonoGame and FNA power some of the greatest indie hits (Stardew Valley, Celeste, Bastion and other Supergiant titles, Terraria come to mind).
Imo this is one of the main reasons Unity went with C# in the first place.
https://en.wikipedia.org/wiki/Arena_Wars
C# being closer to C++, and .NET having direct support for C++ helped quite a bit regarding adoption among game studios.
Unity started on Mac, and they only adopted .NET when doing the cross platform rewrite.
I also don't remember if there wasn't some Mono advocacy at the time, as they became customers in the process.
Ironically Mono/Xamarin is almost gone from official .NET, all these years after the acquisition, with every modern .NET release, another bit falls off.
We are already on the phase that CoreCLR might take the remaining bits.
the hierarchy and physics api isn’t great either, it’s easy to hit heap allocs even from a gdextension
a lot of things wrong with this generic engine, but at least it’s lightweight
I would argue that even if Bevy was ready for production it would not really compete with Godot.
Godot's performance is plenty for the vast majority of small to medium games. Plus they're starting to work on features like texture streaming for bigger games. It also has an editor which is a big plus for most teams.
Bevy would be objectively better for expensive CPU simulation stuff but realistically what percentage of games need that? Maybe 1%?
For Bevy to catch up on the indie game scene it needs an editor plus a scripting language and/or something like Unreal Blueprints. If it only wants to target the hardcore Rust dev that does everything by code it will never go mainstream.
Godot gives GDScript simplicity for the vast majority of use cases which is that iteration boon, provides C# for games that need the additional guardrails. For performance critical game scripts you can just jump to C++, Rust, Swift, etc.
But most game scripts are not performance critical. Clair Obscur: Expedition 33 swept the game awards last year as an Unreal Engine game made using almost entirely visual scripting (blueprints).
Maybe it's the "ancient" part, because more recent is always better ;)
Starting with absolutely nothing but a compiler is always going to be a worse experience (and less likely to result in anything released) than a GUI-driven and aided solution. If Defold developers had produced a fraction of the libraries that Godot has, it might have had a chance. As of now, it's worse than other abandoned engines like Solar2D (was CoronaSDK) for people entering the space. As most people know, the vast majority of games are net-losses, so engines live and die by the ease of adoption by newcomers.
A lot of people complain about OOP, but it's a paradigm very well suited for rapid development.
Seems like carrying a lot of Godot baggage around for nothing.
Also, I am not sure about how easy it is to build binaries using SFML for various platforms (such as WASM), but with Godot you just have to download the right template.
Also .NET integration has the issue it doesn't work in all target platforms, that is why Capcom and Unity have their own compilers to native code. Even when Unity finally adopts modern .NET, Native AOT naturally doesn't cover game consoles.
.NET can generate the code, but your game won't pass certification if it runs machine code generated by something other than the officially provided C/C++ tool chain.
They have their own in-house fork of modern .NET, integrated into RE:Engine.
So, is a zero-copy impossible due to world (C++ vs Godot) boundaries?
A bit tedious but that's how it goes.
I’m not familiar with distributing godot games. If I build a game to distribute on steam (for example) would this be an option? Or is a GDExtension (runtime loaded .so) the standard way to go?
That being said, this has no impact on distribution either way as far as I know.
If the API is c++ based you have to statically link it to the engine since the chosen c++ runtime is statically linked to the engine binaries.
You cannot ship as a shared c++ runtime since it would conflict with a possible version installed on the user distro (version of the gcc libstdc++, version of the clang runtime, intel?, or none see below).
To avoid c++ ABI issues, distros may statically link their c++ runtimes (clang[c++ and compiler versions]/gcc[c++ and compiler and versions]/intel[c++ and compiler versions]/etc)... if they need any (and the new c++ to C transpiler may have some significant impact in the near future).
(BTW, is the c++ intel compiler still shipping??)
If the API is "C" based (aka core platform ABI), no issue, just statically load only the common glibc libs (ELF DT_NEED entries) and dynamically load (libdl/dlopen/dlsym/dlclose) everything else (private libs, or system interface shared libs), and you are good to ship. A word though: wayland code with its libxkbcommon are statically linked, do not reproduce the same mistakes than with x11).
This is required for broad distro support [and long term support].
Basically, game binaries should be "-static-libgcc -static-libstdc++ --enable-new-dtags" everywhere, statically load _ONLY_ common glibc libs (and with "old" symbol versions, see binutils ld documentation, the 2nd part of the VERSION documentation page), and dynamically load everything else.
I have been inspecting many recent godot4 games on steam: all had "correct" binaries to maximize broad distro loading support on the long run.
The current issues: some games are written in microsoft rust which toolchain is still unable to statically link libgcc (see tinyglade game). Or some unity versions which "forgot" the '-static-libgcc' compiling/linking options, and even forgot to statically link their libz Oo.
If valve could do just that with the binaries of their client and their games... They can keep their 'runtimes' for old broken games but should have 'correct' binaries for everything else on their side (and valve still has to port the final 32bits reaper command to 64bits for clean 64bits support, hopefully I did not miss other 32bits binaries). Forcing distros to compile that user namespace in their linux kernel is quite "inappropriate", better keep that optional for those broken games only.
If your API is C based (or core platform ABI), and you should design such API for interop with any framework anyway, you can ship a shared lib (but it has to statically load only the common glibc libs, and that with "old" symbol versions, and the other things too, see my previous post).