MonoGame: A .NET framework for making cross-platform games

It sounds like you don't like programming. I am in the process of writing my own language/IDE/compiler on the side of making games, and have already written a dialect of C# with a compiler that transpiles it to legal C# for use in the meantime. I would, in fact, love to write my own OS if not for the fact that proprietary hardware vendors make it virtually impossible for anybody to create a new OS that runs on consumer hardware in the year 2026. If you gave me a trillion dollars with which to build a CPU factory, I'd jump at the chance to learn that too.

People who don't like programming, who wish to abstract it all away and "stand on the shoulders of giants"[1] without understanding anything about the giants, seem to view low-level code as a bogeyman. It doesn't take a lifetime to understand. To the contrary, I would argue that low-level code is easier to work with than working only with high-level code, because you can reason about it. The more you rely on abstractions you don't understand, the more impossible it becomes to effectively reason about anything, because your reasoning is glossing over the details that make things work. But reasoning about primitives, and the things built out of those primitives that you understand, is not actually nearly as hard as the people who just want to plop Javascript libraries together and stop thinking about it would believe.

In particular, when it comes to games, especially 2D games (which are what Godot and MonoGame are typically used for), it's really not that hard. Windows has an API for doing X, Y and Z with graphics. Linux has an API for doing X, Y, and Z for graphics. You write a wrapper that your game code calls that passes through calls to each of those APIs with an #if statement filtering for which OS you're running on. Rinse and repeat the other set of platforms, with a bit of extra finangling for API limitations on web and phone OSes. Rinse and repeat for audio, input, and font handling. It took less than a month of work for me to get a polished cross-platform system working on five platforms. Not because I'm a genius, but because it's seriously just not hard. There are a thousand tutorials and books you could pick from that will give you a rundown of exactly how to do it.

Then, for example, writing your own rudimentary 2D GUI map editor can literally be done in a day. Presumably you know how to code a main menu. Add an option to the main menu that changes the gamestate to State.MapEditor when selected. Set a keybind on this state where your arrow keys increment or decrement X/Y coordinates, a keybind to place tiles/objects, a keybind to cycle which object ID is selected, and a keybind that calls a function which serializes your map state to text and saves it to a file. A little bit more work for a moving camera viewport, but it's not that hard. Want more features, polish it more. When you fully understand the primitives your system is built with, adding new features can be done quickly and easily, because it's so easy to reason about compared to reasoning about code you've never read built with primitives you don't understand.

3D does up the difficulty level, but it's by no means unachievable, either. The content creator Tsoding is currently doing a semi-weekly challenge to build his own 3D game engine from scratch on video, and he's making great progress despite not spending that much time on it, a side project that gets a few hours a week.

The end result of all this is a codebase that is more performant, lightweight, easy to read, and very easy to extend. I think developing your own engine can actually save time in the long run (if you're willing to forego the instant gratification), because it's so easy to fix bugs and add new features when you have a complete mental map of your codebase and the primitives used to construct it. For example, I have a friend who used Godot to develop a game, and they've been plagued for months with a low percentage chance of fatal crashes on a boss that they are completely unable to identify and fix, and it's because they don't have a mental map of the engine code. It's simply not even possible for them to reason about what in the engine could be going wrong because they don't even know what the engine is actually doing.

[1] Another metaphor that is grossly mis-invoked, in my view. Do you think Isaac Newton did not understand the work of those that came before him? The great thing about giants is that by doing the hard work of exploring new concepts, they make it easier for everyone who comes after them to learn them. I think it's a bit intellectually lazy to put off the work of giants as something that should not, or even can not, be learned.

[2] "like J.R.R. Tolkien wrote books, and there's a reason nobody writes books the way he wrote his." It's a real shame more people don't, considering there has never been a fantasy work rivalling his in the nearly century since.

Same here (minus the making any money). XNA is how I started learning graphics programming and started my interest in things like physics engines. Shawn Hargreaves had great blog posts on gamedev back then, too.

One person wrote books like JRR Tolkien. His name was JRR Tolkien, and those books are widely celebrated by millions of people as classics.

I don’t have any issue with people using an engine like Godot or Unity or RPG Maker or Unreal or anything else, but I do think that there can be value in “owning the entire stack” of a project, even if that means “reinventing the wheel”.

When I do a project involving HTTP, I could reach for Rails or something, it’s a valid enough and I certainly have done that plenty of times, but I often will work with a lower level protocol. Depending on the language I will use a more simple HTTP server thing like Axum with Rust, and other times I will go full epoll/Selector with a raw socket.

I do this for a variety of reasons, but the main one is that I can build my own framework that works in a way that I think and I don’t pull in a bunch of extra crap I don’t need. I can optimize the “hot paths” of my particular project without worrying about a one-size-fits-all you get for generic frameworks, I don’t have to worry as much about leaky abstractions, and I am intimately familiar with a much larger percentage of the codebase.

There is value in both approaches.

Haven’t used the engine specifically, but seems to be a cool project. I have used the Stride renderer which is embedded in VVVV, a live multimedia node-based language, which makes it interesting that you can extract and reuse such large components from the engine.

Several games used to target Monogame for consoles but XNA for PC, and later FNA for PC.

Monogame on PC used to be somewhat buggy in my hobbyist experience.