Design constraints for games
This document covers some key points to consider when designing a game for Decentraland. Considerations such as the adjacency of other scenes and the distributed ownership of the LAND make Decentraland a unique place that requires you to reconsider assumptions you may have from previous games.
For instance, you must understand that, unlike in other game platforms, Decentraland games don’t exist in a vacuum. You don’t have control over what’s in adjacent scenes, and you don’t have control over certain details like the player’s avatars or items they could bring in from other games. This opens the door to exciting possibilities, and requires you to think about game mechanics differently.
The closest thing in mainstream games right now is Roblox, where content that’s generated by users in the community can then be a meeting place for others to explore, play, and interact. Unlike Roblox, you navigate scenes not by browsing a menu of unrelated experiences but by physically exploring a terrain where all scenes are adjacent to each other. Decentraland also makes use of the blockchain as a way to manage ownership of land, avatars, assets, etc.
We’re continually improving the SDK, so some of the following limitations will be removed with future updates before Decentraland is opened to end users.
Scene boundaries #
Your game must fit entirely in the LAND that your scene is built upon. For small scenes, think of games like soccer where the rules of the game keep the relevant interaction within a confined space, even though players are able to step outside of the playing field. Players can walk outside of a scene’s boundaries, but any asset or entities that belong to the scene must stay within the scene.
Players that step outside your scene keep rendering it as long as it’s at a visible range. If they walk away too far, they will stop rendering it entirely.
You could also build a game that spreads out throughout several disconnected plots of land that are unknown to players, and where the exploration of the rest of the world becomes part of the gameplay. A game like that would be made up of multiple separate scenes, that could share data with each other via a server.
User inventory #
There currently isn’t an inventory where players can store game items as they walk between scenes. The following alternatives are available today:
- You can store inventory information in the scene itself and link it to each player’s Ethereum address (this can be used as a persistent id). This information would only be readable from your scene.
- You can use an external custom storage and sync all of your scenes to it. This is a more robust solution that can deal with larger volumes of players. It can also extend the access to this inventory to multiple separate scenes that you or others own.
- Use tokens in the blockchain to handle the ownership of items.
When earning a game item, it could be stored as a special token in a player’s Ethereum wallet. When a player that possesses the token walks into your scene, your scene could grant the player certain characteristics within the game.
Other scenes could potentially also respond to the same token in different ways, which can make for interesting interplay between games.
The downside of using the blockchain to store inventory items is that all transactions have a cost for the player and aren’t immediate. Read more about the blockchain in a specialized section further below.
In future releases, players will have an inventory they carry everywhere which will include both on-chain and off-chain assets.
Portable experiences #
📔 Note: Portable experiences and smart wearables are still in an exploratory stage and not yet available for community creators to make.
Portable experiences are parts of the gameplay that players take with them as they move through the metaverse. These are not tied to parcels of land, they are sometimes tied to tokens, or sometimes launched by the explorer. For example, a player could take a snowball from your scene, walk away to another scene, and throw the snowball to another player who’s also playing the same game.
Smart wearables are a kind of portable experience that is tied to a wearable token and turned on when the player puts on the item of clothing. Smart wearables can grant players new abilities, like a jetpack that lets them fly, or add a new layer of content on top of the rest of the world, like randomly placing coins to be collected throughout the whole of genesis city.
Keep in mind that players might be using someone else’s portable experience while on your scene. See User Data to learn how to check what portable experiences a player currently has activated.
Game Persistence #
Decentraland is a persistent world, your scene can be visited by players at any time. Your scene has no startup phase and no ending, so you should design the game mechanics in a way that allows players that walk in or out at any time to also participate.
Your scene could have a reset mechanism that sets it to an initial state, but you should be careful not to disrupt the game for players who are already playing.
Sync scene state #
Currently, scene states aren’t shared between players unless manually implemented. This is the simplest way to build a scene, but it’s not ideal for social experiences.
You can use the MessageBus to use the same messaging architecture used to share player position changes and chat. These state changes are not stored anywhere. If no players are currently near the scene and loading it, the scene will reset to a default state the next time it’s loaded.
You can host your own server to store information about your scene and keep all players in sync with it. This ensures good connection speeds and keeps the scene running continuously even when no players are near. If you do this, your latency limitations would be no different to any other massively played online games.
Hosting your own server is also a recommended safety measure for games that involve transactions with valuable game items, as you can keep certain information like security tokens only in the server, never exposing that information outside.
📔 Note: In future releases, we will provide out-of-the-box solutions and code examples for how to implement your own server.
Game timing #
Games that use default communications architecture should take into account that there could be lag between players and shouldn’t rely on fast reactions between the actions of different players. We recommend games that are turn based, or that are mostly based on player versus environment interactions.
For games where the timing of actions between players is critical, like a first person shooter, you should implement your own server as a real-time authoritative source of truth between all players in your scene.
Players in the scene #
Players are identified in Decentraland using their Ethereum wallet address. This wallet is used as a persistent ID that’s already associated with all of the tokens that the player owns.
There currently is no way to limit how many players can be present in Decentraland at the same time. Unlike a lot of other games where there may be different game sessions hosted in separate servers, there’s only one instance of Decentraland shared between all players, at least for now.
You need to keep in mind that there may be several players walking around your scene at any given time. Some of them might be walking through and not participating in the game. Make sure that the game mechanics can’t be easily disrupted by this.
The game loop of your scene can’t affect players directly, the scene has a reactive approach to the player’s actions. If a player is standing on an entity and the entity moves or rotates, the player will move with this entity. This is especially useful for elevators, floating platforms, and the like.
As the owner of a scene, you can’t forcefully push or teleport an offending player out of your scene. However, you will be able to blacklist players in the signaling server. You can also implement a blacklist in your scene’s code and deny certain services to blacklisted players.
Scene content limitations #
Please build your scene being extra careful with the efficiency of your code. Decentraland needs to run on web browsers and mobile devices, and players will be rendering multiple scenes at the same time as they walk through the metaverse.
You should also try to keep the scene lightweight. Unlike other online games where the same textures and assets are conveniently repeated throughout a large open world, in Decentraland every scene could have its own completely different set of assets. As players walk through multiple scenes, they should be able to download the entirety of the scene content, including textures, sound files, etc at a reasonable speed.
Because of this, we’ve imposed some limits to prevent excessive use of computational resources. See scene limitations for details on what these limits are.
Access to scenes #
The map of Decentraland is designed so that there are roads and public plazas, these guarantee easy access to various parts of the map, regardless of what other people build. Plots of land that are not adjacent to any road or plaza run the risk of being walled out by neighbouring scenes, although we expect most scenes to be walkable and not block others out.
New players will start their experience in Genesis Plaza, in the center of the map, where they will be encouraged to follow some tutorial activities and then to explore the world.
Players can also manually type a URL for a specific coordinate in the Decentraland map to spawn to that location. You can also share links to URLs that have hard-coded initial coordinates.
Keep in mind that if a player starts at a location that is walled out or below the level of the terrain, it won’t be a pleasant experience. To avoid this, there’s a way you can define a set of specific locations in your scene that is safe to spawn into. See scene metadata for details.
In future releases, players will also be able to navigate the world rapidly using maps with spawn points, lists of popular locations, and friend locations. The SDK will also make it possible to add teleports in your scene that can transport to other parts of the world.
User UI #
The default overlaid UI that players see when entering Decentraland has only the essentials. You can add extra elements to that UI while a player is on your scene. Keep in mind that the Decentraland default UI is displayed above anything from your scene, so design your UI so that it doesn’t overlap with this.
When a player steps outside the scene, all UI elements are removed to not intervene with other scenes. Players also have a button available in their screen to toggle all UI elements in the scene off, this is mainly useful to prevent abusive behavior by scenes that may want to cover all of the player’s field of view.
Physics #
Keep in mind that the SDK doesn’t provide its own physics engine. If you want to use physics in your scene, you can import a library or code the behavior yourself.
Controller Inputs #
Your game controls should be limited to basic movements, jumping, point and click, as well as a primary and secondary button. We will support mobile and Virtual Reality controllers, so we can’t assume that everyone has a keyboard.
We have support for global button up and button down events for all three buttons. All three buttons also have hit events that let you identify if an entity was in the player’s aim.
Avatars #
Players can build their avatars based on a set of default wearable items. We will expand the list of available wearables and options, and in the future we’ll also make it possible for third parties to create and sell wearables.
Communication between players #
Users are able to chat with each other. Avatars currently have no way to convey body language beyond the use of basic movement controls.
In future releases they will also be able to do voice chat and to perform gestures like dancing or frowning with their avatars. They will also be able to display a temporary emoji above their avatar to express themselves. Players will also be able to display tokens they own so that other players can see them.
Game notifications #
There currently is no cross-scene notification system. Any game requiring notifications displayed outside of the current scene is going to have to implement them using an external service.
Using the blockchain #
In Decentraland, the blockchain is used to store information about ownership. Today this mostly refers to LAND ownership, but it can also be used ownership of game items, wearables, special avatars, emotes, and tokens that can ensure certain game privileges or access to games.
The blockchain isn’t used to store the game state, player position or anything that needs to change in real time.
LAND and MANA #
Players don’t need to own any parcels of land to participate in the metaverse. In fact, the vast majority of players won’t. Player avatars and the LAND tokens that they own aren’t connected in any direct way.
Players don’t need to previously own an Ethereum wallet or MANA tokens to enter Decentraland. If your gameplay relies heavily on owning tokens, you would be excluding most players. A freemium game model could be an ideal way to tailor to both user bases.
Other NFTs #
You can use special non-fungible tokens (NFTs) to represent game items, custom avatars or wearables. If a player owns one of these tokens, your scene could respond to it in different ways.
Read about what NFTs are in this blogpost .
In-game transactions #
Your scene can support blockchain transactions for players to buy or earn tokens.
Blockchain transactions aren’t immediate, they require verification times and have a cost in Ether, both the time and cost vary depending on the current usage of the network.
Decentraland is working on creating a side-chain that will be able to handle transactions faster and cheaper than the Ethereum network. This side-chain will be ideal for in-game transactions, as changes can occur closer to real time and at a very low cost. The main Ethereum chain will still be recommended for transactions that require higher security and that can afford to be more expensive and take longer.
The player must always approve these transactions explicitly on their Ethereum client. For example when using Metamask, Metamask prompts the player to accept each transaction before it’s processed.
Players could also sign a contract that automatically approves all transactions requested by a specific address or within certain constraints, so as to avoid interruptions to approve transactions.
You can also use smart contracts to condition transactions based on custom conditions. For example, players could stake a bet on the outcome of a game, and the corresponding payments would occur automatically as soon as the outcome is known.
To implement blockchain interactions in your scene’s code, you must use external libraries that interface with the Ethereum network. Future releases of the SDK will provide a custom API to expose these functionalities in a simpler way.