Threads for peer to peer communication

Question

I am trying to make a multi-player network game. Each player is represented by a rectangle on the screen. I am using OpenGL for the graphics and also the user input (commands like MOVE-LEFT, MOVE-RIGHT etc ) will be handled by it (or GLUT or sumthing).

I have the following architecture for the game.

There are 4 players(nodes) in the game. Each player is sending and receiving data using UDP. Each player can send data to any other player.

Data is required to be sent by a player if there is any input from the corresponding user. (For example MOVE-LEFT command etc). Whenever a player (say p1) receives any data from any other player(say p2) (like new position of the player p2 on the screen), the player p1 's screen should be updated immediately.

I am thinking on the following lines : Create one thread for handling graphics. Create 2 more threads , 1 each for receiving and sending data, using UDP.

Whenever the graphics thread gets input for 'myposition' from the user, it updates the shared global variable 'myposition'. The network-send thread, which is waiting on this variable, gets activated and tells every other player about its new position.

Similarly whenever 'position' updates are received from any other player 'i', the network-receive thread updates the global variable player[i].position. The graphics thread will now redraw the scene with the updated positions.

Is this design correct. If yes, How good is this design and how can i improve it

Answer 1

Network Game Programming is a monster of a topic, so it is hard to say "yes, this is how you design a network architecture". It is completely dependent on your game requirements. What sort of volume of packets do you plan on sending? Will there be a packet sent every frame that indicates Player A is holding the left key? Is this traffic confined to a LAN?

For something as simple as synchronizing movement between amongst 4 clients, putting send, receive, and rendering in separate threads seems like overkill. Perhaps as a starting point, you should begin with a more simple design and make the move to multithreading when you feel that your packets are not going out fast enough.

For example, you may wish to have a game loop like the following (all within the same thread):

while (running):
    readUpdSocketForIncomingPackets();
    updateGameObjects();
    renderGameObjects();
    sendPacketsToPeers();

At the start of each frame, you can read your udp socket for incoming packets and update positions (and whatever else you are sending to your peers), then draw. As game input is processed, packets are created and accumulated in a packet queue. Doing it this way, allows you to perform optimizations, such as cramming/merging multiple messages into one packet, removing duplicate messages (e.g. only send the latest position update), etc. So at the end of each game loop, the final queue of packets are processed and send to the peers.

But again, this is a big topic and I've glossing over a lot of details.

Take a look at gaffer's blog: http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/

He's got some great articles that address some fundamentals of network game programming.