There are already examples of interoperability in the traditional gaming space. Fortnite licenses IP (Intellectual Property) from third parties to give players access to skins from the likes of the Marvel Universe, Star Wars, and many others. IP rights are negotiated by stakeholders to allow specific usage within a single game for limited time, usually for business and/or promotional reasons. However, this is not the type of open asset interoperability envisioned by the Web3 gaming community, as the Fortnite developers still need to create the skins and store them in proprietary databases within an owned ecosystem.

Roblox is another example of a Web2 interoperable game and is often referred to as a microverse, a sort of self-contained metaverse where everything is controlled and owned by the developer. Roblox is a UGC (User Generated Content) platform that allows content creators to build experiences for players to enjoy. Players have avatars that can be used in any experience built on the platform. So within the closed Roblox ecosystem, they are interoperable without the need for a blockchain.

In the nascent Web3 scene, terms like cross-game interoperability can often be oversimplified. However, anyone who has built games before will know that in reality it presents immense challenges, not only technically but also from a business and IP standpoint. It is not our intention to discuss these non-technical points in detail, but it would be remiss of us to not mention them at all.

One key point when considering interoperability between games is how it may affect the level of immersion and escapism experienced by players. 

Game worlds are meticulously crafted by designers to have a specific aesthetic and narrative. Bringing in “foreign” game assets risks ruining that immersion that players crave. If multiple games all support the same set of game assets, it’s easy to see how each of these games will become less differentiated over time. Furthermore, it’s a difficult enough feat to balance gameplay in a closed ecosystem. Weapons, perks and abilities need to be carefully tuned so that any combination doesn’t make a player OP (over powered) in order to maintain fair, skill-based gameplay. If a game had a fully open and permissionless ecosystem that allowed players to bring in weapons and items from other games, this balancing act would become a near-impossible task for the developers.   

There are also a lot of complexities when it comes to negotiating the business/financial incentives for allowing external assets into a game. For instance, how does the game developer protect their user base and profitability if their assets can be taken elsewhere or if external assets created and paid for in another game or bought on secondary markets can enter their game? Interoperability adds complexity both in terms of execution and game balance, and thus increases costs for the developer. It will also likely introduce compromises in game functionality, as games will need to support a more generic asset model rather than tailoring to the specific game experience. As such, there will need to be significant incentives to adding interoperability features to a game to make it viable from a business perspective. This does not necessarily mean that cross-game interoperability is an impossibility, but it does add a significant hurdle.

So what interoperability solutions are there in the Web3 space today? There are far too many to cover all of them in this article and a lot of them are general purpose solutions for moving assets between chains. There are entire blockchain networks that claim to provide an interoperable future such as layer 0 architectures like Polkadot with its parachains and XCM (Cross-Consensus Message Format), as well as Cosmos with its dedicated app chains and IBC (Inter-Blockchain Communication protocol). This article will explore specific interoperability solutions that have applicability in gaming and they can be summarized into the following categories:

• Cross-chain – a single game client communicating with multiple blockchain backends
• Partnership-driven – A game may choose to allow the holder of a certain NFT to mint a new version within their game. A kind of pseudo-interoperability
• Game assets as primitives – The game asset itself could be the foundation upon which a whole host of games and other derivatives are built
• Community-centered – The game could be designed around the premise that communities will populate the virtual world with representations of their NFT assets
• Cross-game – Multiple games allowing users to actually cross “borders” between games with a single asset (i.e. true interoperability)

We will address each of the above in turn, using existing projects as examples.

This is what we referred to earlier as cross-chain interoperability and it in theory allows a game client to be blockchain agnostic. One issue Web3 games face is fractured liquidity of both assets and users across the many different chains on offer. Projects like Spanning Labs aim to solve this issue by allowing a singular game client to communicate with multiple blockchain backends. At a very high-level, the basic concept dictates that a user can play the game on whichever chain they prefer and their in-game assets will automatically be replicated (minted, burned, updated or transferred) on all other chains the game is running on. This not only allows a game to acquire more users, but it also makes for a better UX (User Experience) because it avoids users having to create multiple chain-specific wallets and abstracts away the gas fees (paid by the user in a single currency or potentially subsidized by the developers).

Below is an high level outline of the process:

