Learn how to import 3D models to use in a scene
The purpose of this document is to help guide you through the process of building your initial experiences and environments in Decentraland. We’ll refer to these initial experiences and environments as the 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 is incredibly 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.
Separating these goals will allow you to provide your users with greater value in addition to optimizing your pipeline.
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.
So, how do you fail quickly? Very easily. You do the minimum needed to get your player to touch your product.
For example, let’s say that you’ve determined your players want to ride unicorns, so you spend months developing a pipeline to create blue unicorns and only blue unicorns. Then you give your blue unicorns to your players, only to find out that they despise blue unicorns and want only purple unicorns. You’ve wasted months of effort, and now you have to create a new pipeline to deliver your users the experience they want.
However, if you gave the minimum viable blue unicorn to your players as quickly as possible, with a pipeline you could modify, then you would quickly learn that they want purple unicorns. Putting forward the minimum amount of effort needed to poll your users allows you meet their needs faster, without wasting effort and resources.
Here is the list of factors to consider for your basic MVP. It is absolutely acceptable to state that you will use X and will phase in Y. Planning your post-MVP product using a phased approach will help guarantee success.
Art Rendered in Scene
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 personal and immersive experience.
We recommend creating your MVP as a single player experience. However, your MVP will ultimately be limited by the current capabilities of the SDK.
For example, you could design a scene with the following successive experiences:
Once these 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.
Camera perspective is another critical aspect of the user experience that will require specific and sequential goals. Since the ultimate vision of Decentraland is to build a VR world, the camera will eventually take a first person perspective. So, depending on the experience, this perspective will drive the individual experience of each player.
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.
Consider the MVP as one of many, 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 that can be seen by the player in the world. 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.
Finally, 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 district 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.
If you plan to include a number of applications within your experience, then you may need to think about authentication at multiple layers. The interaction with these applications should be seamless for your players. They should only have to log in once, with your applications operating “behind the scenes” to ensure that their login info is passed on to your other downstream systems. This will require a robust and thoroughly tested security architecture.
Given this complexity and stakes of security, please allocate the time and attention to these processes. Do not rush your security architecture to delivery.