👾 Switching To Monogame For Game Development

01 Sep, 2026

Long time no post. I've had a hard year and stepped away for a bit, but have some time now to talk about what I've been working on. I did cancel my bearblog subscription so I can't post images anymore, but maybe that'll come back later. Just trying to save pennies at the moment.

I haven't talked about gamedev stuff in a while, so figured I'd do a quick post to say I've switched my engine again. No more Godot, since I was having some trouble with it. The main problems being:

1. When I'd click in a location, I wasn't getting the values I expected. I wanted the x/y coordinates of the location I clicked in the window, but I couldn't figure out how to get this correctly.
2. The signal system was overly complicated compared to what I'm used to with desktop programming. I'd really rather just pass values the way I'm used to as a ten-year C# software developer.

I discovered Monogame through youtube. Some video talking about the development of Stardew Valley, and how it had been done with XNA - Microsoft's old game library. Which surprised me, as I'd thought XNA would have been gone by the time Stardew started development. But there are successors that extend XNA still to this day, like FNA and Monogame. I ended up looking into Monogame.

I'd originally heard about XNA at the end of college. My instructor¹ had mentioned it off-handed as a library for making video games and explained how to download it. But I was very new to coding at the time, and didn't really know how to go about using it, so I abandoned it after a while. Now that I have more development experience under my belt, it's actually what I prefer when I compare it to Godot or Unity; both of those are great options and I wouldn't try to chase someone away from them necessarily, but for myself, Monogame makes far more sense.

So if I have time and the energy, I'll start sharing some coding posts here. I'd thought about making a post like this one sooner, but decided I wanted to really figure out whether or not I'd be sticking with Monogame before declaring it. And I'm much, much further along in my game progress than I'd ever gotten with Godot or Unity; I've gotten in several months of good, solid work, and have the following systems with a solid foundation:

1. Player movement & collision.
2. Camera follows the player.
3. Different types of characters can be loaded, like the player or NPCs.
4. Clicking a spot on the screen gets the (correct!) coordinates of the mouse, and even grabs the character/object/control clicked.
5. Stage loader based on a keycode system for creating unique level layouts.
6. Working doors to other floors in a stage.
7. Basic skeleton of a title screen started.
8. Detailed, useful, custom error handling.
9. Writing the player's control mappings to file and reading it when loading the game.

I think between Unity and Godot I felt comfortable with maybe just #1? I had bits and pieces of #9 but they both have their own keybinding manager which felt very obtuse to me. And I tried so, so hard to get #4 working in both and it kept giving me odd numbers that weren't the actual coordinates, but I coudln't figure out what they were. It felt like I was fighting the frameworks to deconstruct what was happening almost every step of the way, and they actively fought against using established coding design patterns.

But Monogame doesn't. It's all custom to my own wants and needs. Yes it's a lot of work to reinvent the wheel - instead of just using Unity/Godot's velocity methods, I have to write my own - but it's very exciting stuff to me and honestly much more fun now. I don't get stuck as easily when I do encounter problems, and solving them is a lot more intuitive than with the pre-built engines, as I'm not just limited to those strict frameworks.

#2026 #game-dev #godot #monogame #unity