1. User on chain A commits a signed transaction on-chain, e.g., minting a new sword NFT.
2. The smart contract implementing the Spanning interface will emit an event which contains an instruction, the user’s public address and the destination chain ID.
3. Within the Spanning Lab peer-2-peer network, a node (AKA delegate) will pick up this event and forward it to a relayer module (BOS in the diagram below).
4. The relayer will forward the message on to a delegate connected to chain B.
5. The delegate will then execute the transaction (minting the sword NFT) on the target smart contract, thus replicating the user’s state from chain A on chain B.

Spanning Labs refer to this as “Ownership Bridging”, meaning that users own a real asset on chain B rather than a wrapped version of the original. Historically, most major hacks have targeted bridge contracts so removing them from the equation removes many attack vectors.

This type of interoperability can be seen when a project decides to honor holders of a particular NFT project with game assets in their own game. This could occur through a mutually beneficial agreement between two projects or it could take the form of a user acquisition attack on a popular project’s open social graph. This is sometimes referred to as a vampire attack in crypto parlance, whereby users are incentivized away from one project towards another. In either case it’s straightforward to get a list of all holders of a specific NFT and airdrop them new NFTs. Often this is targeted at popular or blue chip projects, as it’s a great way to bring attention and generate hype around a game. We have seen a very recent example of this with the collaboration between Castaways and DigiDaigaku. However, this is not true interoperability in the sense of shared assets, i.e. the DigiDaigaku assets are not actually in the Castaways game, they are recreations that had to be designed and coded by the Castaways developers. Due to the labor requirements, this limits the scalability of this method somewhat. However, the user acquisition benefits offset the additional work required to a certain extent. This manual labor requirement by developers and designers may become less so in the future as AI-driven 3D asset creation tools like Kaedim become increasingly prevalent. This is one area where Bitkraft is actively investing. 

It’s also worth noting that although this can be an effective way of acquiring new users, the Web3 industry still lacks best-in-class analytical tools that allow targeting of specific player types. For example, a gamefi whale may have assets spread across multiple wallets for opSec reasons. This makes them difficult to categorize and target as a singular user with the current analytical tools on the market.

To conclude this section, in the near-term we are likely to see this type of IP interoperability occur frequently between partnered projects, as it’s a reasonably effective user acquisition strategy and probably the least challenging to implement from a technical and business standpoint.

This next type of interoperability is unique to Web3 and involves multiple games and other derivatives being built on top of a collection of genesis NFTs. Perhaps the most well-known example is Loot. For those unaware, the Loot project was created by Dom Hofmann (the co-founder of the video app Vine) in August 2021. At the time there was a lot of hype as well as confusion due to the simplicity of the NFTs, which just contain a list of items on a black background.

At the time, speculation was rife, as the project had no apparent utility or roadmap and the community was left to their own devices to use them as they saw fit. Fast-forward a year and an entire “Lootverse” has been built with this NFT collection at the heart. Many developers have created games, utilities, DAOs, art, lore and even new NFT collections all based on the original Loot NFTs. This was aided by the fact that the Loot bag items are actually part of the metadata within the NFT, allowing any smart contract to use their contents without having to call out to a decentralized storage network like IPFS. Because these games are all built around a common primitive, the Loot NFTs are naturally interoperable across games built on top of it, effectively flipping the traditional gaming model upside down. Now the games are the derivatives, not the game assets, and rather than the project creator generating value around the NFT, it’s completely driven by the community from the ground up.

Some notable games being built within the Loot ecosystem include:

• The Crypt – Loot holders can collaboratively raid dungeons to collect relics
• Loot Realms – An MMO based around land Realm NFTs, shepherded by Bibliotheca DAO
• Crypts and Caverns – Generative dungeon maps
• Loot MMO – An open-source fantasy RPG where adventures are created by Loot holders, fans, and community. Built on Manticore Games (BITKRAFT portfolio company) Core platform.
• BibliothecaDAO – A community of developers, designers and artists that have come together to progress the Lootverse. One notable project they have developed allows the list of items from the genesis Loot NFT to be broken down into individual items and equipped by a new Adventurer NFT. 

This type of interoperability can only be enabled through the use of blockchain technology. All of the above are built on Starknet, a permissionless, decentralized validity rollup on Ethereum. On-chain games perhaps represent one of the most compelling and innovative uses of blockchain technology within gaming and interoperability. Not only are game assets and currencies recorded on-chain, so too is the game logic and every action performed by players.

