Serverside code runs in a distributed fashion on Player.IO game servers, thare are either shared or dedicated.
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.
On dedicated game servers, developers can set the CPU runtime and players per room limits to whatever they want. And since there are no other games running on the same hardware, there won't ever be interference caused by other games.
Dedicated game servers are available on the Pro and Enterprise plans. Currently you need to contact Player.IO to order one or more dedicated 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.
Only 45 players are allowed in each room on a shared game server. You need to distribute your players across different rooms, and Player.IO will distribute your rooms across different 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:
The Player.IO 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.
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 Player.IO 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.
Even though game servers may be located in different physical locations across the globe that are in different timezones, 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.