Hacker News Reader

Comment by LandenLove | Hacker News Reader

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.

View on HN

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...

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.

What does your crystal ball say, when will bevy be production ready? And when will we see the first bevy game be ported to consoles?

Reply on news.ycombinator.com