Why we use A-Frame
A library for our virtual space. Security, physics, components.
The decision to use A-Frame to power our web client stems from two different angles: first, to empower content creators; second, to make the experience of world exploration secure and performant.
The Decentraland client needs a way for land owners to easily create experiences, but a compromise always exists between being featureful and withstanding a high level of security.
Describing a virtual space
By making A-Frame look like HTML, the goal is to make virtual reality development accessible to anyone who has dabbled in web development. You can use your existing skills, as well as your existing tools (text editors, version control systems, stack overflow), to build VR scenes in no time.
Decentraland and A-Frame
The question then arises as to what format should we use to describe the scenes. We could have used something like GLTF or Collada, but these formats do not fulfill all of our requirements. Some of the advantages to using A-Frame for the Decentraland web client are:
- Users can work on scenes using any text editor, given that A-Frame is not a binary format.
- Support for physics can be baked in.
- Code interactions using a declarative language.
We want to have a scripting API so that people can build interactive multiplayer scenes and play games together. That is one of Decentraland’s most important short-term goals: to allow users to play games, like Cards Against Humanity or role-playing games, inside of a virtual world.
A custom renderer
When we sat down and started coding the Decentraland client, we based our work directly off of A-Frame, but after a few days of work, we stumbled upon too many difficulties, which led to the idea of building our own renderer.
This decision wasn’t taken lightly, and we’re checking our work against the A-Frame GitHub regularly to ensure that we made the right decision. Due to our special needs, it has been simpler to implement a custom renderer instead of using the A-Frame engine. So we moved forward with the same A-Frame markup, as well as their tools (our editor is based on the A-Frame inspector), but the renderer has been rewritten. Below are some of the drivers behind this decision.
The A-Frame security model relies on the browser, and completely trusts the scene. The scene can have as many scripts, assets, polygons and textures as the user defines in the scene. In Decentraland, we need to manage the performance of different parcels, so that your neighbor cannot have a 1,000,000 triangle fractal that will destroy the experience of people when visiting your land. We also do not yet allow scripting, because we need a way to safely run scripts without allowing these to trivially control the browser. As we start adding digital assets and other cryptocurrency-based interactions, the security of the engine will become even more critical.
We have a physics engine, based on Cannon.js, baked into the Decentraland client. Although A-Frame has a physics engine, it is an add-on, not a core feature. By integrating a physics engine into our client, we can make performance optimizations suited for our requirements.
No Components (yet)
For the time being, the very cool extensible entity-component-system of A-Frame is a security risk. It is our goal, however, to reach a solution that welcomes such components and opens the door to more synergy between Decentraland and the wider WebVR community. Some solutions we are exploring include a re-implementation of the component system, sandboxing the execution of scripts, and creating a system to whitelist components, among others. If you want to join this conversation, join us in our community chat!
Each part of the Decentraland world is described as a parcel, an A-Frame scene that is added to the wider world so you can walk from one parcel to another. Each parcel must be treated uniquely, so that any elements with an id attribute do not conflict with other parcels. This was a bit painful to get going in A-Frame, so again, we favored developing our own renderer.
A-Frame is great and we’re excited to contribute to the ecosystem
Our custom renderer is still early and focussed on the features we need for our virtual world, but as it matures, we look forward to open sourcing our work and contributing it back to the WebVR ecosystem. Having multiple renderers for the same markup might be a really exciting future.