When switching in and out of the builder in world, we need some way to switch the hide/show state of arbitrary UI elements of the explorer.
Right now, the show/hide interface responsibility is defined within the
HUDController class.
Currently, HUDController has the following responsibilities:
Kernel <> renderer bridge
Kernel sends messages directly to this class for interaction
HUD Factory
Self-explanatory. Related to instancing the actual HUD elements.
HUD Initialization
Sometimes, special initialization should be performed after the HUDs are instanced.
HUD Composite
The references to the instanced HUD components are stored in this class.
Show/hide of UI elements
Despite HUDController existing interface for showing/hiding any HUD element, a
lot of times this functionality can't be used because of how this class assembly is
referencing every other HUD assembly.
Most of the times we are faced with cyclic assembly references issues and we are forced to work around this issue.
Inter-HUD interaction
In some cases, we want a composite architecture, where one HUD depends on the state of the others.
For instance, when implementing the private chat window we had to write callbacks on
HUDController itself to be able to wire the back button to the opening of the
friends tab. This broke the encapsulation and made the HUD flow harder to follow.
There are more examples of this kind of responsibility bloat here.
Distribute the different HUDController responsibilities to individual systems
This implies a refactor and is the most likely solution that would take care of our use cases
niftly, however it would take a bit of design and coding work, because
HUDController is pretty intertwined with our current kernel <> renderer
communication and the HUD system foundation.
Move the HUD status responsibility to individual ScriptableObjects
This would allow an easy approach to handle the show/hide use case. However, it doesn't fix
the issue for Inter-HUD interaction. The idea is to have a single SO for HUD element, and then
suscribe from them in HUDController.
Note that this solution places even more responsibility burden on HUDController,
however it does so in a way that should easy to handle and move around later when we get to
the root improvement.
We agreed upon implementing the ScriptableObjects solution as a first stage, and then perform
the responsibility segregation redesign on the HUDController class later.
HUDs will be able to be toggled from any part of the project quite easily.
HUDController will still suffer from having many responsibilities, however, the
decentralized approach of the solution will keep the tech debt manageable