I consider myself an old-school programmer.
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.
1 Like