Multiplayer Essentials

Here are the basic concepts you need to know in order to work with the Multiplayer Service:

Player.IO operates clusters of Game Servers. Your players connect to these and play your game through them.
To take your game live, you need to upload your serverside code. Player.IO will then distribute it to all game servers.
Game servers are shared or dedicated. Your game will run on shared servers unless you buy dedicated servers.
You can upgrade to get dedicated servers. If you upgrade to the Enterprise plan you can get your own exclusive cluster.

Clients can create, list, and join rooms. Any extra properties on a room can be seen when listing them.
Each room runs your custom serverside code. The type of the room determines which part of your code it should run.
Each room has a unique id. The room id is used for joining the room.
Two or more players can communicate with each other by joining the same room. You can send messages to individual players or broadcast to all players connected to a room.
It is not possible to send messages between rooms. Two different rooms belonging to the same game may reside on game servers in separate physical locations across the globe.

A multiplayer game needs both clientside code and serverside code.
Serverside code can be written in any .Net language such as C# or VB.Net
Serverside code is organized into different room types. When a client wants to create a room, it has to specify the type.
A game can consist of several room types. For example, you might need one type for a lobby system, and one for the actual game.
Your serverside code is mainly event-driven. You need to write code to respond to events such as players joining or leaving, or messages being received.
You can use timers to set up code to run delayed or in intervals. Use this when you need to run code without it being a reponse to an event.
You have full access the other Player.IO services. BigDB, PayVault, Errorlog, etc are all accessible through the Player.IO Serverside API.
All servers are using UTC as their local time.

Clients can use any of the Player.IO Client Libraries. These contain methods for managing and connecting to rooms.
A client can be connected to several rooms at once.
Players in the same room don't need to be using the same kind of client. You can mix and match and have for example players on a Flash client play together with players that are using a Unity3D client on an iPad in the same game.
Clients can't communicate with each other directly. Clients can only send and receive messages through rooms they're connected to.

Serverside code is secure and can be trusted.Clientside code is inherently insecure since it runs on players machines, but since serverside code runs on trusted serves, you don't have to worry about tampering with serverside code.
Use validation on the serverside to make your game tamper-proof. Whenever you get a message from a client, make sure that the action the client wants to take is valid, and it will be impossible to cheat in your game.
Your serverside code has full accessrights to all Player.IO APIs. For instance, you can always read and write to all BigDB tables from your serverside code.
To ensure the shared game servers run smoothly, there are some restrictions on code running on shared game servers:
- Serverside code cannot run for longer than 100ms. This ensure that no game consumes all CPU resources of a server.
- The code is scanned to ensure it behaves nicely. There is a whitelist of allowed keywords and classes.
- A single room can hold up to 45 players simultaneously.

The Development Package contains everything you need. There is the development server, client libraries, and example projects so you can get started quickly.
Games are developed locally. You don't need to upload your code to Player.IO every time you want to test some changes.
Everything you write to the console is shown in the output area.
You can add buttons to the development server interface that executes your custom debug code.
You can write your own image visualization of game state. Sometimes it's easier to visualize what's going on in a game by showing it as an image, for example player and NPC positions relative to each other.
You can add your development server to the live cluster. This allows you to inspect and debug live games on your local machine.