[roflcopter69]

Isn't Godot kinda flawed for deploying to the web? For example, no C# as of now, although there have been plenty of efforts to make it work. Or AFAIU audio being forced to stay in the main thread which can cause glitches. I just mean that it's not all fun and games as soon as you want to make a more ambitious game and not just a quick demo or game jam thingy.

[LandenLove]

I found GDScript to be quite powerful in terms of functionality. I don't have experience in professional game Dev to be aware of the benefits of C# beyond it being the industry standard for Unity.

Single threaded audio is a big concern. I haven't implemented music in my game yet to know if it is a deal breaker.

The main problem that I have run into is shader compilation stutters on the compatibility render. Makes the game basically unplayable. My work around was to spawn certain objects on the main menu out of sight to force compilation. I believe the forward renderer has some pre-compilation.

[roflcopter69]

Of course it's a matter of perspective and I can totally get how one would be happy with GDScript. Tbh, it's hard to beat GDScript when it comes to making small games. It's quite evident that only GDScript has first-class integration into the Editor, C# comes second and all the other serious language bindings come third.

I might state the obvious here, but static typing, null-safety, being able to refactor and such things make C# much much better for bigger games. Slay the Spire 2 has been made with Godot + C# and people have already decompiled and peeked under the hood (for example here https://www.youtube.com/watch?v=SpB4-W9L4ec) and imo it shows quite well how certain patterns simply require a more powerful language than GDScript or would at least be very painful and fragile to make in GDScript.

Your workaround for shader stuttering sounds quite hilarious :D I don't mean it's bad. It seems pragmatic in a good sense. But yeah, it's those limitations that pile up when making Godot target the web...

[tancop]

gdscript is missing basic features like interfaces (only abstract classes with no multiple inheritance) or custom value types. spawning scenes from code is tricky and not type safe. asset loading and globals are a mess. the engine is built around using a lot of nodes but nodes are expensive, so you need to drop down to confusing low level server apis if you have performance issues.

the worst part is theres no defined build step so `@tool` scripts run both in the editor and at export time. its easy to accidentally crash the editor or mess up your scene with a bad editor script missing one line of code. and as far as i remember its impossible to undo so remember to save often.

godot is still the best option if you want a open source engine for your game but only because bevy is not production ready yet.

[tapoxi]

Godot 3.x supports C# on the web because it uses Mono.

Godot 4.x migrated to CoreCLR since Mono is a dead end, but Microsoft insists on .NET being the entrypoint in a WASM build. MS initially promised support for .NET being invoked by something else but dropped the feature, leaving Godot stranded. The current proposal is to make Godot a library (libgodot) invoked by .NET.