This ADR proposes the implementation of player data components in SDK7 to enhance the information retrieval and management of player entities. The goal is to improve the real-time player data experience by reserving specific entities for players, optimizing data updates, and ensuring every scene receives player data components.
In SDK6, retrieving player information involved an async function, which provided data from the closest tick, resulting in latency between the actual player state and the received data. SDK7 introduces a new approach to address this limitation by reserving entities specifically for player data. Entities 0, 1, and 2 are reserved for the root scene, current camera, and current player, respectively, leaving 509 entities available for further optimizations.
The proposal consists of the following key points:
Transform
updates. Non-active parcel scenes MAY
have no Transform
of the player outside of them. Exception: the primary player
Transform
MUST be present in all scenes.
// AvatarCustomizations sets all modifiers over the avatar's apparence.
message PBAvatarBase {
decentraland.common.Color3 skin_color = 1;
decentraland.common.Color3 eyes_color = 2;
decentraland.common.Color3 hair_color = 3;
string body_shape_urn = 4;
string name = 5;
}
// AvatarEquipData is used to read the information about the avatar's owneables.
// this component is written by the engine using the communications transports' data.
message PBAvatarEquippedData {
repeated string wearable_urns = 1;
repeated string emotes_urns = 2;
}
// PlayerIdentityData is used to read the information about the avatar's identity.
// this component is written by the engine using the communications transports' data.
message PBPlayerIdentityData {
string address = 1; // ethereum address of this player
bool is_guest = 3;
}
// AvatarEmoteCommand is a grow only value set, used to signal the renderer about
// avatar emotes playback.
message PBAvatarEmoteCommand {
message EmoteCommand {
string emote_urn = 1;
bool loop = 2;
}
EmoteCommand emote_command = 1;
}
By implementing player data components and reserving entities for players in SDK7, we aim to enhance the real-time player data experience and streamline the retrieval and management of player information. This proposal sets the foundation for better player interactions and gameplay experiences within the SDK7 ecosystem.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", " SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.