The purpose of this document is to help guide you through the process of building the first iterations of scenes in Decentraland. We’ll refer to these as a Minimum Viable Product (MVP).
When creating the Minimum Viable Product (MVP) for your scene, you need to think about two areas of focus:
An MVP should not try to demonstrate every possible outcome of every possible experience. Instead, an MVP should be the best first impression of your experience that you can make using Decentraland’s SDK.
It is important to consider your own limitations, how you plan to provide content to your users, and the expectations of your users. Approaching your MVP in this way requires three different perspectives:
It's important to distinguish this approach from traditional agile development, because you may have to use non-optimum methods to meet your design goals.
You will have to examine your own goals in the context of your users’ expectations to decide if a certain release is focused more on the player, the pipeline and content contributors, or little of both.
When planning each release, it is critical that you conscientiously and deliberately set your priorities according to each of these three perspectives.
You can expect your development backlog to follow two tracks:
These two tracks will also follow two different approaches to testing:
The sooner you can get a value proposition in front of your user or player, the sooner you can get feedback to either confirm or reject that proposition. Confirming value quickly is critical. Many experienced developers will share stories of how they were certain beyond a shadow of a doubt of how amazing a new mechanic would be until they used it and it felt awkward and glitchy, the players didn’t respond to it at all, or it didn’t solve a consumer want/need. You want to fail quickly with as little effort as possible, so that you can learn from your failure and plan the next iteration.
How do you fail quickly? You do the minimum needed to get your player to touch your product.
Here is the list of factors to consider for your basic MVP. It is acceptable to state that you will use something as a placeholder and will then phase it out as you develop a more solid replacement.
Art Creation
Scene Creation
Art Rendered in Scene
Player experience
Pipeline Goals
Failing quickly allows you to develop your experience by creating successive prototypes, with each iteration building upon the last.
Start with a single player prototype. Then you can plan for scripting multiplayer interactions. Finally, you can tackle your persistent core loop that demonstrates transactional layers.
What’s a persistent core loop?
In game design, a persistent core loop is the fundamental “game loop” that drives player actions and the game’s response to those actions. These persistent loops extend to any form of virtual experience (like those provided by Districts).
Note: The Decentraland client borrows some architectural ideas from React.js and only renders a scene when a change has taken place, not at a constant rate.
What are transactional layers?
The transactional layers are the interfaces between systems like an update to the blockchain or another application that has been interfaced with your experience to maintain a persistent record of player actions. Creating and maintaining this persistent record is what builds a more personal experience.
We recommend creating your MVP as a single player experience.
For example, you could design a scene with the following successive experiences:
Although the Decentraland world is not yet open to all, you can upload a scene preview to a server and easily share a link to it with people who can give you feedback.
Even once Decentraland is made available to all, we still recommend testing changes with test users in a separate preview server first, before uploading a new version of your scene to Decentraland.
Read this blogpost for details on how to upload your scene preview to a free server.
Once basic use cases are covered, you can start to get more sophisticated with your release management strategy by focusing on mechanics. Mechanics are a broad term covering all of the actions a player can take and the responses the system will provide based on those player actions.
Device interoperability is an important thing to be aware of. Users of your scene may be accessing your scene using a desktop, a mobile device or a VR headset. Users should be able to interact with your scene reasonably well using either. For those using a VR headset try to avoid dizzying movements that could cause motion sickness.
Audio is another critical aspect of a scene's atmosphere. Background sounds like wind, crickets, distant conversations, maybe even music can be a very powerful way to increase immersion and give context. You can also change how volume levels relate to distance from the sound source to put more or less emphasis on a sound's location.
Read design constraints for games for a detailed look at a number of other considerations.
Consider the MVP as one of many prototypes that you can use to establish your cadence for releases once you have established your pipeline. The focus of each release may vary, or it may be a hybrid of each aspect of the experience. However, you should aim to deliver successively more complicated experiences, each iteration building upon the last.
For example, let’s say we are building an MVP for a Frisbee golf game. The MVP will include some still images of the course. The player may even be able to throw a disc, in a very rudimentary, block-style fashion. This allows us to work out our basic throwing mechanics. The next release may include a prototype for multiplayer support so we can demo and test two users logged in and playing on our LAND at the same time.
Remember, while the end goal is a truly immersive 3D world, that is not where your MVP will start. Getting a player into your world as quickly as possible should be your first goal. Taking weeks, not months, to test your releases is critical to learning and iterating without wasting effort.
We strongly recommend that you stay mindful of the first impression your experience presents. An empty experience will leave players disappointed. On the other hand, a scene with some initial content and basic experiences shows players the potential for what is to come and encourages them to engage with your community and return to the next few releases.
Ultimately, you want reach a level of persistence where you can demonstrate that the transactional layers of your architecture are operational. Transactional is not limited to the players actions, but also the system’s reactions to players.