Next
Previous
Contents
There are four major sub-components. The Game Subsystem
(QGS) and the the server side client system are both run
by the server process. The client side prediction (CSP)
and the refresh subsystem are both run by the client.
There are four different loops, one in each subsystem,
which respond to events and changes.
We will mostly ignore the refresh subsystem and loop run
by the client process for this discussion, as it
simply samples the client side image of the world
state.
There are four different images of the world state:
- Game Subsystem world state, full detail,
authorative.
- server side client system world state,
already simplified to what is needed
with respect to network transmission to
the client.
- client side prediction world state,
based on the network transmission from
the server, simplified and extrapolated.
- snapshot image used by client side refresh
subsystem, only refresh-relevant data
from the CSP created image.
The QSP process ticks away at 10Hz, at each Game Tick
calling the Game Subsystem. The Game Subsystem
updates the master copy or master image of the
world state, in full detail.
This master image is exposed to the server process
to a limited extend (see DLL documentation).
The following data is seen by the server: NOT DONE.
Theoretically the server would just tick away and
send ??? updates at 10Hz, in the absence of any
client responses (see timeouts???).
The overall game loop, server side, should
look like this:
- The server executes the game system every FRAMETIME
to update the authorative world state, calling
g_main.c::G_RunFrame as set by game_export_t.
- The server transmits the entity_state_t and
player_state_t data to the client every FRAMETIME.
- The client overrides the ???current pmove_state
with the new one, and resets the CSP.
The server side client system is driven by network
packets indicating that the client executed its
CSP. The server tries to saty in sync
with the way the client processes user inputs
as much as possible, to minimize the artifacts
resulting from POV snapping.
- The client sends a
svc_frame
packet
once it executs a refresh.
- The server executes the server side client system
by calling p_client::ClientThink. It effectively
runs this at client side refresh rates, separately
for each client. The server
side client system creates pmove_state_t records
and ???what?
- The server ???transmits the pmove_state_t records
???and what? to the client ???in response?
- The client does ???what with pmove_state_t???
Updates ?CSP???
- The client uses predictions at framerate to
compensate for roundtrip latency.
Next
Previous
Contents