Deep Dives, Dots and Diagrams

We’re going to try something a bit different this week; we’re going to do a bit of a deep dive on one of the systems I’ve been working on. It should be understandable for folks with no coding knowledge, so don’t be scared to read on! Normal blogging should resume next fortnight. I will give you a brief rundown on the last two weeks before we get into that though!

I’ve spent a lot of the last fortnight brushing up on some programming fundamentals. I was attempting to refresh myself on my entire games programming course in record time. It has been a wild ride. From the Dot Product to Path Prediction to Q-Learning, I’ve been stuffing as much information into my brain as I can.

You know what? It has been fantastic! I had forgotten the simple joy of learning things for the sake of learning. That endorphin rush when you go “OH!” and your world gets a little bit wider is addictive. I’ve loved every second.

So what of Strays? Well. I’ve been working on some less visual internal code I’m afraid. Namely the Event System. I’ve been building a flexible way of sending information to a bunch of places. Let’s take a closer look!

Deep Dive on the Event System:
There is a concept in programming called “clean code”. This amounts to writing code that is efficient, and easy to understand. It makes code easier to come back to, makes it easier for others to understand, and avoids unnecessary code bloating. It’s a huge topic that I cannot unpack in a single post! However, one of the concepts important to writing clean code is “Blackboxing”. This means making each section of your code a closed system, an isolated pocket that is independent of the rest of the codebase. For example, an Input System does not need to know about the Audio System.
There are a lot of practical reasons as to why this makes a lot of sense. The biggest one is that it avoids dependencies, and makes your code more flexible. It’s a lot easier to swap out an Input System if nothing else is relying on it being there! The problem then becomes, “Well what if I need to send another system a message?” That’s when things get complicated.

Lets take an example: When we are on the start screen of a game and press the A button to start a New Game, we need a few things to happen. We need the button to respond, to flash or give some visible cue that it has been pressed. We also would like it to make a sound, an audio cue. Most importantly, we want the game to start loading up the first level.

Ok, so let’s assume we want to do all of that from some “OnA” function. This might be a function on the button, or in the UI, or in some “Game Manager”. We’ll assume the latter for now. “OnA” will need to check the Input System every frame to see if you have pressed A. It will also need to know about the New Game button, so it can do the visual effect. Finally, it will need to know about the audio system so it can request it play a sound, and we will assume the loading happens in Game Manager. Let’s look at that:

This isn’t the worst example by any means, but you can already see, Game Manager needs to know about a lot of things, and we have arrows going in both directions. It could also be that the button controls the sound, so Buttons need to know about the Audio System and connect to the Game Manager, which might use the Audio System for background audio, and the input system detects volume changes so connects to the Audio System also and… you get the idea.

Instead, what if we had just one way of communicating between each of these systems? This is where an Event System comes in handy. The simplest method of using an event system is to have a list of Events, which could just be the text (or string, in programming) “A_Button_Pressed”, that other entities can ask to be told about. The Start Game Button, Game Manager, and Audio System will ask the Event System to tell them when the “A_Button_Pressed” event happens. Input System tells the Event System when that happens through a “Dispatch” function, then the Event System sends that message out. The Start Game Button receives that message, and flashes. Meanwhile the Game Manager and Audio System have also picked up that message, and start loading and play the correct sound respectively, all without knowledge of each other’s existence.

What’s more, thanks to a nifty coding concept called an “Interface” the Input System doesn’t even need to know that Game Manager, New Game Button and Audio System are those things; to the Input System they are just an “Event Receiver”. I won’t go into how exactly, but it is because the Event System doesn’t need to know that they are those types, it only needs to know that they can receive messages! Pretty nifty right?

Now the Input System doesn’t know about any system other than the Event System, the Event System only knows about Event Receivers, and nothing else is aware of anyone else’s existence! Our code is blackboxed, and we can still inform each system about tasks it needs to do!

So that’s basically what I’ve been working on. As you might imagine, my version is a little more complex than the above. For example, I want to package data with my event, so I need to account for data being sent around. But the principle is largely the same!

Anyway, that about does it for this post. I’m hoping to return to the more visual blogs I’ve been striving for of late soon. Until then,

Matt out.