The fastest way to build online games without breaking a sweat.

Multiplayer Server Security and Permissions

Serverside code runs in a distributed fashion on the Game Server Cluster.

Players in a single room will always be connected to the same game server, but different rooms of the same game might run on different servers in different physical locations. In addition, the rooms of several different games may run on the same game server.

Shared game servers

Shared game servers runs serverside code from many different game developers at the same time.

To ensure that all this works fine on shared game servers, without any one game disturbing the other games, serverside code is sandboxed and restricted in a number of ways:

45 players per room limits

Only 45 players are allowed in each room on a shared game server. You need to distribute your players across different rooms, and the system will distribute your rooms across different servers.

Code restrictions on shared game servers

Serverside code on shared game serves does not have full access to the entire .NET library. It is scanned to ensure that it will behave nicely when running on live game servers, according to these rules:

  • A whitelist of allowed keywords and classes
  • It is not possible to use static variables
  • It is not possible to use unmanaged code
  • It is not possible to use any framework classes to connect to outside systems or do other computationally intensive functions

The Development Server will scan your code each time you start a development room and warn you if you are using restricted keywords or classes.

We are constantly evaluating the needs of game developers, and if you have any suggestions for code or classes that you think should be allowed simply let us know and we'll investigate if it can be allowed on the whitelist.

Runtime/CPU Limits

Shared game servers enforce a strict limit on the runtime of game code, in order to ensure that no single game will use up all the CPU resources of a shared game server and that all connected players receive a good gameplay experience.

In practice this is implemented by limiting the amount of time your code is given to execute. The limit is set to 100 milliseconds for every event that occurs.

For instance, when the UserJoined() method is called, you have to ensure that your code will not take longer than 100 millisconds to complete, or the executing thread will be aborted forcefully.


Since the serverside code is considered trusted, it always has full access rights to all Backend Services. For instance, it can perform all BigDB operations on all of your BigDB tables, and it has full access to each player's vault in PayVault.

UTC Timezone

Even though game servers may be located in different physical locations across the globe that are in different time zones, the local time on each server is always UTC, which means it is always the same on all servers. This in turn means that there is no difference between using DateTime.UtcNow and DateTime.Now in your serverside code.

We recommend that you use server time whenever you are transmitting dates and times between players, or for example when you are storing dates and times in BigDB.