Building A Blockchain Game Dapp: One Year In
I recently stumbled on to an older email I sent to a friend mentioning a game idea I was researching. It was dated March 13th, 2018. At the time, having long been enthusiastic about Bitcoin, I was finally learning about the Ethereum network and how to build applications that run on it. Learning about something that introduces a new paradigm is always great; ideas tend to flow like water. That was the head space I was in when I emailed my friend about one idea that stood out. Here are a couple of lines from that email:
I've had dozens of ideas. Most of them are already being executed on. Others I eventually realised were unfeasible.
I had this one cool game idea. I haven't been able to find anyone doing it.
The idea was not profound. It was thus: would it be possible to port an old 1980's BBS game, Trade Wars 2002, to the Ethereum network? It was a naive idea, but it was an inspiration and a starting point. Along the way, I found an unexpected collaborator. World class designer Walter |2| Costinak got involved and gave the game a unique look as well as a name: Orbiter 8.
Like Trade Wars, But Different
I soon decided that even if a direct port was possible, it was not what I wanted to do. However, Trade Wars 2002 held a vital design component that helped me craft a game tailored better for Ethereum. The game world in Trade Wars consists of a directed graph where each node represents a "sector" of space that you can move to via your ship. A directed graph is a nice way to represent a large virtual space using a relatively small data structure.
I set about building a blockchain based game world around a basic directed graph. Working in my spare time after work, it took six months to build and release an initial prototype to a public test network. In Trade Wars, the game world is generated before anyone starts to play in an event called "genesis" where all the nodes are created and written to disk. Writing an entire game world to the blockchain at once would be prohibitively expensive, so I took another route. The cost of writing the data for a new sector in Orbiter 8 is democratized to the players; new sectors are dynamically generated and written to the chain when a player encounters one for the first time. A secondary benefit is that the frontier of space can be expanded continuously rather than confined to the size of the original genesis. To incentivize players to explore, they will be rewarded with an early opportunity to claim property in each new sector. Owning game world properties will not only provide value in the game play experience, but will be tokenized and thus inherit the utility provided with standard Ethereum tokens.
On January 28th of this year, I released our prototype contracts to the Ropsten test network and posted a Web3 based game client on Orbiter 8's website. The demo serves as a proof of concept for our dynamic world building model and provides a sandbox for exploring the costs associated with exploring the frontier this way.
One Small Step
While it felt like a great victory, the demo we released had fewer features than I hoped for, took considerably more time to create than I could have imagined, and is by no means written in a clear, efficient, or pragmatic way. Heavily inspired by the Blockchain Zombies tutorial, I created Orbiter 8 as a Web3 app. For local development, I found the Truffle Suite to be great way to ease the pain of managing a local Ethereum instance. I chose to use VueJS as my client's application framework because 1) I've used it before and 2) it's really good. While there was (and still is) a lot left for me to learn about building on this stack, it feels a lot like a familiar, traditional full-stack Web experience where you think of the blockchain component as you would other data stores.
The familiarity of this tool chain started off advantageous but soon another problem emerged. I have worked with several game engines including both Unity and Unreal, but I have never used a browser based game engine of any kind. Instead of looking for one, I started building my own. It's not that I ever made a conscious choice to write my own engine, I just never stopped to think about using a game engine until I was fairly deep into the project. I wanted a lightweight game client that's easy to host and distribute, so all of the game assets are SVG and go directly into the compiled JavaScript. The assets are stitched together into a scene using VueJS to create a several layers of SVGs that, together, render my game world.
Building the client has been fun and satisfying; building a game engine from scratch - even a modest one such as this - takes an unfortunate amount of time. Worse still, modern game engines provide high quality rendering and effects out of the box that I will not achieve with my custom engine. Fortunately, Orbiter 8's core game play is entirely in the code that lives on the Ethereum virtual machine rather than the client, so a new and improved game client can be created without impacting the game play. Still, if I want a fun game, my client is going to have to meet a certain level of quality. Fortunately, Walter's design work is turning the game into something elegant.
What Works Well
While building a blockchain game (perhaps more accurately referred to as just a game dapp) comes with many challenges and restrictions, some of Orbiter 8's most interesting features come inherently with the platform. First, since Ethereum is a single global instance of a virtual machine, Orbiter 8 will naturally be massively multiplayer with a single game instance serving the entire world. Because Orbiter 8's game world is dynamically generated, as players press up against the frontier the galaxy will continue to expand and be able to host more and more players. When numbers get significantly large, you may not be able to list every player currently in a sector with you in your client's console. However, they'll be there with you.
Another benefit inherent to the dapp paradigm is the notion of players paying tiny payments for each turn. I have added no additional fees, so the only fees involved in taking a turn are paid to the miners who support the network the game runs on. I see this model as a thing of beauty and hope it can be sustainable. In Trade Wars, the administrator could set a maximum number of turns anyone could play in a single day. With limited turns, players used their turns more mindfully. In Orbiter 8, every turn costs just a little bit of Eth to pay for the transaction. The approach of pay-as-you-play creates a new and interesting collection of incentives to design around. The hope is that this micro-payment will encourage players to take their turns mindfully. This model stands in contrast to the popular subscriber model where players pay a flat monthly fee no matter how much they play.
It would be irresponsible not to mention the value of tokenization. There are a variety of token standards and Ethereum makes it rather trivial to produce a new token. By treating objects in the game as tokens, they become objects whose ownership can naturally be tracked on the blockchain. This also opens up the opportunity to transfer ownership of game objects in marketplaces outside of the game itself. Generally speaking, tokenization is one of the most hyped ways to integrate blockchain technology into gaming experiences with cool solutions coming out like Enjin and Loom. In Trade Wars 2002, ownership and trade are critical game play components. It seems only natural for a blockchain-based game to take advantage of the native tools for ownership and exchange.
The Giant Leap Ahead
The January release met the acceptance criteria (interstellar travel) for our first of four scheduled demos. The second demo will allow players to interact with the objects in each solar system including planets, moons, space ports, and other players. The third demo will introduce basic trade allowing players to collect, trade, and sell resources. The fourth demo is the moment when Orbiter 8 will finally feel like a game as it will introduce the element of combat.
Having limited time to invest, the first demo took a full six months to create. We are three months into the second demo and I believe it will take longer to accomplish than the first. The Ethereum platform itself is likely to change and evolve before Orbiter 8 is ready to launch to the main network. While it's easy to look into the abyss ahead and feel overwhelmed, working on this project has proven eye opening and exciting, and generally speaking - I've been having a lot of fun.
Closing Linkage
If you would like to keep track you can follow the game's progress on Twitter, the Orbiter 8 website, or the Discord channel. You can find out more about the creators and how to reach us on the Partavate website.
Hands-on engineer with 25 years of software development across Web, Blockchain, AI, Gaming, Mobile and Aviation. Wrote my first line of code in 1994 and my most recent line last night.
5 年Cool post! This would be fun to port to EOS. That’s where I’ve spent the last year. Since txs are free for users I might need to implement a “fee” like maybe a fuel token required to explore space. I also choose Vue for its ease of use. Hope all is well.
Co-Founder & Chief Executive Officer @Belter Labs
5 年Have you considered rolling with Enjin? :) Our platform is out on testnet, Unity SDK is super-decent - and we have kickass dev docs.?
Dear headhunters, please read my LinkedIn profile, all my experiences can be found there, no need for guessworking. And no I'm not looking for a new job either.
5 年That’s cool.