I'm the type of person that would rather reinvent the wheel instead of learning how to use an existing and arguably better wheel to begin with. Meaning: Instead of using one of the existing arguably better game engines I prefer to write my own! This comes with a few key benefits in the long run but the main benefit i get out of the process is being able to know exactly what is happening when it happens. If something goes wrong; I'm the one that can fix it, because I was the one who wrote it! Now I'm like this with most things but not everything. Some stuff like Matrix math and Transformation parent system I leave that work to the professionals because normally it works right every time and even if I did write it myself it wouldn't turn out how I envisioned it.

Scene System

So starting from the top I have a Scene system that manages my Update and Render loop for different times during the game. If you're familiar with Monogame you'll understand what that means but the jist is that Monogame give you two functions "Update" and "Render" they're called each frame and they're quite self explanatory. I have a system set up where I inherit a "Scene" class which allows me to feed those Render and Update methods down the stream for say.  

Entity System

Diving a little bit deeper into the Scene class I have a List of "Entity" classes which is pretty much an object that holds all of the data and functionality of everything in the world. For example the player is an Entity and all of his functionality is handled on this entity class. Now each entity doesn't inherit the base Entity class rather each entity contains a list of "Attachment" classes which act as the pass through for those Update and Render methods I talked about earlier. This system is not how a traditional ECS system works but it works for me so that is how I often set it up. Dividing all of the functionality into these attachment classes comes with a few advantages. It allows the functionality to be really close to the data its most likely going to be manipulating. 

What I didn't reinvent

Physics

So something I know very little about apart from basic AABB collision is full on simulated 2D physics worlds. There are plenty of highly usable libraries out there that can easily be added into most game engines and provide super simple and straight forward results. Many of these 2D physics simulation libraries are much very alike and work about the exact same so once you know one of them you pretty much know all of them. For Missing Link I'm using a build out version of Aether2D  Found Here. It's the most up to date physics simulation I could find and it works exactly how you'd expect it too. It's also build with some helpful diagnostic tools which is a plus. 

Transformation Matrix

Like Physics transformation math is going to be the same across the board in most game engine use cases. I needed very little from this so I opted for the likes of Transform by Aloïs Deniel on github Found Here

Camera's & Viewports

Something like an Orthographic camera can be accomplished very easy in Monogame without using any external libraries but I decided I want the extra functionality of a full featured camera and viewport package. For this I'm using Monogame.Extended to provide this functionality. Admittedly this is something I can write myself but there isn't any point when it will give me back near exact results.  

Renderering

Now writing an entire renderering system from the ground up is no easy feat. Doing this would allow zero time for game development all time for writing all the boiler plate code to even get a polygon on screen. Monogame provides just the right amount of usefulness to work for nearly all 2D workflows in my opinion. 

Monogame's Content Pipeline 

I'm sure I'm not alone in saying this but I really really dislike the Monogame Content Pipeline. I found that my workflow doesn't allow for the usefulness it can provide other people. The downsides of the pipeline out weigh the upsides of its functionality. In my experience it's crashy and doesn't respond nicely when using external libraries like Monogame.Extended.  In the my test build of the game I'd implemented my own pipeline managment system to allow me to do what I need. Coming from a strong background of work in Libgdx where you just load of the raw texture from disk it feels like a lot of extra work to just load up a texture or something else that isn't default in it.