Player.IO

We’ve just released version 2.1 with updated multiplayer features.

Our Multiplayer service was the first service we launched, and since it hasn’t received many updates since the original launch, it was about time we gave it an overhaul and added some of the often requested features.

“So, whats new?” you ask. Well I’m glad you asked:

Stability and Performance
We’ve focused a great deal on stability and performance in this release. We have quadrupled the amount of multiplayer specific unit tests, fixed quite a few edge case bugs, and we have spent quite a bit of time tuning and optimizing the core socket layer for even better performance!

Full rights in development server
One of the biggest frustrations we’ve heard from customers has been the fact that the old development server did not run with full rights against Player.IO like the production servers. Instead, it inherited it’s rights from the first client to start a room.

Developers could easily workaround this issue by using a connection with full rights in their clients, but it caused a lot of confusion and wasn’t really an optimal solution.

This was done because we didn’t have a secure way to ensure that only your development server had full rights against your games.

In version 2.1, we’ve fixed this issue with the simplest possible solution: When you start the development server, you’re asked to login to your Player.IO account which will grant the development server full rights against all your games.

You can even make it save the credentials so you don’t have to login every time you press F5 (run server). And of course there’s also a logout button so you can clear those saved credentials at a later time.

Ability to have multiple room types in one dll
Our second most requested feature has been the ability to develop a game with two or more room types (previously we called them “server types”), on one machine using one development server. This was next to impossible earlier, which lead to local-and-live development where developers would run one room type in a local development server and the rest on the live servers.

Needless to say, this was more than a bit bothersome when switching between code in different room types and made it impossible to setup breakpoints and other debugging information across all room types at once.

In version 2.1 we’ve fixed this issue by allowing you to have multiple room types in each dll. You have to mark each main game code class (The one that inherits from Game) with the RoomType attribute like this:

And just like that, you can have multiple room types in one dll.

Ability to upload debug symbols (.pdb)
Another often requested feature has been the ability to get file and line number information in the error log for exceptions throw in the production servers.

With 2.1 we’ve added the ability to upload debug symbols (The .pdb files generated by visual studio) along with game code dlls. These files are loaded by the production servers and ensure that accurate file and line number information is submitted to the error log for every exception in your game.

Since running code with debug information uses more resources we’ve decided to make this feature only accessible for costumers on the Plus plan or better.

Updated Multiplayer Admin Panel
The multiplayer section of the admin panel has been given a major overhaul. It now has a Statistics tab where you can see how your game is performing over time, a tab where you can list running rooms and their room data, and a tab where you can manage your clusters. Uploading game code now has its own tab, and it should be easier to upload and update that code now.

Cluster Management

Multiplayer rooms run on groups of game servers we call clusters. Previously you didn’t have any choice regarding which cluster or servers your game would run on, but with this release we’ve laid the ground work for allowing you to manage and control just that.

In the multiplayer admin panel you’ll now find a new “Game Servers” tab where you can select which clusters are used to run your live game rooms, and prioritize them.

To begin with most users will only have access to these two clusters:

• Player.IO Main Cluster: The main server cluster running most games.
• Your own development cluster: A special cluster created for you that contains all your currently active development servers.

In the long run we want to expose multiple higher-capacity clusters around the world so you can choose to run your game close to the geographical location of your players, so they will get an get an optimal experience.

And finally we’re also considering letting costumers run their own clusters of game servers on their own servers. This would give you the ability to control server settings such as room capacity, max run time, disable the codescan/class-whitelist and more. We’re not quite sure how to approach it, so we’d love to hear from you if you are interested in such a feature and would like to be one of the first users.

Run live rooms on your development server
You can even use the cluster management features to run live room on a development server on your local machine, giving you the ability to set breakpoints and view live debugging data directly inside your live rooms!

Simply drag your development server cluster to the top of the active clusters list, and if there are any development servers with publicly accessible ports (8184) in your cluster, then it will be used to create the next room.

Development servers are limited to 10 rooms, which should be enough to get you some live traffic to work with, but the majority of players will still be on the main cluster.

Those are the major new features. Give it a go and don’t forget to let us know what you think!
- Team Player.IO