4 Months For A Game: How To Self-Publish Quickly As A Small Studio?
By Samuel Kahn, CTO at Darewise(@kahncode)
The Story So Far
When I heard Benjamin Charbit, CEO of Darewise and my partner in crime, saying we were going to launch our Massively Multiplayer Online game (or MMO for short, like World of Warcraft among many others) prototype in four months, I didn’t think it was possible. As CTO, I couldn’t help but think: “we don’t have enough time, or resources, to build a game in such a short amount of time!”. Needless to say we were astonished by our own results!
To say it was a challenge would be an understatement. Had we stayed in line with the classic formula to make an AAA game (a game developed by a major publisher on a large budget — think, summer blockbuster movie), things would have been simple: we would have hired a bigger team, gotten an even bigger budget, and most importantly, we would have gotten a publisher. Their support is crucial in bankrolling your project, taking care of marketing, publishing, but more importantly in our case, they usually take care of putting your game online with their engineering teams! Since we came from that world, it seemed like the logical thing to do.
But our project, just like Darewise, was different: coming from the world of AAA games, we wanted to prove that there was another way to create and distribute a high-quality game as a small developer. And most of all, we wanted to get our game online quickly so we could iterate on it thanks to direct user-feedback. Having only a small team, very little resources and no publisher, we couldn’t have done it five years ago. Yet we managed it, by being smart, relying on our agility and getting the right partners.
Why Self-Publish?
Let’s roll back to the early stages of our project: Benjamin and I had decided to make a high-quality PC video-game, while staying in control of its development all the way up to its launch, and improving it thanks to close contact with future players. We just needed a publisher to back up our project… except it didn’t follow their expectations. It was simply too risky for them: not only did it not fit within their game portfolios, but they likely wouldn’t allow us to give access to our game while in development, to validate our ideas continuously with player feedback. Usually, Publishers want to be in control of all the messaging, and only allow final quality things to be shared publicly. So for Benjamin and I, things were crystal-clear: we weren’t going to waste five years of our lives toiling on a game, only to realize after its launch that it didn’t work or that no one wanted it! If we were going to make this game, it was going to be on our own terms.
The only problem was that, at the time, we didn’t think self-publishing was even a viable option: at first, it looked like a goal that only the elite of developers could ever hope to reach, if they had a large team and an even larger budget. Most studios will hire up to 150 people to work for 5 to 7 years on a game with a budget going at least up to €50 million. We thought there must be another way, and looked at both tech startups and mobile games. Tech startups will typically create an MVP (Minimum Viable Product) that they can test out directly with a smaller market as a proof-of-concept to see if their project is worth pursuing. Similarly, mobile game developers follow a go-to-market approach, by testing out several game prototypes before selecting the most viable one and focusing their resources on it. Following in their footsteps, we could quickly build and launch a prototype of our game, while keeping our team small and our expenditures low.
This may sound similar to early access, but our situation was different: early access is limited to games with already stable features that can regularly promise new content to their backers. Our model was what I like to call “open development”: our players access a regularly updated development build of the game. We choose what we share with the players, and make no promises on any of the content or features shown. Meanwhile, we observe the players and run qualitative and quantitative analysis. This development strategy would limit our risks if the project was unsuccessful, making Darewise a better investment opportunity, and allowing us to fine tune the game to make the best possible version of it.
Though this development strategy is still pretty niche, it’s already been validated by several recent game-as-a-service successes. I could mention Dauntless by Phoenix Labs, Spellbreak by Proletariat, or Riot Game’s League of Legends! Other studios are taking note, German developer Yager’s The Cycle has been following a similar strategy. More and more, this self-publishing strategy has shown its efficiency for small developers and is sure to become a stronger option as time goes by.
How Did We Self-Publish?
Going back to our game, after setting our objectives and finding our business model, we had to go into the nuts and bolts of how we could get our game off the ground. Firstly, we needed to create our MVP: since our team at Darewise was entirely composed of game developers, they were very efficient in developing new features. But we didn’t have the resources necessary to build our own game engine, or to create our game’s backend services (everything around the game that make it work, such as authentication, payment, or choosing how and where the game servers are hosted). So, I set out to evaluate all available services and technologies on the market, and selected the best solution providers. Over the game’s production, they became our close partners, and I know for a fact that we couldn’t have achieved this challenge without their support.
Epic Games’ assistance was key in our success: traditionally in AAA games, most studios build and maintain their own game engines, often reinventing the wheel in the process. Ubisoft, for example, develops its own game engines, like Anvil or Snowdrop. Thanks to Epic Games’ Unreal Engine, we avoided spending years of development and millions of dollars into creating our own game engine. Unreal Engine is probably the benchmark for how powerful and user-friendly a game engine can be! And even better, they supported us from day one and have been doing so throughout the whole process, even going as far as giving us a Megagrant.
Improbable also supported us right from the start: since the earliest stages of development, we ran our game on top of Spatial OS, their high-scalability engine. Its distributed servers allowed larger games, with more players and more complex AI, leading to a more immersive multiplayer experience. And they even allowed us to host our game on their servers for free! We started from the very first day using their infrastructure, and in the first week, we had a playtest that was running on our target infrastructure.
Instead of making a smoke-and-mirrors demo, we built an embryonic prototype very quickly thanks to the tools of Unreal and SpatialOS. We iterated on it regularly and every sprint’s playtest was better than the previous one!
Three months before launch, since development was well on the way, I decided to keep the team focused on getting our game prototype ready, while I would work on sorting out our backend. Our team has a lot of C++ experience, but no one in-house had any concrete web front-end or backend expertise. We still had no account management system, and most of all, no website and no platform to distribute our game.
Of course, we could have used Steam, the world’s most popular PC gaming platform, to get our game out to the largest audience possible. But the platform wouldn’t have given us access to players’ email addresses, preventing us from exchanging directly with them. Not to mention the fact that the platform takes a cut of every transaction. To remain in complete control over our game, our best option was to look for partners who could provide the tech and expertise we lacked. Fortunately, there are many backend-as-a-service solutions that specialize in gaming.
After thorough evaluation, we decided to go with PlayFab, Microsoft’s game backend-as-a-service. Playfab supports a limited amount of customization using JavaScript, which made it easy to tailor it to our needs. We integrated user accounts and authentication, leaderboards and database services, as well as basic analytics. For €100 a month up to 100000 users, this is a lot for the money! And although their tech quickly showed its limitations, we ended up with a working backend that fit our launch needs.
Out of our main partners, XSolla was particularly helpful: we didn’t even have a single line of code for our landing page at the time. They liked our vision, believed in our team’s solid background and were convinced by Benjamin’s pitch. So much so that they supported us in more ways than we could have hoped: not only did they support us in creating and hosting a customized website free-of-charge leveraging their site builder, they also provided a launcher and a state-of-the-art payment system for our founders packs. They even went the extra mile by offering their expertise, giving us advice on publishing and monetizing our game. Even now, we’re in contact with them pretty much every day, and we’ve got a very strong relationship going on.
These partners’ services proved invaluable as well as cost-effective, although we couldn’t customize them as much as we could have with tailor-made tools. These developer-friendly solutions have met our requirements, and I have no doubt that this tech strategy will only get more attention as time goes by. In fact I expect that most games these days will be made out of a mix of in-house and third-party services.
Our results (and new uses):
After four months of hard work, our “game-as-an-MVP” approach started to pay off: we started to test out our prototype with a few players at first, which quickly got the ball rolling. Now our game is getting more and more attention… and yet that’s not the only positive outcome of the choice we made with Benjamin. It wasn’t simply a new strategy, but a new way to work, to interact with our community and to develop future projects. Much like start-ups, we got our prototype ready for a small launch, and followed our KPIs to prove the appeal of our upcoming game. This process made it possible for us to take bigger risks, backed by constant validation from the audience.
In terms of working schedules and objectives, Darewise has changed drastically compared to the standard method in the PC gaming industry. We had moved on from the traditional milestone-based development, to continuous development: instead of reaching for medium-term objectives every three to six months, our development process was punctuated by minor releases every two weeks, and major ones every four to six weeks. Working with our product team, we adopted a new data-informed approach. This new product-oriented strategy was key to understanding our audience, informing our design and even our company strategy.
Our players are the cornerstone of our entire process, since they will validate (or invalidate) each idea we try out. One of the fundamental goals Benjamin and I had in creating our MMO was to stay close to our audience, to connect with them directly so we could improve our game, and offer them the best experience possible as quickly and easily as possible. Our creative choices are always motivated by our vision for the game, but whenever we implement a new design choice, we always take real user-feedback into account to fine tune it and make it as user-friendly as we can.
And what better way to get direct feedback from our player-base than by creating a community? So that’s what we set out to do: and we did it without investing millions in marketing. To onboard our new players, we took inspiration from another trailblazer: the Superhuman emailing app. First, we would collect our users’ interests, by getting them to sign up and fill up a survey. Then, we would activate a specific set of users, based on their profile, and personally onboard them on our platform during a call. Without a dedicated community manager, we let every member of our team volunteer to welcome new users and show them the ropes of the game. Every developer, programmer or designer, and even Benjamin, got to interact directly with a newcomer! Beyond that, we also shared continuously with our players, using a dedicated Discord server. More than a strategy, this proximity with our customers is a key element of our identity: not just talking to our customers, but listening to them, learning about them and knowing how to provide them with the best experience possible. This might be our greatest achievement in our journey toward self-publishing: by keeping Darewise small-scale, we kept it at human scale.
Conclusion
Within four months, we at Darewise achieved more than we could ever hope: with only our vision, a small team and little to no resources, we set out to self-publish a game prototype for our genre-redefining MMO… and we did it! Using an MVP approach, and relying on developer-friendly partners for high-quality game engines, backend products and more, we could take calculated risks and give free rein to our creativity to achieve our vision.
I’m convinced this could be the way forward for many small game developers, especially the ones interested in remaining as independent as possible: if you have an ambitious vision, an agile team of talented co-workers, solid partners and confidence in your project, self-publishing just might be the right plan for you. Gaming has never been this open, and it’s only the beginning!
Samuel Kahn is a software engineer, co-founder and CTO of Darewise. You can follow him on @kahncode and check out his blog on https://kahncode.com
