3 ms·

This is exactly how these types of problems are solved. Local clients run simulations based on known locations/directions, and are synced with the central serve

This is exactly how these types of problems are solved. Local clients run simulations based on known locations/directions, and are synced with the central server at a specified interval. This allows a client to have a light-weight "cached" view of the reality, and the only trade-off is the occasional discrepancy from the reality. However, if you send updates about changes in speed/directions in real time, you get a pretty reliable representation of the state known by the server.

jere 14y ago
Sure. It's commonly called dead reckoning as I understand it: http://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_for_networked_games http://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_f... But even if you only send a "real" update once a second, I still don't see how this thing scales (that still leaves 1 PB in the above calculation). And if you send it less than that, I imagine things would start to look rather jittery. The "occasional discrepancy form reality" would be awful.
- stingraycharles 14y ago
  It depends. If you have 3000 clients and a full sync of all visible ships occurs every second, you get 3000 * 48 = approx 150kb/sec/client. Yes, that means that the server must be able to handle 3000 times that speed, but that still leaves us at about 0.5gbit. Yes, it's a very high load, but then again, these types of situations are extraordinary. Last but not least, compression is your friend.
trout 14y ago
Depending on the game (it's been 10 years for me) one 'hack' was to head in one direction, pull the network connection for 3-4 seconds, head in the opposite direction, and plug back in. This allowed you to escape or hide in the terrain fairly reliably. With higher bandwidths and server capacities I'm guessing these timeouts have been reduced, but never underestimate the player's ability to abuse your trade-offs.
- DigitalJack 14y ago
  There was an exploit in eve sort of like this. What you did was start warping toward a planet on the far side of the solar system and then kill the application as you got close to it. The effect was to allow you to sling shot past the destination at warp speed, and if you logged back in at teh right time (seconds later) you could setup a waypoint far outside the outermost celestial body. (Normally you can only warp to planets and moons, etc... you can't just pick an arbitrary direction and engage warp).
- gizmo686 14y ago
  That problem is not because of the trade off. The problem is that the server believe the player's client when it provided an updated location. The 'correct' behavior in this case would be that the server resyncs the client, and the player observe's his ship jump to where the server thinks it should be.

jere 14y ago

Sure. It's commonly called dead reckoning as I understand it: http://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_for_networked_games http://en.wikipedia.org/wiki/Dead_reckoning#Dead_reckoning_f... But even if you only send a "real" update once a second, I still don't see how this thing scales (that still leaves 1 PB in the above calculation). And if you send it less than that, I imagine things would start to look rather jittery. The "occasional discrepancy form reality" would be awful.

stingraycharles 14y ago
It depends. If you have 3000 clients and a full sync of all visible ships occurs every second, you get 3000 * 48 = approx 150kb/sec/client. Yes, that means that the server must be able to handle 3000 times that speed, but that still leaves us at about 0.5gbit. Yes, it's a very high load, but then again, these types of situations are extraordinary. Last but not least, compression is your friend.

trout 14y ago

Depending on the game (it's been 10 years for me) one 'hack' was to head in one direction, pull the network connection for 3-4 seconds, head in the opposite direction, and plug back in. This allowed you to escape or hide in the terrain fairly reliably. With higher bandwidths and server capacities I'm guessing these timeouts have been reduced, but never underestimate the player's ability to abuse your trade-offs.

DigitalJack 14y ago
There was an exploit in eve sort of like this. What you did was start warping toward a planet on the far side of the solar system and then kill the application as you got close to it. The effect was to allow you to sling shot past the destination at warp speed, and if you logged back in at teh right time (seconds later) you could setup a waypoint far outside the outermost celestial body. (Normally you can only warp to planets and moons, etc... you can't just pick an arbitrary direction and engage warp).
gizmo686 14y ago
That problem is not because of the trade off. The problem is that the server believe the player's client when it provided an updated location. The 'correct' behavior in this case would be that the server resyncs the client, and the player observe's his ship jump to where the server thinks it should be.