2
\$\begingroup\$

I have been working on a real-time game, and am closing in on the point where I send and receive data. I have previously accomplished this before with a couple other test games, but I have never really learned the correct way to pass data from server to clients efficiently.

My question: What is the best practice for a real time game to pass data? I have my doubts that I should be sending an update every frame (currently running at ~30 fps), but in all honestly I dont know what is best.

Most of the games ive worked on have passed the data instantly when they happen and continue to update every frame. Any suggestions or advice? Ill post more info if needed as well.

Thank you

\$\endgroup\$
2
  • \$\begingroup\$ your game is fast paced (FPS Style) ? \$\endgroup\$ Jun 25, 2016 at 21:38
  • \$\begingroup\$ No it is not going to be FPS. It will be more RTS. it will resemble a custom game from Starcraft 2 \$\endgroup\$
    – Mishtiff
    Jun 25, 2016 at 22:12

1 Answer 1

1
\$\begingroup\$

In multiplayer networked games, exchanging information among clients and server, dealing with synchronization, update every client at a proper rate, and all other stuff about game networking, they make up a game network protocol, thus the rules adopted by such game to deal with the so-called netcode. So, the right question to ask is:

How do I set up a network protocol for my game?

Building a game network protocol, and dealing with game networking in general, is not a simple task. A fast-paced game such as an FPS may use a different net protocol compared to the one used by a RTS game, because of some aspects:

  • Data quantities: the quantity and quality of data exchanged between any client and the server depends on the complexity of a game. A simple FPS - where you are required to move and shoot only - will require less data than another FPS where much more user interaction is required, like using grenades, switches, vehicles, platforms, chat. Also, an RTS will deal with different kind of data, because there are less players but many more objects to keep track of, whence more data to exchange.
  • Synchronization rate: a RTS doesn't need constant updates to keep the clients on sync, as there are limited actions from the players over the time; on the other hand, an FPS requires fast action, and any player may move, shoot, interact, or die at any time, and you need to make sure every other player can see it as soon as possible.
  • Reliability: ideally, we may have a game where no packets are lost when sent. This is not a real scenario, so we must distinguish between data packets that need to get always to the clients (or server), and data that can be lost when sent without harming the gameplay or the user experience with the game. In FPSs and RTSs there are different type of packets which belong to the former or the latter category, still this depends on the complexity of your game.
    • Example 1: you order an ally unit to attack an enemy unit, and the enemy unit dies. This must be notified to all other players; if information is lost, we send it again until the client tells us the packet has arrived.
    • Example 2: you write a message to the global chat. You don't read the message on the screen because it was lost. We may choose to send again the packet, or let the player just write the message again.

Other aspects are more or less common to game networking in general. In any game you must deal with players' bandwidth, application throughput, in-game timestep, lag detection, client-side prediction and server-side correction, congestion avoidance...

To answer your question, sending game updates at a high rate is not good or bad: it depends on the type of game. In a chess game you don't need nothing special but sending updates every time a move is performed; in an FPS, you may want to send updated 20 to 60 times per second, because anything can happen at any moment.
If your game runs at 30 fps, you can choose to keep this rate or lowering it if the gameplay doesn't break at all. You can change its values and test the overall performances.

Network Programmer Glenn Fiedler wrote, and is still writing, very interesting articles about game networking, building a game protocol, and dealing with networking issues (congestion, packet loss, compression) on its site: gafferongames.com. I suggest you to give a read to his articles, like Sending and Receiving Packets where he explains the many aspects of data input/output in a networked game.

\$\endgroup\$
2
  • \$\begingroup\$ Thank you for your thought liggiorgio. I only had my doubts about how much data could be sent out before it started slowing the computer I have running the server. I am needing to program a bit more to understand how intensive the current system I am working on will be, but I will take this advice with me and check once I get the chance. \$\endgroup\$
    – Mishtiff
    Jun 26, 2016 at 2:08
  • \$\begingroup\$ Then, I suggest to read the articles about network congestion. Also, Valve Dev Forums have a lot of interesting articles about networking and the amount of data one can send \$\endgroup\$
    – liggiorgio
    Jun 26, 2016 at 2:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .