It's a fundamental rule of physics that you if you want perfect information you have to wait for it, or you can have predicted information but at some point it will inevitably need correcting.
No, it's not a rule of physics. It's a law of signal transmission theory.
The last time I checked, signal transmissions were governed by the laws of physics. :) Signals travel over a medium at the speed of light or below which means you always receive a signal some period of time after it was sent, and during that period the recipient cannot possibly know what has changed at the sending end.
If quantum computing becomes common - not just for the internet but within each computer - maybe it will become possible for 2 computers to be in perfect sync. Until then, physics prevents it because signals can't be sent faster than the speed of light.
It's not that I'm trying to make things perfect. If you saw how the game is acting currently, you'd understand. It's simply unacceptable, no one would want to play with this amount of jittering on a local connection. Every other game runs nearly flawlessly under ideal network conditions, I don't see why ours shouldn't.
Sorry, I'm a bit snappy because this is the 3rd thread I've seen on this forum in recent days which basically has exactly the same problem, ie. people are trying to synchronise the client to the server and having an awful time of it, probably because they're trying too hard to get things 'in sync' using complex systems like the Valve networking model that was designed for fast-paced shooters. Keep it simple. When I write networked games I don't even try to have all the computers in sync. Clients always have their character slightly ahead and other characters slightly behind, and it doesn't matter unless your game is so fast paced that the distance a character moves in 100ms is going to make or break the gameplay.
So things are working quite well now, thanks for all your help so far guys. The dejitter buffer solved the issue of the spikes, along with another change I made to allow the client a chance to catch up before forcing a resync.
I'm starting to work on getting other aspects synced and I was wondering what kind of things should use client-side prediction and what shouldn't. For example, player skills/attacks and world modification (placing and destroying blocks).
Also, what about things that involve random elements? Such as AI or maybe a cannon that has a slightly random firing angle. Does that require waiting on a server response?
Assuming by "prediction" what you mean is extrapolating from previously known state: the rule of thumb is to predict anything you can. Failing that, predict anything that is sensitive to latency. As a layer of filtering, don't predict anything that costs more to undo than it costs to wait for the authoritative update. If you can predict world geometry changes well enough, do it; but if you hit a point where it takes, say, 60ms to undo the modification once you get updated world state, it's probably time to just eat the latency and let the server control it completely. This is kind of an art form and is going to vary heavily per game.
Randomness is a tricky one. If you're aiming for full determinism, just share a PRNG seed and the current state of the generator when clients enter the game. If you have any doubts whatsoever about being able to maintain a fully deterministic simulation (hint: if you're not doing lockstep and/or you do any kind of on-the-fly state correction, you probably aren't fully deterministic) then just let the server be authoritative.
There is a hybrid approach, of course. If you know that some action will result in, say, 20 consecutive PRNG rolls, you can avoid transmitting all 20 roll values from the server by just transmitting a random seed to the client and having the client generate the 20 numbers itself. This is basically just a form of data compression.
Ok so I guess since we're not doing a fully deterministic simulation, we'll have to wait on the server for random based stuff, but the rest of it should be predicted.
Determinism is nice for some things (replays, validation, etc.) but it's an extremely difficult thing to do if you haven't designed for it from day one.
In many cases you don't need to predict anything, but can hide the latency anyway. eg. Start a player attack animation as soon as the player clicks on the target, but only show the damage information when the client receives it from the server.
In my opinion the only cases where you really need to try running simulations in parallel are at 2 ends of the gaming spectrum - twitch games like shooters where every millisecond counts, and strategy games where it's imperative that everybody has the same data but there is too much data to send. Beyond that, a simple interpolation layer on the movement is usually enough.
I'm having a problem figuring out how to deal with syncing creation of entities. Suppose you have an important entity like an arrow where it wouldn't be acceptable to wait for the server response before you fire the arrow. How can the client predict this locally? At first I thought, oh, just create a temporary entity and when the server acknowledges it, use the ID the server assigned so it can be synced. But then how do you match up that entity with the one the server will create when it processes the player's "fire" command?
