High performance The engine compiles to a binary artifact that is close-to-the-metal (either native or highly-efficient VM code/small runtime overhead such as .NET). This is desirable to achieve the best user experience possible — as delays and rendering problems are highly correlated with a poor user experience.
Engine Popularity within the Game Industry This criteria selects for projects that have good tooling and plugins built on top of it (particularly useful to test and iterate user interfaces and game controls), proven techniques for crafting high quality games, a broad developer user base, and a proven track record of published titles on game stores. Particularly important is the size of the developer user base: game developers building a career select and specialize on the languages and frameworks that are in high demand in the market. Picking an engine with a small user base severely constrains the amount of collaborators the project can enroll, leaving us on the wrong side of “quantity leads to quality”. Also important is picking an engine with a proven track record of published titles on game stores: for example, there are hundreds of titles on the Steam store built with Godot, while there are tens of thousands built with Unreal or Unity. That’s two orders of magnitude of organizations that successfully built projects on those foundations. By using an engine that has a low number of publications, we’re risking running into fundamental problems with the development process in that engine.
Language Safety and Binary Security As of 2022, there’s an industry wide call to avoid new projects from being developed on C++ and C, favoring languages that are garbage collected or have strong insurance against mismanagement of pointers and memory access (such as VM-based binaries like C#, VM-based interpretation like JavaScript, or other memory management strategies as with Rust or Golang).
Commercial Viability to launch on Marketplaces/Stores and Licensing Proprietary engines generally have licensing models that could be against the long-term objectives of Decentraland. Particularly, Unreal has a 5% “revenue share” license model that would be unenforceable for us. Unity, on the other hand, charges organizations for developer seats.
Potential for Educational/Standard Implementation This criteria selects for the engines with scripting/coding languages that are the easiest to use, closest to pseudocode (like Python), script independence of context (specially when GUI is the only way to define entry points to the code, as with Unity triggers), and where language syntax would not get in the way of expressing an idea. The three most popular languages that met this criteria are Lua, Python, and Javascript. For example, the “reference implementation” of Ethereum, and the source code discussed on the Ethereum Improvement Proposals, is written in Python. Although nobody runs this reference client in practice, it’s useful to discuss the tradeoffs and check for compliance with the standard.
Long-term Support Would this engine be around in ten years’ time? If we travel forward to 2032, how likely is this engine to still be one of the top choices we would consider? This criteria uses the “Lindy effect”: the longer a project has been around, the higher the probabilities that it would be around in the future.
Free, Open Source Building on open source foundations de-risks the long-term sustainability of the Decentraland project. If the Decentraland project is successful, but the underlying private platform maintainer goes out of business, Decentraland could be forced to abandon the project. By picking an open source engine, we ensure that in the worst case scenario, Decentraland could find developers to maintain the foundations upon which it’s built. There’s a long history of community forks for open source projects that changed their license, had a change of vision or became unmaintained, such as RedHat OS → Fedora, Debian → Ubuntu, XF86 → X.org, and KHTML/WebKit/Blink. In all these cases, the community forking away had the liberty of changing the foundations to best serve their interests. By using open source technology, we make sure that the final build is transparent, secure, and open to contributions from the broader community. This helps to ensure that the technology behind decentralized systems remains open and accessible, and that it continues to evolve and improve over time.