Networking Pong Clone

Question

I have the fundamentals of TCP sockets, UDP communication etc, but can't find much on how to apply these to a real time game environment.

I have a Pong clone, with 4 players, and need to synchronise the paddle positions between the three clients and the server (the server is the fourth player). Currently I use UDP to send real time updates (paddle movements), and TCP for setting up the game lobby etc.

Is it a BAD THING to be spamming out huge amounts of UDP traffic? Should I look into something like DCCP for its congestion features? Or is this not really a problem with a small scale project like this?

When should synchronise messages be sent between client/server? Currently the server is spamming out UDP packets with the current game state as fast as it can manage, and clients are spamming out their paddle position back to the server as fast as they can. Is this the best way to do it? Is there some sort of delay I should add so messages are sent once every X milliseconds, or should I only be sending out messages as events happen? (eg paddle velocity changed due to user input)

Would it be better to make clients communicate their paddle positions with each other peer to peer?

I am asking these questions within the context of Pong but am also interested in how these problems would be overcome in other games, or generalised solutions.

Answer 1

Have a configurable update interval (so you can tweak and try 5 packets per second or 20), and each frame see if it's time to send an update. You might be ok with a simple game sending packets for each event, but in a more complex game this isn't practical. Also keep in mind that there is a packet overhead so if you are sending a bunch of small packets you are going to waste bandwidth.

Each update interval have each client send its paddle position to either the server, or to each client (peer-peer). Have the server also send the ball position and a velocity vector. Each client can run the same screen drawing code as it does in single player so the movement of the ball will be smooth. In multiplayer though you have only the server send the position/velocity updates for the ball at a regular interval (and if you like each time it hits something).

Have the ball position updates reference a gametime across all clients so you can discard out of order packets and even make the interpolation of the balls position more accurate (you know the position and velocity at a specific time in the past so you can interpolate the new position).

With this model with a laggy game you might see the ball move backwards at times or jump around a bit. But with a decent connection it should be pretty smooth.

Answer 2

Regarding traffic concerns - you want to avoid sending more than 20-30 packets per second per peer. In the general case, if you send smaller, fewer packets, you will experience (slightly) less latency and a lessened chance of dropped packets.

You definitely don't want to send updates at a speed faster than framerate, as players won't be able to tell the difference -- indeed, if you only send packets 10 times a second and interpolate/extrapolate the results on the receiving end, most players won't notice a difference.

Answer 3

This is a pretty broad question, but I'll try to summarize the important aspects.

The first decision to make in the network code for your game is whether you want a client/server setup of a peer to peer arrangement. Most games, with RTS probably being the only notable exception, are probably using a client/server architecture. The main advantage being that this arrangement is more fault tolerant and provides more control over what data each client receives. Peer to peer allows to send far less data, but requires each peer to fully simulate the world precisely as every other peer does. If one peer lags or desynchronizes, everyone must either wait for them to recover or they are simply lost.

UDP is generally the correct choice as well, certainly for any client/server model. TCP might be practical for a peer to peer game, but even then UDP might be a better choice. Basically, UDP handles less for you, which means more effort but also more control over how you deal with faults.

For Pong the choice I would make is client/server, being that it is an action oriented game. One thing to note here, even though you say that one player "is the server", you are best off structuring your code such that they are essentially running a local server and connecting to it as a client.

You definitely don't want to be "spamming" updates in any direction either. One update from the server per frame is all that is needed, and your server should be running at a fixed frame rate. What that is is up to you, but there is no need to go overboard. A 50ms frame (20 FPS) is plenty to get nice smooth game play. To keep things smooth on the client, you want to make use of interpolation. The client should be constantly transitioning between server frame snapshots, this could easily be the topic of a separate question though.

Client updates should be limited as well, though one per frame will likely be far too much if your client is running at a decent frame rate.

Answer 4

Do you care about cheating?

If not, going peer-to-peer will halve your lag, as it's A<->C instead of A<->B<->C. If so, for fairness in synchronization you may want to make response somewhat laggy for the local player, or what most games do - let the player do whatever locally and then snap back if the server's result diverges from the locally simulated.

A pong clone is actually a bit tricky, because unlike most games you can't (as a developer) cheat by having one side see a hit and the other not.

As for something generalized, one technique I've heard of but haven't found necessary (may be for action games though) is to keep actions with their true timestamps (receive time - ping/2), and have the server roll back (snap) if an earlier-time event comes in, and then reapply later actions. That way, everybody is consistent locally unless there is some conflict due to different players' interactions. The only danger is the ability to 'roll back time' if they fake a laggy connection.

Answer 5

Google dead reckoning. Sending out updates for 4 players is not going to be significant. The amount of data sent is going to be on the order of bytes. So, that means frequent updates should be ok. With dead reckoning, you move the player on the client and the server. The server is the authority. When the clients position becomes too far out of synch from the server, it has to drift back into alignment. http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking Using UDP is the way to go. Bupdates will be sent to frequently that lost data will soon be replaced by incoming data anyway. The packet retransmit of TCP is not worth it for player position. Look at this article for more info on how to keep the client and server on synch.

Answer 6

I have programmed a 2-player-local-network-pong game a few weeks ago, here's how I did it:

-One side opens a server, the other one connects automatically -they are both spamming their paddles x position towards each other @ 60fps or less [UDP] -if one side hits the ball they decide about the balls new velocity and position and send that to the other one [TCP] -if the ball flies past a paddle, the player who missed it contacts the other one with an increase score message and the ball is reset [TCP] -the ball is getting simulated independently all the time, which suits the simple ball physics of pong

This creates roughly 0.3 to 0.5 KByte/s of traffic at 60fps and the players have no lag in their perception, but only if the ping is below a certain threshold, because the balls new position needs to be transmitted.

Also cheating is easy with this system and there's a high possibility to go out of sync with a very lossy connection, but who cares about cheating in pong?!