ADR-22: Quests Progress UI

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

Context and Problem Statement

How to render the Quests progression?

Based on the context of a previous meeting with Pravus, Alex, Pablo, Marcosnc and Mendez on Jan 7, 2021:

Portable experiences & quests

How do we integrate quests with portable experiences?

The quest (the SDK scene running the logic and visible part of the quest)

Considered Options

Option A

sequenceDiagram
  quest_scene->>controller: make some progress
  controller->>server: update quest state
  server->>controller: new state
  controller->>unity: quest progress state(new state)
  controller->>quest_scene: new state (return)

Option B

sequenceDiagram
  quest_scene->>controller: make some progress
  controller->>server: update quest state
  server->>controller: new state
  controller->>quest_scene: new state (return)
  quest_scene->>unity: quest progress state(new state)

It enables us to test the UI without interacting with the controller or the scene:

sequenceDiagram
  quest_scene->>unity: quest progress state(new state)

Implementation details

The renderer will receive an entity with a component of the type QuestTrackingInformation(data). Based on that component, the renderer will have custom logic to render the component following the UX designs.

Since the component will be tied to an entity, once the entity is removed from the engine the UI will disappear.

UI for quests is different than UI for the rest of the SDK, it has few customization options and it doesn't dissapear if you leave the boundaries of the scene. This is so, to enable a better experience with quests and because the UI/UX designs also offer a way to close the individual UIs.

Decision Outcome

We choose B because it enables us to render the quests UI without coupling the quests controller and therefore, the server. Also positions Decentraland in a more decentralized path by making centralized servers not required to access the features.

Anyone could now implement their own custom Quests servers without asking permission or having the platform as a limitation.

License

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