GDC and the engineering nobody outside games learns from

The Game Developers Conference is running this week, and as usual the technical talks contain more transferable engineering than most software conferences, delivered to an audience that mostly does not overlap with the people who would benefit.

Here is what the rest of us should be stealing.

the frame budget#

A game running at 60 frames per second has 16.6 milliseconds to do everything: input, simulation, physics, animation, culling, draw call submission, audio, and whatever the game is actually about.

Not on average. Every frame. A frame that takes 20 ms is a visible stutter, and players notice a single dropped frame.

That constraint produces a discipline the rest of software largely lacks:

Budgets are allocated per subsystem, in advance. Physics gets 3 ms. AI gets 2 ms. If a system exceeds its budget, that is a bug with an owner, not a "performance improvement opportunity for next quarter."

Compare to how most web services handle latency: an aspirational p99 target, no per-component budget, and no mechanism that fails when a component regresses.

Steal this. Give each layer of your request path a latency budget. Assert on it in tests. A change that pushes the database layer from 20 ms to 40 ms should fail CI, not show up on a dashboard a month later.

Worst case matters more than average. Nobody in games optimizes mean frame time. They optimize the 99.9th percentile, because that is what the player experiences as jank.

The web equivalent is obvious and widely ignored.

determinism as a feature#

Multiplayer games with lockstep networking require that the same inputs produce bit-identical outputs on every machine. That is a much stronger constraint than "correct," and achieving it teaches you where nondeterminism actually hides:

• Floating point differences across compilers and architectures.
• Iteration order over hash containers.
• Time-based logic.
• Uninitialized memory.
• Anything threaded without a strict ordering.

Every one of those is a source of flaky tests and unreproducible bugs in ordinary software, and most engineers have never had to hunt them systematically.

If your test suite is flaky, the game industry solved that problem decades ago and the answer is: make the system deterministic, then the flakiness is a bug you can find.

data-oriented design#

The insight: modern CPUs are enormously fast and memory is enormously slow, so performance is dominated by cache behavior rather than instruction count.

Which means the layout of your data matters more than the cleverness of your algorithm, at least until the constant factors stop dominating.

Arrays of structs versus structs of arrays. Contiguous memory over pointer chasing. Processing in batches over per-object virtual dispatch.

This applies directly to any data-processing code and most developers have never been taught to think about it. If you have a hot loop over a collection of objects and it is slower than it should be, the layout is usually why.

shipping to a fixed target#

Console games ship to hardware that does not change for seven years. You cannot tell the player to buy more RAM. You cannot autoscale.

That produces genuine engineering rather than procurement: measure, budget, optimize, cut scope, ship.

There is a lesson here for cloud-native development, where "we will scale it" has become a substitute for making things efficient. The teams that treat their resource envelope as fixed produce dramatically more efficient systems, and the constraint is a gift.

the thing games do worse#

To be fair: game codebases are frequently a mess, crunch culture is a genuine industry problem, testing practices are often weaker than in other software, and "ship it and patch it" has become normalized in a way that undermines a lot of the above.

Take the engineering discipline. Do not take the working conditions.

the talks to look for#

The technical postmortems are the good ones — a team explaining what went wrong in a shipped product, in detail, publicly. The industry has a stronger culture of this than almost any other software domain, and the material is excellent regardless of whether you care about games.