It's 13+ minutes long. So I'll do my best to explain it here as well.
In online game play, do shared objects of motion have a path that is based on a function (this function being defined upon the creation of the object considering the factors associated with motion; gravity, wind, weight, etc) as opposed to a path that is persistently being updated by re-applying the defined laws of physics every "step/moment/frame" during game play.
After some thought, I think this is the standard & most effective way of determining a path.
Here are two more videos expanding on the concept.
The final additional video is about when NOT to use this method because the creation of the function is far too expensive in comparison to re-checking with the server just for 3 simple variables. http://www.youtube.com/watch?v=50ZJvVRknwE
(sorry did not watch the videos) All depends on what you are trying to do with the interactive objects as to what type of movement methods you use. Do you have a specific project in mind?
For the Unreal Engine:
1. Player Controlled Pawns, which basically move randomly based on player's inputs: The player controlling the pawn generates the new acceleration vector and rotation based on keys being pressed, jumping etc. and sends this to the server. Both the server's copy of the pawn and the controlling players version use the acceleration to figure out the new velocity direction, apply per frame/tick and move the pawn (deltatime * velcoity = change in position) (does collision checks etc.). If the server detects some obstruction that would prevent movement (say colliding with some other fast moving object that was not yet "network relevant" to the original controlling client), the resulting difference in movement may cause there to be a location difference between the server's copy and where the client moved their copy of the pawn. If enough of an error is detected (something like greater than 3 UUs in UT2k4), the servers sends a client adjustment back down to the controlling client who then replays some moves and is adjusted to the server's position. Non-controlling clients are only fed some very basic info about other pawns: rotation, location and velocity. Non-controlling clients still simulate movement of the other pawns using the last received location/rotation/velocity information (that is why it looks like other pawns are sliding around sometimes if the latency is high, since it is starved for movement updates it just uses the last info received to continue locally simulating physics).
2. For other actor subclasses (decorations, weapon pickups, anything else that can move), the logic to figure out which direction to move is *usually* only executed on the server. Depending on the actor's RemoteRole, the clients may simulate the movement of the things locally using the last received update on velocity and location, or may only update position when they receive a data update (look really jittery).
The frequency of how often actors/pawns etc are updated is based on the overall network latency, and a few variable settings (netUpdateFrequency, NetPriority, NetUpdateTime). These typically affect how smooth the updates look.
If the movement is pretty restricted (like movement along a track, or with fixed/non-changing force vectors like wind) then you can probably get pretty tight with positional differences by only replicating a float that corresponds to the fraction of the length of the path, and a float for the velocity along it (then give the client simulated code to figure out the "inbetween data updates" position on its own, maybe even take into account the ping latency).