A network for games?

Question

I want my game to be fully server-side. Meaning, the client only sends its keystrokes. Then they are provided with updates to the positions of changed objects from the server. Then the client displays all the frames.

This is a 2D game.

I was thinking of something like this: compute an intermediate frame using Box2D and not try to predict where the server actually will be.

ServerPos → ClientPos → ServerPos → ...

If by a certain time we have not received a packet (dropped or something else), we simply simulate the next frame on the client. The idea is to avoid the server always correcting our position. We want the client to populate inbetweens, but not try to predict where the server will be.

We want the player to move in the opposite direction at any cost, because the client simulated, so we could multiply the resulting vector by a scalar, for example, 0.98, which would mean that the client would be slightly slower than the server, and help ensure a smooth transition to the server position.

thanks

Answer 1

Just a thought, but I think you can forget about network latency.

Assuming you are really sending data 60 times per second in response to what the client is sending. Than maximum latency can be 1 second / 60 = 17ms . This will be a problem for almost any Internet connection, as your application will also introduce some delay. So ... if you want something like this to work, you will have to have a small buffer window to catch this delay. And that will make him less responsive.

There is a reason that most online games have some in-place prediction algorithms if the connection drops / stops a bit.

I think the idea is good, but in practice this probably won't work so well.

Answer 2

This will work and can only work on the local network or, in exceptional cases, on some low-host connections between servers. Try TRACERT on some public server - here is an example:

 C:\Users\mosh>tracert -d -w 3000 www.google.com Tracing route to www.l.google.com [209.85.149.104] over a maximum of 30 hops: 1 46 ms 99 ms 99 ms 192.168.1.1 2 * * * Request timed out. 3 10 ms 9 ms 10 ms 172.29.16.133 4 10 ms 9 ms 10 ms 195.29.110.230 5 41 ms 41 ms 95 ms 80.81.193.108 6 46 ms 47 ms 127 ms 209.85.255.176 7 49 ms 47 ms 47 ms 216.239.48.11 8 47 ms 47 ms 47 ms 216.239.48.5 9 54 ms 53 ms 54 ms 209.85.254.21 10 51 ms 42 ms 40 ms 209.85.149.104 Trace complete. 

Each router that you have between your server and your clients will add a few milliseconds and depending on the delay of 17 ms (one frame) will make the game unusable.

Answer 3

No.

Network latency will make the game unstable if you control all server ones. You only need to look at a game that is already doing this, such as LaTale . Input latency is terrible.

Answer 4

You cannot do this because you do not know how long it will take to press keys on the server. And given that physics changes the state of objects over time, this unpredictable point in time means that you cannot guarantee that the server view will still match the client. One side must be authoritative - the other must predict, wait, or both.

Answer 5

Sync as little as possible. 60 times per second is too much and not necessary. For LAN, sycn once per 100 ms is enough; for WAN, once in 200 ms - the usual case.

And what kind of game are you doing? In different games, politics is very different. You may need to configure a synchronization policy for your game.