Author:y77c
Compiled by: TechFlow
We develop Project Mirage (@mirage_game_), a casual on-chain island building game. Since launching on the testnet in April this year, we have been releasing new features, fixes, and experiments every two to three weeks. Although we are still in the early stages of game development, these iterations have allowed us to learn a lot in the process.
(Note: This is a transcript of a speech I gave at an ETHCC-related event)
I lied. I'm not bearish. Take off your shoes, we're going to build games on the blockchain until it reaches mass adoption
Don't get too hung up on theory/philosophy
As early developers, we were probably attracted to the on-chain gaming space because of the Autonomous Worlds theory — a world that runs forever, is permissionless and composable, where you truly own your assets. The harsh truth is that for most players, none of that matters. Players seek fun and engaging experiences. Maybe 1 in 100 players (since on-chain open backend is already high-end) will be inspired by the extensibility of the game and build on it. Openness and composability are nice features, but they won’t drive traffic to your game. What really drives traffic is fun, unique experiences. If being on-chain doesn’t enhance the gaming experience itself, you shouldn’t build a game on-chain. Instead of asking “What game can we build on-chain?”, the better question is “For the game I want to build, how can being on-chain make it better?”
In a niche, early-stage, and research-driven space, we often convince ourselves that following theory will ensure success. However, a game is a game, and a game is a consumer product, regardless of the underlying technology. Providing a fun and unique experience is the only way to succeed. The challenges and visions of this space keep us interesting, but as game designers, the ultimate goal is to create experiences that bring joy to the player.
Research GameFi
GameFi is often criticized as unsustainable, but we have to acknowledge that the speculative nature of cryptocurrencies is an excellent virality tool. The GameFi project has done an excellent job of attracting users and building a community, and the “Fi” part empowers people and creates a sense of belonging. Even holding underperforming game assets, being with the community fosters connections between players and provides a unique experience. (In fact, this punishing behavior may have a near-win effect, making the game more attractive.)
Building games on-chain is extremely challenging. Not only do you have to deal with resource constraints, you also face the same challenges as any regular application, such as daily active users (DAU) and retention. As a technical team, we initially focused on overcoming resource constraints, but later realized the importance of building virality into the game early on. Fortunately, it's not too late.
If you are just starting out, it is important to think about who you are building for. Are you targeting crypto gamers, regular gamers (currently hard to reach), or venture capital firms (VCs)? If you are building for crypto gamers, know that they are overstimulated, have short attention spans, and are constantly being tempted by new forms of gamification. If you are building for VCs, it is best to think of your game company as a research organization, trying out any new technology possible, and forgetting about users in order to sell vision and imagination. For those of us with little brains who just want to build interesting things, financialization is inevitable to survive in this space.
It is not necessary to be fully on-chain in the early stage
Now, with many on-chain games live on testnets and mainnets, and the larger crypto gaming market vying for attention, you need to win the battle for attention, no matter what your theory is. One way to win this battle is to test and iterate quickly to understand exactly what players want. However, it is difficult to iterate quickly on a fully on-chain build because it suffers from resource limitations or complex solutions to resource limitations.
We found that the best approach for us was to keep the core game logic on-chain while using off-chain solutions for experimental features or those that don’t have a good on-chain solution yet. Mirage’s randomness and some experimental features are off-chain, which allows our small team to release quickly without too many constraints. Once we decide a feature is permanent, we move it on-chain for scalability and permanence.
If we were to start over, the classic GameFi approach of just putting assets on-chain would probably be a better way to iterate faster. However, starting with absolutely no resource constraints will impact design decisions and could lead to more headaches when migrating to a limited on-chain environment. It's a trade-off. Both fully on-chain or hybrid are valid approaches, but both can go wrong. Ultimately, no matter what technology and approach you choose, you'll need to survive by iterating quickly and winning the battle for attention.
Summarize
I believe fully on-chain games will be the vehicle for novel on-chain use cases and will enable creative player behaviors we haven’t seen before. No more visions to discuss, now go build a fun game.
