Game Networking: Client request or Server Sending

Question

I'm trying to implement a basic client-server setup for my game. But what confused me was how I would approach sending updates.

Would I do:

1. Server has a tickrate, let's say at 20ms. Each tick would sends an UDP package to EVERY connection with the current game state and it's entities.

OR

2. Client request an update from the server and the server respond with the update. When the client receives it, it asks for another update and so on.

Pro-cons:

• 1. Con: Sends a package every tickrate and in this case 20ms. What if a clients broadband connection has a triptime at 300ms? Wouldn't that overload that client and his broadband? Pro: Consistent and fast?
• 2. Con: Requesting is done via TCP which is slower because the client has to wait before sending the next request. Pro: no overload?

So my question would be, what I'm I missing and how would I approach sending updates about the current game state?

Cheers!

Answer 1

Given what you've wrote I'm guessing that you're working on a real time game, not turn based. So you'll want to send player specific UDP packets continuously at a more or less fixed rate. Do not use full TCP for real time games - if you need TCP-like behavior then emulate it with UDP. This is because both use IP (see also OSI model), and one protocol can interfere with the other.

If only the latest state matters then you don't need to send all changes in every update. Just send the changes that apply to that client. You can even transmit updates piece-wise - one packet contains some position changes, next contains a few more and an entity removal, etc. Essentially you'll architect your client so that it's acceptable to lose some packets and retroactively figure out what must have happened in the intervening time. Various methods of handling this are described elsewhere which amount to creating a very specialized version of TCP.

For example, a player moves from point A to C via point B. If we drop the update containing B, we can do some interpolation to figure out where they must have gone to get to C faster than it'll take a packet containing B to get to the observer.

From the client side perspective, you can use a variable tick rate to only send as many ticks as necessary to keep the server informed. Specifically, you'll want to send at least one packet often enough to indicate that the client is still alive. However, it's much simpler to use a constant update rate - most of the updates will effectively be "did nothing for 20 ms."

• See also Gaffer On Games - UDP vs. TCP
• And Gaffer On Games - What every programmer needs to know about game networking
• e.g. Source Multiplayer Networking
• Data and analysis from Starcraft 2 The Revolution of StarCraft Network Traffic

Answer 2

When to send events?

In a typical game design a particular range is set where the center is the player.

In the server point of view, it does not send you details on what does not concern your range of sight or range your player is affected at. So it does not send events(bandwidth) if it happens on [another map] or [on the same map but you are not in range]. It depends on how your game was designed.

Note some events are server wide hence it affects all players.

In the clients point of view, it does not send to server if you do not move or do anything unless you got time triggers from the client. Again it depends on how the game was pre-programmed.

Putting that aside, here's more on server operation.

On Server side, some good architecture games handles different job per task. Example a game server instance can handle logging in and out while another handles storage/item retrieval and another instance handles map/view updates. This map/view updates can be separated in different instances. Treat each instances as a executable program always running but separate to each operation. It can be operated on a similar physical server or a different server depending on the required performance.

As an example please research on how Ragnarok operates it's engines, it is good way to start.

UDP & TCP

TCP are targeted IP so obviously you can use it on client to server updates. UDP can be used by game server for broadcast while client just listens like in LAN games, so depending on your setup you can utilize it as well.

Hope this helps.

Answer 3

For a realtime Game there are two kinds of network packet:

1. client send request then server response

2. server push packet to client

if you want to sync game state such as hp, mp, position, client need to send these state packet to server, then server push these packet to all other clients;

server only send state change of each entities.

so for state sync, you need to use tickrate method;

if client want to initial state, client should use the request-response method.