With Genesis Worlds, we’re building a decentralized Metaverse that’s going to last for 100 years. That’s a massive, ambitious goal, and it’s only possible through the application of blockchain technology. Each of the four concepts within that phrase have their own technical requirements and tradeoffs. As we’ll see, there are no easy answers to the question “what tech should we build on?”, and in fact the answer that’s closest to right today may be wrong tomorrow, as the underlying technologies change.

Decentralized: “Decentralization” can in some circumstances mean “100% trustlessness,” but that’s not our goal here, as it significantly impacts other parts of the Metaverse and game we are building. Instead, our measure is that community members can and do contribute directly to the project, and make changes to the fundamental nature of the project.

Metaverse: There are thousands of different opinions on what a Metaverse is, but for us, it’s a 3D multiplayer environment, created and built on by users, owned by the users, and with strong interoperability across different platforms. 

Game: It has real gameplay woven through the Metaverse environment, made up of shared user-created experiences. It’s fundamentally multiplayer, and it’s not a collection of mini-games and disjointed experiences. 

100 years: We’ve seen major technological jumps roughly every 10 years – from the personal computing revolution of the 1980s to Web 1.0 of the 1990s to Web 2.0 of the 2000s to smartphones in the 2010s to Web 3.0 in the 2020s. That pace of change is likely to continue. The platforms and technologies used in 30 years from now will be vastly different from what we’re used to today. And this has a big impact on our tech stack and the considerations we make during our development process.

Tech Stack

So what does the tech stack look like? Firstly, there’s some pretty standard components needed:

1. Front-end client: Most games use native clients, usually written in Unity/Unreal, with a minority in homegrown engines. The remainder use web clients, mostly HTML5/WebGL. Native clients allow for the most performance, web clients allow for the most decentralization.
2. Back end: Almost every multiplayer game requires servers to run gameplay logic, ensure fairness, and enforce the economy. Servers also handle payment transactions etc. 
3. Storage: In a traditional game, there’s a massive amount of data storage. Truly massive. A mid-sized mobile game company can generate a terabyte of data a day. That’s more data than the entire Ethereum chain, lifetime. It’s not going to be stored on chain; it’s almost certainly not going to be pinned on IPFS either.
4. Hardware. These days, hardware comes in three flavors: Mobile, console, and PC. There’s some blurring of these groups, and there’s some special-purpose hardware to consider (especially VR), but most decisions on hardware boil down to those three.

The “Metaverse” and “game” requirements don’t have too much of an impact here – while there will be some differences on the depth of experience, or quality of graphics, we can achieve them with almost any tech stack choices. “Decentralized” and “100 years” are far more impactful, especially where it comes to front-end tech.

Hardware

The biggest unknown is clearly future hardware. We have absolutely no clue about this, and the impacts could be profound. It’s entirely possible that in 50 years, quantum computing will make current blockchain technologies obsolete. Also, the blockchain tech that exists today is 3-6 years old, and has gone through massive upheavals and changes. What this tells us is that we need to ensure that we plan for flexibility to adjust to newly-evolving tech stacks. 

Front End

But… we also know that the world will also adapt to changing technology stacks, and we can use that to our advantage. That brings us to possibly the biggest choice, and a controversial choice: Choosing an engine to drive the front end. The first Metaverses (Sandbox, Decentraland, others) all picked home-grown engines. This was a choice that maximized decentralization. But, the tradeoff for that choice is reduced agility, and much reduced flexibility. You’ve taken something that isn’t really a core part of your value proposition – making a 3D game engine, and you’ve taken it on as a core part of your business. Now, when the world changes tech platforms, as it will many times in the future, you have to do all the work to support that new tech platform, or risk going obsolete.

So really, you don’t want to be writing your own game engine, you want to use a commercial engine. This feels like it’s a big step back in terms of decentralization. But is it? I’d argue it isn’t, or at least not in a meaningful way. The only commercial game engine that has flat-out died in the last 20 years is Flash (and for good reason). Every other engine is either going strong, or has transitioned to open source. There is a AAA-level open source game engine out there: Amazon’s Lumberyard. There’s also Unity and Unreal. Unity is mostly a no-go, as its licensing terms don’t play nicely with open source projects. That’s sad – in many ways, it would be the perfect engine; we even did our initial Genesis Worlds prototypes in Unity. So it comes down to the open-source Lumberyard vs the closed-source Unreal. This, as it turns out, is a no-brainer. Unreal wins by a landslide. 

Wait – is that really right? Yep. Open source in this case is worth very little, for two main reasons. One: The future will be different, so it’s probable that we’ll be rewriting the client several times in the future. Two: Lumberyard is a cost center for Amazon, not a profit center. If Amazon pivots away from gaming (and it will at some point), Lumberyard effectively becomes an in-house engine. Three: People. Way, way more devs are highly skilled in Unreal than Lumberyard. And people are the most important factor here; even more so for a community-driven project like Genesis Worlds than for a corporate project.

So, our selection for the front-end client becomes the latest version of Unreal Engine, Unreal 5.0.

Back End & Storage

Usually when you’re specifying a game platform, you think of back end server tech and storage tech at the same time; they interact closely with each other, and are managed by the same people. Building a decentralized game, you’re in a more complex world. 

Luckily, it’s a world that helps you in many, many ways. Firstly, your core economic transactions have a clear place: On chain. We’ll have to pick the right chain, but we’ll come back to that. Secondly, you need storage for user-generated assets (and source code etc). Again, there’s existing solutions here. IPFS for UGC is great for the most part; open source repositories handle the source code. 

For the actual gameplay logic, it’s unrealistic to attempt to do that on a traditional chain – with millions of transactions per second and required response speeds measured in milliseconds, the only real option is a traditional server. It’s possible to decentralize those servers, at least for small player counts – Decentraland handles 2,000 concurrent players in this way. That’s several orders of magnitude smaller than a traditional game’s user base. And there’s a lot of traditional functionality you have to compromise on. So, the majority of modern blockchain-powered games instead rely on more traditional game servers. For now, we’ll stick with that trend, and run on traditional servers. But… the future will likely look different here, and we can set ourselves up to take advantage of it.

A Crazy Idea

Up until now, we’ve assumed that our decentralized Metaverse is going to run on a tech stack that’s similar to traditional games. But… that doesn’t have to be the case. What if we could make decentralization work for us in terms of efficiency and resilience, rather than against us? 

Here at GameCredits, we are building a large-scale multiplayer game where players will be connected for significant amounts of time. That gives us access to a massive amount of connected, readily-available storage and compute power: Every device that’s live and running the game. The technology to turn that mass of computing and storage into a live gaming network doesn’t yet exist, but it’s within our grasp to create it. Once you’ve got that built and running, you no longer need servers, and you no longer need storage for in-game assets. You still need storage for downloadable content, but that’s already solved in a decentralized manner. You do still need some centralized touchpoints – all the app stores require a true business entity, and someone still has to provide analytics & telemetry analysis to a scale that couldn’t be stored in a decentralized manner. Those two points, however, could be replicated by other teams, so the project at this point would become forkable.

In summary, I don’t know what the future holds. But I do know that it will be different than the present. And just knowing that is a massive help in making tech stack decisions for Web 3 and the Metaverse.