Vampire Survivors had already sold ten million units before its first online multiplayer session ran. It had a BAFTA for Best Game and had spawned an entire new genre of games. We knew that the online co-op launch would be a success. The problem was actually making sure the game didn’t get overwhelmed by its own success.
When multiplayer launches fail in a spectacular manner, they tend to do it in specific, predictable ways. The classic one is the endless waiting in a login queue, that sometimes also crashes for no reason, kicking you all the way back to the end of the queue. It’s not a game problem, it’s what happens when the infrastructure isn’t prepared for what real traffic looks like, when it suddenly arrives, all at once. To pull off a flawless launch with real player numbers behind it, you must prepare and prime the infrastructure beforehand. Even then, a team of engineers should be standing by for any curveballs.
This is the story of how coherence did the preparation work for the launch.
(The technical implementation - distributed simulation, cross-platform sync, how we handled hundreds of enemies and thousands of projectiles - is covered in the original Vampire Survivors case study. Start there if you want the networking architecture. This piece is about everything that comes after.)
This is how the game looks at the start...
Every Vampire Survivors multiplayer session starts in a coherence lobby. That part is always on our cloud. The lobby layer handles session coordination, room codes, and player presence across all platforms. When a player invites a friend, shares a code, and starts the game, what happens next depends on what platform they are playing on.
On PC and Steam, the session runs peer-to-peer (which we call Client Hosting). The coherence Cloud handles the lobby and nothing else. The gameplay side is handled on the hosting PC. On consoles, sessions run on coherence Cloud, where our servers handle the real-time sync. The lobby layer is lightweight, with minimal bandwidth and minimal cost, and the gameplay layer is where the real load lives.
Launching a live service game is always a guess, but to get that guess to be more accurate, you need to run load-testing scenarios.
Here’s how our load testing works: first, we build a headless emulation of the game, so there’s no UI, no client, just a script that replicates exactly how the game behaves on our servers, derived from the networking schema the developer configures in our SDK. That schema tells us what game objects get synced, at what frequency, and what the bandwidth profile looks like under real conditions.
Vampire Survivors' profile is genuinely unusual. We had considerable experience launching various online games by that point, but the in-game entity counts here were in a completely different category from any of the games we’d worked on before.
For context, Vampire Survivors successively ramps up enemy waves in a bid to kill the player, until it hits the 500 units on-screen cap. Add projectiles, spells, and multiple players into the mix, and you have total mayhem that seems utterly un-syncable on the surface, because the bandwidth requirements would be insane. We still found a way to make it work by using coherence’s book of tricks, and you can read about that fascinating journey here. As a result, we had a working online multiplayer client with its own coherence schema, a sort of an online multiplayer footprint of the game client.
Once we had that footprint, we could scale it: thousands of simultaneous headless instances ramping up slowly, ramping up fast, starting from a pre-scaled state to simulate a known launch peak. We modelled what traffic looks like when Asia-Pacific comes online at prime time while the rest of the world is asleep, and what a cold start looks like when you have no idea how many players are coming.
The goal is to have hard numbers for every scenario, not optimistic guessing. For Vampire Survivors, we pre-scaled our backend by 200% ahead of launch, deliberately over-provisioned. If traffic came in hot, we would be ready and, once the actual connection pattern established itself, we could adjust automatically to keep the player experience smooth but still manage costs.
The 1.14 Ante Chamber (AC) update, introducing online co-op, gave the game the most significant player bump within a year. HB on the graph denotes VS being offered in Humble Bundle.
Basically, we watched it!
Real-time monitoring, global traffic, regional scaling as each time zone came online. Asia-Pacific spiked, plateaued, then dropped as Europe woke up. Our backend scaled up and back down automatically, tracking the rhythm of the player base across time zones.
We had exactly zero issues. Not just "no major issues." Literally zero, in a very satisfying way. We had pre-scaled, pre-tested, and pre-positioned for the scenarios that we could model, and none of the un-modelable scenarios showed up either. When the launch window closed, the game was just running and the players were having fun.
...and this is the end-game mayhem.
Vampire Survivors' online co-op has been running smoothly ever since launch. Traffic cycles automatically, scales to match global demand, and requires no active management. Player counts for multiplayer games naturally decrease over time and the infrastructure reflects that, scaling down as efficiently as it scaled up at launch.
Team coherence worked with Poncle to set up the multiplayer in a way that really minimizes the ongoing maintenance. We added it once, preparing it for its full lifecycle, and it has kept running of its own accord, no interventions required. The other thing that happened along the way is harder to put in a graph: the coherence SDK is now a natural part of the Poncle workflow. Adding multiplayer is no longer a risk they manage, or a tack-on functionality at the end of the dev cycle, but a capability they can confidently build in from day one.
One of the main goals coherence has when working on a project is to make sure that the partner studio learns the technology so they can be more independent on future games. We don’t want people to feel locked in, we really want to make it easier for more teams to make multiplayer games on coherence as we always intended – on their own.
Poncle now has coherence in their toolbox and we’re very excited to see what they come up with next.
coherence is a multiplayer networking engine and co-development studio built by a team of veterans from DICE, CD Projekt Red, Crytek, Ubisoft, Blizzard, and Playdead. Studios use coherence to add or build online multiplayer in Unity without rewriting their games. For more, visit coherence.io.
Written By
