Unity Game Architecture

Question

I'm working on a relatively simple game, but even simple games have a lot of moving parts, and I'm running into some architecture issues. Just to be clear, everything works fine, but it feels dirty, and that's usually a sign of a problem.

So, I'm following SOLID principles, which, by my understanding means that I should have many scripts that each do a single thing versus large scripts that do many things. It makes things easier to maintain, but linking things that require references turns into a mess, for me at least.

To get more specific, my game uses a grid. Great, I've got a script that represents a grid and contains methods related to the grid (ex: converting from world to grid position).

I've got another script that instantiates the grid and manages things with the grid in a level, such as populating it. Then I've got a script that handles the merging logic for the items on the grid. (matching game logic)

Then, I've got a score manager that manages the game's score, and then I've got a UI manager that manages the UI.

The thing is that the merge script requires a hard reference to the grid to work, and the score manager requires a reference to the merge script, and the UI manager requires a reference to the score manager, and by the end of it, everything is referencing everything.

For the record, I'm trying to avoid inspector references, and instead referenced the main components using the Singleton pattern. But I don't like it.

Is there a better way?

The only thing I can think of is having a game manager script that references everything and then handles communication between all the other managers.

Answer 1

It seems that you're generally following SOLID principles and utilizing the Singleton pattern, which is a step in the right direction. However, relying heavily on the Singleton pattern can often result in tangled code where components are overly interconnected, as in your case.

As with many architectural challenges, the appropriate solution depends on the specific context of your problem. In this scenario, employing a service locator pattern could offer a more elegant approach to managing dependencies.

Here's how a service locator pattern might be applied:

Registration: Essential services, such as the grid or score manager, would register themselves with the service locator, associating each with a unique key or identifier. This registration typically occurs during application startup or initialization.

Lookup: Clients of these services can then request an instance by specifying its corresponding key or type. The service locator responds by querying its registry and returning the requested service instance to the client.

Instantiation: In some cases, the service locator may need to handle the creation and lifecycle management of services. However, in your scenario, since essential services like the grid are likely already present in the scene, you may be able to skip this instantiation step.

Using the service locator, clients are effectively decoupled from the specific implementations of services. They can simply request services from the locator without needing to be aware of how those services are created or where they originate. This promotes cleaner, more modular code and simplifies the process of integrating and maintaining various components within your game architecture.

Answer 2

There are a couple ways you could approach this depending on your needs and viewpoints.

The first method would indeed be to use singleton patterns for each manager. This is the approach I personally use in my game with about 80+ scripts and I've never had a huge problem with it.

Benefits:

• Easy to implement
• Accessible by any script (no reference needed)

Drawbacks:

• Can be confusing

The other method is to use some sort of "level asset", I also use these in my project however its slightly more complicated.

The idea is you have a Game Object, I usually call mine "Level", tagged with some specific tag like "LevelAsset". Then you create some kind of LevelAssetLoader script that can take all the references and place them into reference slots within the specific managers.

Benefits:

• Gives a clear place to drag and drop scene references
• Easy to swap/remove/change values

Drawbacks:

• You would have duplicates (for example all the references in GameManager would also need to be in LevelAsset which may become confusing and unneccessary)
• More references
• Can be messy

Both have their pros and cons, so me and my team tend to use both, but it's up to how you like it. I think singletons are much easier, but its personal preference.

Answer 3

Ultimately, I find that giving classes meaningful names, and using "as many namespaces" as necessary to make sense of it all, is what keeps things sane. The harder a class is to name, the "busier" it probably is; that's where the (static) "one method per class" starts making more sense. I realized I had a "Geometry" namespace, if I just gathered all my "calculators" in one place. That was a reward in itself. (Now I can create a "geometry dll" if I need to).