After working on Stellar Winds (a university final project) for over 6 months, I have managed to build an intense amount of technical debt as a result of my own negligence, in the form of spaghetti code. If you’re reading this then maybe you can avoid the same mistakes that I have made by considering modular code.

Unity offers a very easy way to remove instance reference dependencies and facilitates a space for modular architecture to shine. In this blog, we will explore what Modular Code Architecture is within the context of Unity, how to design your systems in a scalable and reusable way, and define some limitations of the architecture.

If you want access to the source code, check out my Patreon where you can get it for just $1. It takes a lot of time to research and put these together so I’d appreciate the support, thanks!  

Put simply, it is code that does one very specific thing really well. It is code that can be used by anything in any given context. Think of your classes as a specialisation, we wouldn’t want a plumber to install our roof as much as we wouldn’t want a level designer to program our AI.

Don’t worry, we’ll be going over some practical examples that you can pull from and use. By the end of this blog, you’ll have a great understanding of the concept and be able to do it yourself.

I get that you want to jump straight in and get it done. Programming and game dev is really fun, but that’s what I did with Stellar Winds and as a result, its codebase is brittle. If you jump straight in without a plan you’ll end up building insane technical debt and waste a lot of time on “unforeseen circumstances.” Just look at this health class that handles shields and health, ridiculous.

Depending on how you currently work or were previously taught, you may have been required to write a Technical Specifications Document. It’s pretty commonly disliked amongst my peers, including myself, however, in the context of modular code, it is the most important step.

We will be primarily using UnityEvents in order to make everything work and reduce the overall code we have to write, so let’s explore what we can do with them for clarity’s sake. For starters, we can call public methods from a class within the inspector. We can also parse strings and send floats if a method has a parameter. Note that only methods with a single parameter can be used like this.

We can also send dynamic variables by declaring the events a little differently. This is important to understand as we will be using it frequently. You write them as follows:

// Declaration
UnityEvent<float, int, bool> eventToCall;

// Invoking
eventToCall.Invoke(0.2f, 1, true);

Now when we hook up a class that has a method with one of the same parameters, a ‘dynamic’ option will appear in the response of the UnityEvent. Neat right? Note, you can still call normal methods when you’ve marked an event as dynamic, however, you still need to give the invoke method a value when invoking the event. That pretty much sums up UnityEvents, if there’s anything I may have missed let me know.

Now, by referring to the first instance of our tech spec, we can clearly see what methods we need to call through our UnityEvents. So let’s quickly do that. Note: objects highlighted in red are objects that the UnityEvents reference.

On Damaged

• Slider Controller – UpdateSliderValue (dynamic float)
• Animation Controller – SetAnimationTrigger(Damage Anim param)
• Animation Controller – SetBlendTarget(Blend param)
• Animation Controller – SetBlendValue (dynamic float)
• Audio Controller – Play
• Particle System – Play
• Camera Shake – LightShake

On Healed

• Slider Controller – UpdateSliderValue (dynamic float)
• Audio Controller – Play
• Animation Controller – SetBlendTarget(Blend param)
• Animation Controller – SetBlendValue (dynamic float)

On Died

• Game Event Controller – Trigger

So now we’ve managed to create a nicely organised modular system, in definite contrast to the spaghetti code you may have been writing up until now. It’s refreshing, isn’t it? However, overall, this class is much simpler than the health class in Stellar Winds (about 250 lines simpler). One thing to consider here is Stellar Winds features shields and this example system does not. “Is that why it’s 250 lines shorter?” aha, no… The next step is to scale the systems up further, so let’s start by adding shields. 

Now you could just add another float, a set of UnityEvents, and their relative methods to the Health class and call it a day. However, that’s not very modular, is it? What if we wanted to add an ability that gave the player another temporary layer of protection in the form of an over shield? That means we need to add, again, another float, a set of unity events, and their relative methods. Just as this paragraph is getting longer, so will your code.

Next, let’s make a new Health Controller class that has two “Stat” variables. These will replace our health float and acts as our new shield float. Just as before we’ll need to add ProcessDamage() and ProcessHeal() methods. Let’s also add an onDamaged and onDied UnityEvents so we have a higher level of control and remember to call each stats Tick() method in the Update() method. 

Okay great, so now we’re pretty much back to where we were except this time we have two stats to work with. The best thing is, we can add as many as it makes sense. Setting this system up is exactly the same as the previous, however, now we have control over individual stat changes nested within the new Health class.

Now you may also be thinking, “But what if as you said, we want to add a temporary overshield? Would we have to declare a new stat for each temporary item we want to add? If so, would that not just be spaghetti code creeping back into our development patterns?” You can probably guess what I’ll say at this point. Did you plan ahead and allow for temporary stats? If the answer is yes then you probably didn’t ask that question.

Easy, now when each limb takes damage, the overall speed of the player is reduced linearly. You can make this as complex or as simple as you want, but notice how straightforward it is to create more advanced systems with this modular method.

You can easily isolate function and all feedback works as intended while you make changes to your existing systems. No more spaghetti code and no more wasted time.