Hello,
At 18:01 29/05/2012, you wrote:
That's interesting; you may have a lot of lag but still enough
bandwidth to push through 60 input states per second.
I can imagine with 500ms ping, the delay of moving a tennis player
around can cause a miss when striking the ball.
So how do you handle the moving tennis ball? Does it move the same
(the same time) on both clients, or is there some sort of lag
between what one client is seeing vs the other?
Do you also send 60 pkt/sec with the ball position? I'd expect a lot
of jerks when trying to update the ball like that; you'd need a bit
of filtering to avoid timing issues and have a jittering ball on the screen.
There are 2 levels of processing : the input delay, and the prediction.
The game runs in parallel on both PCs, and basically, each game sees
the same than if both players were physically on the PC, playing with
2 gamepads (for example). So only the local input (pad direction &
fire buttons) is sent to the distant PC, from each PC. No other game
related information is sent (except at game start, to ensure the
initial states match on both PC ; and during the game some other
little infos are sent to know if the games are still in sync).
But as one player is distant, the trick to make it work is to delay
the local input until the distant input is received. This delay must
be fixed and cannot be different between the 2 PCs : this is the main
downside of this technique. It means if the fixed delay is under the
actual latency, then the game will pause and wait to receive the
distant input. You can adapt the delay to the conditions, though, but
it's not as easy & convenient than in a standard client/server
configuration as it must be done on both PCs on the exact same game frame.
This technique is commonly used for RTS game network code (with some
variants), where the maximum number of players is not too high.
So at 500ms ping, that requires at least 250ms input delay to make
the game runs normally.
It means that your player starts to move 250ms after you actually
pressed the movement key. Which is totally unplayable... ;) I know
well because the game used to be only that, without prediction, and
the maximum enjoyable delay was around 100ms.
So above that, I added a prediction module.
It's always possible to predict our player movement, as all the local
input in stocked locally and can be used to know where our player will go.
We can predict a bit our opponent movement, by using any input packet
already arrived, and by predictable behavior (for example : he will
usually run to the ball), but this prediction can be wrong often, so
I can't push it too much, and I smooth the distant player's
coordinates over several frames to avoid jerkiness when prediction
went wrong ; so in average the perceived latency on the distant
player movement for the local gamer's eyes will be usually around
125ms. It's not great, but it's good enough to give an enjoyable
online experience.
It's always possible to predict where the ball will go, as it's
deterministic, except after our opponent hits it, coz we won't know
for sure where he sent it before the next 250ms. So here, I need to
predict where the distant player will aim and as it's not always
possible to do it exactly, the ball will jerk sometimes a bit between
the wrongly predicted position and its real position that will be
known once all 250ms of input will be received.
_______________________________________________
ENet-discuss mailing list
[email protected]
http://lists.cubik.org/mailman/listinfo/enet-discuss
