ADR-23: Entities meta-data flow for builder in-world

More details about this document
Latest published version:
https://adr.decentraland.org/adr/ADR-23
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

Builder in-world needs having per-entity meta-data. For now, is believed that this data stores editor specific attributes, like entity names, lock status, and so on.

This data will be replicated across the network, and will take part of the scene state.

At the moment, the following data is needed per-entity:

The options have been discussed on the following needs:

Considered Options

Option 1: Use many ECS components to deliver the data

With this solution, a new ECS component will be created for each unit of data.

{
  entities: [
    {
      id: 'Entity 1',
      components: [
        {
          type: "name",
          value: "Mi nombre"
        },
        {
          type: "floor",
          value: true
        },
        ...
      ]
    }
  ]

The following concerns were raised against this approach:

Option 2: Use a single ECS component with all the needed attributes

To deal with the Option 1 scalability issues, we discussed to just put all the attributes into a single component.

{
  entities: [
    {
      id: 'Entity 1',
      components: [
        {
          type: "EditMode",
          value: {
            name: "Mi nombre",
            floor: true,
            visible: true  
        }
      ]
    },
  ]
}

This enables us to solve Option #1 scalability and maintenance issues.

However, it raised the following concerns:

Option 3: Decouple the data model from ECS, send the data through a custom pipeline

We can ignore the component pipeline and have the editor meta-data as a raw dictionary in the stateful scene model.

{
  entities: [ ... ]
  editInfo: [
    {
      entity: 'Entity1',
      value: {
        name: "Mi nombre",
        floor: true,
        visible: true
      }
    }
  ]
}

Option 4: Use many ECS components but deliver the data on a separate set

To counter the data translation issues posed by the option #3, we can keep the data separated from the rest of the "runtime" components but as ECS components.

{
  entities: [
    {
      id: 'Entity 1',
      components: [ ... ],
      non-runtime-components: [
        {
          type: "name",
          value: "Mi nombre"
        },
        {
          type: "floor",
          value: true
        }
      ]
    },
  ]
}

Very similar to option #3, but now we use components as option #1. We still have the scalability issues of option #1 and the danger of data-domain mismatch of option #3.

Decision Outcome

Criteria for components:

Looking at the data based on its use cases and future plans for builder in-world, we can group them like this:

Participants

License

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