Guide

Game server tick rate and update rate networking systems explained

Harbor Crest shipped ranked 5v5 on a 64 Hz simulation tick with polished lag compensation and player-facing “64 tick” marketing. Yet players on 70–100 ms routes filed 47% of duel deaths as “I shot first on my screen” — not because rewind was missing, but because the server only advanced the world every 15.6 ms. Two players who fired in the same real-time window often tied on the same tick; tie-break rules silently favored lower ping. Peek windows at corners quantized: a jiggle peek that cleared cover for 8 ms between ticks was invisible to the holder’s simulation.

The refactor raised authoritative simulation to 128 Hz, added sub-tick hit sampling for fire inputs timestamped between ticks, and decoupled network snapshot send rate (64 Hz bandwidth budget) from simulation step rate. Unfair-trade support tickets fell to 9% while per-match CPU rose only 18% on the same host class. Tick rate is not a vanity badge — it is the clock that prediction, rewind, and interpolation inherit. This guide separates simulation Hz from snapshot cadence and render FPS, explains why shooters care about granularity, compares 64 vs 128 vs sub-tick designs, documents Harbor Crest’s upgrade, provides a technique decision table, pitfalls, and a production checklist alongside tactical shooter design.

Three clocks: simulation, network, and display

Players conflate “tick rate” with everything netcode does. In production you maintain three independent clocks:

Clock	What it controls	Typical competitive values
Simulation tick	Server physics step, damage resolution, round timers, economy grants	64 Hz (15.6 ms) or 128 Hz (7.8 ms)
Network snapshot rate	How often authoritative state broadcasts to clients	20–64 Hz; may be lower than simulation
Client render frame	GPU draw and local input poll; not authoritative	60–240+ FPS

Raising simulation tick tightens the server’s model of time. Raising snapshot rate tightens how fresh remote players appear. Raising render FPS only improves local responsiveness if client prediction consumes inputs every frame. Marketing “128 tick servers” should specify which clock moved — players feel simulation granularity in trades; they feel snapshot rate in enemy smoothness.

Why tick granularity matters in shooters

Hitscan weapons raycast at a point in server time. At 64 Hz, the server evaluates position and fire intent on discrete steps. Effects:

Trade resolution — simultaneous deaths within one 15.6 ms bucket need explicit tie rules; lower ping often wins by default.
Peek quantization — exposure windows shorter than one tick may never register; peekers gain or lose unfairly at corners.
Movement authority — velocity changes apply in steps; counter-strafe settle gates align to tick boundaries.
Utility timing — smoke bloom, bomb plant progress, and round phase transitions snap to ticks; UI countdowns should match server buckets.

Doubling simulation rate halves maximum temporal error before lag compensation even enters the picture. That is why competitive communities treat 128 Hz as a baseline expectation even when bandwidth stays at 64 Hz snapshots.

Tick and update rate taxonomy

Design	Simulation step	Best for	Cost / risk
30–60 Hz casual	16–33 ms	Co-op PvE, large maps, mobile	Cheap CPU; unacceptable for ranked duels
64 Hz standard	15.6 ms	Legacy CS lineage, budget hosts	Known peek/trade artifacts; well understood
128 Hz competitive	7.8 ms	Ranked tactical shooters	~2× sim CPU; diminishing returns past 128
Sub-tick hits	128 Hz sim + timestamped fire	Hitscan fairness without 256 Hz full sim	Complex rewind; must cap rewind ms
Rollback (GGPO-style)	Variable resim	Fighting games, small player counts	Hard at 10-player projectile + utility scale

Sub-tick does not mean the whole world runs at 256 Hz. It means fire and hitscan inputs carry client timestamps; the server samples entity poses at that sub-tick instant when resolving damage, while movement and physics remain on the coarser simulation grid. This is how Harbor Crest kept host CPU manageable.

Input buffering and send cadence

Clients should tag each command with client_time and sequence_id. The server ingests a ring buffer each simulation step:

Poll all inputs with server_tick − 1 < t ≤ server_tick.
Apply movement and stance changes at tick boundary.
Resolve hitscan at sub-tick timestamp if within lag-compensation cap.
Emit snapshot at network rate (may be every 2 sim ticks).

