In the previous article of this mini-series I talked about the problems inherent in MonoGame (and other Game Engines) that effectively prevent Dependency Injection (DI). During the development of Clean Space I made several attempts to resolve this particular issue, and in this article I want to describe the first (pretty crude) mechanism I put together.

Quite some time ago, following a short and shallow review of the game development industry, I started writing a game; Clean Space. Work on the game is ongoing and I have learned an incredible amount so far. Whilst I’ll happily talk the ears off of anyone in proximity that shows but a hint of interest, I’ve done very poorly at writing down some of the lessons I’ve learned throughout the course of Clean Space’s development. So, in this article, I want to talk about “The Game Loop”, how it fits into major Game Engines, and why I very quickly came to the conclusion that it is wrong.

Whether you’re a game developer, or write software for large corporate enterprises, there is one frustration we all share. The end user always finds a way break our software, or find a way to make it behave strangely. It’s never the user’s fault, our failings in UI/UX design, our missing restraints and misunderstanding of user intent all point to the developer being at fault. Of course, this only makes the situation all the more frustrating.

In this article I’m going to delve into some of the science behind the exploration aspects of Clean Space, and perhaps tackle a couple misconceptions that you and I may share, such as the title of this article. Nothing I’m presenting here is ground-breaking, but I hope you find some of the facts interesting as we recap ourselves on those awful trigonometry lessons or physics classes of your past! Don’t be put off, I literally had no formal education beyond Secondary School in the UK (10th grade - or sophomore I believe it’s called - in the US), so there should be nothing here most layman can’t grasp. I’ll apologise now, because that same education (or lack thereof) will no doubt account for some level of ignorance and subsequent mistakes in this article; if the actual smart people fancy lending me some pointers in the comments section, I’d be very grateful!

In my previous post I talked about the reasons for writing a game, but without going into the detail of what the game is actually about. In this article I hope to clarify some of the high level detail, concepts, and goals of (code name) Clean Space, to give an idea of the scale involved and an idea of what this series has to look forward to.

All my life I’ve dreamt of writing a game. Not just any game; one game in particular. The subject of countless hours of daydreaming, theorycrafting, brainstorming, and outright planning. For a long time I put off this endeavour, all too aware that one should never undertake a project of the magnitude I intend for my game, as their first game. I’ve glimpsed at the possibility of game development from afar whilst growing my skill and experience as a Senior Software Developer. At long last, it’s time to act.