Although I now use AI as an assistant for certain tasks, I chose MonoGame for game development because I wanted to abstract away some low-level details without giving up full control over the development process.
What I really wanted was to build my own framework: define my own game loop, architecture, and engine, rather than work on top of an existing one.
I hope I never find myself spending hours customizing Unreal or Unity… but that’s where my existential question comes in.
I see so many games being developed with those engines, as well as with “no-code” or “zero scripting” platforms, that I can’t help but wonder:
What if I’m actually being a dinosaur by trying to build my game almost entirely on my own?
So I’d like to ask you:
Why did you choose MonoGame instead of Unity, Unreal, or other engines that already solve almost everything for you?
In my case, the satisfaction comes from building the game from the ground up. I enjoy programming the systems myself much more than assembling prebuilt functionality. I’m not saying one approach is better than the other—it’s simply the one that motivates me the most.
But if the ultimate goal is to publish games and, hopefully, make money from them…
Do you think MonoGame is still a good path, or from a practical standpoint is it ultimately better to adopt a full-featured engine like Unity or Unreal?
I’d really like to hear from people who have published commercial games using MonoGame.
Firstly, there are plenty of games built on top of MG that have made significant money. Some are even a few of the most (financially) successful indie games of all time. If you widen that net to general XNA/FNA/etc as a whole, you’ll find plenty of real-world examples that prove making games with MonoGame/XNA/FNA/etc is just as viable as any other approach to making games. This coupled with the fact that most MG/XNA/FNA/etc games have drastically better engines/performance/etc than their counterparts would suggest it’s absolutely a great approach for making good software in general as well.
The main reasons to use MG over an engine of any kind is because you A) like creating your game via programming, or at least like making your own game-making tools, and B) want to create your own engine rather than fighting with an existing one to get it to do what you want. Yes, there are advantages to X engine does this and Y engine does that, which may be pre-canned, useful features for your project. But, without fail, if you’re doing something new/creative, you’re going to run up against the engine eventually and have to fight it to get what you want. With MG, you just write it to do what you want to begin with. If you talk to developers that use engines for large commercial projects and not just prototyping, or watch/read documentaries and the like, invariably you will hear stories of the most pain they experienced during development involving fighting with their engine/tools.
The next main reason, and why you’d pick MG over vanilla C# or whatever else, is that MG abstracts the really low level stuff that all games need — for many platforms. Things like loading textures, sending polygons and shaders to the GPU, processing input, etc. Every game needs these to communicate with the hardware of the given platform, and every platform is different and really complicated. So, we use the MonoGame Framework instead. You can write your game using the MonoGame Framework/API to load and use your assets, and you can publish to a ton of platforms with remarkably little friction, relatively speaking. That said, especially for consoles, there is still porting work to be done (platform-specific requirements, APIs to support things like achievements and whatever else, etc). But it’s nothing like having to rewrite your game in a different language, having to implement graphics/sounds/etc in a completely different API/backend, etc.
From my personal experience, for 2D games, MonoGame is a better choice than Unity, because Unity’s codebase tends to feel fragmented and isn’t great for tightly controlling complex game mechanics. For 3D games, though, graphics rendering becomes extremely complex, and MonoGame’s graphics framework is fairly low-level. In practice, developers essentially have to build their own engine on top of it. That’s probably why 3D indie games using MonoGame are relatively rare.
I don’t think you’re being a dinosaur. I think it depends on what you enjoy and what you want to optimize for.
For me, one of the interesting things about MonoGame is that it sits somewhere between writing everything from scratch and using a full engine. You don’t have to deal with all the low-level platform work, but you still have a lot of freedom over how your game is structured.
Unity and Unreal can definitely make it faster to get a prototype running, especially when you need things like physics, animation systems, editors, and ready-made tools. But there is also a cost to having all those systems already built. Sometimes you end up spending time learning or customizing the engine instead of building the game itself.
I also don’t think using AI changes this decision as much as it might seem. AI can help with code, debugging, or explaining unfamiliar systems, but you still need to understand the architecture if you’re building your own framework. In fact, I think that can be a good combination: let AI handle some repetitive work while keeping control over the important parts of the game.
The commercial question is probably the more difficult one.
If the goal is simply to publish a game as quickly as possible, I can understand choosing Unity or Unreal. But if the goal is also to become a better programmer and have complete control over the technology behind the game, MonoGame seems like a very reasonable path.
I’d actually be interested in hearing from developers who have shipped a commercial MonoGame title: at what point did building your own systems become a limitation rather than an advantage?
I love all these responses! I personally started with Pygame, and it was pretty fun for what it was, but it didn’t quite give me the satisfaction of really thinking about how systems worked, if that makes any sense.
I guess it felt a little like pool floaties that kept you above water most of the time. Then I fell in love with C#. It felt like somebody took a BB gun and shot the floaties, forcing me to think in much smaller, but somehow bigger, ways.
I was never a huge Unity fan or a fan of editors in general (especially after that whole pricing-model debacle). When I finally started looking around for a framework I could really get behind, MonoGame was pretty much everything I’d been looking for. Open-source and code forward.
It lets me learn how things actually work without someone holding my hand too much. My code probably looks absolutely terrible compared to people who know a heck of a lot more than I ever will, but it’s my code, and that makes me happy enough. If it works, it works.
I get that, the code-first approach gives you much more control over how everything works.
And honestly, building your own systems can be pretty satisfying when the game itself is fairly simple. The C# part is a big plus too, once you get comfortable with it.
