Stride Game Engine 4.3 with .NET 10 Support
stride3d.net31 points by bj-rn 7 days ago
31 points by bj-rn 7 days ago
Let's say I want to create a small 2D game. I'm no game dev so nothing fancy, just a PoC. I'm willing to take a code first approach and I love C#. What is my best best?
- 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.
Recent versions of Unity are actually using Roslyn ¹) but they are admittedly running a bit behind on C# language version. The currently supported version is at 9 while 14 came out last month. It's not really a huge issue in practice, though.
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...
> which makes switching languages decidedly non-trivial.
No, it does not. The C# version supports both GDscript and C#, so just download that if you ever plan to use C#.
Godot has full C# support and it is a first class citizen. GDScript has a few advantages, the main being game package size, but they are extras from the fact it's a custom language. The C# development experience is smooth.
I have released commercially successful (for a single dev) games with Godot and C#. GDScript is just the default because most newer Godot users prefer the Python-like syntax, and being a custom language it has some extra features and integration in the editor.
MonoGame is stable and still receiving updates.
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.
The thing with MonoGame is that it was designed to be an opensource version of XNA, thus it doesn't have an evolution path.
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.
MonoGame is not abandoned, here are two good examples of frameworks on top of MonoGame/FNA: https://github.com/prime31/Nez https://github.com/isadorasophia/murder
Unity is easily your best option if you've got any sensitivity to platform targeting issues. They are working on a CoreCLR conversion but no telling if it will actually see the light of day.
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.
Microsoft is a big advocate of C# and game dev, so they sponsor .NET support in Godot. First class support absolutely.
AFAIK Microsoft is not a Godot sponsor, if you mean in terms of money or time? The companies listed down in this page are Godot sponsors:
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.
Googled it:
> During the past year (2020), Ignacio Etcheverry worked on significantly improving C# support and its integration in Godot, adding support for Android, HTML5 and iOS, as well as popular third party IDEs. This was financed thanks to a generous donation from Microsoft.
https://godotengine.org/article/help-us-reach-next-funding-g...
Nice find, thanks! Turns out Godot reached to Miguel de Icaza for a few grants from Microsoft for C# integration around 2017-2020. Coincidentally, I can't find any mention of Microsoft grants for Godot after de Icaza left MS. I guess we found who used to care for Godot at MS. Still, cool that they did it.
Godot is a great engine, and .Net support is very good. You can't go far wrong with it, especially for small 2D games.
Raylib is a very good option for 2D games. For me it was the easiest way to translate my toy Doom renderer from javascript that used html canvas to C#.
> Bepu Physics
This is a seriously impressive physics engine. Their design is difficult to integrate with but the performance is insane.
Wow. That is actually very impressive. Things have moved quite a lot since I did a physics engine.
What makes it difficult to integrate?
Thanks!
The direct hooking into the narrow phase solver is the most performant way to go about it, but it does present several issues in state management. I did the same thing in Farseer Physics Engine, but also added high level events on bodies[1]. The extra abstraction makes it easier to work with, but due to the nature of delegates in C#, it was also quite a bit slower.
They could do with creating defaults for the narrow phase handler, buffer pool, threat dispatcher, etc. for devs who don't need extreme performance and just want a simple simulation.
[1] https://github.com/Genbox/VelcroPhysics/blob/ddf8292da6bc59e...
Great news, Stride has been coming along quite nicely during the last years.
OK, but why?