Having a single point of failure can be catastrophic for your game. What happens if it goes down? Find out how to avoid locking into a vendor.
In gaming, we build on the shoulders of giants. Almost every studio these days relies on a third-party service at some point or other. It’s rare for a developer to build each individual part themselves. There’s the engine. The matchmaker. The server orchestration. The social meta-features. The physics and collision detection.
In most cases, this is fine. If every game had to start from scratch, we’d have far fewer games on the market. Hell, the majority of games rely on Unity or Unreal these days.
But in some cases, this can lead to disaster. What if you rely solely on one vendor and it goes down? This is called a single point of failure. And it’s a particularly important consideration when building a multiplayer game.
As gaming gets evermore technical, it’s almost impossible to build everything yourself. Yes, it’s possible. But it’s a long and arduous road to craft your entire game from scratch. At some point, you’re going to want to rely on a third-party service.
Whether you use a third-party vendor really depends on how mission-critical that service is. The best way to figure this out is to ask yourself four questions.
Some services are going to be essential to make your game run. Take your matchmaker or server orchestrator. These are crucial elements of your multiplayer experience. If they go down, it’s very likely that everything else grinds to a halt. And if everything grinds to a halt, you lose money. That’s a critical service.
But your chat and social services? Well, those are less important. What’s the worse that happens if your players can’t see the leaderboard for a couple of hours or speak with their guild? It might be annoying – and you’ll probably get complaints – but the game is still playable.
How important these services are depends on your game, of course. If you’re making a MMORPG, you might consider those social elements a crucial part of the experience. But maybe your players would be forgiving if the auction house went down.
This is particularly important for free-to-play games. Your monetization strategy might solely depend on your mediation platform working correctly, for example. Or what if your battle pass breaks? Sure, the game can run. But you can’t make any money.
Once you’ve decided what’s mission critical and what’s not, you need to think about what’ll happen when it breaks. Is it a simple phone call to the supplier? If you can’t easily get in touch with your supplier, you might have thousands of angry players, blaming you for a mistake a third-party application made.
Make sure you know how to get hold of the support team. We’d recommend having a file with all the direct contacts. And to test them. Call them up and time how long it takes for them to respond – even if that’s to tell you that all is well.
With that information, you can decide how the downtime is going to affect your business. Can you even get hold of them? Some companies make you jump through multiple hoops to get through to a real person. Save yourself the time and find out those details. Otherwise, you’ll be wasting time searching for how to contact someone.
Software gets out of date. Support stops. Companies get acquired and their technology disappears into the wind. What happens to your game if that happens?
Do you need to completely rebuild your game? Can you continue to use a legacy version of the service? Check the contract or the terms and conditions to see what happens when they release new versions or discontinue old ones. You don’t want a nasty surprise.
As you iterate and improve your game, you might realise that you need to tweak and change certain elements. For example, you might want to switch out your matchmaker for an alternative or add a new server provider to cover a new region.
This can be incredibly difficult if you haven’t considered it from the beginning. Make sure you develop your game’s architecture with this in mind. Make sure that you only need to make minor changes to your code if you want to change which API you’re calling, for example.
So design your game to make it easy to plug in different providers. Even parts that you might initially build yourself, consider how you’d replace them as you’re coding it.
Our orchestrator uses multiple server providers. If one goes down, we automatically switch to an alternative. And, if you want to customize it further and have more control, you can licence our source code to bring everything in-house. You’ll still get updates, if you want them. But if ever you rely on something we discontinue, you can just use the old version.
If you’d like to learn more about how the Gameye orchestrator works, check out our documentation.
