Announcing the MonoGame Foundation
community.monogame.net
community.monogame.net
But it had a fair bit of downsides too - it had to have all content compiled into a proprietary format using a Visual Studio plug. The font rendering was blurry and had poor support for internationalization. And the ergonomics of its APIs left something to be desired.
MonoGame has essentially replicated XNA 4 wart for wart including the content pipeline. Development has been really slow on new features.
But it's also one of the more lightweight and code-centric game development frameworks out there currently, and I do prefer that to working with a heavy bloated editor like Unity (which I've used professionally in the past). And as long as my game takes the warts into consideration, 95% or more of my time is just spent coding, not figuring things out the quirks of the framework or engine.
Like I had some issues getting some animations to import properly from Blender the other day (there's some video with like 100 views of someone who got something a bit different sort of kind of working, but I didn't feel like figuring out how to decode what they're doing and transpile that over to my needs), and just decided "Okay, I guess I'm not going to bother with making animations in Blender and only use static models instead. What I wanted it for isn't really that necessary anyway." And I'm only targeting Windows for now. I'll try to get other platforms working later, if ever (got it working on Steamdeck, at least).
It was also pretty disheartening to see almost zero development on Monogame over the past year (judging by its Github activity).
I have been considering giving Godot or Defold a try for my next game (Godot I was highly considering since it has XR support, and I've really wanted to make a VR-compatible game for a while now), but I'm hoping I can at some point jump back into Monogame once this Foundation gets into gear.
I also started with XNA, and I quite enjoyed it. But this was back in 2012, and I felt the shift happening. I used Unity for several years, and always felt a sense of confusion when looking at someone else's implementation: should I look at the code? The scripts? How is the project structured? It can be quite a task.
In the last 6 months (shortly before the infamous Unity debacle) I started using Godot with C#. Like many, I can say that I quite like it. Related to your comment though, I tried going back to a code-first approach, and so far I have to say, it's going great. I have managed to create most of my scenes with scripts alone, and as far as I can tell, Godot is made for this. Everything that can be done in the editor can be done in code.
The shift to unity killed any desire I had to try to make indie game experiments. The UI was confusing and I couldn't grok it. It just felt so alien to me.
Awesome to hear that you can use godot in a code first way. I might have to try and pick it up at some point when I have free time.
Of course you don't spend time on warts if you know where they are and how to avoid them. The problem is learning that, which you apparently have, but then again, this can be said for any cumbersome tool.
You can also run the content pipeline as a .NET tool outside of Visual Studio. It works on Linux too!
This was intentional and beneficial in some aspects. So games could be ported easily. And existing team expertise could be leveraged.
Thats pretty neat that its opensource.
Between this and Godot, I think indie developers and smaller professional studios will have options to choose from in the future.
There's also FNA, which is more focused on being an accurate reimplementation of the original XNA on top of exclusively OSS libraries and open APIs, although you can use it to make new games as well. Some games have actually used both to target different platforms in the past, as MonoGame is arguably buggier.
Had I known it would be that easy I would have done it years ago. Actually lead to me remaking the game in 3D and turning it into a proper sequel (which I'm still working on).
Just note if you wrote it in XNA 3.x, you might need a guide as the modern version is more akin to v4.
Glad to see it.
Anyway I really appreciate MonoGame folks carry on the XNA flag, after the people responsible for it on Microsoft lost to the DirectX/C++ group, hence DirectXTK as its replacement.
The difference is that you get to code most of the engine as opposed to mostly coding gameplay. That's of course a significant trade-off. If you like being low level and understanding how things work and learning a ton then Monogame is the tool to use. If you strictly want to make a game and don't mind ramping on someone else's toolset to "go slow to go fast later" then Unity/Unreal/Godot are the tools.
Monogame shines when it comes to 2D games since 2D games require less specialized engine tools and most of the editors can be made quite easily for a 2D game and will teach you a lot. Don't get me wrong, it's capable of 3D but the experience will be much harder and unstable. You'll be much more at the mercy of outdated open source libraries for things like importing animations from your favorite 3D editor. Conversely, writing a library to import and load your own 2D animations can be done in an afternoon.
The showcase of games built in Monogame echo this with lots of heavy hitters and well-known 2D games and very few well-known 3D games.