I’ve been thinking a lot lately about why people choose different game engines / frameworks. As far as I can tell it comes down to a few reasons.
What have I missed? I’m curious what got you started with MonoGame?
It started long before MonoGame was even a thing. It was about 15 years ago. I got into C# and wanted to use it for games because I loved it so much compared to C++. Options were very limited, unlike today. I messed around with Managed DirerctX but found it clunky and not very intuitive. Then Microsoft released XNA. I tried it and was immediately hooked on it. I used XNA all the way up to 4.0 and continued to use it long past Microsoft dropped support for it. I knew about MonoGame and decided to migrate from XNA. I liked, still like, that it was 99% compatible with what I was doing in XNA. I also still like it over drag and drops like Unity with their bloat. It, like C#, gives you a finer degree of control over everything. I also like getting my hands dirty, so to speak.
This thread explains my reason, grab a cuppa 
before you click into it…
I can relate. Although, I never actually used XNA when it was a thing but I have been making games since I started coding in my early teens. I used Managed DirectX and OpenGL a couple of times, tried other game engines but eventually came back to C# based ones.
You mentioned there’s lots of options these days, and that’s true if you’re talking about the whole spectrum of game engines and frameworks but in terms of C# based one’s there’s not really that many. I’m not a big fan of drag and drop (Unity / GoDot) so that really only leaves MonoGame or building something from scratch with OpenTK.
I started using XNA back around 2009. Having been so long, I don’t fully remember my reasoning, but I was working on a project that had a graphical interface despite being a line of business type of application. I wrung every cycle I could out of GDI, and found a situation where it just wouldn’t do as well as I wanted. I first tried out XNA in place of GDI not so much because I had made the decision that I wanted to use XNA, but because XNA shifted work from the CPU to the GPU and I wanted to see if it performed better.
All I was doing was drawing controls, though, so it wasn’t typical game stuff. WPF was also an option, but I had been told not to go there, and hadn’t been told not to try XNA, so I didn’t ask and just tried it out. Once I realized how MUCH faster it was than the GDI solution, I was sold.
I stuck with XNA for a very long time, but always realized that I was holding to what was clearly the past. MonoGame was still an extant option, and was moving forwards. With COVID delaying some of my plans, I felt it was time to see about moving from straight XNA to MG, and now was the time.
For the most part, it has been painless. For the part that hasn’t been painless…well, here I am.
In 2017 I decided to join a coding bootcamp and change careers to software development. It wasn’t until this year that I started trying to learn game development in earnest. Naturally, I started out with Unity because of how popular it is, but it didn’t take long to figure out that I didn’t care for the Unity way of doing things. For me I found that trying to pick a game engine (especially as a novice) comes with a bit of peer pressure and uncertainty, MonoGame is a hard sell. But I finally decided to go with what I like.
I like MonoGame because it’s open source, C#, and a lower level framework. As someone without a math or computer science background, it’s been challenging learning how to implement things like collision detection and shaders from scratch, but it’s been really rewarding. Also, (I may be really naive in thinking this) but it seems to me that creating unique/original games often requires creating things from scratch anyway, so why not just start off with a framework that doesn’t get in the way.
Heh, that’s a really interesting story. Whatever works I guess 
The reasons are XNA structure, C# and of course cross compatibility, write once run everywhere (I hope, didn’t try it yet) 
I started using MonoGame only recently, but it felt VERY GOOD from the beginning.
It took me only a few hours to understand the basics of MonoGame: just a simple project with a game class, a load, update and draw method that’s called by the engine is actually all I needed to know to start creating games. This is what I prefer, no intricate game environment, just a simple wrapper for directx, opengl or whatever, with just C# as my main tool and calling the monogame functions is all I need. A big shout out to the creators/maintainers of this platform.
My foremost draw to Monogame was that is a continuation of XNA, which I had already been using for nearly a decade. But, some additional reasons include C#, and my adamance to write my own custom and streamlined engine rather than the bloated mess that is Unity, etc. I like to know exactly how everything in my program works, both for debugging and for my own learning.
I found some extremely cool tutorial/blogs with impressive effects by Charles Humphrey - made me excited to try XNA and learn how to program fx stuff. I then got into oyyou’s tutorials which made me realize it would be far quicker to develop under than regular DirectX (which is what I used to use).
Then finding out Dust (Elysian Tale) was made this way… and that monogame is cross platform - that pretty much sold me on sticking with it.
Other game engines have too many “magic” going underneath. But monogame gives us fine control over everything - from game loop to GPU buffer.
Therefore, the real creators and inventors choose monogame to create genuine software from scratch.
Well put.
I came from C++ background where I used a library called Allegro.
When C# came along I fell in love with it and did some game development using WPF (!).
I mainly did boardgame implementations so that was fine.
Then I stumbled across Monogame and when I saw it produced a working “game” (the pale blue screen) out of the box I knew it was the one for me.
I did a quick demo of goblins walking around which evolved into Dragon’s Lunch (not a boardgame conversion 
) which was released on Steam in 2017.
For me, two reasons:
I wanted a framework I could release my game to all current platforms (Desktop, Mobile and Consoles).
It needed to be a Free and Open-Source software.
I was really, really tired seeing people recommending mostly Unity and UE4 all over the web, as if they would be the only and right choice. I’m so glad I found MonoGame. Learning it by myself was not easy (I knew very little of C#), but I didn’t give up. Great framework! Keep up the great work, guys!!
Why did I start using it? It was and is the easiest way to draw 2d graphics to the screen. No messing with SDL, no messing with low level stuff you don’t need, most of the work is already done for you.
It doesn’t take a 4 gb download to distribute your 2D game or take 20 seconds to load unused things because you’re packing the entirety of the Unity engine. It doesn’t drain the battery or lag the computer because it’s not bloated.
Plus you get to work with C#, which is much easier than C++. It’s much easier to control and create things without learning third party libraries.
Everyone that I’ve showed Monogame has said it was by far the easiest game framework they’ve ever worked with.
I played around a bit with making games when i was a kid. Was trying to get back to that feeling. So i moved from AmigaBasic to Unity… not as smooth as you would have think. Lots of features missing in unity.
I was trying to get an handle on how to structure large(re) projects. Cant explain it but i felt a bit trapped in Unity. I was going to do the c/c++ thing but then i remembered that XNA was all the rage back in the day.
I Love how, in this framework, can brake ever rule and make my own solutions to every problem. My code is not pretty or very optimized but it sure is mine
So true. I feel like this benefit is not talked about enough. When you’re coding any kind of software the development experience is everything imho. It’s amazing how lightweight engines and frameworks can be freeing.
I’ve been coding games and other software for around 25 years back when you had to write slabs in Assembly to squeeze out enough performance and running out of memory was a very real problem.
Since I had to write boring software to pay the bills it didn’t seem realistic to be writing games using C++ and the DirectX SDK.
Managed DirectX came along so I started making a few terrain demos and stuff in that then XNA came along so I moved to that… then moved over to MG. Fine control over everything without having to learn how to fudge your game into the some engine.
I really hope to actually release a game with MG next year. I should have started with something smaller
To me the reason to use MonoGame and (specially) C# is the difference between doing games and finishing games.
I started 34 years ago (something’s wrong with me, I should be tired by now 
), as most 80’s bedroom coders, with BASIC. As time passed, moved through Z80, C, x86, C++, DX, …
I finished my first ‘decent game’ on Y2K with C++ & allegro, then moved experimenting with ‘cheat devices’ with gameboy, GBA and PSX, and settled for PDAs/Smartphones (Window Mobile, the predecessor of Windows Phone). Ended 3 games for that.
I knew you could do games for Xbox since 2006, but C#? A managed language? To do games? Don’t make me laugh. Finally, in 2010 I was thinking of “leaving the game scene” and decided to try XNA. After all, watching things run in a console is always cool.
Sometimes I wish I wasn’t so stubborn.
After a few weeks I was asking my real life work boss to move everything C++ related to C#. Finished more games in the first 2 years than in the last 25 years, and was able to leave the job to keep doing games. The ratio of unfinished games was like 90% without C#, and is like 20% in C# (sometimes not all projects are viable)
Once XNA disappeared, MonoGame was a logic step.
I tried Unity when XNA disappeared, and have tried several times since then, but I don’t seem to be able to wrap my mind around Unity’s paradigm. I’m more of a “gimme a void main ()” programmer, so XNA/MonoGame is heaven for me. I really envy Unity’s ability to be able to just plug things in via packages (shaders, artwork, scripts, …), I wouldn’t have had so many problems with my current game with Unity.
But on the other side, I’d have lost lots of times to try to make Unity behave like I’d want to. Slower startups, no edit and continue (afaik), chaos updating versions, fighting with unity’s demons (which not always can control), … at the end, it’d probably have taken the same time despite having lots of things already done. If I have to fight someone’s code, I prefer fighting my code. At least I know who to blame
If it wasn’t for C#/XNA/MonoGame I wouldn’t be doing games by now. I don’t know if that’s good or bad, though 