i spent aprox 160hrs learning the newest version of godot (3.2) using c#.
It's pretty well featured for hobby projects and experimenting. You can translate any GDScript example into C# on nearly a 1:1 basis. So honestly "C# docs" are not needed.
The big turn off for me, which I only came to the realization after my 160hrs, is that there is no easy way to performance analyze/tune your code. You have to manually instrument with Timers and even that is of limited utility when you have unknown 15ms+ spikes every couple seconds (and that's not even GC related).
My desire getting into Godot was to build a job/ecs system similar to unity (because I did this 10yrs before with my own xna based engine) but sadly, until there is better perf tools this is a futile task.
yes, it's a C# system, though it's written for the .net framework 2.1, and assumes a desktop so care isn't taken to reduce GC pressure very much. The unity job system is based on structs and unmanaged memory to avoid GC pressure, which in hindsight is a good idea for targeting broader platforms (phones, embedded)
It's pretty well featured for hobby projects and experimenting. You can translate any GDScript example into C# on nearly a 1:1 basis. So honestly "C# docs" are not needed.
The big turn off for me, which I only came to the realization after my 160hrs, is that there is no easy way to performance analyze/tune your code. You have to manually instrument with Timers and even that is of limited utility when you have unknown 15ms+ spikes every couple seconds (and that's not even GC related).
My desire getting into Godot was to build a job/ecs system similar to unity (because I did this 10yrs before with my own xna based engine) but sadly, until there is better perf tools this is a futile task.