Rome Tech Stack

Building games for mass adoption

Even though web3 has seen an incredible growth spurt in the last few years and months, the truth is, that the vast majority of the world's population is still not crypto- literate. In a lot of cases, it’s already hard enough for a lot of individuals to download a wallet, create an address, buy a token on an exchange and send it to an address. For crypto games, this gets even worse if users have to download a game in addition to going through the wallet setup. In our opinion, if you already have a wallet, you should just be able to connect to a crypto game with the wallet you have already set up, without downloading additional software. We believe that technologies like WebGL/WebGPU and libraries like Threejs make that possible with some tradeoffs (for now). But first, let’s explore the potential ways of building web3 games.

Building web3 games

There are several widely used game engines with different strengths and weaknesses. The most widely known commercial game engines at the moment are probably Unity and Unreal Engine which let you build games with C# and C++ respectively. Both these languages have been around for decades and are suitable for high-performance and complex games. Next to that are less well-known engines like Godot or Bevy which start to become more popular. But as you may know (especially if you’re technologically versed), a lot of UI-related tooling is built with JS/TS and around web frameworks like React. The web is a very, very UI-heavy landscape and used by virtually everyone on the planet. Naturally, this means that most tooling nowadays gets built with being used on the web, first. Web3 is comparatively new, so we’re only barely seeing web3 related tooling for the web, let alone for games. E.g libs like ethers, wagmi, web3-react, typechain, hardhat come to mind. You don’t really have these things for languages like C# or C++, and if they exist, they are very limited compared to their JS equivalent. This will change but will most likely take quite a while.

Basically, what this means is that building anything web3 UI related within a Unity or Unreal game as of now, is almost impossible. Specific example: A marketplace. You might have seen that Axie Infinity for this reason builds their marketplace separate from the game, and that brings us to the next point: Should we separate web3 UI from the game? Can’t we use staking, the exchange, marketplace on the web and download the game?

That’s entirely possible, but then you’re back at users having to download a game and on top have them use a separate website. We think we can and should do better for true mass adoption.

Basically, we have three options available for building crypto games (no particular order).

• Game contains web3 UI elements (almost impossible to build, have to download game)
• Game + separate web3 UI (a la Axie, have to download game)
• Web app contains game and web3 UI (no download, limited game features for now)

We are trying to go after the third approach but before explaining why and how, we’d like to briefly give an overview of why you can’t just export Unity to the web, connect it to your web3 React app and call it a day.

Shortcomings of Unity

Currently, most crypto games seem to get built with Unity, arguably one of the best game engines to build games with. Unity is very good at creating desktop or mobile games that you have to download and install. This works perfectly well but lacks the tooling and the DX when it comes to building in-browser gamified experiences.

It is a full-blown game engine & game studio that allows you to easily build simple and complex games alike. Long story short, Unity is great for building games… that you have to download. Some people might correctly say “but unity can export to webgl”, yes that’s true and works as long as all UI elements are also built with Unity. Once you start overlaying some Html or god forbid try to embed a Unity game in a React application, the fun is over.

One of the reasons for that is the very limited API Unity offers to interact with it from a browser environment https://docs.unity3d.com/Manual/webgl- interactingwithbrowserscripting.html. The API doesn’t even have the notion of async behaviour like Promises (if you’re a dev you already know that this is hell). It essentially means that the API is a little bit like a straw that you can use to send data from Unity to the frontend or vice versa, but not simultaneously (this is called a half-duplex). What we need however, is a full-duplex highway that lets you send data back and forth simultaneously, wait for some data, work with it, send a response back, etc. This is one of the biggest shortcomings of not only Unity, but all game engines that aren’t natively built with browser technology.

In simple terms, you just can’t tightly integrate a Unity application into the browser because it’s not built to integrate with browsers. Yes, it can RUN in the browser, but that doesn’t mean it’s well integrated.

Another reason why building with Unity on the web is suboptimal is that compiling the project often takes several minutes, there is no hot-reloading or anything like that (instant changes). It becomes almost impossible to build frontends that have both a unity and a react part to it because it just takes such a long time to see any change. Fixed a bug in unity? Great! Now just build it for 5 minutes and send the output to the frontend devs that need to figure out if it works. Another bug? 5 mins compile-time, and so on.

Enter Webgl / WebGPU

Now you might be thinking, what if we can build a game with AAA graphics and all of the benefits web libraries have to offer? Wouldn’t that be the holy grail? Just visit a URL, and get access to an amazing web3 powered game AAA game.

What if we told you that this will eventually be possible? The keyword here is eventually though.

Currently, the technology that powers 3d related stuff on the web is called WebGL which is based on a graphics library called OpenGL, which was released almost 30 years ago. Needless to say, both hard- and software have changed quite drastically and because OpenGL is so old, (it got a few updates, but no major and fundamental changes), it’s not really suited anymore for the content users demand. However, this is the only thing we have right now and if you’re building a Unity game and export it to the web, it will end up using WebGL/OpenGL just the same. Thankfully, some very smart people at Google, Apple, Khronos, Intel and some other companies are building the next version of WebGL that can fully use hard- and software just like native games can. Essentially it means you’ll be able to have triple-A games in the browser because the field will be levelled.

While this sounds great, it’s unfortunately not just as simple as that. JavaScript execution time still is much slower compared to languages like C++. We can have AAA graphics, but not AAA game logic (e.g bot AI, etc.). Luckily, that’s where WASM comes in. Nowadays you can build computationally heavy libraries with extremely fast languages like rust or go, and compile them to something the web understands. A good example is rapier and react-three-rapier. A Rust-based physics library that you can use with Threejs. Combined, you’ll truly be able to build AAA games (easier said than done, you still need a huge team for 3d assets, content creation, etc.) on the web. And that’s what we call true mass adoption. However, these things are still at least 1 year away to be used seriously, before that, we need to stick to technology that might seem like it limits us, but will quickly turn into an advantage very few projects will enjoy.