TL;DR: console porting is still my biggest pain-point with MG, all else is manageable and/or almost exactly the way I’d like it to be or at least is already moving in that direction 
I apologize in advance for how long-winded this is going to be, but I mean… you asked 
I want to start by saying I’m absolutely jacked about MG and have been since I started using it some years after XNA was no longer really viable, especially in recent years with the foundation and everything. Crazy development has been happening behind the scenes (and not behind the scenes) and I love the direction MG has been taking overall.
For context of where this is coming from: I have been using MG for some 10+ years at least and XNA for many years before that. I have commercially-released several games, some of which have been ported to consoles, mobile, etc, even having releases on stuff like Atari VCS (the new one). Up till now all our released games have been 2D and our console porting has been touch-and-go as I’ll explain later, but porting to mobile and PC/Mac/Linux-based stuff has been a relative breeze. The purpose of stating this is to point out that the following brain dump is coming from the perspective of an experienced MG-based developer. It is my opinion that the main reasons people use MG, for the most part in this order, are (and therefore MGs goals should align with):
- We want to code our games in C#
- We like to write systems ourselves instead of using clunky existing engines
- We like the XNA format/approach to coding games (i.e. I want to write my game to use the framework, not DirectX or whatever else directly, so I don’t have to worry about the specifics of how texture memory and sounds and whatever else is handled per platform)
- We want to be able to write one code-base that can be deployed to multiple platforms relatively easily (by ourselves). DESPITE BEING LOWER ON THE LIST, THIS IS A BIG ONE!
To that last point, I want to point out that despite my personal extensive-ish experience deploying MG-based games, console porting is still mostly a black-box type of thing in my mind. If I code a DesktopGL game and want to port it to Android/iOS/Mac/Linux/Windows there are for-sure some platform-specific considerations to be made, but at least getting things running there is mostly “make a new project that’s set to deploy for that platform and click build”. What I have always had issues with is console porting. After you go through all the trouble to get approved with partners and they ship you devkits and everything is seeming awesome you come to find even just getting the boilerplate cornflowerblue MG project to run on it takes days or weeks to figure out, if you can at all. Then, even when you finally do, getting required stuff like showing the current player’s username is a whole other battle for no reason. If it wasn’t for roz, I wouldn’t be working on a PS5 port right now, which we’ve been blocked from doing for literal years. Our devkits were just collecting dust. To this day I’ve never gotten a non-UWP MG project running on my Xbox devkit, and we even have a game that released on Xbox years ago. I say all this to point out a first-hand experience from a non-novice and I know I am not the only one with these pains. Being that one of the top 5 reasons for pretty much anyone to use MG (imho) is to be able to build their game for consoles themselves, it seems nuts how difficult it is. Especially because the solution is just “knowing what knob to twist” as was the case with the excellent “Get Started on PS5” document roz put together for us. One day we had no hope of running on PS, the next we followed a few spelled-out steps of stuff I’d almost certainly never be able to work out on my own and bam-boom, PS5 build running. Also, just so it’s said, yes I’m aware that MG devs have put A TON of work into getting MG to run on consoles and even share their companies’ in-house-made porting tools (BRUTE) for free and we are EXTREMELY grateful for all that, but all that generosity is lost to the end-user that is unable to use it (me). Which, again imho, is the whole point of using MG in the first place. To wit…
Things I’d like to see (in order of priority, imho):
- Updated readmes or whatever needs to be done to get a “follow these steps to run MG on X platform” as a part of each platform’s Github Wiki or wherever else. As they stand, the existing “Getting started” docs simply do not work. Full stop. Unless you have a deep understanding of either the platforms backends/SDKs, or .NET versioning issues, or both, you’re just SOL.
- Per-Platform out-of-the-box integrations. These aren’t even really MG-specific, more so C#-specific, but still.*
- Basic/Intermediate Networking examples (both for LAN and actual Online)
- Post-basic-3D-understanding step-by-step tutorial for the most basic form of making a model in Blender, importing/building that in MG, and not only rendering it but even animating it a bit. Nothing crazy - but more than just moving/scaling/etc the model, having it actually have like an actuating arm or some such. It’s not that hard to study existing material to understand the basics of 3D, matrices, basic vertex shaders, etc. But it’s a decent jump between that and like shadows/model animation/etc. Basics that could maybe bridge the gap between “this is how you render a billboard, a box, or an FBX” and “this is how you could have a character with a running animation”.
*For our Xbox port of Muffed (a top-down shooter game we released some years ago when UWP was still allowed for ID@Xbox builds), it took ages to work through all sorts of Xbox docs and forums and you-name-it to end up putting together what became a simple 300-ish line class file that handles all our “Xbox Integrations”. Stuff like checking the user’s game license/ownership, displaying the username, awarding achievements, player-specific save file storage access, basic stuff like that. There’s no reason there couldn’t be a boilerplate version of this that would work for any game as a “starting point” that would have saved me literally weeks or even months of BS to get our game doing Xbox things. I propose a bounty for simple .cs files included in each platform for like MonoGame.Integrations.(Xbox, Steam, PS/SCE, etc) classes. I have one of these for each of my platforms, the only one that could be stripped and re-used now is probably just the one for Steam, but again is one of those “for someone that knows what APIs to use and how, this is so straightforward it’s silly. For those that don’t, this will be a multi-week deep-dive into random disconnected docs at best, and most likely end up as an effort to hound other devs into helping you out to get a boilerplate thing started because all you can find on your own is Unity-referenced nonsense.” Steam integrations are a great example of this, because it’s literally just “include Steamworks .NET and then call MonoGame.Intregrations.Steam.GetCurrentUsername”. Since I’ve used Steam APIs a lot it’s super easy for me, just as I assume other APIs are for other devs that have used them as their main platform. I’m not suggesting these would include more than just the basics because they’d end up having crazy maintenance needs, but at least just the “required features” to run on X platform and stuff like license checking seems like it’d be maintainable enough.
Upcoming things I’m most jacked about:
- NativeAOT support (this is huge, especially for consoles)
- New project-based content management. As a developer that never really liked MGCB and always used it completely separately from my game project anyway, this is really neat to see
- Updated/updaing support for consoles and mobile
I <3 MonoGame