Game dev devlogs: decisions justified in public

This was an online-learning day spent with published game development engineering devlogs, mostly Riot’s writing on Valorant. I do not work in games and I am not about to start. Almost nothing here is transferable technique. I kept reading because of something the writing does that mine does not.

Constraints I do not have

Valorant’s engineering problems come with budgets I have never had to meet. Matches run on dedicated servers – one per match, server-authoritative – simulating at 128 ticks a second, which gives each tick about eight milliseconds before the next one is due. Riot’s server and netcode writing talks about routing players so most sit within tens of milliseconds of their server, and then about squeezing the server’s own work down so the tick fits its budget. On top of that, the opposition is not only other players: it is thousands of people actively trying to subvert the client you shipped them.

The tightest constraint I had personally worked under, until recently, was Cloudflare’s cap on outbound requests per invocation – and before that, every constrained environment I had known limited memory or time, never request count. That was a genuinely new shape of limit for me, and it is a rounding error next to a per-tick deadline with a scoreboard attached. That gap is why the reading was useful. Tight budgets force the reasoning into the open, because you cannot hand-wave a millisecond.

How they justify a decision

The pattern, repeated across the netcode and anti-cheat writing, is: state the constraint as a number, price the options, choose, then publish the choice with the reasoning still attached. Two examples stayed with me.

Wallhacks. Riot cannot stop players from hacking their own client, so they shrank what the client is given. The server culls enemy position data a player is not supposed to see – the Fog of War approach – so a modified client has nothing to draw. The trade is client-state fidelity against size of the cheat surface, and they took the side that costs the attacker.

The kernel driver. Valorant’s anti-cheat goes as deep as a consumer product can go: a signed kernel-mode driver that loads at boot. The stated reasoning for loading that early is that software started later is already running behind whatever the cheat loaded first. The cost is named too – a component with that reach sitting on every player’s machine, and the trust that has to be earned to keep it there. The 128-tick dedicated servers are, on the same logic, simply expensive, and defended on competitive-fairness grounds, with the follow-on routing and performance work presented as the bill for having chosen them.

The part I am worst at

None of this taught me a technique. What it modelled was justification: constraint, priced options, decision. Justifying a technical decision is the weakest part of my written assignments. I will say what I built and what it does, and quietly leave out why the alternative lost – usually because at decision time I had not made the alternatives explicit to myself, so there was nothing to write down afterwards.

The devlogs do it differently, and it is not a writing trick. Their alternatives are explicit because they actually had to be chosen against. Writing the justification is easy when the decision was genuinely reasoned and impossible when it was not, and I can tell the difference in my own retros. So the change I am taking from this day sits upstream of the writing: when I make a technical choice, write down what it beat and what it cost. The prose then writes itself – the way it evidently does for engineers with an eight-millisecond budget.