Multiplayer games based on the Source Engine use a Client-Server networking architecture. Usually a server is a dedicated host that runs the game and is authoritative about world simulation, game rules, and player input processing. A client is a player's computer connected to a game server. The client and server communicate with each other by sending small data packets at a high frequency (usually 20 to 30 packets per second). A client receives the current world state from the server and generates video and audio output based on these updates. The client also samples data from input devices (keyboard, mouse, microphone, etc.) and sends these input samples back to the server for further processing. Clients only communicate with the game server and not between each other (like in a peer-to-peer application). In contrast with a single player game, a multiplayer game has to deal with a variety of new problems caused by packet-based communication.
Network bandwidth is limited, so the server can't send a new update packet to all clients for every single world change. Instead, the server takes snapshots of the current world state at a constant rate and broadcasts these snapshots to the clients. Network packets take a certain amount of time to travel between the client and the server (i.e. half the ping time). This means that the client time is always a little bit behind the server time. Furthermore, client input packets are also delayed on their way back, so the server is processing temporally delayed user commands. In addition, each client has a different network delay which varies over time due to other background traffic and the client's framerate. These time differences between server and client causes logical problems, becoming worse with increasing network latencies. In fast-paced action games, even a delay of a few milliseconds can cause a laggy gameplay feeling and make it hard to hit other players or interact with moving objects. Besides bandwidth limitations and network latencies, information can get lost due to network packet loss.
To cope with the issues introduced by network communication, the Source engine server employs techniques such as data compression and lag compensation which are invisible to the client. The client then performs prediction and interpolation to further improve the experience.
The server simulates the game in discrete time steps called ticks. By default, the timestep is 15ms, so 66.666... ticks per second are simulated, but mods can specify their own tickrate. During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary. A higher tickrate increases the simulation precision, but also requires more CPU power and available bandwidth on both server and client. The server admin may override the default tickrate with the command line parameter, though tickrate changes done this way are not recommended because the mod may not work as designed if its tickrate is changed.
Clients usually have only a limited amount of available bandwidth. In the worst case, players with a modem connection can't receive more than 5 to 7 KB/sec. If the server tried to send them updates with a higher data rate, packet loss would be unavoidable. Therefore, the client has to tell the server its incoming bandwidth capacity by setting the console variable (in bytes/second). This is the most important network variable for clients and it has to be set correctly for an optimal gameplay experience. The client can request a certain snapshot rate by changing (default 20), but the server will never send more updates than simulated ticks or exceed the requested client limit. Server admins can limit data rate values requested by clients with and (both in bytes/second). Also the snapshot rate can be restricted with and (both in snapshots/second).
The client creates user commands from sampling input devices with the same tick rate that the server is running with. A user command is basically a snapshot of the current keyboard and mouse state. But instead of sending a new packet to the server for each user command, the client sends command packets at a certain rate of packets per second (usually 30). This means two or more user commands are transmitted within the same packet. Clients can increase the command rate with . This will increase responsiveness but requires more outgoing bandwidth, too.
Game data is compressed using delta compression to reduce network load. That means the server doesn't send a full world snapshot each time, but rather only changes (a delta snapshot) that happened since the last acknowledged update. With each packet sent between the client and server, acknowledge numbers are attached to keep track of their data flow. Usually full (non-delta) snapshots are only sent when a game starts or a client suffers from heavy packet loss for a couple of seconds. Clients can request a full snapshot manually with the command.
Responsiveness, or the time between user input and its visible feedback in the game world, are determined by lots of factors, including the server/client CPU load, simulation tickrate, data rate and snapshot update settings, but mostly by the network packet traveling time. The time between the client sending a user command, the server responding to it, and the client receiving the server's response is called the latency or ping (or round trip time). Low latency is a significant advantage when playing a multiplayer online game. Techniques like prediction and lag compensation try to minimize that advantage and allow a fair game for players with slower connections. Tweaking networking setting can help to gain a better experience if the necessary bandwidth and CPU power is available. We recommend keeping the default settings, since improper changes may cause more negative side effects than actual benefits.
Servers that Support Tickrate
The tickrate can be altered by using the parameter
- Counter Strike: Global Offensive
- Half-Life 2: Deathmatch
The following servers tickrate cannot be altered as changing this causes server timing issues.
- Counter Strike: Source
- Day of Defeat: Source
- Team Fortress 2
- Left 4 Dead
- Left 4 Dead 2
By default, the client receives about 20 snapshot per second. If the objects (entities) in the world were only rendered at the positions received by the server, moving objects and animation would look choppy and jittery. Dropped packets would also cause noticeable glitches. The trick to solve this problem is to go back in time for rendering, so positions and animations can be continuously interpolated between two recently received snapshots. With 20 snapshots per second, a new update arrives about every 50 milliseconds. If the client render time is shifted back by 50 milliseconds, entities can be always interpolated between the last received snapshot and the snapshot before that.
Source defaults to an interpolation period ('lerp') of 100-milliseconds (); this way, even if one snapshot is lost, there are always two valid snapshots to interpolate between. Take a look at the following figure showing the arrival times of incoming world snapshots:
The last snapshot received on the client was at tick 344 or 10.30 seconds. The client time continues to increase based on this snapshot and the client frame rate. If a new video frame is rendered, the rendering time is the current client time 10.32 minus the view interpolation delay of 0.1 seconds. This would be 10.22 in our example and all entities and their animations are interpolated using the correct fraction between snapshot 340 and 342.
Since we have an interpolation delay of 100 milliseconds, the interpolation would even work if snapshot 342 were missing due to packet loss. Then the interpolation could use snapshots 340 and 344. If more than one snapshot in a row is dropped, interpolation can't work perfectly because it runs out of snapshots in the history buffer. In that case the renderer uses extrapolation () and tries a simple linear extrapolation of entities based on their known history so far. The extrapolation is done only for 0.25 seconds of packet loss (), since the prediction errors would become too big after that.
Entity interpolation causes a constant view "lag" of 100 milliseconds by default (), even if you're playing on a listenserver (server and client on the same machine). This doesn't mean you have to lead your aiming when shooting at other players since the server-side lag compensation knows about client entity interpolation and corrects this error.
Lets assume a player has a network latency of 150 milliseconds and starts to move forward. The information that the key is pressed is stored in a user command and send to the server. There the user command is processed by the movement code and the player's character is moved forward in the game world. This world state change is transmitted to all clients with the next snapshot update. So the player would see his own change of movement with a 150 milliseconds delay after he started walking. This delay applies to all players actions like movement, shooting weapons, etc. and becomes worse with higher latencies.
A delay between player input and corresponding visual feedback creates a strange, unnatural feeling and makes it hard to move or aim precisely. Client-side input prediction () is a way to remove this delay and let the player's actions feel more instant. Instead of waiting for the server to update your own position, the local client just predicts the results of its own user commands. Therefore, the client runs exactly the same code and rules the server will use to process the user commands. After the prediction is finished, the local player will move instantly to the new location while the server still sees him at the old place.
After 150 milliseconds, the client will receive the server snapshot that contains the changes based on the user command he predicted earlier. Then the client compares the server position with his predicted position. If they are different, a prediction error has occurred. This indicates that the client didn't have the correct information about other entities and the environment when it processed the user command. Then the client has to correct its own position, since the server has final authority over client-side prediction. If is turned on, clients can see when prediction errors happen. Prediction error correction can be quite noticeable and may cause the client's view to jump erratically. By gradually correcting this error over a short amount of time (), errors can be smoothly corrected. Prediction error smoothing can be turned off with .
Prediction is only possible for the local player and entities affected only by him, since prediction works by using the client's keypresses to make a "best guess" of where the player will end up. Predicting other players would require literally predicting the future with no data, since there's no way to instantaneously get keypresses from them.
- All source code for lag compensation and view interpolation is available in the Source SDK. See Lag compensation for implementation details.
Let's say a player shoots at a target at client time 10.5. The firing information is packed into a user command and sent to the server. While the packet is on its way through the network, the server continues to simulate the world, and the target might have moved to a different position. The user command arrives at server time 10.6 and the server wouldn't detect the hit, even though the player has aimed exactly at the target. This error is corrected by the server-side lag compensation.
The lag compensation system keeps a history of all recent player positions for one second. If a user command is executed, the server estimates at what time the command was created as follows:
Command Execution Time = Current Server Time - Packet Latency - Client View Interpolation
Then the server moves all other players - only players - back to where they were at the command execution time. The user command is executed and the hit is detected correctly. After the user command has been processed, the players revert to their original positions.
On a listen server you can enable to see the different server and client hitboxes:
This screenshot was taken on a listen server with 200 milliseconds of lag (using ), right after the server confirmed the hit. The red hitbox shows the target position on the client where it was 100ms + interp period ago. Since then, the target continued to move to the left while the user command was travelling to the server. After the user command arrived, the server restored the target position (blue hitbox) based on the estimated command execution time. The server traces the shot and confirms the hit (the client sees blood effects).
Client and server hitboxes don't exactly match because of small precision errors in time measurement. Even a small difference of a few milliseconds can cause an error of several inches for fast-moving objects. Multiplayer hit detection is not pixel perfect and has known precision limitations based on the tickrate and the speed of moving objects.
The question arises, why is hit detection so complicated on the server? Doing the back tracking of player positions and dealing with precision errors while hit detection could be done client-side way easier and with pixel precision. The client would just tell the server with a "hit" message what player has been hit and where. We can't allow that simply because a game server can't trust the clients on such important decisions. Even if the client is "clean" and protected by Valve Anti-Cheat, the packets could be still modified on a 3rd machine while routed to the game server. These "cheat proxies" could inject "hit" messages into the network packet without being detected by VAC (a "man-in-the-middle" attack).
Network latencies and lag compensation can create paradoxes that seem illogical compared to the real world. For example, you can be hit by an attacker you can't even see anymore because you already took cover. What happened is that the server moved your player hitboxes back in time, where you were still exposed to your attacker. This inconsistency problem can't be solved in general because of the relatively slow packet speeds. In the real world, you don't notice this problem because light (the packets) travels so fast and you and everybody around you sees the same world as it is right now.
The Source engine offers a couple of tools to check your client connection speed and quality. The most popular one is the net graph, which can be enabled with (or ). Incoming packets are represented by small lines moving from right to left. The height of each line reflects size of a packet. If a gap appears between lines, a packet was lost or arrived out of order. The lines are color-coded depending on what kind of data they contain.
Under the net graph, the first line shows your current rendered frames per second, your average latency, and the current value of . The second line shows the size in bytes of the last incoming packet (snapshots), the average incoming bandwidth, and received packets per second. The third line shows the same data just for outgoing packets (user commands).
The default networking settings are designed for playing on dedicated server on the Internet. The settings are balanced to work well for most client/server hardware and network configurations. For Internet games the only console variable that should be adjusted on the client is "rate", which defines your available bytes/second bandwidth of your network connection. Good values for "rate" is 4500 for modems, 6000 for ISDN, 10000 DSL and above.
In an high-performance network environment, where the server and all clients have the necessary hardware resources available, it's possible to tweak bandwidth and tickrate settings to gain more gameplay precision. Increasing the server tickrate generally improves movement and shooting precision but comes with a higher CPU cost. A Source server running with tickrate 100 generates about 1.5x more CPU load than a default tickrate 66. That can cause serious calculation lags, especially when lots of people are shooting at the same time. It's not suggested to run a game server with a higher tickrate than 66 to reserve necessary CPU resources for critical situations.
If the game server is running with a higher tickrate, clients can increase their snapshot update rate (cl_updaterate) and user command rate (cl_cmdrate), if the necessary bandwidth (rate) is available. The snapshot update rate is limited by the server tickrate, a server can't send more then one update per tick. So for a tickrate 66 server, the highest client value for cl_updaterate would be 66. If you increase the snapshot rate and encounter packet loss or choke, you have to turn it down again. With an increased cl_updaterate you can also lower the view interpolation delay (cl_interp). The default interpolation delay is 0.1 seconds, which derives from the default cl_updaterate 20. View interpolation delay gives a moving player a small advantage over a stationary player since the moving player can see his target a split second earlier. This effect is unavoidable, but it can be reduced by decreasing the view interpolation delay. If both players are moving, the view lag delay is affecting both players and nobody has an advantage.
This is the relation between snapshot rate and view interpolation delay is the following:
interpolation period = max( cl_interp, cl_interp_ratio / cl_updaterate )
"Max(x,y)" means "whichever of these is higher". You can set to 0 and still have a safe amount of interp. You can then increase cl_updaterate to decrease your interp period further, but don't exceed tickrate (66) or flood your connection with more data than it can handle.
- Don't change console settings unless you are 100% sure what you are doing
- Most "high-performance" setting cause exactly the opposite effect, if the server or network can't handle the load.
- Don't turn off view interpolation and/or lag compensation
- It will not improve movement or shooting precision.
- Optimized setting for one client may not work for other clients
- Do not just use settings from other clients without verifing them for your system.
- If you follow a player in "First-Person" as a spectator in a game or SourceTV, you don't exactly see what the player sees
- Spectators see the game world without lag compensation.
A reload is a seconds-long sideshow of watching ammo numbers go back up, a firearm equivalent of off a blade. Whether it’s the snappy accuracy of a mil-sim mag swap or feeding vomit balls to a living rocket launcher, reload animations are testament to the artistic prowess of personalizing a ubiquitous aspect of shooters. In alphabetical order, here’s some of the best reload animations on PC.
Battlefield 1 - Gewehr 98
Battlefield’s reloads mix function with form to spruce up each kit’s arsenal without straying too far into prolonged five-finger theatrics. The bolt-action rifles have satisfyingly crisp rechambering sequences, and it’s wonderful picking out DICE’s split-second touches on the older weapon design. The left hand of this Gewehr 98 sniper clamping over the rifle’s port to prevent an unspent bullet from flying out as he cycles the bolt to reload is a fine example.
Battlefield 1 - Kolibri
Behold the pee-wee Kolibri, the tiniest sidearm in a game filled with bulky, ancient MGs and hulking tanks. This novelty pistol has perhaps daintiest reload animation in gaming history. Swapping a magazine smaller than some caterpillars (the slight wiggle before the magazine enters its housing is a hilarious nudge) perfectly accompanies the sophistication of the pinky, ring, and middle fingers raised at maximum teacup clearance.
Battlefield 4 - AK-12
Diverging from typical FPS fare of tilting the gun sideways for a clearer view of a reload, Battlefield 4’s AK-12 instead scores points for sticking with the realism of a trained military soldier dispensing with unnecessary movements. Note the forward-facing angle during the entire animation—this keeps the barrel’s business end pointed at the enemy—and the support hand curving beneath the grip to rack the charging handle and keep the firing hand near the trigger.
(gif via )
Battlefield 4 - AN-94
The AN-94 provides another AK-style reload with a much flashier “mag-pop” sequence that both seems terribly wasteful and oddly celebratory at the same time, almost as if it’s the gun version of .
(gif via )
Battlefield 4 - Unica 6
Catching one of DICE’s handful of easter-egg reload animations guarantees a double-take and that special feeling of accomplishment for triggering the fabled 1-in-10,000 probability. The Unica 6 secret reload is one of the earliest recorded from Battlefield’s community, and it holds a special place of honor for its ridiculous speedloader flick and follow-up cartridge comfort pat.
Battlefield Hardline - .410 Jury
Battlefield Hardline boasts plenty of hidden reload animations seemingly trying to upstage each other with . with powerful criminal magic is impressive enough, but it’s hard to top the mesmerizing smoothness of the twirling .410 Jury and its gunslinger savant performing some extremity ballet.
(gif via )
BioShock - Grenade Launcher
Everyone’s favorite objectivist dystopia beneath the sea is a playground of art-deco architecture and hybrid steampunk weaponry—and then there’s the Grenade Launcher which looks like something the Home Alone kid slapped together in his garage. Its rough reload gives weight to its explosive power; you practically break the thing in half to shove in another coffee can’s worth of grenades into its metal gullet.
Borderlands 2 - Tediore
Borderlands 2's zillion guns follow a small pattern of reload animations based on each manufacturer. For Tediore, it involves chucking the entire gun like a slab of beef (with obligatory explosion) before generating a new one right in your hands. And yes, there’s entire character builds centered on .
Call of Duty: Black Ops - G11
The few prototype guns found in Black Ops’ Cold War-era arsenal are a refreshing change from the cookie-cutter animations pasted across nearly every Call of Duty, and the G11 assault rifle nails that conceptual feeling best with its caseless rod reload and cocking handle crank that wouldn’t look out of place on a windup toy.
(gif via )
No single weapon in Crysis 2 sports an interesting reload, but each Nanosuit mode changes how Prophet rearms himself with suitably subtle animation changes. If you’re in power mode, you’ll slam in magazines with gusto and cock the handle with a firm grip. In stealth mode, you’ll more gingerly swap magazines and slowly bring back the handle so it makes less noise. Maximum context.
Counter-Strike 1.6 - M4
Surprising detail and nuance, for the time. The classic one-two of the open-palm mag-tap and fantastically inaccurate forward assist yank was a common occurrence when spectating a CT victory during those binge nights when homework was finished early.
Doom 2 - Super Shotgun
The only new weapon in Doom 2 was a powerhouse of a double-barrel shotgun with a big boom and a framey click-clack reload that’s music to a shooter grognard’s ears. You could've switched back to the original pump-action and saved some ammo, but you didn't.
Far Cry 3: Blood Dragon - Galleria 1991
Picking out a single example from Blood Dragon’s neon hallucination was almost as impossible as questioning Rex Colt’s sense of subtlety, but the Galleria 1991’s extra flair of casually tossing in shells is too excellent a combo to pass up.
Far Cry 4 - M-700
Carried from Far Cry 3 into the mountains of Kyrat, the M-700 is a plain but reliable sniper rifle favored for stealth-inclined players. Its reload is far more interesting with its abundant use of left-side screen space as the gun traverses across your monitor and back.
(gif via )
Half-Life: Opposing Force - Spore Launcher
Shepherd’s logical action of picking up a baby of those creatures from another dimension trying to kill him gives us this Half-Life memento of an impromptu feeding session followed by—what else?—deadly vomit.
Killing Floor 2 - Dual 1858 Revolvers
The gun nuts at Tripwire earned their reputation as reload wizards from Red Orchestra’s authenticity, and Killing Floor 2’s high-fps, motion-captured animations are . The Gunslinger’s dual reloads pack so much refinement, the above GIF had to be slowed down to more easily observe the entire reload from start to finish. Nearly every other reload style is a blast to watch, a popular favorite being the smooth for rifles and SMGs.
Max Payne 2
With enough kills chained during Bullet Time, Max whirls into a camera-orbiting move that’s less of a traditional reload and more of a sudden urge to pirouette his pain away. Still, it’s a stylish ode to Payne’s cinematographic influences, especially if you keep “Ave Maria” playing in your head the entire time.
Max Payne 3
Rockstar gleefully embellished Max’s gun-fu in his third killing spree, with the best animated touches emphasizing Max’s familiarity at juggling a small armory of guns. Reloading a one-handed gun while holding a two-handed weapon in the offhand is one of the best displays from the world-weary monologuer, as he tucks the bigger gun beneath his arm to free up his hand to change magazines.
Metro: Last Light - Shambler
The ramshackle design of Metro’s arsenal is already a pleasure to behold, but the Shambler shotgun’s revolver-style reload is one of the most unique of the series. The small toss between Artyom’s left and right hands as he feeds a shell into each clamp is a dash of detail and personality.
(gif via )
Overwatch - Torbjörn's Rivet Gun
Blizzard’s penchant for polish is on display in Overwatch’s reloads. Most of the cast would be right at home in this gallery, such as Torbjorn’s screen-spanning scrap refill, the only time I can think of molten liquid being poured into a gun.
PlanetSide 2 - Commissioner
The powerful Commissioner revolver is a trusty companion in PlanetSide 2’s massive warzones, and its split cylinder reload and automated spin bring that subsequent thrill of badassery after some bullseye frags.
Postal 2 - Beta Shotgun
The well-known of Postal Dude elegantly shoving a fistful of shells into his awaiting shotgun embodies creative reload animations dispensing with silly real-world rules such as gravity and jams. The animation’s absurdity is even better experienced firsthand in the thick of Postal 2’s chaos, so definitely grab either the DLC or the to see it for yourself.
Resident Evil 4 - Broken Butterfly
Console players have long recognized Leon Kennedy’s reloads in Resident Evil 4 as those of an expert zombie slayer, and the 2007 PC port brought his expertise into sharper detail. The Broken Butterfly revolver is a top pick; Leon’s nonchalant no-eyes-needed head tilt as he dumps out the cartridges and the almost lazy-looking single-bullet toss into the cylinder are just pure awesome.
(gif via )
Rise of the Triad - Dual Pistols
The challenge of animating an elaborate akimbo reload is smartly executed in Rise of the Triad, a fantastic world where air resistance is a myth and wrist strength reaches mutant levels.
Shadow Warrior 2 - Springchester
A lever-action flip might be passé by now, but Shadow Warrior 2’s Springchester exaggerates the pull-flip sequence so strongly that it's a wonder Wang isn't ducking for cover on the backswing.
(gif via )
Squad - M4
With all the arsenal acrobatics, it's nice to sometimes plug some realism back into restoring ammo to a weapon. This M4 reload from Squad reinforces the no-frills approach and the professionalism of the soldiers you play as therein, particularly with the confident-looking hand movements and double-check of the ejection port for a clean mag transition.
Titanfall 2 - 40mm Cannon
The Titans of Titanfall 2 are massive robots shooting equally massive guns, but their reloads pleasingly mirror human hand movements at a bigger scale. I love the small gears spinning open the ammo box housing and the slight jiggle of the barrel cover responding to the charge handle slamming forward.