Rewinding Time:
https://www.scirra.com/tutorials/892/mu ... ge-8#h2a18
Local Input Prediction:
https://www.scirra.com/tutorials/892/mu ... ge-7#h2a15
I can only recommend reading through the entire tutorial.
But using the Rewinding Time will ensure that the HOST is able to recalculate what the player actually saw, and handle accordingly.
Just think about it in a Shooter Game like Battlefield for instance.
What would you think if you shot someone in the head, but the server didn't recognize it?
That would kill the entire fun.
With rewinding the time, the server can recalculate the actual position of where the enemy was standing from your standpoint when you triggered the shot.
Otherwise the Host will think, the enemy was already behind the wall and you shot into the void.
With local input prediction you can ensure that the players input will be immediatly shown on their screen.
Even though the server did not even get your input as of yet.
As soon as the server recieved your input, it will sync the information back to the player, and in case the prediction was wrong, it will do some small corrections to get you back in place.
Otherwise, if you only let the players move as soon as the server responded, it will feel very very laggy for the players.
For a real-time multiplayer game.
It is KEY, to send really ONLY required information.
AND the information sent must be set as SMALL AS POSSIBLE.
More details at the bottom.
What do we want to sync?
And which ones need to be fast?
- NO client side prediction for deaths
Because if we blow up a player and then realize it was mis-prediction, we would have to bring it back together.
This would look kinda weird!
Basic Information
---------------------------------
High (double, 8 bytes):
a double-precision floating-point number that can store numbers without affecting their precision.
It has about 15-17 significant digits of precision. However it takes 8 bytes to store a single number,
which can end up increasing bandwidth requirements significantly.
In practice this is unlikely to be a necessary choice.
Normal (float, 4 bytes):
a single-precision floating-point number that can store fractional numbers with about 6-9
significant digits of precision. This means some numbers will be rounded to fewer significant digits.
However it is usually far more practical than a double, since it only takes half as many
bytes and digits beyond the first 6 are usually unimportant
(e.g. 0.333333 is close enough to 0.333333333333333 for practical purposes).
Low (int16, 2 bytes):
a signed 16-bit integer that can only store whole numbers in the range -32768 to 32767.
Very low (uint8, 1 byte):
an unsigned 8-bit integer that can only store whole numbers in the range 0 to 255.
To minimise bandwidth, it is important to choose the lowest precision possible that will
not seriously affect gameplay. For example X and Y positions can often use low (int16) precision.
As long as the layout is smaller than 32767x32767 (which is very large), and sub-pixel positions
are not important to gameplay (since this will round off any fractional value), it is perfectly
sufficient and uses four times less bandwidth than a double.
For example:
If your total of all synced data is 32bytes:
2 players = 32 x 2 x 2 = 128 bytes per update x tickrate 60 = 0,06 Mb/s (Required Upload Rate of Host)
4 players = 32 x 4 x 4 = 512 bytes per update x tickrate 60 = 0.25 Mb/s (Required Upload Rate of Host)
Even though the player count increases linearly, the bandwidth requirement increases proportional
to the square.