29th April 2022 - By David Amor
I see web3 as a paradigm shift for games. And while I’m not the only one who thinks so, there aren’t many of us who have also spent more than 30 years making games professionally!
Why are experienced game developers so sceptical? Partly because the benefits are less obvious and, let’s be honest, often over-hyped. It’s also hard to keep up. The world of blockchain moves incredibly fast, and few people are good at explaining what it actually adds to game design.
So why do I think this is a shift in magnitude similar to 3D, online multiplayer, or free-to-play mobile? Here’s a couple of ideas that caught my attention early on…
A fundamental difference between web2 and web3 games is that in web3 games the ownership of game assets is recorded on the blockchain, rather than being recorded in a closed centralised database owned by the game maker. It allows players to buy and sell assets. It also allows other games to see what game assets a player owns.
Interoperability is the idea of using one game’s assets in another game. The second game doesn’t have to be made by the same person and the first person doesn’t even need to be asked. In practice I don’t think this means a gun in Game 1 can be used in Game 2, but the idea can be used in a more creative way.
Anyone playing Game 1 can now choose how they prefer to progress, by playing more of Game 1 or by completing levels in Game 2.
Game 1 is an Idle Mining game; Game 2 is a Tower Defence game. Game 2 decides that a method of powering the towers is by using the iridium from the mining game; Game 1 decides that a method of doubling the idle-returns is by accepting stars that have been won by completing levels in Game 2. Anyone playing Game 1 can now choose how they prefer to progress, by playing more of Game 1 or by completing levels in Game 2. The two games become joined until one or the other decides to cut the cord. It creates a richer game because there are now multiple game loops and multiple options for players. This example describes a game pair but there’s no reason why 20 games couldn’t interoperate with each other.
Aside from being an interesting idea for game mechanics it’s also a great user acquisition tool, allowing players who have invested in one game to use that investment in another game.
Our game, The Crypt, uses interoperability. We take the Loot NFT (which we’ve played no part in) as a game piece. We also take the output from other Loot games into The Crypt. By using a combination of these, players can progress through the game. The NFTs won in our game can, in turn, be used in other people’s games.
An original Loot NFT (left), that can be used in The Crypt, and one of our relic NFTs (right) that can be won from playing
Most blockchain games keep only their game assets on-chain. It’s a good use case but misses some opportunities that building game logic on-chain affords. By putting game logic on-chain, others are free to permissionlessly build on top of the game.
An obvious first step is bots. Because the game logic is on-chain then code is free to interact with game logic without using the game interface. Bots get a bad reputation but it’s possible to design a game that expects bots to show up. In our first game we’ve already had a battle between humans and bots and it’s been fun for those involved.
Bots get a bad reputation but it’s possible to design a game that expects bots to show up.
After bots comes some more interesting ideas. Anyone could write a dashboard to track the price of resources in a game, they could build a marketplace for game assets, they could create a DAO that pools the resources of a guild and puts them to optimised use. They could decide to forfeit the game-makers game client and build a mobile version, which (rights permitting) they’d be free to sell on the App Store. Justin Glibert calls this being client agnostic.