Chain Clash is a mobile-first browser game built on EOS. Players can join their favorite crypto clans, collect a variety of different avatar clan fighters and train and develop them over time. Avatars engage in clashes versus others to test and show their strength and ultimately score points for their clan. The game is our take on utilizing blockchain in a meaningful way to create a fun game.

Blockchain and gaming seem to be a great fit (learn why in this and this post), which is why many people in the space — blockchain enthusiasts, players, as well as game developers — set their hopes on the topic. The same goes for us, which is one reason for why we’re building Chain Clash. In this new series of posts, we’ll share some of the key take-aways we’re making along the way of developing a blockchain game.

Let’s get started with the first one…

Decentralization is a process

The ideology behind decentralization is what everyone in our space believes will be the future of gaming. However, decentralization in the context of gaming can have multiple manifestations.

Decentralizing ownership. That’s one of the biggies in blockchain gaming, right? Transferring ownership of in-game assets from centralized systems to decentralized ones is what enables true asset ownership for players, instead of just the game developer.

That’s one of the biggies in blockchain gaming, right? Transferring ownership of in-game assets from centralized systems to decentralized ones is what enables true asset ownership for players, instead of just the game developer. Decentralizing game logic. Not only in-game assets, but the game itself can be decentralized. The back-end of the game, holding the game logic and processing player requests can be done on-chain instead of with centralized servers. That’s a great way to make processes and interactions transparent and the game itself immutable.

With Chain Clash, we’re aiming to make our game as much “blockchain” as it can be. Regarding in-game assets on blockchain, that’s rather straightforward to do. However, making game logic work on-chain is a whole ‘nother story.

Spoiler: for some aspects of a game, there can be a big trade-off between decentralization (in the sense of making it work on-chain) and UX.

UX is key

For a seamless and fun gaming experience, UX is particularly important, which also includes the appeal of game mechanics. Now, without a minimum level of complexity in mechanics, games can become boring rather quickly. However, bringing complex game logic to blockchain in a feasible way is not necessarily an easy task.

Let’s take a look at two of the more pressing obstacles when building a blockchain game.

Problem: cost and time of transactions

Complex game mechanics most likely induce more interactions between player and game. Letting players pay and wait for each interaction is neither fun nor feasible. Imagine you’d be playing a round of speed chess and for every turn to confirm you’d have to wait a minute and/or pay a couple of cents. Now, this problem can be mitigated to some extent by choosing the right fit of blockchain. However, generally choosing more speedy and cost-efficient solutions will most likely happen at the expense of decentralization.

Learning 1: we currently can’t have both, a user-friendly and fully decentralized game, so we’re focusing on one (UX) first.

For Chain Clash, we’ve decided to build on EOS to be able to provide good UX to our players, by eliminating transaction fees and enabling quick transactions. But there are always two sides to the coin, right? Making it cheaper and faster for our players to interact with the game, in the case of EOS, induces more costs for us. As the developer, deploying the smart contract, we’ll have to make sure that enough resources are available at all times, so our smart contracts can function properly (in case you’re new to EOS, that’s a mechanic specific to this blockchain). Although that was expected, it still results in us having to consider which parts of the game logic we put on-chain to make the smart contracts feasible.

Learning 1.5: Nothing is for free, especially not decentralization.

Ultimately, we’ve decided to apply the traditional 80/20 rule to this problem. Our rule of thumb when deciding which parts of the game to put on-chain is to always consider which parts of the game logic have big gameplay impact (80%) while taking little computing resources (20%). Thus, the parts of the game that are resource-intensive remain off-chain for now.

Problem: transparency

Yes, you’ve read that right. Despite transparency always being declared as one of the major benefits of blockchain, in the context of gaming it can also be a drawback. Just imagine you’re playing a round of online battleship and your opponent just has to visit a third-party website to see your ship placement at the beginning of the game. In traditional gaming, that would be considered cheating, right? Well, if this version of battleship was built on blockchain, and all interactions are done on-chain, it would be quite easy to find out your strategy. Since the blockchain ledger is public, everyone can see what you’re doing.

Learning 2: For the sake of fun and fairness, some parts of the game better be off-chain.

This problem doesn’t apply to all blockchain games and eventually can be mitigated by adjusting the architecture of a game as well as the game mechanics. However, coming back to our first learning, we’ve decided to build something that works in a user-friendly way and is technically feasible first. Eventually, the technology will allow us to decentralize those parts of the game as well.

We’ll get there

In the current state of blockchain technology, every game developer will have to lower their sights regarding either UX or decentralization at some point. Interactive blockchain games, that nail it in both areas, still seem to be some way off. However, since blockchain games are still in their infancy, it’s not necessary to accomplish both right away. That brings us back to our first key take-away: decentralization is a process. Creating good gaming experiences first, and then incrementally making it more and more decentralized, at least for us, is the way to go.

The path to decentralization and the trade-offs along the way, belong to one of the most interesting topics to be tackled in the blockchain gaming space. Eventually, every game project will have to figure out a way and balance that works best for their specific requirements. Sticking to one major objective (in this case either UX or decentralization) when evaluating the design and implementation alternatives will help tremendously in accomplishing that.

This was the first post of the series about our key takeaways from developing a blockchain game. If it caught your interest, make sure to stay tuned for future posts. We’ll dive into more of our learnings along our journey and would be happy to get your feedback, thoughts and own learnings in the comments below!