A Glimpse Into the Past
The concept of smart contracts predates the inception of blockchains, having been delineated by Nick Szabo in 1994.
The first practical application emerged years later in 2015 with the Ethereum platform. Fundamentally, smart contracts automate contractual obligations and eliminate intermediaries.
Smart contracts have found extensive applications in finance, overshadowing their potential to automate processes across various domains.
Decentralized Applications (DApps) extend beyond financial tools; they merely scratch the surface. While the DeFi market has soared in complexity and success, other sectors lag behind significantly.
Challenges Facing DApps in Non-Financial Sectors:
- Development complexity and cost
- Blockchain’s slow performance
- Lack of robust integration tools (wallets, infrastructure, etc.)
Attempts at broader application have made little headway.
The State of Gaming in Decentralization
CryptoKitties marked the first step towards decentralized gaming, though it was largely controlled by its developers.
Axie Infinity, despite its success, faced significant challenges, including a $615 million hack, due to its proprietary blockchain.
Moreover, its gameplay mechanics are private, challenging its decentralized nature.
Other projects like Gods Unchained and Heroes of Mavia also fall short of full decentralization. The current trend involves separating gameplay from asset ownership (NFTs for characters and items), with gameplay largely centralized.
However such projects omit that mere ownership of NFTs does not provide “full control over assets.”
Assets only have value thanks to gameplay mechanics, which are 100% under the control of developers.
A popular term describing current projects is GameFi.
Low decentralization and emphasis on play to earn.
Examples:
- Axie Infinity
- Illuvium
- Splinterlands
- Pixels
- League of Kingdoms
- Gods Unchained
- Heroes of Mavia
- Seraph
Decentralized Games
Truly decentralized games are currently few and far between.
Existing games can be divided into the following groups:
Focus on the Blockchain Component
The gameplay consists of a basic set of actions or resembles very basic game mechanics. The characteristic of such projects is that tokenomics are central, with gameplay tacked on top. It’s hard to call these fully-fledged games.
Examples include CryptoKitties, DefiKingdoms, Crypto Raiders, and Neon District.
Community-Developed Ecosystems
The main project develops only basic assets while the community ecosystem develops games for these assets.
This sounds cool and could achieve full decentralization.
The problem is that games tend to be boring and often have centralized gameplay.
This approach could lead to some good games, but any successful project within such an ecosystem is likely to outgrow it and become its own entity (as happened with DOTA evolving from a map for Warcraft 3 into a standalone game).
Examples are Aavegotchi and Axie Infinity (planned).
SDK for Simplified Game Development
This route allows for significantly fewer resources to be spent on blockchain, and in theory, the gameplay should be more refined.
This approach is very promising, but there is a risk that all games will look alike and be quite formulaic.
Nonetheless, studios that invest efforts in developing an SDK based on their contracts have every chance to make a good game as a “showcase” for their engine (similar to Unreal Tournament from the web2 era).
Examples include MUD SDK and Paima Studios SDK.
Effort to Combine Forces
Creating quality gameplay and laying the foundation for full decentralization.
This approach requires prioritizing the creation of a gameplay process where blockchain serves as an advantage rather than a checkbox feature. This direction is the most promising but also the most challenging.
Examples are Primodium and Sacra: Falling of Myrd.
Why Do We Need Decentralization for Games?
To break the current trend, it’s necessary to focus on the question, “Why does a game need to be decentralized at all?” and convey this to the users.
The simple answer to this question is the same as “Why is Bitcoin needed?”
Real Ownership of Assets
True ownership of an asset means control over its value. Only by providing decentralized gameplay can you guarantee real ownership of the asset.
Security
Open source is not just a whim of crypto maximalists. Only open source allows for a real security audit and identification of vulnerabilities.
Moreover, immutable (or DAO-controlled mutable) code guarantees the preservation of assets and the gameplay mechanics that give value to the game’s main assets.
Economy
Building a complex economy capable of handling significant assets requires unprecedented quality and security of code in the gaming industry. Fortunately, years of DeFi existence have accumulated best practices in this area.
For a game built on smart contracts, it’s easy to imagine an economy operating billions.
Excluding the influence of third parties, whether intentional or unintentional, ensures confidence in the stability of the in-game economic model.
Resistance to Censorship
I think almost every gamer has faced being banned for unclear reasons or even denied access to a game altogether. A decentralized game is protected from this as much as the blockchain it runs on is protected. Even in the presence of a centralized company that supports the game’s UI, the original client code will always be available, allowing the game to be launched locally.
Community and Governance
The openness of the product attracts a genuinely interested community around the project. The ability to contribute and manage key issues through voting creates incredible long-term support.
Integration of Real Assets into the Game Economy
A game can be seen as a small state. Like any other state, to ensure a stable economy, it can own assets of other states. This is fully relevant for decentralized games. It’s easy to imagine assets locked in a game generating passive income and creating additional value for the project.
All of this can be summarized in one word: DeGame.
Technical Implementation
Currently, various blockchains have their smart contracts, but EVM and Solidity are the de facto industrial standards.
It’s not just that 90% of all developments are written in Solidity, but also the infrastructure built around EVM networks.
RPC providers, The Graph protocol for the backend part, Dune analytics dashboards, and other tools solve many problems that are difficult to compensate for with other tech stacks.
But is it really possible to “squeeze” game logic into Solidity given that the size of contracts is limited to 24KB and the block time in most blockchains does not exceed 2 seconds? Yes, it’s more than feasible.
There are many design patterns for writing complex logic, such as The Diamond Standard (EIP-2335) and the use of libraries along with the ERC-7201 standard.
These approaches allow us to almost completely bypass the limitation on the size of the smart contract code.
The gas limit per transaction imposes serious restrictions on the number of actions a player can take in one go.
However, the use of packed data and standard gas optimization methods allow for even complex logic such as pathfinding on terrain and determining lines of sight within a single transaction.
Blockchain enables unique gameplay mechanics for multiplayer. In a standard MMO game, solving the problem of lag with 1000+ players online is practically impossible, but here, the mechanism of competition for gas comes into play.
Moreover, gas payments can be tied to in-game currency through ERC-4337. This means you can control the online servers with in-game mechanics (pay more in-game currency to participate in a castle siege with other players, for example).
At this stage, it’s too early to talk about a fully decentralized game with real-time action gameplay. However, game genres with turn-based gameplay fit perfectly with the concept of block finalization. Essentially, technical limitations encourage the creation of new genre combinations, such as turn-based MMO RPGs.
Over time, a specific blockchain will be created to process on-chain actions of players sufficient even for real-time shooters. L2/L3 blockchains, which can now be deployed in minutes through a UI, have proven themselves well in this regard. It’s more than realistic to imagine a situation where a blockchain game can create its own temporary L3 for a specific game session.
The Future of DeGame
As always, games present a real challenge to the entire IT industry, pushing it towards more efficient solutions.
Not only is there a need to develop complex logic on smart contracts, but the blockchain must also be capable of processing a huge number of transactions.
Fortunately, there are now many blockchains capable of achieving the necessary throughput.
A sufficiently large project could even develop its own blockchain to handle transactions specific to the game. A decentralized server part for the game with its validators and consensus.
However, in the early stages, a standard universal blockchain is more than enough for games without real-time action.
And as experience shows, it’s better to focus on one thing, whether it’s the game itself or the infrastructure in the form of a fast blockchain.
In the future, we will see many projects that implement gameplay on smart contracts and open a new era in the gaming industry.
This revolution goes hand in hand with the evolution of all crypto projects, and it’s only a matter of time before the old game development is displaced by new approaches.