Scene metadata

All scenes have a scene.json file where you can set metadata for the scene. Some fields in this file are predefined with information that’s necessary for the Decentraland client.

You’re also free to add any fields that you wish. In the future, custom fields can then be checked by alternative clients, or other scripts embedded in interactive inventory items.

Scene parcels

When deploying a scene, the scene.json file must include information about what parcels will be occupied by this scene in the Decentraland map. The CLI reads this information from off this field and deploys to those parcels directly.

 "scene": {
    "parcels": [
      "54,-14"
    ],
    "base": "54,-14"
  }

This information is not necessary while developing a scene offline, unless you’re building a scene that occupies more than one parcel.

The base field defines which parcel to consider the base parcel. If your scene has a single parcel, the base should be that parcel. If your scene has multiple parcels, the base should be the bottom-left (South-West) parcel. All entity positions will be measured in reference to the South-West corner of this parcel.

To display multiple parcels in the scene preview, list as many parcels as you intend to use. They don’t need to be the exact parcels you’ll deploy to, but they should all be adjacent and arranged in the same way in relation to each other.

 "scene": {
    "parcels": [
      "54,-14",  "55,-14"
    ],
    "base": "54,-14"
  }

Scene title, description, and image

Give your scene a title, a description and a thumbnail image to attract players to your scene and so they know what to expect.

Players will see these when they select the parcels of your scene on the map, they will also see these in a confirmation screen when being teleported there by another scene.

When players navigate the world and enter your scene, they are able to read the scene title from under the minimap.

  "display": {
    "title": "My Cool Scene",
	"description": "You won't believe how cool this scene is",
	"navmapThumbnail": "images/scene-thumbnail.png",
    "favicon": "favicon_asset"
   }

The thumbnail should be a .png or .jpg image of a minimum size of 196x143 pixels.

The image on navmapThumbnail should be a path to an image file in the project folder. It can also be a URL link to an image hosted elsewhere.

Note: If you host an image elsewhere, make sure this is in a site that has permissive CORS policies for displaying content on other sites.

Contact information

In case you want other developers to be able to reach out to you, you can add contact information into the scene.json file.

  "contact": {
    "name": "author-name",
    "email": "name@mail.com"
  },

Spawn location

The spawnPoints field defines where players spawn when they access your scene directly, either by directly typing in the coordinates into the browser or teleporting.

Your scene might have objects that can block players from moving if they happen to spawn right over them, like trees or stairs, or your scene might have an elevated terrain. It would be a bad experience for players if they spawned over something that doesn’t let them move. That’s why you have the option to set multiple spawn positions in ad-hoc locations.

  "spawnPoints": [
    {
      "name": "spawn1",
      "default": true,
      "position": {
        "x": 5,
        "y": 1,
        "z": 4
      }
    }
  ],

The position is comprised of coordinates inside the scene. These numbers refer to a position within the parcel, similar to what you’d use in the scene’s code in a Transform component to position an entity.

Note: All spawn points must be within the parcels that make up the scene. You can’t spawn a player outside the space of these parcels.

Multiple spawn points

A single scene can have multiple spawn points. This is useful to limit the overlapping of players if they all visit a scene at the same time. To have many spawn points, simply list them as an array.

  "spawnPoints": [
    {
      "name": "spawn1",
      "default": true,
      "position": {
        "x": 5,
        "y": 1,
        "z": 4
      }
	},
	{
      "name": "spawn2",
      "default": true,
      "position": {
        "x": 3,
        "y": 1,
        "z": 1
      }
    }
  ],

Spawn points marked as default are given preference. When there are multiple spawn points marked as default, one of them will be picked randomly from the list.

Note: In future releases, when a player tries to spawn into a scene and the default spawn points are occupied by other players, the player will be sent to another of the listed locations. This will open the door to allowing players to teleport to a spawn point based on the spawn point’s name, as described in the scene.json.

Spawn regions

You can set a whole region in the scene to act as a spawn point. By specifying an array of two numbers on any of the dimensions of the position, players will appear in a random location within this range of numbers. This helps prevent the overlapping of entering players.

  "spawnPoints": [
    {
      "name": "spawn1",
      "default": true,
      "position": {
        "x": [1,5],
        "y": 1,
        "z": [2,4]
      }
    }
  ],

