This document presents the Playground, a new learning tool for SDK users, focused on learning by doing. It’s a light web editor where you can quickly write and iterate code and see its effects side by side. Users don’t need to install or set up anything, removing all friction. No file management, saving or deploying, it’s meant for prototyping code and throwing it away, or then pasting somewhere else.
Learning to use the SDK is tricky, and there’s a lot of friction up front until you have everything set up and ready to actually run code and see its effects. If you’re new to the Decentraland SDK, you don’t know if you’ll feel comfortable and capable enough to use the tools, and if all that set up will even be worth it. So it’s good to get a taste of what it’s like to use our SDK before you start the setup. When we release SDK7, all the developers in our community will have to learn a new syntax, and in many cases a new programming style (Data Oriented Programming). It will be a challenge to get them to transition to this new version, anything that can help them learn faster is valuable.
To experienced users of the SDK, this is also super valuable. When you encounter a new feature, or when you have a doubt about some corner case, you currently have three options:
Thanks to this playground, if any doubt comes to your mind, you’re a click away from jumping into a safe and easy test environment.
Developing an initial version of this tool would not take much extra effort, given that something similar is already being built for internal testing of the SDK7. The effort put into this is also likely reusable as part of the Decentraland Editor, a much more ambitious tool meant for creating fully-fledged content.
This tool will be similar to other existing developer playgrounds. In other playgrounds, there’s a code input panel on the left, and a visual output on the right. There’s a Play or Run button, to convert the code into visual output, and that’s essentially all there is to it.
You should be able to start up the playground with different initial states:
Learning by doing is a LOT more effective. By reducing the friction it takes to try things, developers will try out a lot more things, and will learn a lot faster. It’s a game-changer feature for the experience of using our documentation.
For new users, they can have an easy and frictionless first experience writing code with the Decentraland SDK, before they set up everything to start building their own scenes. That way they might feel more reassured that all that setup and learning is worth the effort.
For users that might be on the fence about transitioning their work to SDK7, this can be a huge help to make them more confident that they can get there.
The tool we’re planning to build follows a pattern that is familiar and well known to developers in other platforms. It’s similar to w3Shools, Babylon Playground, or Mulesoft’s DataWeave. These tools are all loved by the dev communities that use them, we expect our playground to also be very valued by our content creators.
Rely purely on documentation and examples
We absolutely need to have good documentation and examples, but these will always cover limited ground. Allowing the imagination of users to run free and try their own variations on examples is always going to be valuable.
Focus work directly on the Decentraland Editor
The Decentraland Editor will take a long time to be developed. Initial versions of the Decentraland Editor will likely still not be a single-install product, they’ll surely have a bunch of dependencies and hurdles (node, OS permissions, launching via command line). Once the editor is finalized, it’ll be a huge help to onboard more users to SDK7, but we can’t wait till then. Even after the release of the Decentraland Editor, the playground will remain useful. Using the Playground will always have less friction than the Editor, as it’ll require no installation, it will open faster, and not bother with creating projects, folders, etc. Also, as mentioned, a similar tool to the playground is already in development, making it a relatively low hanging fruit to develop.
What are the open questions that may need to be explored? Be explicit and honest about any “elephants in the room”.