Imagine you are playing Call of Duty (or your favorite shooter) and your game received the message for every gun shot and grenade in the game for every player on every server. In a large online game with hundreds of thousands of concurrent users your handling these requests would probably not even be possible to be processed on displayed. And if it were able to render all these events you wouldn't know what the heck was going on because you would be hearing thousands of guns being shot and grenades exploding every second.
Of course when you actually play the game you don't you hear the gunshots of all players that are in other matches happening. You only hear gunshots of players in the same match as you, or more generally in the same room as you. This room just happens to be a game room, but its the same when you're waiting in the lobby and you can talk to other players. It's just a different type of room. Sure call of duty takes the game room a step further by making it so that you only hear fires of shots if they are from a player shooting at you or standing near you. But now we are getting into deeper things like location based sound and 3D worlds. For now let's just take the familiar example of a flash game.
Making a multiplayer game is can be thought of as putting players in a room and giving them something to do.
Users in a Room Don'tTalk to Each Other
This is an important concept to understand because it will help you think about a game more in terms of how it is coded. With the player IO framework you Arnel empowered with this mystical new object called a message what is when you here is what it looks like to send a basic message from the actionscript client (the _connection variable is a value of type Connection that is returned from Playerio when the user is successfully authenticated).
The first argument is the message type. Then after that you have the option to send variable values in the message. You can send as many as you like, and then these variables are passed along to the other side. But what is the other side? Where does the message go after you send it? Well, it goes to the server. Now in different industries and even different areas of game programming different people have different definitions the word server. I'm not saying any of them are wrong, but for the moment let's let the server be defined as just the .dll file of c# code that handles the room. Let's look at this boilerplate template of a room:
using System;
using System.Collections.Generic;
using System.Text;
using System.Collections;
using PlayerIO.GameLibrary;
using System.Drawing;
namespace MyGame {
public class Player : BasePlayer {
public string Name;
}
[RoomType("MyRoomTypeName")]
public class GameCode : Game {
public override void GameStarted() {
// happens when the first user joins the room.
}
public override void UserJoined(Player player) {
// happens when user joins the room.
}
public override void UserLeft(Player player) {
// happens when user leaves the room.
}
public override void GotMessage(Player player, Message message) {
// happens when sever receives a message from client.
}
}
}
Great! So, you write the c# code for what happens in a lobby a room or a game room, and then when users join a room of that type a new instance of this server class is made. Now if you want two more users in a different room all you need to do is say you want to join another room of that type. Once anther player joins the room they now share this common connection the instance of your server room class. So now we have messages leaving the client and coming into the server. At this point you may be thinking (going back to the first person shooter game), "Alright, so now the opponents are sending messages about their gunshots to the server, but how do those messages get back to me?"
Well, that's an excellent question and it is where you begin getting into the server api. In playerio it is quite simple to send a message from client to server, and the very similar to the actionscript message. There are two ways to send message from the server. The first is just a send() method that takes the message type and whatever parameters you want to send back to the client. Here is an example of sending the C# message:
public override void GotMessage(Player player, Message message) {
// sends a message of type HELLO_MESSAGE to this player.
// sends an parameter: a string with the value "Hello there!"
player.send("HELLO_MESSAGE", "Hello there!");
}
You can also very easily send a message to all players using the Broadcast method. In the Broadcast method the first parameter is again the message type, and then the other optional parameters are sent back to the client.
This messaging system is very powerful because it's flexible. In the message you can send as many parameters as you wish. For the different types, you can make an many message types as you need. So if we're making a first person shooter we would have one message from the client of type "GUNSHOT_FIRED", and with is it you might send some variables like the type of gun you are shooting and / or your position or maybe even the bullet landing position / target position. You can then compare those positions with the the current positions of other players. If a player was in range, you might use the Send method to give them a message of type "BULLET_NEAR_YOU" with an extra parameter between 0 and 1 to adjust the volume based on the distance. I'm sure you'll be able to think of plenty of great messages to send, so let's rev up those big, bad IDE's and put them to work.