What a decade of tickrate arguments was really about

The tickrate argument ran for over a decade, outlived the engine it started on, and was never settled, because the two sides were measuring different things and neither noticed.

What a tick actually is

A server simulates the world in discrete steps. Each step it reads the inputs it has received, advances the simulation, and sends the result. Tickrate is how many of those steps happen per second.

At 64 ticks a second the server makes a decision every 15.6ms. At 128, every 7.8ms. Everything else in the argument follows from what you think happens in that gap.

The first thing people conflate

Tickrate is not the only number that decides how the game feels, and for most players it is not the dominant one.

Three separate things determine whether a shot registers the way you expected:

• Tickrate, how often the server decides anything.
• Update rate, how often the server tells your client what it decided.
• Interpolation, how much your client deliberately delays rendering other players to smooth out network jitter.

The third is usually larger than the first two combined, and it is set on the client. A player on a 128-tick server with a large interpolation buffer is seeing the world later than a player on a 64-tick server with a small one, and the argument they are having about the server is actually about their own settings.

What each side was actually right about

The higher-tickrate side was right that the server's temporal resolution matters at the margins, and that competitive play lives at the margins. A fast movement across a doorway can be resolved differently at 64 and 128, and at the top of the skill distribution those cases are not rare.

The lower-tickrate side was right that for the overwhelming majority of players, latency and interpolation dominate completely, and that doubling tick cost to fix something invisible to most of the population is a poor trade.

Both of those are true. They are answers to different questions ("does it ever matter" and "does it matter to most people") and a decade of argument never separated them.

Why community servers ended up on one side

Community servers could set their own tickrate, and many set it high, because they could, because their population was competitive, and because it was a visible differentiator on a list where everything else was hard to compare.

That produced a real association between community hosting and high tickrate, which then became part of how community servers were marketed. Some of that was substance and some of it was positioning, and the two were never easy to tell apart from the outside.

The cost was borne by the server owner: a higher tickrate is more CPU per player, which is why it shows up on servers with fewer slots and better hardware, and why the trade appears in what a server actually needs to run well long before it appears in gameplay.

What settled it in practice, if not in argument

Two things, neither of them a resolution.

Server-authoritative movement and lag compensation got better. A great deal of what tickrate was being asked to fix was fixed by better reconciliation instead, which made the difference smaller.

Official infrastructure standardised on one number. When matchmaking runs at a fixed rate, the argument becomes theoretical for everyone who plays there, which is most people.

So the debate did not end. Its audience left.

The part worth keeping

The useful residue is the habit of separating the three numbers. A player complaining that shots do not register is describing a symptom with at least four possible causes, only one of which is tickrate, and the other three are cheaper to check.

That diagnostic discipline is worth more than any position on the original question, and it is the same reason reading what the server is actually doing beats arguing about what it should be configured to do.