Sending one input packet per render frame at 240 FPS wastes bandwidth and reorders easily. Batch inputs at 64–128 Hz send cadence aligned to simulation, not to VSync. Display-layer interpolation fills gaps between snapshots so enemies do not strobe when snapshot rate is half of simulation rate.

Harbor Crest refactor: 64 Hz to 128 Hz plus sub-tick hits

Harbor Crest’s competitive team instrumented tick-aligned death replays and found three failure modes:

Same-tick trades — 22% of rifle duels had both damage events on one tick; ping-based tie-break angered mid-ping players.
Missed peek samples — jiggle peeks under 12 ms lost to holders who never saw head hitbox on server replay.
Plant/defuse snap — bomb progress bar moved in 15.6 ms jumps; clutch defuses felt random at high ping.

Shipped changes:

Authoritative simulation raised to 128 Hz on ranked pools.
Sub-tick hitscan with 100 ms rewind cap (unchanged policy).
Network snapshots held at 64 Hz with delta compression.
Trade rule changed to both-kill when damage within 4 ms sub-tick window instead of ping tie-break.
Telemetry dashboard: tick bucket histogram per death, unfair-trade rate by ping decile.

Unfair-trade tickets dropped 47% → 9%. Host CPU per match rose 18%; queue times unchanged because only ranked pools moved to upgraded hardware. Casual playlists stayed 64 Hz sim for cost.

Technique decision table

Approach	When to choose	When to avoid
64 Hz sim only	Budget hosts, large BR maps, co-op	Ranked small-map duels where peek/trade fairness is brand
128 Hz sim	Competitive tactical shooters, esports path	Mobile or 100+ player shards without dedicated silicon
128 sim + 64 snapshots	CPU for hits, bandwidth constrained routes	When enemy skating is already your top complaint
Sub-tick hits on 64 sim	Incremental upgrade before full 128 migration	Without movement sub-tick, peek quantization remains
Full rollback	2–4 player fighting, deterministic physics	10v10 utility + projectiles + persistent world state
Higher render FPS only	Local feel via prediction	Never as substitute for server tick on trades

Common pitfalls

Marketing 128 tick but sim stays 64 — players benchmark with replays; trust loss is permanent.
Raising tick without tie-break review — finer buckets still collide; define both-kill or damage-priority rules.
Ignoring snapshot rate — 128 sim with 20 Hz snapshots looks like teleporting enemies despite “good tick.”
Sub-tick without rewind cap — exploiters stretch timestamps; cap at min(client ping, policy max).
Tick-dependent UI — countdown timers that use client frame delta drift from server bomb tick.
Physics at mixed rates — grenades sim at 30 Hz while players at 128 Hz causes foot sliding on explosions.
No per-pool labeling — casual 64 and ranked 128 in one queue confuses MMR and complaints.

Production checklist

Document simulation Hz, snapshot Hz, and sub-tick policy in server config.
Tag every input with sequence_id and monotonic client_time.
Align lag-compensation rewind cap to tick and sub-tick sampling rules.
Define explicit trade resolution for same-tick and sub-tick collisions.
Instrument death replays with tick bucket and ping decile dimensions.
Match bomb/plant/defuse progress to server tick, not client animation.
Decouple snapshot bandwidth from sim rate when CPU allows.
Expose tick rate in server browser and post-match telemetry for ranked.
Load-test CPU per player at target sim Hz before fleet resize.
Playtest duels at 30, 60, 90, and 120 ms artificial latency on each pool.

Key takeaways

Simulation tick, snapshot rate, and render FPS are three clocks — raise the right one for the problem you are solving.
64 Hz quantizes peek and trade windows in ways lag compensation alone cannot erase.
128 Hz sim with 64 Hz snapshots is a practical competitive default when bandwidth is tight.
Sub-tick hit sampling improves hitscan fairness without doubling full-world physics cost.
Harbor Crest cut unfair-trade reports 47% → 9% with 128 Hz sim, sub-tick hits, and both-kill trade rules.