Game server player density: tips and tricks to keep costs down

This blog is part of our ongoing Essential Guide to Game Servers series.

As one of the most significant factors in determining the cost of hosting your game, game server density is something you have to get right.

Unfortunately, it is often overlooked during game development (don’t worry, we won’t judge).

To tackle this we spoke with Multiplay’s Senior Solutions Engineer, Curt Anderson, who regularly tackles the challenge of getting game server player density right for games of all sizes.

This blog covers the four main categories of game servers, with key considerations for each, before diving into optimization best practice.

What is server density?

Game server density is the amount of game instances you can run per machine. Player density is the amount of players you can service per machine.

In this article I’m going to run through the common pitfalls developers make when exploring game server density. This will help you to ensure your game runs smoothly without costing two buckets of gold bullion per player.

The bound factor

Before we jump into the nitty-gritty, there is one thing that you’ll need to consider first when working on your game server density; the bound factor.

The bound factor (or binding factor) will limit the number of game servers on the machine or network.

For example:

  • If a machine consists of 8 logical cores and 32Gb of memory
  • The game server uses 50% of a logical core and 6GB of memory

On the machine you can fit:

  • 16 game servers by CPU/logical cores
  • 5 (5.3 rounded down) game server by memory

This basic example shows that this game server is bound by memory. There are more factors at play here, such as average usages, max usages of the game servers, CPU/thread limiting and CPU affinity, to name but a few.

The four categories of game servers

All games are different (well, they should be!). Because of this, it’s difficult to consider specifics but there is some hope as most games can be grouped into four categories:

  • Relay game server
  • Authoritative game server
  • Authoritative and physics-offload game server
  • Authoritative persistent game server

Let’s take a look at them in detail.

Relay game server

Relays are most common for mobile titles. They are simple game servers which are not authoritative, but fix problems around NAT connectivity between phones. They are normally extremely lightweight as they are only packet-pushing, with the authoritative part being handled by a ‘game leader’ or ‘session leader’ on the client side.

The main issue with a relay game server is with bandwidth, as they are normally extremely dense, which makes the relay game server bound by bandwidth. Game servers in this case are limited by bandwidth first.

Things to consider

Primary

  • Game server update rate (frame rate)
  • Bandwidth input/output (I/O) per player

Secondary

  • CPU
  • Memory
  • Disk I/O
  • Game server running idle

Authoritative game server

An authoritative game server is your standard session game. Examples include PUBG or Counter-Strike. The game state is reset after each session and the persistence is not saved to a specific game server. It even might do some light physics processing.

The main concern about authoritative game servers is the update rate or the game server’s tickrate, and the corresponding CPU requirements. For fast-paced games, the higher the frame rate, the better the player experience (at least that’s the perception, which is a topic for another day!).

Things to consider

Primary

  • Game server update rate (frame rate) and corresponding CPU usage
  • Memory
  • Game server running idle
  • Garbage collection (no memory leaks please!)

Secondary

  • Bandwidth I/O per player
  • Memory
  • Disk I/O

Note that the idle here is very important, but only when you are looking at averages. If the game server continues to run the world at the maximum frame rate, even when no players are connected, you are likely to reduce your overall game server density.

Authoritative and physics-offload game server

These game servers are similar to the standard authoritative game servers, except for an even greater emphasis on CPU. With this option, you’ll almost certainly be CPU-bound or even GPU-bound if you decide to go down this route. Be warned, if you are making a game which has physics processing game server-side….there be dragons.

Things to consider

Primary

  • Game server update rate (frame rate) and corresponding CPU usage
  • Physics processing and corresponding CPU usage

Secondary

  • Memory
  • Game server running idle
  • Garbage collection (no memory leaks please!)
  • Bandwidth I/O per player
  • Disk I/O

Authoritative persistent game server

Authoritative persistent game servers are in a league of their own. These game server are normally heavily customized game engines or even custom engines, simply because of the customization that takes place.

Considering the usage of these game servers is extremely difficult as persistent worlds are constantly updating. You might find that the memory usage of the game server is the binding factor, simply because of the amount of entities the server has to track and generate.

You might also find that the game server has greater CPU swings when players are closer together and interacting with these entities. If you are storing the persistent data locally, you might be running into disk I/O problems, which might compound all other factors.

Things to consider

Primary

  • Game server update rate (frame rate) and corresponding CPU usage
  • Memory
  • Disk I/O

Secondary

  • Game server running idle
  • Garbage collection (no memory leaks please!)
  • Bandwidth I/O per player

Optimization targets

Making sure you optimize your game enough is key – player and game server density can make or break the commercial viability of a title.

What is viable though? This is a difficult question to answer as there are numerous variables, such as:

  • How much should I sell my game for?
  • What is my marketing budget?
  • What markets and regions are being targeted?
  • What is the cost to host?

This is something the Multiplay team work closely with our clients on, to ensure servers are optimized in the right way.

The best way of looking at it is to consider the player density, rather than the game server density. To give you an idea of a target to aim for, let’s look at an example.

Use case

From our experience, for an E3, 8-logical core server at 3.4Ghz you should be looking at around 300 players, with the average coming in at 254 players. This is based on the games Multiplay host as well as the ones we can get stats for online.

Breaking this down, that’s:

  • 0.091Ghz per player
  • 0.11Gb Memory per player
  • 120kbps per player

Don’t forget design

When designing your game, you want to make sure you cover off three bases: creativity, infrastructure and commercial viability. The optimization required for a viable game server density comes under the latter two.

The creativity, however, is also key. Understanding the technical limitations or workarounds of features at an early stage is essential.

A character creator is a great example of this. Ever wonder why you can’t control individual strands of hair? Or add that birthmark you really want? It’s because any changes you make need to be represented to other players; it needs to be stored per character and it needs to dynamic to the environment.

Some games have tackled these problems but you can never have unlimited customization, even in single player games, simply because of the design overhead.

Also remember that in-game designs can also affect game server performance. If the player presses a button and a 4,000 piece house is instantly constructed it will generate a game server load, so what if 10 people do that at the same time?

To reduce the game server load, an in-game system could be added. For example; making it so building the virtual house over 30 seconds does not change the gameplay drastically, which will enable a smoother game server performance.

Summary

Game design and game features can affect performance. If your game uses one of the models above then game server performance and load will need to be considered to ensure any title is commercially viable to host.

An amazing game can be scuppered by offloading work to the game server, degrading performance and increasing cost to the user.

Players expect dedicated game servers and the challenge is to deliver the performance benefits without breaking the bank or eating into your profits.

If you’re creating a multiplayer game that has game server support, the best advice I can give is: create your game servers early and benchmark them together, adding features and optimization along the way.

Looking for ways to optimize your game servers but don’t know where to start? Get in touch to discuss your game with one of the team.

2019-02-14T12:01:34+00:00February 13th, 2019|Essential Guide to Game Servers|