A Case for MonoGame in 2023

Why the longstanding successor to Microsoft’s XNA framework won’t be for everyone but shouldn’t be counted out

With respect for our friends who are entrenched in projects or have decided to stick it out, it’s starting to look like an increasingly post-Unity game industry. Teams small and large are flocking to other technologies and trying to minimize wasted time as they get back up to speed elsewhere.

While many folks wisely headed for Godot, I committed to a fresh run at MonoGame. For the last month I’ve worked to get as capable as possible in the open-source framework doing pure C# development, and I’m glad I made the effort.

Here are a few reasons I think more of the community should be giving MonoGame a look.

Proprietary engines will always lead to heartbreak

I don’t have to rehash the whole Unity runtime fee debacle that sent unknown thousands of developers running for the hills. Unity dropped a bombshell on its customers, sources official and otherwise admitted it the plan was half-baked at best, and occasional internet main character and CEO John Riccitiello made his exit from the company. The trouble should be over with, right?

Probably not.

Unity is a public company with a board and a list of executives making millions more than they probably ought to. Unity merged with IronSource which exists solely to monetize apps in ways most people hate. Its engine is brought to you by a company that does not make games itself and is increasingly focused on commerce. Unity will probably either do something else just as unpopular soon or it might starve itself to death.

It’s far from alone, needless to say. Many of us have been around long enough to see GameMaker go from little scrappy engine startup to shapeshifting license yogurt that charges monthly once you’re publishing anything outside of the Opera browser (I still have no idea how that happened). You may have even seen me personally pressing Buildbox for transparency when they did their most recent version of this in 2021. I’ve said around social media that triple-A game development has become unsustainable no matter how successful the games are. Big engine development seems to be headed in the same direction.

It’s important to point out that open source…ness is not exclusively an argument in MonoGame’s favor, either. I don’t believe indies should use big proprietary engines in any situation, and there are loads of good alternatives. Godot, MonoGame, Love2D, Cocos, and many more engines and frameworks remain freely available and need community participation to thrive. Whatever your skillset and areas of expertise, you can find tools that won’t pin you under corporate bullshit, and you should.

Godot is cool, but let it be Godot

While I was still on Twitter (I’m doing great without it, thank you), I started to get the idea that this mass exodus from Unity may have been the worst thing ever to happen to Godot lead developer, Juan Linietsky.

Immediately after Unity indirectly reminded everyone to stop using Unity, Unity’s self-styled power users showed up to start throwing their weight around like they own the place. “I did what I do in Unity and that doesn’t run well in Godot.” “Change your C# support.” “Why not organize scenes exactly how Unity did it?”

Juan has stayed relatively gracious. I would have quickly invited these people not to use Godot.

My suggestion, if you’re a C# deity and you’re displeased with Godot, is to head on over to MonoGame and show us what you can do when it’s just you and the editor of your choosing. That’s what MonoGame basically is: total freedom and nothing else.

C# framework development will make you superhuman

We just touched on this, but let’s talk about what MonoGame is.

Whereas Unity and Godot attempt to be full-featured engines that allow you to develop content and make a game, MonoGame is a framework that will allow you to develop enough of your own engine and tools to develop content and make a game.

Imagine spending your time on transferrable, real-world skills instead of scouring the internet for documentation and tutorials about which proprietary menu item you’re looking for. With MonoGame, you start from the ground up and make exactly what your game needs and nothing more. Furthermore, imagine knowing exactly how every little detail about your game and the underlying code works.

Fine, few of us know what our own code is doing at all times, but still…

Development environment flexibility is nice

Having worked as a professional Unity contractor for years, I can’t tell you how much I came to hate Unity Hub and all it stands for. There is always a new version you may or may not need to move to. You will rarely have one version installed at a time. Unity Hub itself updates more than the actual engine ought to.

MonoGame makes it a point to mention on its download page that you don’t strictly need to download an installer at all anymore. NuGet packages and project templates will take care of everything.

This is because there’s no hard fast requirement to use a specific program to create a MonoGame project. I’m sure most devs use Visual Studio where everything works through mysterious magic. As the crotchety old developer I’ve become, I don’t even really want to be a “Visual Studio Guy” these days. I’ve created many happy projects with Atom, but that was taken out behind the server shed at the end of last year and everyone has moved on to VS Code which is just below my threshold for blinking flashy annoying software. Thanks to MonoGame’s .NET command line interface, users can also make use of JetBrains Rider or probably even Notepad if you’re stubborn enough.

MonoGame’s .NET adjacency is actually kind of nice because, since you’re coding from the ground up, a big enough project will probably lead to some custom tool development, level editors, whatever it is you need. My friend Michael Hicks put out some great content about this in his FNA series on YouTube. You can think of FNA as a sibling fork of the original XNA framework. Since you’re going to be a C# superhero, it should be fairly simple to jump over, lay down some more C# code, and .NET yourself up something nice.

Platform support looks good

If that sounds vague, it’s intentional. You can clearly ship games for Windows, Mac, Linux, as well as iOS and Android devices. Console support is where people are usually asking questions.

Nintendo Switch is listed as being supported. PlayStation 4 and 5 are currently listed, as well as “Xbox.” When it comes to console development, everything is supposed to be under NDA, and engine/framework websites are usually very abstract in their wording. Godot is notorious about this, and Godot has very obviously been used in modern console games at this point.

I hear a lot more devs extremely concerned about console ports than devs I know to be actually working on console ports. My advice is not to throw the baby out because he wasn’t born with a Series X controller in his hand. When you get to that point, there’s typically a way forward with any widely accepted engine or framework. I can’t think of any examples where I heard “we never got the Xbox version. It just couldn’t be done.”

And, yes, MonoGame supports 3D!

As for me, I’m currently tinkering with two MonoGame PC projects: a collection of old paper and pencil games I used to play with my grandpa as a kid, and a game my son wants to design who is, not coincidentally, named after that same grandpa. Progress has been a tad slow as I get back on my feet with pure C#, but I’m thrilled at all I’ve done already.

If you have a different take on this, or you’re doing something cool with MonoGame, I’d love to hear about it.