Currently, unity-renderer entry point is segregated between a few MonoBehaviour objects present on the InitialScene unity scene.
Main object
All bridges
Player object, that contains CameraController
TutorialController in charge of Explorer's tutorial.
SettingsController with a few objects used by the Settings menu.
NavMap in charge of the minimap
HUDAudioHandler in charge of the audio system.
A few minor objects, like SceneReferences, MouseCatcher and Environment
This has a few design issues:
By having some systems scattered over the scene, we encourage singletons and unmanaged global access.
More global access leads us to unreliable tests, as we don't have a clear lifecycle of some parts of the project.
As we don't have a clear system lifecycle, integration tests have to rely on loading the entire scene, and this make the tests slower over time as new systems are added to the InitialScene.
We don't have control over the loading order, and all the MonoBehaviour drawbacks stated in #14
Actionables
[ ] Clean up InitialScene by removing all the systems initialized via MonoBehaviour. Setting components can still be left on the scene if this makes sense and they are directly tied to Main initialization.
[ ] The application lifecycle starts and ends on Main only.
[ ] All systems are moved to Environment, HudController or some kind of feature controller using SOLID.
Problem Statement
Currently,
unity-rendererentry point is segregated between a fewMonoBehaviourobjects present on theInitialSceneunity scene.MainobjectPlayerobject, that containsCameraControllerTutorialControllerin charge of Explorer's tutorial.SettingsControllerwith a few objects used by theSettingsmenu.NavMapin charge of the minimapHUDAudioHandlerin charge of the audio system.SceneReferences,MouseCatcherandEnvironmentThis has a few design issues:
By having some systems scattered over the scene, we encourage singletons and unmanaged global access.
More global access leads us to unreliable tests, as we don't have a clear lifecycle of some parts of the project.
As we don't have a clear system lifecycle, integration tests have to rely on loading the entire scene, and this make the tests slower over time as new systems are added to the InitialScene.
We don't have control over the loading order, and all the
MonoBehaviourdrawbacks stated in #14Actionables
[ ] Clean up
InitialSceneby removing all the systems initialized viaMonoBehaviour. Setting components can still be left on the scene if this makes sense and they are directly tied toMaininitialization.[ ] The application lifecycle starts and ends on
Mainonly.[ ] All systems are moved to
Environment,HudControlleror some kind of feature controller using SOLID.