Overengineering Code in Unity: When Good Game Architecture Can Become a Problem

Back in September of this year, I wrote an article about decoupling game systems in Unity with an EventBus. This is a crucial part of  game architectural design, and should be implemented in those areas of your project that make sense. Once you understand it, you're probably eager to implement it everywhere! But be aware that this can also lead to some unwanted results in your project.

 

In brief: the whole idea of EventBuses is to decouple scripts, so that your whole project becomes more modular, where you can add or remove implementations without breaking the whole assembly. Sounds good? Technically it's possible to do so in your entire Unity project, but it will cause some problems, you may not have thought of. Although it's very important to understand how this observer game design pattern works, I do think you need to be cautious when implementing it.

Dependency can be a good thing.

The thing is, (Unity) Events, including EventBuses, can sometimes make certain concepts harder than they need to be. Why? Because if you have too many events, it’s harder to backtrack which script is raising or listening to it. In this case, dependency can be a good thing!

Sometimes it’s better just to keep things simple. This is particularly the case with small to mid-sized Unity game development projects.

It’s OK to utilize event systems like EventBuses when it comes to sound coordination or something else that is easily traceable in your game. For example, in my game development project, I use a struct that holds all the necessary parameters for sound management. Then this struct gets published by means of an EventBus. That’s fine. But I had a few instances elsewhere (UI system) where an error would pop-up, and I had a hard time backtracking which event was raised that caused the error. Of course, you can safeguard this by adding a simple script that just prints out all the events that are being raised by which scripts and those listening to it, but if you have a lot of Events you can imagine that it gets harder and harder to trace back the error or bug.

Keep it simple with Singletons

When you overengineer code to avoid Singletons at all cost, you'll likely end up with something worse.

Unity is already a heavily state-driven, visual, and event-based. Don’t overcomplicate things with too many architectural patterns on top of it. In many cases, you only need one system anyway. Especially in smaller to mid-sized projects, you probably only need one SaveSystem, AudioManager, or GameManager in your scene. In your game-over method, for instance, you can see line by line what is being called, and make adjustments accordingly.

When you decouple too many scripts, it can be a mystery to unravel when something goes wrong in your code.

Not every Unity project needs enterprise-level design. A solo developer or small team working on a game does not benefit from the same patterns as a large back-end service.

Don’t make it hard on yourself, as long as you know what the code is doing and it works, and there are no performance issues, there’s simply no argument against Singletons.

Don’t pass references arbitrarily between unrelated systems

I still strongly advise against caching or referencing unrelated scripts on their own though (unless absolutely necessary). It that case, I do recommend using a design pattern like the observation pattern in order to avoid the dreaded spaghetti code. If you find yourself in a situation like that, think about how an observer pattern can help.

Again, don't overcomplicate your code, and happy coding!