Sign in to follow this  

Game Message Packets

This topic is 4066 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Currently I'm thinking about the design of the message structures I need in my fps. In the first step it only will be for about 8 players in a LAN or over the Internet, where one client acts also as Server. Here is what I got right now: INTERNAL_PING - sends a ping with piggybacked timestamp CONNECTED_PONG - sends a pong with piggybacked timestamp CONNECTION_REQUEST - player requests a connection, including the playerdata BROADCAST_PINGS - keepalive ping to every host CONNECTION_ATTEMPT_FAILED - connection failed CONNECTION_ATTEMPT_SUCCESSED - connection granted NO_FREE_CONNECTIONS - error if maximum amount of players reached TIMESTAMP_REQUEST - peer requests a timestamp TIMESTAMP - the timestamp UPDATE_PLAYERDATA_BROADCAST - sends the update of playerdata to all hosts UPDATE_PLAYERDATA - sends the playerdata to the server (movement, speed) CONNECTION_ASYNCHRON - error if client time is asynchron The login procedure could look like this: 1. CONNECTION_REQUEST (Client -> Server) if Free connection slots available and clientdata valid 2. SUCCESS (S->C) else 2. NO_FREE_CONNECTIONS (S->C) goto ende 3. TIMESTAMP_REQUEST (C->S) 4. TIMESTAMP (S-C) 5. INTERNAL_PING (C->S) if servertime and clienttime synch 6. CONNECTED_PONG (S->C) else { 6. CONNECTION_ASYNCHRON (S->C) 7. TIMESTAMP_REQUEST (C->S) 8. TIMESTAMP (S-C) ... } I'm not sure if this is a good way of organizing such a login process. Did I forget anything? Are there any suggestions how I could make things better? [Edited by - Zerd on October 19, 2006 6:45:21 AM]

Share this post


Link to post
Share on other sites
I think you forgot, uh, the login process :P. Somewhere in there the player who's trying to connect needs to send his player data, so the server can refuse the connection if it's a banned or unknown user.

Also, I'd be surprised if an FPS needs keep-alive packets since it's a pretty fast type of game – something's going to happen to keep the connections alive anyway. But a bit of extra safety isn't a bad thing, I suppose.

Share this post


Link to post
Share on other sites
Ehm... maybe I wasn't clear enough...
The CONNECTION_REQUEST sends playerdata in the datafield of the package.

But I forgot to mention this in my first if-case, I'll fix that

Share this post


Link to post
Share on other sites
(Excuse the brevity, lost the message first time around...)

- NO_FREE_CONNECTIONS is redundant, it should instead be represented as an error code in CONNECTION_ATTEMPT_FAILED.

- INTERNAL_PING, BROADCAST_PINGS and CONNECTED_PONG should be replaced with a PING/PONG for calculating latency between Server and Client. This will also act as your Keep-Alive.

- TIMESTAMP_REQUEST and TIMESTAMP should have the timestamping moved into PING/PONG(though the questions is.. is timestamping required at all?)

- UPDATE_ENV should be added for communicating changes in the global enviroment (eg, for explosion sound effects), and for game events such as a player being killed/respawning.

- DROP should be sent by the client for a graceful disconnect, merely having the Server waiting for a keep-alive timeout may be considered rude :) Likewise, the server may also want to send this to an unruly client(or a very laggy client).

Hope this helps :)

Share this post


Link to post
Share on other sites
Zanthos, Thank you for your reply!

I reduced my package structure after I read your post. Now it looks like this:

Package Types:
PING / PONG – For calculating latency between Server and Client
CONNECTION_REQUEST - player requests a connection, including the playerdata
CONNECTION_ATTEMPT_FAILED - connection failed
CONNECTION_ATTEMPT_SUCCESSED - connection granted
UPDATE_PLAYERDATA_BROADCAST - sends the update of playerdata to all hosts
UPDATE_PLAYERDATA - sends the playerdata to the server (movement, speed)
UPDATE_GAMEWORLD – Events in the world like player killed/respawn, new player..
DROP – Client leaves game / Server kicks Client

So if a client wants to login on the server:
- Client sends the CONNECTION_REQUEST package to the Server
- If Server replies with CONNECTION_ATTEMPT_SUCCESSED
- The clients sends a PING package to the Server
- The server replies with a PONG package including the servertimestamp
- Now Client should be synchron with server (servertimestamp + rtt)

A simple update of the playerdata would look like this:
- Client sends UPDATE_PLAYERDATA to Server ("I would like to go to position xyz")
- Server response if the request is valid with a UPDATE_PLAYERDATA_BROADCAST so all connected players get the new position of the client


Did I forget anything important?
I'm not sure how often I have to send the data. The game will be a FPS-like game (not really, but same amount of action).
How often should I send a PING/PONG? After n seconds when a client did not send any updates?

Share this post


Link to post
Share on other sites

This topic is 4066 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this