In the example above, players may appear anywhere in the square who’s corners are on 1,1,2 and 5,1,4.

Rotation

You can also specify the rotation of players when they spawn, so that they’re facing in a specific direction. This allows you to have better control over their first impression, and can be useful when wanting to help steer them towards a specific direction.

Simply add a cameraTarget field to the spawn point data. The value of cameraTarget should reference a location in space, with x, y and z coordinates relative to the scene, just like the position field.

  "spawnPoints": [
    {
      "name": "spawn1",
      "default": true,
      "position": {
        "x": 5,
        "y": 1,
        "z": 4
      },
      "cameraTarget": {
        "x": 10,
        "y": 1,
        "z": 4
      }
    }
  ],

This example spawns a player on 5, 1, 4 looking East at 10, 1, 4. If the spawn position is a range, then the player’s rotation will always match the indicated target. If there are multiple spawn points, each can have its own separate target.

Required Permissions

The requiredPermissions property manages various controlled features that could be used in an abusive way and damage a player’s experience.

The corresponding features are blocked from being used by the scene, unless the permission is requested in the scene.json file.

"requiredPermissions": [
    "ALLOW_TO_MOVE_PLAYER_INSIDE_SCENE"
  ],

Currently, only the following permission is handled:

• ALLOW_TO_MOVE_PLAYER_INSIDE_SCENE: Refers to moving a Player
• ALLOW_TO_TRIGGER_AVATAR_EMOTE: Refers to Playing emotes on the player avatar

If a requiredPermissions property doesn’t exist in your scene.json file, create it at root level in the json tree.

Note: In future releases, when a player enters a scene that has items listed in the requiredPermissions property, the scene will prompt the player to grant these permissions. The player will be able to decline these permissions for that scene.

Custom metadata

You can extend the fields in the “policy” section to whatever you think is relevant. These fields might be taken into consideration by alternative community clients used to navigate the metaverse and be used to filter content or restrict players from doing certain actions like flying or battling.

This metadata might also be used by scripts of interactive inventory items, for example a light sabre inventory item might only be possible to use on scenes that allow for battles to take place.

As clear use cases start to emerge, we plan to define more conventions over the metadata that can be added to this file.

  "policy": {
    "contentRating": "E",
    "fly": true,
    "voiceEnabled": true,
    "blacklist": [],
    "teleportPosition": ""
  }

Fetch metadata from scene code

You may need a scene’s code to access the fields from the metadata, like the parcels that the scene is deployed to, or the spawn point positions. This is especially useful for scenes that are meant to be replicated, or for code that is meant to be reused in other scenes. It’s also very useful for smart items, where the smart item’s code might for example need to know where the scene limits are.

To access this data, first import the ParcelIdentity library to your scene:

import { getParcel } from "@decentraland/ParcelIdentity"

Then you can call the getParcel() function from this library, which returns a json object that includes much of the contents of the scene.json file.

The example bleow shows the path to obtain several of the more common fields you might need from this function’s response:

import { getParcel } from "@decentraland/ParcelIdentity"

executeTask(async () => {
  const parcel = await getParcel()

  // parcels
  log("parcels: ", parcel.land.sceneJsonData.scene.parcels)
  log("base parcel: ", parcel.land.sceneJsonData.scene.base)

  // spawn points
  log("spawnpoints: ", parcel.land.sceneJsonData.spawnPoints)

  // general scene data
  log("title: ", parcel.land.sceneJsonData.display.title)
  log("author: ", parcel.land.sceneJsonData.contact.name)
  log("email: ", parcel.land.sceneJsonData.contact.email)

  // other info
  log("tags: ", parcel.land.sceneJsonData.tags)
})

Note: getParcel() needs to be run as an async function, since the response may delay a fraction of a second or more in returning data.

Was this article useful?

Awesome!

Anything we can do to make it even better?

We're sorry!

Please let us know how we can improve our documentation.

Thank you!

Your feedback helps us improve everyone's experience in Decentraland.

Have a suggestion? Edit this doc on GitHub