4 ms·

Stride has a fraction of the features as unity. Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless

Stride has a fraction of the features as unity. Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries. A real sandbox solution with actual GPU support is needed.

eole666 10mo ago
Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125 https://github.com/godotengine/godot/pull/106125
- 999900000999 10mo ago
  We'll see when it actually ships. I've seen this issue before, they're making progress but theirs no firm release date. Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.
  - ramon156 10mo ago
    Naive question but why not use GDscript? I haven't had any issues with it
    - 999900000999 10mo ago
      I'll vibe code stuff in GDscript, and I guess I more or less understand some of it. But C# is what I've used for over a decade. C# has vastly better IDE support. It's a more complete language. Plus a lot of C# assets/libraries don't really have GDScript counterparts.
    - eole666 10mo ago
      I'll add that C# have better performances than gdscript. It doesn't make a difference for most of the things you code in a game, but it comes in handy when needed.
      - runevault 10mo ago
        I'd caveat this slightly as "it depends" For mathy stuff, 100% c# is going to be better. But if you need to round trip to the engine a lot getting stuff in and out of the dotnet heap can actually hurt performance. You also have to be _really_ careful because there are a lot of cases you generate accidental garbage (biggest one is when you use strings that are getting implicitly converted to StringNames every time you run a function, you can avoid this by pre-generating them as consts but I've run into a fair few people who never ran dotmemory or the like to see the issues).
        eole666 10mo ago
        Yes, it tooks me 2 years to see how much garbage strings conversion to String Names generates and how a fool I was calling something like Input.IsActionPressed("move_right") every frame (sadly it's the example given in the input documentation).
        runevault 10mo ago
        Yup. I remember running dotmemory on a whim and being confused by all the stringnames until I noticed what was in them. They really should put that in the docs to just make a const stringname somewhere. I use a global static class for anything I want in multiple files. But I also tend to just use statics instead of autoloads if I'm doing everything in c#.
dustbunny 10mo ago
Writing C# in godot is a bad choice. Use GDScript and directly write c++ as a module. Skip "HD extension" completely. Godots build system is easy enough to use. Just add new classes to the engine using c++ if you don't want to use GDScript. The GDScript workflow is honestly great. Using C# is like the worst of all worlds.
- 999900000999 10mo ago
  I don't like C++. It's very difficult to me, I generally stick to high level stuff , C#, JavaScript, Python, Dart, etc.
  - chris_wot 10mo ago
    If you can code in C#, how is C++ difficult? Are pointers and the stl that difficult? Not denigrating, genuine question.
    - 999900000999 10mo ago
      One word. Headers. That's just the start. The C++ build system and package managers are the stuff if nightmares. Modern languages are significantly easier to use. Don't get me wrong, if you offer a job with a 200k base salary and give me 6 months to learn C++ I'll do it. But I won't enjoy it, and I definitely won't do it as a hobby.
      - runevault 10mo ago
        If you use an existing template (and are willing to use scons) GDExtension doesn't really have the standard build problems of rigging everything up with CMake/etc in my experience. The template is set up to handle the "set up the build" problem for you. Still have the header problem though cannot deny that one.
    - DonHopkins 10mo ago
      Java was designed to make fun of C++, then C# was designed to make fun of Java, so you're missing two layers of fun.
CyanLite2 10mo ago
I think WebAssembly could become that sandboxed solution. .NET Blazor WASM is moving away from mono to CoreCLR (just like Unity, with an early preview in late 2026). WASM now has really good SIMD support, native GC, large memory support, and with WebGPU we could finally see some native WASM games running at native speeds.
- bloomca 10mo ago
  Wait, what, WASM has native GC now?
  - WorldMaker 10mo ago
    It's still not JS-level/JS-compatible GC (yet?) and it is still quite low level (more about corralling buffers of bytes than objects, a bit closer to OS-level page management than JS or C# level GC), as it is intended to be lower level than most languages need so that different languages can build different things with it. It is also a tiny stepping stone to better memory sharing with JS APIs (and the eventual goal of WASM "direct DOM"), but still not quite finished on that front as more steps remain.

eole666 10mo ago

Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125 https://github.com/godotengine/godot/pull/106125

999900000999 10mo ago
We'll see when it actually ships. I've seen this issue before, they're making progress but theirs no firm release date. Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.
- ramon156 10mo ago
  Naive question but why not use GDscript? I haven't had any issues with it
  - 999900000999 10mo ago
    I'll vibe code stuff in GDscript, and I guess I more or less understand some of it. But C# is what I've used for over a decade. C# has vastly better IDE support. It's a more complete language. Plus a lot of C# assets/libraries don't really have GDScript counterparts.
  - eole666 10mo ago
    I'll add that C# have better performances than gdscript. It doesn't make a difference for most of the things you code in a game, but it comes in handy when needed.
    - runevault 10mo ago
      I'd caveat this slightly as "it depends" For mathy stuff, 100% c# is going to be better. But if you need to round trip to the engine a lot getting stuff in and out of the dotnet heap can actually hurt performance. You also have to be _really_ careful because there are a lot of cases you generate accidental garbage (biggest one is when you use strings that are getting implicitly converted to StringNames every time you run a function, you can avoid this by pre-generating them as consts but I've run into a fair few people who never ran dotmemory or the like to see the issues).
      - eole666 10mo ago
        Yes, it tooks me 2 years to see how much garbage strings conversion to String Names generates and how a fool I was calling something like Input.IsActionPressed("move_right") every frame (sadly it's the example given in the input documentation).
        runevault 10mo ago
        Yup. I remember running dotmemory on a whim and being confused by all the stringnames until I noticed what was in them. They really should put that in the docs to just make a const stringname somewhere. I use a global static class for anything I want in multiple files. But I also tend to just use statics instead of autoloads if I'm doing everything in c#.

dustbunny 10mo ago

Writing C# in godot is a bad choice. Use GDScript and directly write c++ as a module. Skip "HD extension" completely. Godots build system is easy enough to use. Just add new classes to the engine using c++ if you don't want to use GDScript. The GDScript workflow is honestly great. Using C# is like the worst of all worlds.

999900000999 10mo ago
I don't like C++. It's very difficult to me, I generally stick to high level stuff , C#, JavaScript, Python, Dart, etc.
- chris_wot 10mo ago
  If you can code in C#, how is C++ difficult? Are pointers and the stl that difficult? Not denigrating, genuine question.
  - 999900000999 10mo ago
    One word. Headers. That's just the start. The C++ build system and package managers are the stuff if nightmares. Modern languages are significantly easier to use. Don't get me wrong, if you offer a job with a 200k base salary and give me 6 months to learn C++ I'll do it. But I won't enjoy it, and I definitely won't do it as a hobby.
    - runevault 10mo ago
      If you use an existing template (and are willing to use scons) GDExtension doesn't really have the standard build problems of rigging everything up with CMake/etc in my experience. The template is set up to handle the "set up the build" problem for you. Still have the header problem though cannot deny that one.
  - DonHopkins 10mo ago
    Java was designed to make fun of C++, then C# was designed to make fun of Java, so you're missing two layers of fun.

CyanLite2 10mo ago

I think WebAssembly could become that sandboxed solution. .NET Blazor WASM is moving away from mono to CoreCLR (just like Unity, with an early preview in late 2026). WASM now has really good SIMD support, native GC, large memory support, and with WebGPU we could finally see some native WASM games running at native speeds.

bloomca 10mo ago
Wait, what, WASM has native GC now?
- WorldMaker 10mo ago
  It's still not JS-level/JS-compatible GC (yet?) and it is still quite low level (more about corralling buffers of bytes than objects, a bit closer to OS-level page management than JS or C# level GC), as it is intended to be lower level than most languages need so that different languages can build different things with it. It is also a tiny stepping stone to better memory sharing with JS APIs (and the eventual goal of WASM "direct DOM"), but still not quite finished on that front as more steps remain.