"the bottom line is, if you are lagged, ... , any real-time game is gonna suck hard. "http://irrlicht.sourceforge.net/phpBB2/ ... 6&start=15
keless, as to doing the physics on both and updating..
what i have managed to find on that subject, of whether to use just a sort of dead reckoning between the client and server says that it is not preferred, but in most cases unavoidable. of course the server always has the last say, but in most games it is judged that the little bit of jitter when the server "corrects" the player's position is considered acceptable as long as it is getting those correcting updates as frequently as possible. naturally you cant sync the position every frame and expect to have a playable game...so of course we do it on a timer. the real question is HOW OFTEN?
the bottom line is, if you are lagged, no matter how well written its is, any real-time game is gonna suck hard.
for fmorg what im trying to do is make the actual network messages as succinct as possible to hopefully minimize the lag, and to run ALL movement on timers, do nothing based on framerate.
several ideas have occured to me as to how i can help keep the game expeirence thae same for all, no matter how different their lag is.
not all of these may be good ideas:
-sort the message queue BY the lag, so the more lagged people sort of get preference in processing, since they have less preference in receiving time
-when client send a state change req, and server sends back the OK, account for the lag when setting the timeForWay in the animator to move them(on the client)...the idea being that they both hopefully arrive at the same time
of course, the more fast-paced i make the game, the more noticable the lag becomes, no matter what i do, since i can't seem to come up with any way to account for the fact that network messages just take time...
also the obvious way (to me anyway) to track lag is to timestamp all messages from the source and then check what time they arrived and subtract. is there a better way?
i think on a fast enough LAN i could prolly get away without really handling lag at all, but i would like it to work over the internet too, who knows, i guess i will just see what i can do with it
correct.
"sort the message queue BY the lag"
This is not good, because as soon as some HPB joins the server EVERYONE suffers. If you say that your server can do a ping check to make sure it only accepts connections from LPBs, thats fine-- otherwise, no no no!
"when client send a state change req.."
typically, actually you time stamp your world updates. Every world update lists entities' 1) position, 2) direction 3) velocity 4) acceleration. Even if you get a world update timestamped for two seconds ago, you can extrapolate where all of the objects should be at the current time from that data. This is how Q3 does it. It is called "Predictive Interpolation" or something.