Recording all player actions and game logic on a public blockchain poses some unique challenges, as a lot of games rely on the notion of hidden information. A relevant example would be that of an MMO where there is the concept of fog of war (obfuscated unexplored zones in the map). If all coordinates and resource locations are recorded on a public blockchain there’s nothing stopping players from viewing this data and discovering the location of a valuable resource or an enemy base. This problem is solved on Starknet through the use of zkSTARK proofs (zero-knowledge Scalable Transparent Argument of Knowledge), which allows transactions to be committed and verified on Ethereum without revealing their contents. This opens up the possibility of creating a much richer on-chain gaming experience because it enables games to incorporate hidden knowledge. 

One example of a game that makes great use of this feature is Dark Forest, a space themed 4X strategy MMO. Players start with a home planet and a huge shared universe. The aim of the game is to explore, collect materials, upgrade infrastructure and expand your territory by claiming other neutral and player-owned planets. Planets produce ships and planets are captured by sending more ships than the current number stored there. The game ends when only one faction remains. Exploration works a little bit like proof-of-work mining, whereby discovering a new set of coordinates (previously obfuscated by fog of war) requires players to compute a hash of those coordinates. The resulting hash is compared with a list of all hashed contents of the universe. If a match is detected, the corresponding asset is found there. It actually uses the player’s CPU to compute the hash and even allows them to select how many cores they want to use.

Because all game logic and actions are stored and recorded on-chain there is no need for a centralized game server or database on the backend. Games built in this way can last in perpetuity, even if the original creators abandon the project. Furthermore, the fact that it is also open and permissionless allows anyone to deploy smart contracts that extend the base-layer logic. This has led to some interesting emergent gameplay not originally intended by the creators. For example, in Dark Forest smart contracts are also able to play the game. The Astral Colossus is one such contract deployed by the community that automates certain tasks for players (who contribute resources and planets) such as withdrawing silver and discovering resources.

The Dark Forest creators couldn’t stop this contract even if they wanted to. In fact, they actually encourage this sort of composability and extensibility. They have implemented support for community-created plugins and renderers that allow the permissionless building of useful tools to enhance the gaming experience, as well as new shaders and effects to improve the look of the game. Another potential gameplay style involves the bribing of validator nodes to not accept incoming transactions from enemy players. Whether or not you agree with the morality of this, it demonstrates an entirely new potential layer of gameplay, which is unique to this type of game.

The unique token incentive structures in crypto, coupled with the community-driven, open and permissionless nature of fully on-chain games naturally leads to experimentation and collaboration between projects. The on-chain gaming community sees the interoperability of assets as a core pillar of what they are trying to build. As the underlying infrastructure matures this will certainly be an interesting space to keep an eye on.

The next variation of interoperability is that of games being designed on the premise that communities will bring their assets with them in order to populate the virtual world. In some ways this is similar to partnership-driven interoperability and is perhaps best described with an example. Worldwide Webb describes itself as an interoperable, dystopian pixel art metaverse that gives utility to popular NFT projects. It is an MMORPG that allows NFTs to be used as in-game avatars, pets, lands and items. NFTs currently integrated into the project include Cryptopunks, BAYC, Kaiju-Kingz and many more. A full list can be found here.

They focus on 2D rendering, which simplifies and speeds up the process of integrating external assets. The project has quite specific integration guidelines, requiring NFT project owners to submit their art in a certain format depending on how they want the NFTs to be represented in-game. At the most straightforward end, this can be simply providing an Opensea link to the art (if the art has either a transparent or solid background that can be easily removed). This would result in the (non-animated) head of the character being placed on top of a default body as shown below.

If the NFT collection would like their avatars to be animated they need to provide an API endpoint linking to a sprite sheet (shown below) for every item in the collection, which shows the character from different angles both whilst walking and standing still.

This project was one of the first of its kind within the blockchain space and through leveraging existing NFT communities, is able to generate network effects around the game and build its player base. However, this approach to interoperability requires a lot of manual effort both on the part of the game developer and the third party NFT projects wanting to integrate. It will be possible to automate much of this through custom software, however it is questionable how scalable this type of interoperability is.

