Quote:

you don't have to sacrifice instant reaction time for a consistent and smooth simulation

What you are doing is sacrificing global consistency for snappier response time -- that's what I suggested as the "more complicated" option. You relax the constraint to say that "any path taken by one player is taken by that players avatar on all other machines, but not in sync with all other entities that player sees."

The draw-back is that the relative locations of player entities will be different on different machines, so you can't run player<->player interactions in tandem on all machines.

In practice you are only in an inconsistent state for a short time -- ie only when the player's input disagrees with the server or client extrapolated position for that player. In an RPG, where you click on a destination position, you can rapidly interpolate the remote client players' positions to their "correct" positions when the server notifies the client that remote players have submitted new destination positions. So you still get the benefit of a consistent world view, but it feels substantially snappier.

Quote:

Original post by markf_gg In practice you are only in an inconsistent state for a short time -- ie only when the player's input disagrees with the server or client extrapolated position for that player. In an RPG, where you click on a destination position, you can rapidly interpolate the remote client players' positions to their "correct" positions when the server notifies the client that remote players have submitted new destination positions. So you still get the benefit of a consistent world view, but it feels substantially snappier.

If you snap remote entities to their predicted locations when you get the update, then you will be in sync after each snap, assuming that nobody else is just issuing a command, too. However, this does mean that you have to go back and re-simulate the path the player should have traveled during that time, so each time you receive a command from anyone else, you have to re-simulate an amount of time that is (Your Ping + His Ping)/2. And, because you may have interacted/collided with other entities during that time, you have to re-simulate anything that can have intersected the union of the volume affected by the previously predicted movement, and the actual movement. This starts sucking down the ol' CPU once you start scaling up.

So, you have inconsistent display after each command issued by each other player, until you "catch up", which may take shorter or longer time based on how smooth you want the movement to be. For an RPG, player<->player interaction/collision might actually not even be desired; in that case, use lots of smoothing, and don't care about the inconsistencies.

With this method, there's a trade-off between, on one hand, command lag and totally consistent world view, and, on the other hand, re-simulation and termpoarily inconsistent world views, and/or seeing a smoothed, non-consistent view.