Sign in to follow this  
Zerd

Game Message Packets

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

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