Summary

A new version of Decentraland’s SDK is being developed to bring it closer to the idealized SDK that was originally imagined for the platform. The ultimate goal is for Decentraland’s SDK to be an open protocol for creating metaverse content, open to any other platform that may want to adopt it, and accessible for anyone to use.

The changes currently being worked on will have a huge impact on several dimensions of Decentraland’s SDK. The main categories of improvement are:

  • Usability: Make development easier for content creators and pave the way for the addition of the Decentraland Editor, a powerful scene builder that is visually-based (like the Builder) but still allows for full control of a scene’s code.
  • Performance: Allow players to enjoy a smoother experience, with a lot less hiccups, without relying on creators to optimize.
  • Portability: Make the SDK more adaptable to other engines/platforms.

The SDK up until now

The first version of Decentraland’s SDK was developed over 4 years ago by a team whose members were experienced in creating software applications but had never developed a game or a gaming platform. As a result, it would take a few different iterations of the SDK to make its tools more intuitive and to reduce limitations as the product evolved. During this process, the SDK team has learned a lot and the Decentraland Foundation team as a whole has grown to include many experienced gaming industry veterans that have provided helpful feedback and contributions to the SDK project.

The SDK is currently at a point where its tools make it possible to create complex scenes, and even allows some creators to make a living off of their creations. However, this is only possible for experienced developers, or for people who are willing to put in a lot of effort to learn how to use developer tools and get familiar with advanced programming concepts. We would like to change this so that anyone who wants to can have a part in creating content for the metaverse.

Additionally, the current developer tools available for creating content are not a good fit for some of the purely visual work of iterating over the design and feel of a scene. For example, positioning the elements of a scene to be just right via code is hit or miss and a slow process in general. Ultimately, the goal is for SDK 7 to benefit all user groups by not only becoming more accessible, but just better overall.

Main areas of improvement

The development of SDK 7 is focused around the improvement of three key areas: Usability, Performance, and Portability. Prioritizing the improvement of these areas is essential to bringing Decentraland’s SDK closer to the idealized version that was originally imagined for the platform. Let’s dive into how the SDK team plans to accomplish these overarching goals in SDK 7.

Usability

Currently, creating content for Decentraland is difficult, and that’s a big problem, because by limiting the pool of creators to only experienced developers, the platform misses out on all the potential talent and creativity other groups could offer. Having an unending stream of diverse and amazing content is essential to Decentraland’s existence, and that’s why making the SDK easier for anyone to use is one of the most important goals of the SDK team.

In addition to lowering the barriers to creating scenes, creators should also be having the best experience possible while they build anything imaginable inside Decentraland. The Decentraland Foundation’s vision for Decentraland’s SDK is a product that creators LOVE using.

SDK 7 will increase Usability via:

  • Easier multiplayer experiences: Making a multiplayer Decentraland scene is one of the hardest challenges creators run into today. As a result, most content creators only create single-player experiences, which is unfortunate given that the metaverse is meant to be a social space to meet with others.
    To make creating multiplayer experiences easier, SDK 7 is designed to synchronize changes over the network, implementing sophisticated, conflict-free replication algorithms. This will be a default behavior so that creators won’t need to work out how to do this. In addition to enabling multiplayer experiences, this feature will also allow scenes to store a persistent scene state in servers. For example, if a player opens a door and then leaves, a server will remember that the door was left open, and players who come in later should find it open as well.
  • Scalable complexity: When designing any tool, there’s always a recurring trade off that appears in almost every decision: you either pull towards more ease of use or towards flexibility and broadness of scope. The smaller the scope of a tool, the more complexity can be hidden behind assumptions and kept out of sight from the user. But as stated earlier, creators should be able to build anything imaginable in Decentraland, so limiting what the SDK can do is not an option. Therefore, the obvious solution to make the SDK accessible to everyone but still capable of building anything is to design the UX of the SDK in layers of complexity. The plan is to implement defaults that provide an easy path but also give creators the option to get under the hood if they want to get their hands dirty.
  • Reusability: A goal of the Decentraland Foundation is to enable a rich ecosystem of shared libraries, allowing creators to build upon the work of others instead of being held back by challenges that have already been solved. SDK 7 will be designed to facilitate a plug-and-play approach for custom components and systems, and ultimately, implementing these should become intuitive for most, if not all, user personas at different technical levels.
  • Game servers out of the box: New architectural designs and protocols will make it easier for creators to run game servers. The approach follows the industry standard of sharing code between server & client, running the same simulations in a server as in each player’s instance, with guaranteed synchronization of entities. These game servers can either be trustless or authoritative, depending on the needs of the scene.
  • Paving the way for the Decentraland Editor: This will be an all-in-one content creation tool with both a visual interface (like the Builder) and code editing capabilities. This should ultimately become the go-to tool for both technical and non-technical creators and will be a game changer for bringing non-developer users into the world of creating scenes for Decentraland. Using the Decentraland Editor, creators won’t need to deal with any developer tools like the command line, Node, Visual Studio Code, GitHub, etc if they don’t want to. This single tool will offer all a creator may need in one place and will improve the creating experience in general. For example, adjusting the positions of 3D objects will become an intuitive visual task, but the option to write the code that describes the behavior of a system will still be there.
    Looking at all the existing visual editors (the Builder, DCL Edit, VR Bylder), none can run a scene from the SDK code while in Edit mode. Instead, they keep track of the positions of each item in some schema and only generate SDK code on demand when previewing or exporting. This approach has many limitations. The Decentraland Editor will instead be able to run a scene during every mode, further enhancing users’ experience.
  • A new documentation platform: The current Decentraland documentation platform only shows information relevant to the latest version of the SDK. It isn’t a perfect system as it’s not necessarily the version that everyone uses. Since the change to SDK 7 will contain breaking changes, and everyone will likely not jump on board immediately, it will be more important than ever to support older versions of the SDK. In addition to supporting content versioning, the new documentation platform will also host the technical documentation of the Decentraland Protocol, aimed at code contributors.