The final category of interoperability is what you might refer to as the holy grail of cross-game asset sharing or true interoperability. It is also the type of interoperability that Web3 gamers envision when they think of a “Ready Player One” metaverse, where game assets can cross seamlessly between different game worlds and interact with each other, the environment, and in-game items. Needless to say, this is the most challenging and far-off vision of interoperability, which could turn out to be a pipedream.

During the course of our research, it quickly became apparent that the challenges involved in creating interoperable game assets are less of a “blockchain issue” and more of a fundamental consequence of the way games are built today. Perhaps a good place to start is defining what a game asset is. As Raph Koster discusses in his excellent series How Virtual Worlds Work, in its simplest form, an in-game object or item is a data structure containing things like visual representation (art), metadata, traits and stats relating to the item utility etc. Script components that define an item’s in-game behavior can be attached to the data model but ultimately, they do not encapsulate the whole game system. What we mean by this is that the item’s behavior will have dependencies on other game assets. For example, if a game supports the concept of food, then food items will probably have some sort of food script attached to them that defines their behavior, how much HP they regenerate when consumed for instance. This implies that an entity in the game will eat the food, which in turn means that this entity needs to have some sort of “food eater” script attached. If one of these game assets travels to another virtual world without the other, the scripts now have missing dependencies and make no sense. This makes open asset interoperability beyond simple cosmetic items challenging to say the least. Furthermore, the underlying game logic is what interprets and executes this behavior in the context of the game world. It therefore goes without saying that whatever game engine has been used needs to be capable of parsing the data format the asset is represented in.

In theory you could have an agreement between two game developers to use a set of design guidelines, which would allow them to implement asset behavior in the same way, and thus make their assets interoperable. However, this becomes a social coordination challenge and requires sufficient incentives on both sides to make the increased complexity and cost worthwhile. For this reason, arrangements like this will likely be the exception rather than the default across the games industry, at least for the foreseeable future.

That being said there are projects that are developing systems and tools that take a set of behavioral components defining an assets animations and behavior in various states, serializes them and embeds them within NFTs. These can then be de-serialized and processed by native game engine behavior controller implementations. During in-game use, the NFT’s metadata (e.g. item condition) is dynamically updated and submitted to the blockchain in a rollup along with a zero-knowledge proof. This way the item maintains a consistent state if taken to a new game. This is potentially a novel solution to the problem but is yet to be proven in production. When asked about the viability of such a solution, Frost Giant CEO, Tim Morten commented, “There are some interim data formats that can be parsed by a game engine, but this is inefficient because we optimize our data formats for load time. As soon as I have to do some sort of object conversion into my native data format, I’m incurring a processing hit for every asset, so it’s not a good user experience. You could come up with some sort of preprocessor where, if you have a set of assets in a format that’s not native, you preprocess those to native format so that you only incur the hit once for the player. However, it’s not efficient to generalize formats for games and the volume of data that we load is so massive that you’re talking about increasing loading time perhaps by 5x which is just not acceptable.”

Another approach to sharing asset behavior across worlds could involve loading a set of standardized behavior scripts from a remote repository. Raph Koster alludes to this in the aforementioned series, How Virtual Worlds Work:

“Scripts are just data – just text! — you could load them from a remote site. If there’s a popular set of scripts that lots of people load from a common location on the web, then standards could start to emerge based on actual usage. As long as scripts could actually add data fields on the fly, as long as scripts could come packaged with all dependencies internal, and as long as things like “eaten” could be just messages to the object – you could indeed share behaviors across worlds.”

For many years software, games included, have been constructed using composable third-party libraries and modules. It is a very efficient and safe way of building, as there’s no need to reinvent the wheel if commonly used logic has already been written, battle-tested and open sourced. However, it’s inevitable that as time moves forward and complexity grows, bugs and vulnerabilities will work their way into these modules and as a result will get propagated across all software utilizing them. This is not so much of an issue if there is a centralized entity responsible for managing that codebase, as they can act quickly to remedy the situation and release new versions. However, this all becomes a bit messy if we want true decentralization through DAO governance, community proposals and voting.

