Abstracting Out Some Common MonoGame Code

Working... But Crappy, Code!

I managed to get a version of the Pong game working, and it was kind of fine... but not. I was starting to spot eerily similar code popping up in things like the Ball and Paddle classes for example. 

Both of these objects have a texture, they have a position, a velocity and they'll use that velocity to change the position when Update() is called. They both have a bounding box which is defined by both the current position of the object and the dimensions of the underlying texture. This bounding box is used for basic collision detection. And of course, the texture is used when rendering itself on a call to Draw().

Obviously, this is the kind of pattern that is going to be repeated in any game that moves a graphical object around the screen. 

Many Small Games

A few days ago I wrote a blog post in which I explained how I'm planning to build out lots of small, simple games as I progress on my mission to learn game development. I'm not creating games like Pong because I particularly want to make or play a game of pong, but because I want to use the game to practice what I have learned so far.

By creating many small games I can iteratively apply new concepts that I have learned with each game and hopefully learn a bit more and get a bit better with each game. Plus, for me personally, it also gives me practice at actually finishing something which I am terrible at! I have a habit of starting things, then get distracted by the next shiny thing and abandoning the old thing! #adhdbrain

Always Starting, Never Finishing

This isn't just with game dev, it's everything in my life, even games I'm playing! I'll get completely obsessed with a game, put a stupid amount of hours into it, restart the game a dozen times because I didn't do it right or I want to run with a cool new mod I found, then get completely burned out by the time I've played through something like 20% of the story, despite the hundreds of hours I've put in! 

I know that if I actually want to build a meaningful game in the future, I need to squish that habit and form a new habit of building something, actually finishing it and putting it out there. This is one of the reasons why I've decided to publish on Itch because the idea of people actually looking at what I'm doing kind of holds me accountable in a way.

Anyway, back to the code.... 

Creating Utilities (An Engine?) for MonoGame

When I first started reading about monogame, I read that you need to build your own engine for it. I balked at that idea, and figured that was kind of ridiculous for the kind of very small-scoped games I was intending to create. 

However, now I've been working with it for a couple of weeks I can start to see why this is the case. The framework gives you low level access to the system stuff you need to get stuff rendered to the screen but it hasn't got anywhere near the functionality out of the box as a full featured engine such as Unity or Godot.

That's fine, and it's one of the reasons I actually decided to start with MG rather than one of those engines; I figure I will learn more by implementing some of that stuff myself from scratch. But in my naivety I guess I didn't realise  what was meant by the term "engine". 

I think in my head I was thinking that I would have to deal with lots of complicated math and physics stuff (that I am never likely to understand), and build something that does everything for every kind of game, but of course that's not the case at all. I can just put common code in one place and use it in other games - simples!

When I started out, I had no idea which parts of the code were going to be specific to a particular game, and what would be more general and able to be put into an engine of sorts. To be fair, I still don't! I think this is something I will learn as I go along; with each game I'll learn some new technique and then hopefully will figure out how that could be applied to a different kind of game in a different context.

Second Project For Common Functionality

So I created a couple of simple classes TextObject and SpriteObject for my Pong game but put them into a second project that I am pulling in for the Pong project and thus is available for the next game. With each game I write, I'll want to be looking for opportunities to extract out common classes and patterns and will put it into this base project which over time should evolve into a kind of mini-engine for my games and should make the development of subsequent games easier and faster.

GitHub Repository

At the moment, I've hardcoded the dependency from the Pong project. I don't know enough about project organisation to do it properly, and it probably doesn't matter anyway as it's not like I'm intending this to be used for anybody else. There are already some great projects built on top of MG such as MonoGame Extended and Nez, created by real gamedevs that actually know what they are doing!

But anyway I'm linking the GitHub repo in case you wanna have a look at the code.