🔒 Locked

Simple Multiplayer Messaging Protocol

Started by vidhvat May 14, 2011 at 7:05 AM 9 replies 3.1k views

Original Post

May 14, 2011 at 7:05 AM

I want to know how a game encodes it's messages that are sent to all the other users playing the game.
What I have is a simple game, with characters and objects. Players, as characters in the world, can pickup, drop, give, receive and interact with these objects. Currently, in the engine, every object and character has a url, more like a code to identify it, a single byte in this case (char).

I have no prior experience with network programming, but right now I have a thin layer programmed over UDP that allows me to send and receive simple packets in a reliable fashion.
What I want to know is, how do I pack all this information, in a generalized manner? What I can think of, is give every function a code, like, dropping can be 1, picking up can be 2, giving can be 3 etc. Then just send the character code, object code, and the function number. This information can be decoded and performed on all the other clients. Is there a more elegant way of doing this?

DividedByZero

May 14, 2011 at 11:38 AM

More or less, that is how I would do it. But, I would personally send it as a data structure.

For example;

struct Action
{
BYTE actionCode;
BYTE characterCode;
BYTE objectCode;
}

Then send something like so;

send(socket,&ActionInstance,sizeof(action));

That way you are sending only 3 bytes (in the example) + UDP overhead and you data is easy to re-construct at the other end by copying the data directly back into a temporary struct (of the same properties).

By the way, when you say reliable UDP layer. Do you take into account packet loss, out of order packets, etc?

Good luck with your project and hope this helps.

vidhvat

May 14, 2011 at 12:17 PM

So, I was pretty much on the right track there. Thanks!

[color=#1C2837][size=2]By the way, when you say reliable UDP layer. Do you take into account packet loss, out of order packets, etc?[/quote]
Yes I do :-)

DividedByZero

May 14, 2011 at 10:48 PM

Good one

Let us know how your project goes

Sirisian

May 15, 2011 at 12:04 AM

Good introduction in my opinion is this on the wiki. Covers most of the basics. A key thing to notice is that you should probably be writing a lot of things to a single packet. (Keep them under 1400 bytes usually).

vidhvat

May 15, 2011 at 3:31 AM

Bitfields.

I don't think it's necessary, if I am going to use up all the possible values a byte can represent! This would be a good thing to use where I have smaller values that are being sent, for example, booleans! Nice link though, thanks!

So here's another question. Is it true that most clients just send their user input to the server? I wonder if it really works that way. For example, in my situation, I can send messages(via console) to objects in the world. Right now, I am sending the character code, the object code and the action. Would it be fine if I didn't send the object code and let the other clients figure it out themselves as to which object is closest to the player.

I think, It's a gamble really, because if the position is not synced, we're in big trouble! Right?

hplus0603

May 15, 2011 at 3:51 AM

I think, It's a gamble really, because if the position is not synced, we're in big trouble! Right?

The server can send its position for the client entity to the client once in a while, so the client can snap back in sync if it's not where it should be.

DividedByZero

May 15, 2011 at 11:40 AM

The bottom line is never let you client tell the server what to do. (Never trust the client).

Send requests to the server instead - like "may I open the door please". In this case the server might respond "no you may not, you are nowhere near a door".

You can, however, use the client to predict that the server will be ok with things most of the time and perform the task anyway (as a means of making lag look invisible).

But, if the server responds "you cant do that", then snap back to where the client should be as hplus0603 suggested.

Also a good idea to log the amount of rejected requests too and the disconnect the client when it hits a threshold. As, then you may be dealing with a hacked client.

vidhvat

May 15, 2011 at 2:08 PM

Okay, brace yourselves, here it comes:
I'm doing P2P!

BeerNutts

May 20, 2011 at 4:26 PM

Okay, brace yourselves, here it comes:
I'm doing P2P!

I am too. Considering i'm not concerned with cheating, I think P2P is the easiest way for me. For player movement, the players send updates with position and velocity every X mS via unreliable UDP, for acquiring items from the map, it send reliable UDP, and I'll have it send the position and velocity of bullets it shoots reliably as well.

I just didn't feel like putting in the extra work for Client-Server, and it was for fun.

vidhvat

May 20, 2011 at 6:06 PM

Exactly! I'm doing it the same way!
Though my game doesn't involve any projectiles, there's allot of player-player interaction, which requires synchronization between peers.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.