.svg){kind=small}
Recent years brought us one of the use cases blockchain enthusiasts have been dreaming about: blockchain (or crypto) gaming, usually called Play-to-Earn. The idea was simple - most games have in-game assets - like artifacts, cards, and skins - that can be represented by non-fungible tokens (NFTs). And a token can represent a premium in-game currency and provide additional web3 mechanics like staking. It looks like the dream is here - but if we dive deeper under the hood, we will notice that not everything is perfect.
Why are most crypto games built only around token and NFT ideas?
The first challenge that we face is the finality time. Finality time is the time you need to wait to become sure that your transaction is actually executed. Most blockchains reach finality in minutes. Even the fastest ones - like NEAR with 2s finality time - would not be capable of handling the traffic of first-person shooter, racing, or any other type of real-time game. We can completely exclude physics as it runs very heavy computations. In any case, we can use tokens - both fungible and non-fungible - to provide an additional layer in the metagame of such games - skins, auctions, etc.
But if we put attention to turn-based games - we'll face another problem of blockchains in general - transaction costs. It's a common practice in web3 to make users pay for their own transactions, and it works well in the DeFi space, but when it comes to other types of applications, it can become a problem. You just cannot ask a user to verify every action inside the game, as no one would play a game where half of the gameplay is signing transactions with a wallet. In some networks, you can bypass this, allowing the application to spend money to cover transaction costs by providing a clear limit to it. Check out Near Social as an example - but it's still not an answer, and we'll try to explain why.
If you think about putting your game logic in smart contracts, you may come up with the idea that it is not possible. Game logic transactions would be extremely heavy, checking a lot of conditions before actually modifying the game state. You can still do it, and even if the transaction costs in the particular network in a fraction of a cent - we can bet that your user would not be happy to pay a dollar for a 5-10 minute session.
Still, there is value in making that happen. First, you will have a clear log of every action that happened in your game. Imagine a global chess ledger where all chess games played are stored, so any company can build its own frontend while the global leaderboard is shared and ELO rating is calculated correctly. Second, you can introduce more complex game economics, where the resources that people gain and spend are verified by smart contracts - just as in other DeFi applications. Third, you can literally eliminate cheaters - since the transaction log is public and the logic is in smart contracts - there is no way to hack the game if the logic is implemented correctly. We can continue this list, but you can see the pattern - as you move more to the chain, your players should also pay more to cover transaction costs.
Yes, there is a workaround to solve some of the problems mentioned above - launching your own sidechain, like Axie Infinity. But be aware of the costs and risks associated with that, that count in millions of USD.
What if there is a solution that’s similar to launching your own sidechain but with a fraction of the cost? Introducing Private Shards. Think about the Private Shard as a customizable sidechain run by a professional validator that is connected with the layer one mainnet chain. It allows you to leverage all benefits of public open-source blockchain, make the network protected from activities not connected with your project and be sure that the transaction throughput would be enough to satisfy your users.
Private Shard allows you to start your game and forget about the costs usually associated with blockchain development. Not only do the users not pay for transactions, but you don’t pay for smart contract deployment as well. Since the environment is protected, you can also upgrade contract logic with every new release of your game. Once the game is scaling up and the fact that there is only one owner that controls the whole network - you can delegate the ownership of validators to your community members and turn the private network into a DAO-owned one.
Calimero philosophy is built around simplicity - we believe that the developer should not spend a lot of time fighting with the tools. So every aspect of our platform is built with this idea in mind - you should spend a maximum of one minute to spin up your Shard, one more minute to install the necessary components, and then just visit the Console only to add more functionality - the rest of your time should be spent on your product.
Let’s see how you can utilize different aspects and features of Calimero in your web game.
As mentioned above, you should treat a Shard as your own zero-gas network. The interaction experience with the Shard is completely the same as with mainnet - the only thing is that you don’t pay for the transactions.
If you’re not building a game that would be completely disconnected from the outer world (if you do, you should ask yourself twice - do you need blockchain?), the bridge should be an essential part of your solution. We have developed the most secure and flexible bridge available on the market - let’s see how can you use it in your game
Simple and straightforward - you can bridge NFTs that were minted on the mainnet to Calimero or vice versa - depending on your setup. The connector is installed in a minute, and the NFT transfer takes no longer than 5 seconds (actually, that works for every other type of transaction). You can start using NFTs in your game in the same way as other web3 games do - but the private Shard itself opens a lot of additional opportunities. You can mutate the NFT after some in-game actions are happening - like, tracking player experience in the “Player” NFT. Forget about the limits - your transactions are free.
Even simpler than the NFT connector - bring your existing assets to the Shard with just one transaction. You can deploy your in-game currency token on the mainnet and bridge it to the Shard, where people can enjoy free transactions and send tiny fractions of tokens for various actions. You can also bridge USDT to the Shard - the bridge will keep tracking the consistency of data, so the number of tokens locked in the mainnet would be precisely the same as the number of tokens inside the Shard. There are a lot of opportunities to use this feature, but we believe that free microtransactions would drastically improve the user experience.
The most exciting part - probably, the one you’ve never seen before. With Calimero bridge, you can write smart contracts that can trigger methods of the contracts that are deployed in another network. This does not sound cool, but think in the following way: now you can separate some parts of your game between public and private networks. NFT minting - probably should be done on a public one. Micropayments and action tracking - probably better to do on a private part. And the bridge is just working, hiding the complexity of cross-chain interaction and turning it into an experience similar to using an API.
The gateway acts like a firewall - you can set up different permissions for different user types. Limit the ability of new players to use some aspects of the game, or ask for KYC if the user wants to withdraw the money, or create “guild masters” that have additional powers in the game - everything is possible (and if it is not possible, we’ll add that feature in 1 month).
After reading this, can you answer the question - what is stopping you from starting your new web3 game? Calimero has delivered a solution that eliminates almost every barrier that separates web2 and web3 gaming - so there is just no option to say, “you can’t do that on blockchain because…..”. Now you can do everything - and we are here to help. Contact us if you’d like to get a free trial, or need help to get started
.svg)
