#Quake 3 update
This results in a FULL update since every single field is sent to the NetChannel. Since this is the first udpate, there are no valid snapshot in Client1 history so the engine is going to use the "Dummy snapshot" where all fields are always ZEROed.Master gamestate is copied at index 0 in Client1 history: It is now called"Snapshot1".This is what we can see in the next drawing: Copy the Master gamestate in the next Client history slot.In order to generate a message the network module will ALWAYS do the following : It is now time to propagate the state to Client1: They have impacted the Master gamestate (in green). The Server has received a few updates from every client. Communication are done over UDP/IP: Those messages gets lost quite often on the internet.The server is attempting to propagate the state of Client2 which has four 4 fields (3 ints position, position, position and one int health).The server is sending update to a Client1.In order to understand the snapshop system, here is an example with the following conditions: Trivia : To keep so many gamestate for each players consumes a lot of memory: 8 MB for 4 players according to my measurements. When the server decides to send an update to a client it uses each three elements in order to generate a message that is then carried over the NetChannel. This is used to delta snapshots when there is no "previous state" available. The server also features a "dummy" gamestate with every single field set to zero.The array cycle with the famous binary mask trick I mentioned in Quake World Network ( Some elegant things). For each Client the server keeps the 32 last gamestate sent over the network in a cycling array: They are called snapshots.They are transformed in event_t which will modifiy the state of the game when they arrive on the Server. Clients send theirs commands on the Netchannel. A Master Gamestate that is the universal true state of things.This mechanism features three key elements: The Server side is as bit more complex since it has to propagate the Master gamestate to each Client while accounting for lost UDP packets. The Client side of the network model is fairly simple: Client sends commands to the Server each frame and receive update for the gamestate. Compression with pre-computed huffman key.īut where the design really shine is on the server side where an elegant system minimize the size of each UDP datagram whileĬompensating for the unreliablity of UDP:Īn history of snapshots generate deltas packets via memory introspection.The network stack has been augmented with two mutually exclusive layers: In a fast paced environment any information that is not received on first transmission is not worth sending again because it will be too old anyway.Īs a result the engine relies essentially on UDP/IP: There is no trace of TCP/IP anywhere since the "Reliable transmission"Īspect introduced intolerable latency. The most important thing to understand is: With the NetChannel module that first appeared in Quake World. At the lower level Quake III still abstract communications The network model of Quake3 is with no doubt the most elegant part of the engine.
#Quake 3 code
JQuake 3 Source Code Review: Network Model (Part 3 of 5) >