Entity Movement Extrapolation

Client Side Entity Movement Extrapolation

Replace or at least extend the current client side interpolation of entity movements by an extrapolation based on forces, momentums, masses, velocity and position.

Benefits:

The Q2 client interpolates entity movement between current and previous svc_frame per client refresh, but only for FRAMETIME of 0.1 seconds. The client should get information to extrapolate instead of interpolate. There are two possibilities:

interpolate for 0.1 seconds, extrapolate after
extrapolate immediately

I favour the latter. My goal is to introduce a simple Dead Reckoning to Q3. It is probably not useful to make rather involved changes only to piggyback another mechanism on the existing (and working) one.

There are several benefits with respect to making Q3 a more fast paced game.

no stop of entity movement when an svc_frame update is delayed for more than 0.1 seconds.
if only extrapolation, no interpolation is used, another 100msecs effective roundtrip latency is removed. Currently, the Q2 client withholds the information it receives in svc_frame for another 100msecs from the player.
client does not require any knowledge of FRAMETIME, and will be completely input driven, thus scalable at runtime.
snap correction on reception of a delayed svc_frame event might be smaller for extrapolated movements than for stopped movements. Inertia works in your favour with ballistics.

Problems:

This requires a more generic setup of entity_state_t to provide the necessary information for extrapolation, and a different way of thinking about movement generation - that is, on the basis of forces applied instead of offsets and velocities added. Within a server update, the current processing can be kept. The changes are related to the ones also required to a more generic client side prediction

Particular problems:

snaps might be worse than currently. Interpolation guarantees smoothness at expense of 100msec lag, extrapolation provides most recent data or a good guess at the expense of more or less visible corrections.
it is not obvious to the player that she is lagged - it is obvious when everything but the POV freezes. This might lead to confusion, which can be adressed by a Turtle icon display.
extrapolation is usually more expensive than interpolation, a performance penalty will occur.
extrapolation can be made near perfect for server-controlled entities, but the snap artifacts might be unacceptable for client-controlled entities (other players). If such a client entitiy falls, or is otherwise involuntarily moved without means to interfere, extrapolation will work flawlessly. If the client entity is moved by user inputs, the latency introduced from that client to the server to the observing client might add snaps.
additional collision detection or, alternatively, new artifacts. Events like an entitity penetrating a wall were not possible with interpolation as the client was always working towards a valid position along a valid path.

Feasibility:

The reworking of the client side handling, and DLL handling, of entities is a bit involved. The gains might be negligible and not warrant the effort, except that a technique like this should at least be tried once. Future games might benefit from improved network bandwidth, but game complexity, additional features (voice over network) and increasing number of players will keep the constraint present. Further, this is a bandwidth issue only with respect to sampling (half the FRAMETIME means double bandwidth). Roundtrip latency will still be present, and is much harder to decrease than it is to increase bandwidth. The idea is that the player should be exposed to the latest info from the server ASAP.

Implementation:

the entity_state_t has to be changed to provide first, second, and third order information on movement and orientation.

   short  position[3];
   short  velocity[3];
   short  accel[3];           

   short  orientation[4];       // quaternion
   short  angular_vel[4];
   short  angular_acc[4];

Within the svc_frame updates for the entity, the following data should also be present needed:

   short  mass;        // scales forces to acceleration
   short  inertia;     // scales momentums to angular acc.
   short  force[3];    // current forces
   short  momentum[4]; // current momentum

network protocol for svc_frame related transmissions with respect to entity state has to be changed to provide the information above.
extrapolation has to be tied to wall clock time for client refresh frames
client side entitiy movement now may have to be subject to the same clission detection and push/stop collision response as used in client side prediction of POV movements. The code is there, but applying this to all visible entities adds a performance penalty. Ignoring it could lead to artifacts within the FRAMETIME scale: entity penetrates wall, snaps back on server correction. Such events were not possible with interpolation as the client was always working towards a valid position along a valid path.

There is no need to provide the elapsed time from the last update, or keep a particular timing with svc_frame anymore, as the correction will simply override the current state.

Related Proposals:

Applies the same approach as Generic Client Side Prediction. Actually, both could be implemented in one unified module.

The actual difference for the player might be negligible here, one way or the other - the new artifacts are not so bad, the improvements are not really visible. It might just be a matter of philosophy - do you try to provide the player a feedback as fast as possible, or one looking as smooth as possible. Neither will be accurate, but one looks better - ultimately, the question is: which one plays best?

Could be partly rendered obsolete when the client side handling of entity movement is exposed in a Client Side DLL.

Submitted 980328, revised 980307, revised 980320 comments to bk@gamers.org.