CODEWITHSUNDEEP
c++network-programming
jmasterx
jmasterx

Reputation: 54173

Networking for games?

I want my game to be entirely server side. Meaning, the client only sends their keystrokes. They then are given updates of the changed objects' positions from the server. The client then renders everything each frame.

This is a 2D game

I was thinking of something like this: calculate the inbetween frame using Box2D, and do not try to predict where the server is in fact going to be.

ServerPos -> ClientPos -> ServerPos -> ...

If by a certain time we have not gotten a packet (dropped or something) then we just simulate the next frame on client. The idea is to avoid the server always correcting our position. We want the client to fill the inbetweens but not try to predict where the server is going to be.

We want to avoid at all costs moving the player in the opposite direction because the client over simulated, so we could multiply the resultant vector by a scalar like 0.98 which would mean the client would be slightly slower than the server and would help ensure a smooth transition to the server position.

Thanks

Upvotes: 4

Views: 1464

Answers (5)

Kylotan
Kylotan

Reputation: 18449

You can't do it this way because you don't know how long it will take for the keystrokes to reach the server. And given that physics changes the state of objects over time, that unpredictable timing aspect means you can't guarantee that the server's representation will continue to match the client's. One side has to be authoritative - the other has to predict, wait, or both.

Upvotes: 1

Huang F. Lei
Huang F. Lei

Reputation: 1865

Sync as few as possible. 60 times per second is too much and not necessary. For LAN, sycn once per 100ms is enough; for WAN, once per 200ms is a normal case.

And, which kind of game are you making? The policy is very different for different games. You may need to customize a sync policy for your game.

Upvotes: 0

Daniel Mošmondor
Daniel Mošmondor

Reputation: 19976

That will and can work only on LAN, or exceptionally on some low-hop server-to-client connections. Try TRACERT to 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.

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

Upvotes: 2

Corey
Corey

Reputation: 1195

No.

Network latency will make the game neigh unplayable if you control everything server-side. You need only to look at a game that already does this, like LaTale. The input delay is horrible.

Upvotes: 1

Wolph
Wolph

Reputation: 80101

Just a thought, but I think you might be forgetting network latency.

Assuming you're really sending the data 60 times per second in response to something the client sends. Than your maximum latency can be 1 second / 60 = 17ms. That will be a problem for just about any internet connection since your application is bound to introduce some latency aswell. So... if you want something like this to work, you'll have to have a little buffer window to catch this delay. And that will make it feel less responsive.

There's a reason that most online games have some prediction algorithms in place just in case the connection drops/stalls a bit.

I think the idea is nice, but in practice it probably won't work that well.

Upvotes: 6

Related Questions