Problems with your multiplayer service on launch day can lead to bad reviews haunting your game for years to come. Here’s how to avoid the trap.
Our COO, Craig Fletcher, spoke at Reboot this year about how to navigate the tricky waters when hosting a multiplayer game. We won’t delve into everything he talked about, but here’s a summary of his advice for studios.
The day you finally go live is simultaneously the day you know the least about what your infrastructure can handle and the day you’ll probably get the most traffic. If there’s a problem, it will rear its head.
A crash on day one will inevitably lead to your players leaving bad reviews. And those bad reviews can haunt your game for years, sticking around despite you having fixed the problem. Even a great game can have its average dragged down.
You can’t avoid every problem. But you can make sure you’re prepared and get things fixed before the review bombing starts.
DDoS attacks happen. Humans make mistakes. Hardware can fail. Nobody, not even the big players, is immune from that. So make sure you have a contingency plan. The best way is to use multiple providers and give yourself some redundancy.
You should plan for every scenario. If you make your decisions ahead of time, you won’t be scrambling to find a solution when they happen. Ask yourself: What do we do if our matchmaker stops working? How will we scale if we get too many players? What happens if our API calls stop coming through?
Write down your solutions and agree on them now, while you’re cool-headed and calm. And not in the middle of a crisis.
There’s a tendency for studios to just use the cloud for everything. But the cloud isn’t infinite. We’ve seen times when even the big providers have said they wouldn’t be able to handle the load, particularly in areas like South America or the Middle East.
Cloud is also usually about three times more expensive than using bare-metal. So it’s best to only use the cloud as a last resort. Think of it like using a hotel. Sure, it’s useful if you’re taking a short trip and just need to stay the night. But you wouldn’t stay in a hotel all year. Cloud is there to tide you over if you’re in a pinch. It’s not a permanent solution.
The best way to think about your infrastructure is in tiers. As your top tier fills up and you use up your capacity, you can spill over into the next tier.
You’ll notice that each tier is really about how long it’ll take to get them online. The faster you can get more infrastructure up and running, the less likely your players will get frustrated.
When you plan out your infrastructure like this, it also makes it much easier to communicate with your players. You can give them a clear idea of how long they’ll need to wait before they can start playing again.
Build yourself a team that’s ready to fix problems and form a control centre for launch day. This team should be a combination of senior engineers, capable of actually fixing any issues, as well as decision-makers. You should also have your community manager in the room so you can communicate with your players immediately.
Before you launch, make sure you’ve also spoken with your providers beforehand so you have any relevant deals in place. You don’t want to be negotiating in a time of crisis.
Ultimately, a war room helps you prepare for the unexpected so you can sort things out without any delays. Again, you want to make sure you can fix problems before your players become frustrated.
A large reason that players will leave negative reviews is because they’re angry or frustrated. The most frustrating thing for a player is silence. It’s not knowing what’s going on.
If you’re communicating and explaining the issues, your players will accept what you say. You can’t ‘over-explain.’ So be honest and open with your players. And if you’ve got contingency plans, you’ll be able to give solid timeframes to your players.
Source: Baldur’s Gate 3 Community updates on Steam.
You can never replicate the real world. But you can stress test your systems to make sure they can handle the load. Go through every system and try to break them.
It’s important to test out everything. Look at what happens when you need to quickly switch on servers in a new region. What happens to your matchmaker? Can you make all the necessary API calls? What happens if hundreds of thousands of players try to purchase an item at the same time?
If you stress-test everything before you launch, you’ll have far fewer surprises on the day.
An orchestrator can help you manage multiple server providers and automatically scale to meet demand. It can make the process far easier. So if you want help setting up your deployment waterfall and need an orchestrator to manage the process, get in touch. We’ll gladly help you figure out your infrastructure.
