- Unity seems promising but they have a weird version of mono running things and not so recent C# features available. Might be a non issue.
- Godot seems more promising for my use case but I feel like they want you to use GDScript. I don't want to use GDScript while there is a perfectly capable C# engine there. Is .NET second class in Godot?
- MonoGame was basically abandoned for a long time. I wonder if it got any better. That might be a little too much "code first" though.
Stride.. I just heard it the first time ever. Its a shame. And apparently it is a proven engine especially in VR space. Jumped on it, unfortunately no macOS support available so can't dig in right now.
With Godot 4, the big difference between Godot and Godot .NET is that the version with NET support does not build to web and mobile support is 'experimental' ²). Also, they are two completely separate downloads and editor binaries, which makes switching languages decidedly non-trivial.
For a 2D game, if you can live without building to web, I'd pick Godot. Otherwise, I'd pick Unity.
¹) https://docs.unity3d.com/6000.2/Documentation/Manual/csharp-...
²) https://docs.godotengine.org/en/latest/tutorials/scripting/c...
No, it does not. The C# version supports both GDscript and C#, so just download that if you ever plan to use C#.
I would strongly suggest that for quick code-first prototypes. The boiler-plate of "load a texture and render to screen" is quite minimal - you could perhaps make a small library for yourself?
It also has no opinions about how you structure your game data. This means you can represent things like a Flappy Bird clone as just a `Vector2`, rather than having to bash a graph of entities in the shape you want.
FNA has done some experiments going beyond XNA 4 API design, however for the type of 2D games XNA was designed for, there is little else to add anyway.
The lack of modern c# features and hijacking of things like null coalescing operators are annoying but it's not something that ruins the overall experience for me. The code is like 20% of the puzzle. How it all comes together in the scene is way more important.
https://godotengine.org/donate/
As for advocacy, Microsoft's "Game development with .NET" page points first and foremost to Unity and their outdated, proprietary .NET toolchain; only by digging you get MonoGame/Godot/Stride listed. And if you dig for bindings, they'll first point you to a couple of open source DirectX bindings unmaintained for over 7 years.
I'd say they stopped caring about .NET specifically for game dev as soon as they abandoned XNA. Now they're doing the bare minimum that nets them Visual Studio licenses, which I'm not sure they care much about anymore after Copilot.
This is a seriously impressive physics engine. Their design is difficult to integrate with but the performance is insane.
What makes it difficult to integrate?