Performance

Decentraland presents some unique developmental challenges, starting with the fact that the 3D virtual world needs to run on a browser, which doesn’t leave a lot of room for inefficiency. Additionally, since scenes are rendered next to one another, a scene that performs poorly doesn’t just suffer on its own, it drags down all surrounding scenes with it. So instead of relying on all creators to develop perfectly efficient scenes, the SDK should have tools that lead to lightweight and optimized content, even when creators are not thinking about this aspect.

SDK 7 will increase Performance via:

  • Static scenes: Scenes built with SDK 7 will only load the main 3D models of a scene (or low-res versions of them) when a user is far away, and will wait to load dynamic content once a user gets closer. This can really help with the optimization of the world, as it means that players will be able to experience a much larger visible area that feels more like a continuous world, while not requiring the platform to actually run the code for everything that’s in sight.
  • New data flows: In SDK 7, messaging protocols that connect scenes with the renderer will be optimized to not only be lightweight but to also have middlewares that will be able to potentially cache/filter/redistribute information as needed. For example, static scenes can be thought of as simply ‘cached messages of the protocol’ stored in a file; the renderer can pre-load the file when a user is far from a scene, without needing to download and execute the actual code. Then, when a user walks closer to a scene, the code is loaded using the last state stored in the servers, which could also be cached.
  • New communications technologies: The current P2P architecture is very decentralized and lightweight in terms of servers and infrastructure, but it has proven to not be enough for the kind of near-real-time interaction needed for first-person shooters and other competitive games. SDK 7 will implement the current P2P networking mode by default, but it will also open the door to an on-the-fly switching of communication technologies. Content creators will be able to handle their own matchmaking between players, or even make private connections. Since content creators will be able to plug in any technology that matches the interface, they will be able to use faster (more centralized) communication technologies.

Portability

Decentraland’s reference renderer is built upon Unity, but it’s always been the mission of the Decentraland Foundation to be an open platform that anyone is free to extend. That would mean that one day, alternative community-built clients that use other engines could exist, making Decentraland accessible to players on a variety of hardware types and much more.

Today, the SDK and the renderer are deeply intertwined in ways that would make it very hard to build an alternative renderer. During the development of SDK 7 however, the team will take the first steps to getting closer to redefining the interfaces between the SDK and the engine Decentraland runs on. Once complete, SDK 7 will be built around a neatly modular architecture with clear documentation and, if all goes well, it will be possible to plug it into other engines with relative ease.

SDK 7 will increase Portability via:

  • Universality: SDK 7 will be designed in a way that in the future, it should become possible to use it in constrained and even remote environments. This may include mobile devices and custom light-weight JS runtimes that can be embedded in mobile devices or rendering engines.
  • Standardized protocols: Every component will be revisited, from a scene’s code to the renderer, to ensure new protocols are optimized and well documented. The objective is to not just reimplement every component to follow the new system, but to also enable future systems to be built on top of what already exists. In other words, formalizing the Decentraland Protocol.
  • Welcoming new branches: Once the Decentraland Protocol is formalized and documented, new contributors will be able to create their own versions of Decentraland using alternative technologies like Godot, Unreal, standalone VR, and custom engines or platforms.

SDK 7 Roadmap

These are the milestones that have been set for before and after the release of SDK 7:

The SDK product process happens entirely in open source GitHub issues. As transparency is a core value of the Decentraland Foundation, the whole process of planning and organizing the SDK is available in GitHub for the community to participate in and audit.

Attribution for icons: Usability, Performance, Portability