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
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:
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.
- interpolate for 0.1 seconds, extrapolate after
- extrapolate immediately
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
- 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.
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
- 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.
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.
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.
- the entity_state_t has to be changed to provide
first, second, and third order information on movement
short orientation; // quaternion
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; // current forces
short momentum; // 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
- 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.
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 firstname.lastname@example.org.