When thinking about what type of cross-game interoperability we’re going to see in the short-term it is likely to be limited to purely cosmetic items like skins. The lack of the need for behavior components with these assets somewhat simplifies the technical challenges. However, there will still need to be some sort of conversion to native data formats, which as mentioned above needs to be considered with respect to loading times and player experience. Moreover, when asked if he could ever see a future scenario where the games industry coalesced around a common set of open standards Tim Morten replied, “If we as developers have a business incentive to do it then yes, but right now there is zero incentive. In fact, I would actually pay for technology that prevented such a thing from happening in order to protect my customer base. It will also commoditize what I do and if it doesn’t put me out of a job it will limit the upside on what my business can make.” Although this puts a damper on dreams of a decentralized interoperable metaverse, Tim’s point is a valid one. Game developers are ultimately businesses and have to maintain an edge in order to remain profitable and sustainable. Perhaps as the technology matures, emergent business models will develop that allow developers to monetize in alternative ways or maybe player demand will eventually force games developers to pivot. One thing that is clear is that cross-game interoperability poses immense challenges from a technical perspective and perhaps more so from a business and social coordination perspective. As a result it will likely take longer than people expect to become a reality and may look different from what Web3 gamers envision today. 

One final project that deserves a mention is Petaverse. The project is currently in development by Tiny Rebel Games and aims to to create digital NFT companions that can last in perpetuity, regardless of the comings and goings of different blockchains, metaverses, games and platforms. They state that interoperability and ownership are strongly related. If you “own” an NFT that is dependent on the continued existence of a specific metaverse or blockchain and one day the underlying infrastructure gets shut down for whatever reason, then your asset has no utility and becomes worthless or in the worst-case, ceases to exist entirely. They argue that if you have an asset that can be ported onto any blockchain and has utility across many different ecosystems, then it is inherently more valuable and resilient.

To achieve this vision, they are developing what they call a metadata-managed “passport” system for their Petaverse NFTs. The ERC721 token contains a unique ID that points to off-chain metadata (a common approach for NFT’s created on chains where block space is expensive). This metadata functions like a universal-access “save file” and is accessible/updatable from any blockchain currently supported by the project. It contains things like the pets’ physical details and appearance, personality traits, moral alignments, inventory of toys, clothing etc. The protocol allows users to clone their NFT onto any supported chain and “stamps” the metadata with a reference to this new (non-transferrable) NFT, enabling ownership of clones to be traced back to the original NFT. Because each clone references the same off-chain metadata, any changes made to this data are synced to all versions.

Having the metadata openly available allows external development teams to freely access and interpret this data in their own game in whatever way they see fit. It is also not too hard to imagine a scenario where this metadata also contains a set of scripts that define the way the pet should behave and interact in a virtual world. However, as mentioned earlier, this still requires game/metaverse developers to interpret the data and code logic to interact with these scripts. If Petaverse or another similar project became widely adopted and popular you might see developers going the extra mile to support these assets in their games in order to bring in users.

One obvious elephant in the room is that the metadata is centralized in a database managed by Tiny Rebels. This is not their long-term plan but in order to hit the ground running and maximize player experience the project has opted to start from a place of centralization. As decentralized CDNs and storage network technologies like the IPFS network mature and become able to support fast read/write operations on relatively large datasets at scale, they will progressively move toward decentralization. Due to the challenging nature of distributed computing this transitioning from initial centralization to decentralization is quite commonplace for projects in Web3.

There are many different teams working on different types of interoperability solutions in the Web3 space. Some, like Spanning Labs and Petaverse revolve around making assets cross-chain or chain agnostic and aim to enhance both developer and user experience by abstracting away the blockchain backend and allowing each party to focus on what they do best. It is our belief that these sorts of projects will contribute to the eventual commoditization of blockspace. 

Other teams, like all those involved in the Lootverse and Dark Forest, are completely reinventing the way games are built from the ground up, putting the power of creation squarely in the hands of the community and encouraging interoperability, composability and extensibility. As the technology required to build on-chain games evolves, this will be a very interesting space to watch.   

The vision of a “Ready Player One” metaverse where every game asset can go anywhere and interact in a deep and meaningful way with a myriad of environments, items and other players seems unrealistic, at least for the foreseeable future. There are sizable technological, social coordination and business hurdles that need to be solved before we can see this sort of interoperability at any sort of scale beyond strategic partnerships between a few projects. In the near-term we may see interoperability solutions involving purely cosmetic items like skins, as these assets are simpler to incorporate because they do not interact with the game environment and do not cause game balance issues.

We at BITKRAFT are excited about the future of Web3 gaming and are actively investing in it. If you’re building in this space, don’t hesitate to reach out!