ADR-29: Refactor HUD control

More details about this document
Latest published version:
https://adr.decentraland.org/adr/ADR-29
Authors:
kuruk-mm
BrianAmadori
Feedback:
GitHub decentraland/adr (pull requests, new issue, open issues)
Edit this documentation:
GitHub View commits View commits on githistory.xyz

Abstract

Currently, the Kernel controls the UI in Unity, with a component inside Unity named HUDController. It has many responsibilities breaking the single responsibility principle, making it challenging to adapt and change. Besides that, the architecture doesn't take into account a way of making the HUDs variables for different platforms.

To deal with those problems, we're going to split those responsibilities and modify the architecture of the HUDController to be extendable to different platform implementations, like desktop or mobile, and port the control of the HUD from Kernel to Unity progressively to make Kernel smaller and less responsible.

Needs

Current implementation

Kernel and Renderer communication

We have multiple HUDs synced between Kernel and Renderer.

When we start Decentraland Explorer, the Kernel will send a message to Unity to pre-load and show some HUDs that they live in InitialScene with a HUDController script. Then, the Kernel can hide or show those HUDs as it needs.

sequenceDiagram
  Kernel->Renderer: Load and show MinimapHUD
  Kernel->Renderer: Load SignupHUD
  Kernel->Renderer: Load SettingsPanelHUD
  Kernel->Renderer: ...
  Kernel->Renderer: Show SettingsPanelHUD

HUDController architecture

HUDController is a MonoBehavior that lives in the InitialScene. It is responsible for creating HUDs, keeping each HUD's lifecycle, reacting to the Kernel messages, and different interconnecting HUDs.

Approach

Keeping the objectives in mind, we need to create a way to refactor the HUD System progressively. Thus, we will divide it into three stages.

First stage

This stage's idea is to split the instantiation responsibilities of HUDController and make it extendable.

So, to accomplish this goal, the abstract factory design pattern will be implemented.

The classes will look like the following:

Example of extension of the factory:

So we can add more implementations depending on each platform. If we want to change the HUD's behaviour completely, you can overwrite how the HUD behaves and shows adding a new implementation of IHUDFactory.

resources/ADR-29/diagram-2.svg

Second stage

This stage aims to remove the responsibility from the HUDController to communicate with the Kernel.

Example of this system being extendable:

If we want to have different behaviour against Kernel, we just overwrite/extend the HUDKernelBridge class.

Third stage

Port the kernel responsibility of managing HUDs to Unity, and maybe implement a HUD's state machine between Kernel and Unity.

We're going to discuss this stage in another ADR.

Benefit

Participants

License

Copyright and related rights waived via CC0-1.0. DRAFT Stagnant