Name: Anonymous 2013-09-23 18:07
I'm trying to get real-time networking working with a browser game demonstration I have been working on in my spare time.
The demo is written with Javascript, so on the server I am using node so I can re-use client code (as well as have an excuse to play with Coffeescript and node in general).
This all works fine, and server authoritative movement for players works quite well, albeit with the jerkiness implied with internet latency.
The problem I'm having comes when attempting to set up client-side prediction. The general idea is, keep a record of input and local player state each frame, when the server sends an update, rewind this record to the game time the server update has, insert the player state from the server, and replay local physics to the current local game time before the next frame (this allows for lagless movement from the perspective of the local player).
In nearly all implementations of this general idea I've seen, the client and server have a relatively synchronized clock "timestep". This way, the client can compare the current local time to the server's sent timestamp on the update and decide where in the state buffer to insert the update (which is, from the client's point of view, in the past).
How am I supposed to do this in javascript though? I've tried nearly everything it seems, and perhaps there are other errors in my implementation, but I've spent hours simply trying to get the game clock anywhere near synched up to no avail.
This has to be possible, I've seen several massively multiplayer games written in JS with minimal input lag (the mozilla MMO demo comes to mind, also the bomberman game with >100 players on a map at any time) that surely have stable, synchronized game clocks...
How do I do this? Is using the literal epoch time as game time a good idea or a bad idea? I have no idea what is going on server side for the examples I've mentioned, is there no hope for a Javascript backend with these requirements?
Even if I managed to get a relatively stable clock on either client or server, when do I start the client clock upon connection to an already running server? Do I have to measure latency before I can accept the server's game time?
I'd especially love to hear from the "Javascript is the future" g(o|u)y
The demo is written with Javascript, so on the server I am using node so I can re-use client code (as well as have an excuse to play with Coffeescript and node in general).
This all works fine, and server authoritative movement for players works quite well, albeit with the jerkiness implied with internet latency.
The problem I'm having comes when attempting to set up client-side prediction. The general idea is, keep a record of input and local player state each frame, when the server sends an update, rewind this record to the game time the server update has, insert the player state from the server, and replay local physics to the current local game time before the next frame (this allows for lagless movement from the perspective of the local player).
In nearly all implementations of this general idea I've seen, the client and server have a relatively synchronized clock "timestep". This way, the client can compare the current local time to the server's sent timestamp on the update and decide where in the state buffer to insert the update (which is, from the client's point of view, in the past).
How am I supposed to do this in javascript though? I've tried nearly everything it seems, and perhaps there are other errors in my implementation, but I've spent hours simply trying to get the game clock anywhere near synched up to no avail.
setTimeout and setInterval are both 'unreliable' when it comes to actually running code when you tell them to, this is the nature of Javascript; however even when adjusting the game clock per the actual passage of time, the client always end up falling behind the server. This has to be possible, I've seen several massively multiplayer games written in JS with minimal input lag (the mozilla MMO demo comes to mind, also the bomberman game with >100 players on a map at any time) that surely have stable, synchronized game clocks...
How do I do this? Is using the literal epoch time as game time a good idea or a bad idea? I have no idea what is going on server side for the examples I've mentioned, is there no hope for a Javascript backend with these requirements?
Even if I managed to get a relatively stable clock on either client or server, when do I start the client clock upon connection to an already running server? Do I have to measure latency before I can accept the server's game time?
I'd especially love to hear from the "Javascript is the future" g(o|u)y