Why is the SaveSystem not a persistent manager?

Hi there!

I'm learning about how to make good software architectures in Unity, and this is a great working example to learn from.

All the managers are in their own scene, which never gets unloaded so they can always respond to events. So why is the SaveSystem different? I know the benefits of using a ScriptableObject over a Monobehaviour, mainly not having to worry about initialization and being able to easily reference it from any other object. But if that's the answer for why it is not a persistent manager, then I can turn the question around, why are the other systems persistent managers instead of ScriptableObjects? Hahaha

I guess the question is more about the 'inconsistency'. Why use events for decoupling some systems but not for others?

 

I suppose the simple answer is that the community decided to implement the SaveSystem sort of like a static class, but using a ScriptableObject instead, which is easier to track.

As you can see, it is a "system" and not a "manager", therefore it does not handle any sort of behavior/response by itself, but is instead managed by multiple instances that can access it via direct reference. Contrary to what you find in the "Persistent Managers" scene, the save system does not instantiate objects or interact with other systems; it acts as an internal feature of the game that simply reads and writes data you pass onto it.

Of course this is one way to do it, but it is not the only way. In fact, as long as it works and is consistent, you can implement the same system in any way possible and however you see fit for your own project.