BitCraft: Developing a Player-Driven MMORPG

Introduction

My name is Alessandro Asoni, I studied at Johns Hopkins University, majoring in Computer Science and Biomedical Engineering. At university, I met Tyler in one of our Computer Science classes. We got along very well and started working together on some side projects. After university I worked for Bloomberg as a Software Engineer, working on high-performance/high-availability distributed systems. Tyler worked for Apple and then MZ where he built out the Data Science platforms for some big mobile titles, like Game of War and Mobile Strike.

Clockwork Labs

Clockwork Labs is a fully remote independent game studio, founded in 2018 by me and Tyler. The company’s headquarters are in San Francisco, and that’s where the two of us got started. However with the pandemic, we have fully embraced the remote first strategy, and our team is now spread out across four continents (North and South America, Europe, and Asia). Our first title is the recently announced MMORPG BitCraft, which is the first project Clockwork Labs is developing. We have 13 people on our team.

BitCraft

Tyler and I were working on a different project called SkyLab in late 2018 when we started discussing the concept for BitCraft. Tyler, a longtime Runescape player, came up with the original idea, always being slightly dissatisfied with the static nature of the OSRS world. He wanted a world where Varrock was built and governed by players instead of by developers.

That idea felt very powerful to us, and we decided to start brainstorming some more detailed game design concepts to explore them further. We drew inspiration from the editable worlds in Minecraft and started to imagine what game mechanics and rules would allow such worlds to function and thrive in an MMO.

This is the selling point, and unique feature of BitCraft; we will generate the world, but all the cities and roads, campsites and outposts, and remote villages will be built by players. Big cities by large groups who get together and coordinate to leave their mark with large and bustling towns. Small remote outposts by lone wolves or small parties who would rather explore the more inaccessible corners of the world. 

Game World

The main reason why we opted for procedural generation, is that we want the BitCraft world to be massive. Handcrafting the game world wouldn’t scale to the size we are imagining. The other reason relates to the editable world idea I mentioned earlier. The BitCraft world is a blank slate for players to create in. It wouldn’t make sense for it to be carefully scripted by us since we don’t know how players will want to inhabit it.

There are some considerations, of course, the procedural algorithms have to generate a world that offers interesting landscapes and variation to allow for different gameplay opportunities, trade, etc. The activities we expect players to participate in vary from the more single player (survive on your own in the wilderness, farm and fish) to the multiplayer experiences of cooperatively building a city and creating empires.

The world offers a variety of biomes and survival aspects in the early gameplay which we think will captivate new players. The unique aspects will come when players will join together to build cities in different parts of the world. Players who travel the world will find mountain settlements, big naval ports and remote outposts in the desert, and whatever else the community decides to build.

Development Process

We use Unity as our game engine and are developing our own backend engine for the server. The development process is based on git and pull requests. Having a fully remote team, it was important to have a good process in place for people to be able to develop and test independently and have their changes reviewed and approved. This was definitely a challenge at first, as we needed process in place, but at the same time given the early stage of development, we also wanted to avoid slowing down the dev team unnecessarily.

The procedural world is generated offline, using a variety of different passes, from generating island shapes, to elevations and biomes and finally to resources.

We have also built a few tools to tweak the generated world manually, as it will sometimes be useful to be able to fix up the terrain, or manually place some interesting features or resources.

Funding

We felt that our idea was compelling enough that we could raise VC money instead of going the crowdfunding route and risk disappointing players who invested their own money. Also, a game this size requires a lot of resources, many iterations, and user testing. The raise allowed us to hire some key members of the team, on the engineering side as well as art and communication. We are now building out many of the core mechanics of the game as well as developing the lore and art styles further. We will need to test these early with players to understand what works and what doesn’t. Most importantly the money gets us time to iterate on the mechanics to make sure we are getting them right.

Future Plans

We are focusing on the development of BitCraft and leaving as little as possible up to chance. That means doing early playtests with the community and getting valuable feedback to incorporate in future updates. We currently plan on doing many playtests and we believe the resources we have will get us to a version of the game that is fun and has many of the core features we envisioned. 

We are expecting that the community will grow as we allow more and more people to try the game, and that word of mouth will be the primary engine of promotion for BitCraft. We are also active on social media to keep the community up to date on what we are developing.

The most important advice we can give, which is advice we got ourselves from other game studios and startups, is to test early and often. This advice is repeated a lot, and I think what is tricky in particular for games is that often you don’t feel like you can get valuable feedback when you are still working on a prototype. It’s also scary to put an unfinished game in front of people. However what I would suggest is to try to identify the core mechanics at first, develop those into the simplest version of your game you can imagine, and then have your friends try it. See how they interact with it, what they like and dislike, and so on. The feedback you get at this stage is invaluable. You can get validation that what you are building is fun, or if it isn't, figure out what was wrong about your assumption and fix the issues early.

Alessandro Asoni, Co-Founder at Clockwork Labs

Interview conducted by Theodore Nikitin