Taking the right steps to prepare for a successful multiplayer launch

Gameye gives developers a way to run and scale their multiplayer sessions across the world. It's straightforward in theory, but complicated in practice. Every time your players jump into a match together, that game needs to be hosted somewhere.

As CEO, I often tackle similar questions from developers: Do I need servers? How does multiplayer work? What should I look for? So I want to share some practical advice to help you plan out your launch and make some important decisions.

Does my game even need a server?

There are two architectures you can choose when developing your multiplayer game: peer-to-peer or client-server. Peer-to-peer is when you designate one of the players as the host and the other players connect to their machine. Client-server is when the player connects to an external machine (the server) which controls the game. So when should you use peer-to-peer and when should you use client-server?

• Use client-server when you need to be fair

It's harder to cheat or interfere with the code when the gameplay is being controlled by a separate machine. Imagine an FPS. If it were hosted on one of the player's machines, that player gets an unfair advantage (as they'll have next to no lag). But if it's being run on their machine, that person can find ways to hack it. Client-server makes that much harder.

It's also important for difficult physics, such as bullet trajectories. You want these to be as fair and consistent as possible. And that's much easier if the session is on a client-server.

• Use client-server when you need to be reliable

If you own and manage the servers, they're going to be much more reliable than the possible budget gaming setup many players own. It'll be more consistent, as you know what hardware the server will have. But you also don't have to deal with that player's machine turning off.

Most people forget that in a peer-to-peer game, if the host leaves, you need to migrate the session over to one of the other players. And that's not always possible or can cause a huge delay.

Now, that's actually fine in some games. If you're running a turn-based strategy with only four players who are typically real-life friends, it's probably okay to let the players host. But eight random players in a real-time strategy? You need a reliable server.

• Use client-server if you have a lot of players at once

There are a few reasons you might have a surge of players. It could be that you have a competitive game, for example. Or perhaps you're developing a free-to-play (F2P) or play-to-earn (P2E) game. With these kinds of games, client-server will be much more preferable.

That's because you can only really have four to six players together in peer-to-peer sessions. Any more and you're going to have too much lag. In fact, we worked recently with Chivalry 2, who have 64 players in a match at once. A personal broadband connection could never cope with that much data.

That's not even considering whether that host player is actually anywhere near the other players. Even if they have an excellent internet connection, they could be in a completely different country, which would drastically affect the latency.

But if you've only got two people playing together? It might actually be faster to go from A to B, without travelling through C first.

• Use peer-to-peer when these things matter less

Peer-to-peer is ideal for smaller, cooperative games. If you've got four friends playing an RPG together, it probably doesn't matter too much if one player has an advantage or if they all decide to cheat a little. Hell, if they want to turn on god-mode, who's it hurting?

Before you start developing any multiplayer mode, you should be thinking about how you're going to host them

Likewise, if you've only got two people playing together, it might actually be faster to connect them directly than rerouting through a client-server.

• But know your limitations

A client-server adds complexity. If you choose to go down that route, remember that you'll now have two different code bases to manage. The game itself and the multiplayer session. These are very different. And, for a smaller indie developer, might not be worth it.

Before you start developing any multiplayer mode, you should be thinking about how you're going to host them. If you don't have the resources to use client-server, then don't add a huge competitive element to your game. Keep it simple and think about what you can do with peer-to-peer. Saying that, nowadays it's easier than ever to set up a client-server. Companies like Photon can help you get started quickly.

How do you actually test a client-server approach?

Once you've decided that you want to use a client-server, the next question I usually hear is around how you make sure it's working. It's typically a lot more complex than testing a peer-to-peer system.

• Find people from your community

Your community is your best source of people to get involved in your testing.

1. Set up a closed group. This might be on Discord, a forum or a private section of your site. However you do it, make sure you hire a community manager to keep them up to date and collect the bug reports.
2. Pick a small group. You want to be able to manage the group and make sure you can keep up with the reports they'll be sending. So pick a small group of around 200 to 500 people to use as your testing team.
3. Pick people across the world. Having all your testers in one country can cause problems in itself. You want a variety of people from the areas you're targeting if you want to test fairly.
4. Get a fair sample of skill. This is harder, but no less important. When you're testing things like your matchmaking, you'll need to make sure that you have a fair representation of skill. Remember: People are on a bell-curve. More people are average, with few on the extremes. Your distribution should reflect that.
5. Make sure they sign an NDA. An NDA is a non-disclosure agreement. If you want to avoid leaks, it's important to get all those testers to sign one.
6. Give them an incentive. You don't necessarily need to pay a salary. But you should definitely give your players a reason to help. Cosmetic skins, free copies of the final game, or even a character named after them. All these are great ways to get people on board.

• Think about contingencies

What are you testing during your alpha (or even your beta)? When it comes to your servers, there are a few things to check.

• 1. How do I balance costs? If you get a surge of players, you'll likely have to pay more than you budgeted. You need to think about how you balance the price with capacity. Have an open conversation with your provider and make sure you agree prices upfront.

• 2. Can I handle a surge of players? On the other side of the coin, can your servers actually cope with a sudden surge? Does your provider have the capacity to take on that number of players? Most of the time, when matchmakers or player logins crash, it's because of one single point of failure. So make sure to test your setup with a larger group of players during your beta, and consider using bots as well.

• 3. How can I handle players from different locations? You never know where your game might become popular. What if it suddenly takes off in Japan? Can your servers cope with that? Are they close enough to give a good experience to your players?

For all of these, you'll need to have an open and honest conversation with your provider. Ask them what will happen and decide these things upfront, so you don't have any surprises. And plan for success as well as failure.

We're used to thinking of testing as a way to try and break our game, but we often forget to think about what happens if the game does well. When we worked with Chivalry 2, they got twice as many players as they expected at launch. It's situations like these that you have to prepare for.

And remember, it's all about capacity, location and latency. Can I handle a surge? Can I handle players from all over the world? What about lag?