How can I alleviate network lag issues with players from other countries?

Question

I am developing a small multiplayer game where players move through the map and interact with each other. The game is written in VB.Net.

When I tested my game with players on a LAN everything worked pretty smoothly. Testing it on the internet with players from the same country worked pretty well, without lag, also. The problem is when players from other countries try to connect to the game: they can connect and play but the game is very laggy for them.

What should I do to fix the lag?

Answer 1

I'll rather delve into the problem you are having with network latency: it's unavoidable. Network programming is a fine art and much more psychologically involved than tricking the eye (as you do with graphics programming); people are very sensitive to their perception of time.

What you essentially need to do is do prediction on the client. For example, in a strategy game this is the naive way of doing things:

1. The user selects a unit and issues a move command to some place.
2. The command is packaged up and sent to the server.
3. Some times passes as the server gets the command and starts sending back the 'update position' commands.
4. The unit starts moving.

Typically if you are connecting from a separate country you can expect latencies of up to 400ms, or 600ms if your connection is bad (and even over 1s if you are using TCP and the packet loss is high enough - which it probably will be). Anything over 30ms can be perceived from the average user's perspective - so you are fighting a losing battle. To further compound the issue latency can vary/change (and as the average latency get higher so does the variance) - for example at 180ms I often get about 20ms variance on a premium priority account: this means that a packet takes between 170ms and 190ms to travel from South Africa to Europe on the most stable bandwidth available here. (This is also called 'jitter').

Jitter and latency are two defining characteristics when talking about lag. Most people see them as the same thing; when in actuality they have different outcomes: latency delays the outcomes of your commands, jitter makes things move forwards and backwards or erratically.

We compensate for this using two strategies at the same time: client prediction (solves average latency) and interpolation (solved latency variance). Both of these are described in depth on a large amount of websites, so I will only briefly touch over them here.

Client Prediction

Essentially what the client does here is it anticipates what the server might be sending it at some point in the future. You basically need to resolve the difference in time between the server and the client: in 180ms I will receive a packet from the server telling me where this unit is, but in reality it's actually sending that packet right now - so I will chance a guess and move the unit to where I think the server will say it will be given its velocity, acceleration and sometime even information about the controller (mouse, keyboard, game pad) of the person controlling that unit.

Interpolation

This is when the client says, "OK, I am getting irregular updates from the server even though it is sending them at regular intervals". What we do here is instead of updating the unit to where the server says it is each time: introduce delays between updates from the server and let the client figure out where the unit is in between those delays. To do this we use a very simple function called 'lerp'.

Fine Art

The fine art comes in when you need to trick the user and make them believe that things are happening as they do them (where in reality that signal takes time to reach the server). For example in the case of the 'move command' above what we could do instead is:

1. The user selects a unit and issues a move command to some place.
2. The command is packaged up and sent to the server.
3. The client starts moving the unit.
4. Some times passes as the server gets the command and starts sending back the 'update position' commands.
5. The client starts receiving the position of the unit and over a duration of time (possibly one second) gradually moves from its prediction to what the server will be saying further down the line (depending on the current latency) - once again you would use a lerp here. Furthermore ensure that you smooth (a moving average of the latency might work nicely) the latency so that the unit doesn't jump around.

This way as soon as the user issues the command they see a result - the lerp helps us gradually move to actuality and the smoothing ensure that the unit doesn't jump forwards and backwards due to variance (hopefully just slow down and speed up in a way the user can't notice).

Some resources:

• 1500 archers on a 28.8: Network Programming in Age of Empires and Beyond
• I Shot You First Networking

Answer 2

MySQL (in general, any SQL) is not the best choice for storing your live data. But I doubt that's your problem currently.

It seems like your issue is that your game doesn't work with people connecting from outside the country due to the high latency. Possibly your networking code is embedded in your game loop somewhere, so a high latency network call is slowing down the rest of the game

Example of embedded network send anti-pattern:

while(true) { // MAIN GAME LOOP
    GetPlayerInput();
    GetDataFromServer(); // <-- this is a blocking call
    RunGameLogic();
    SendDataToServer();  // <-- this is another blocking call
    Render();
}

You need to decouple your networking logic from your main event loop so that the latency doesn't affect the rest of the loop.

One quick way to fix it is to move the networking code to a different thread, and have it interface with the main loop through an event queue. Another way would be to convert to asynchronous calls or Socket.Poll.

---

crux of the question was basically like: if I will learn how to use sockets and make server/client comunication does my game will still lag for Foreign players.

No, if written correctly. The only "lag" they should experience is that events happen later for them, but the game should not run slower overall.