i5 Services or RootObject managers?

[BenediktHensen]

Pros of services:

• Singleton managers in Unity are not true singletons - there is no guarantee that an object does not add a second manager of the same type in the scene somewhere. For this, the singleton implementation has a check during its initialization where the component destroys itself it is was added twice. However, this might be confusing to developers if their code accidentally added the second component but then it just silently destroys itself and is not available with the given settings later on.
• Services can be hidden behind interfaces: with singletons, you need to access them by their exact type MyManager.Instance but with services, you could access them via an interface, e.g., ServiceManager.GetService(). This means, that we can dynamically switch between service implementations and the calling code can continue calling the common interface for these service implementations.
• Services are more straightforward to test because they are not MonoBehaviours and so, they do not need to exist in a scene. A unit test can simply set up the service and run it. For managers, the unit test needs to load a scene or set it up first, then trigger the MonoBehaviour life-time events, which is not that straightforward to achieve, and can only then test the manager's functionality.
• Since they are not derived from MonoBehaviour, services can even be implemented without an open Unity instance, e.g., as part of a console application where its functionality can be tested first, before moving it into the Unity project. The service can also lead to other plain C# classes and an entire module that does not know anything about Unity as it is, e.g., only working with data fields but not actually changing the scene.
• Because of this, services are a really nice level of abstraction both to abstract away from the scene as a dependency and to abstract away from specific code. Sevices have a higher potential to decouple pieces of code: https://gameprogrammingpatterns.com/service-locator.html
• We have a lot of control over the initialization order as the services are registered one by one in an order that is given by our code; compared to this managers initialize themselves in Awake or Start and they are executed in an arbitrary order determined by Unity. So, if we have to managers that depend on one another, it can happen that they are initialized in the wrong order; in this case, workarounds by spliting initialization between Awake and Start are necessary.
• Services are not tied to components in the scene and so, they persist even across scene changes without having to ensure that a GameObject survives the scene change.
• The services need to be added to the program in code, e.g., with a bootstrapper class, which can be more easy to maintain as everything is happening in one place instead of having many managers that are spread across multiple objects in the scene.
• Microsoft's MRTK makes heavy use of the service locator pattern and they claim that it is more performant than MonoBehaviour scripts.

Cons of services:

• Since services are not based on MonoBehaviour, they are not as beginner-friendly for new developers who are used to building everything as MonoBehaviour scripts that are then added to objects as components.
• References to elements from other code needs to be provided explicitly to the service, e.g., when setting up the service. It means that the code shows very clearly which dependencies are used but can also be tedious if many external references to elements in the scene need to be added. To add scene elements via the inspector, the reference is currently first added to the bootstrapper class and then passed from the bootstrapper class to the service.
• The services currently need to be added to the program in code, which adds more lines of code and is less quickly done than directly adding a manager component in the scene. We could add inspector panels for configuring services but in its current implementation, this option is not realized. The MRTK also achieved self-registering services which just add themselves to the service manager once they exist but our current implementation does not have this.
• Managers can directly react to MonoBehaviour lifetime events such as OnEnable, OnDisable, OnDestroy. For services, an implementation for frame-wise execution, similar to Update, is provided, along with alternatives that correspond to Awake, Start and OnDestroy but for other lifetime events, custom implementations would need to be added so that the events reach the service.

Services encourage modular, abstracted code where the developer is very concious about all added dependencies to other code or to scene elements. Personally, I quite like this as it means that an architecture with a clear separation between data, application logic and the scene can develop. This way, the application logic layer has well-defined interaction points to read and act on elements in the scene. Unity's components, and thereby, also managers, blur this a lot more as they are already part of the scene and tied to GameObjects. With these MonoBehaviour components, it is more tempting to just quickly reference GameObjects and other components to get the necessary data to realize a functionality without considering whether it would be better to first organize information into an abstracted overarching data model that then drives the logic. However, achieving a well-separated architecture where no corners are cut, is a constant effort and is especially difficult to do in an existing project that already relies a lot on components.

My proposal is to not fully ban the use of one of the two approaches but instead have a clear guide on when to use which. I would suggest the following distinction:

• If a functionality just affects one object, make it a normal component.
• If a functionality affects multiple objects or many different scripts need to access information from this functionality, make it centralized:
  • If a centralized functionality is heavily tied into the scene, e.g., it needs to manipulate multiple objects, has lots of references to GameObjects, etc., it should be a manager.
  • If a centralized functionality can be abstracted away from the scene specifics, e.g., to realize web access to an API, or have very little references to elements in the scene, e.g., for a 3D model importer or to keep track of data model, a service should be used.

[cawke]

in fact, in the current implementation there is almost no difference between i5.Service and RootObject, and almost all the advantages described above can be applied to RootObject.

if the current managers are renamed into services, implement the basic interface; they can also be used in i5.Service.

about MonoBehaviour in managers. Managers should not inherit from MonoBehaviour and use their base events. Now this is present only because we do not have a manager for working with Addressables to obtain the prefabs we need and the need to test various implementations of managers for different platforms in the editor. Also, inheritance from MonoBehaviour can be done for the purpose of Profiling the performance of an individual manager, but this is for the future.

i5.Service has a real advantage in terms of testing, since some managers may have links to other managers (which services in i5.Service will also have).

I would be happy with an intermediate option using i5.Service, which stores the managers currently implemented. The idea is that we work with a manager that works with services, stores some data and notifies everyone subscribed to it about data changes (mainly needed for future work with ui). We will also need a manager to work with various implementations of services for certain platforms, providing another level of abstraction.

but you need to understand that for this you will need to implement a manager for working with Addressables (which will still need to be done in the future).

Do we need to transfer RootObject to i5.Service now? Considering the small amount of time that I can now devote to the project and the number of our tasks, I think not. It is easier to transfer as managers those several services that currently use i5.Service.

current initialization of the root object

current initialization of the i5.Service