David Aldridge, now Head of Technology at Bungie, delivered one of the most referenced gameplay networking talks in GDC history in 2011. Titled "I Shot You First," the session pulled back the curtain on the full networking architecture behind Halo: Reach's 16-player competitive multiplayer.

The presentation covers major aspects of the game’s architecture and design philosophy, from the foundational replication protocols and prioritization engine to the hands-on process of designing, measuring, and optimizing individual game mechanics under real network conditions.

Indirectly, this highlights best practices that any game studio, big or small, can add to their multiplayer to help improve its online architecture.

[Editor's note] Given the massive scope of David’s presentation, we’ve included specifically for this article the “main takeaway” under each major insight to help with readability.

An Architecture Inherited from Tribes

Halo: Reach's networking didn't emerge from scratch. Aldridge and his team traced their entire architectural foundation to a GDC paper from 1998: "The Tribes Engine Networking Model" by Mark Frohnmayer and Tim Gift. For a deeper look at that foundational paper and its lessons for modern developers, Edgegap has a dedicated deep dive on the Tribes networking model.

The core problem Bungie was solving is a familiar one:

• for N players in a match, the amount of game state to transmit scales close to N squared.

• In a 16-player game, a naive "send everything" approach works out to roughly 20 megabits per second of required bandwidth.

• In other words, “totally infeasible”.

The Tribes model gave them the answer. Instead of reliable delivery, where every packet must arrive in order, the system is built on semi-reliable protocols.

The word "semi-reliable" sounds like a compromise. It's actually a deliberate architectural choice.

As Aldridge explained, "unreliability enables aggressive prioritization," which is what makes the whole system scale. When you don't have to guarantee delivery of every update, you can let your flow control layer decide what matters most right now and fill each packet accordingly. No latency debt from a flooded connection. No system-wide stall waiting for a dropped packet to be resent.

Main takeaway: Semi-reliable protocols are not a shortcut, they are the foundation of scalable multiplayer networking. If your game has a large number of objects and players, guaranteed delivery will eventually break you on bandwidth. That’s why a netcode with ability to highly optimize data synchronization is key. Also, data means egress costs, which should be minimized to ensure lower overall cloud costs.

Three Protocols, Three Jobs

On top of that semi-reliable foundation, Bungie operates three distinct replication protocols, each tuned to a different kind of data.

• State data provides one guarantee: eventually, the most current value will arrive. It does not guarantee any intermediate values. If a player's position updates 30 times per second but only 10 of those updates make it through, the client reconstructs the correct current position and skips everything in between. This covers the vast majority of game properties, including positions, health, timers, and hundreds of object attributes across every networked entity in the match.

• Events are the opposite: zero delivery guarantee. They can be dropped entirely. That's acceptable because events describe why something happened, such as why a health bar dropped or why a Warthog lost a wheel. If you weren't present to see the transition, you only care about the current state. The event's value is contextual flavor. State data carries the truth.

• Control data is a sub-sampled stream of player controller inputs, sent as frequently as possible from client to host and reflected back out to all clients. It's tiny, around 20 bits per player, carefully hand-packed. Its sole purpose is prediction accuracy. If a player pushes their stick to start strafing left, the resulting position change won't be visible for several frames. Control data transmits that intent immediately, letting every other client begin predicting the movement well before it shows up in state data.

contextual events, and input prediction into distinct protocols with distinct reliability guarantees is what lets you serve each data type efficiently rather than over-engineering for the worst case across the board.

Prioritization: The Engine Under the Hood

Three protocols give you the right data types. Prioritization decides what actually gets sent in each packet.

Every object in the game world receives a continuous priority score, evaluated per client. The system weighs distance, screen presence, threat potential, and recent interaction history. Some weightings are intuitive. Some are not.

Aldridge's team discovered that players watch their own grenades in flight obsessively, "even though they're completely irrelevant to them after they've thrown them," so player-owned grenades needed higher priority than pure threat logic would suggest. A dead body gets near-maximum relevance for several seconds, because players watch ragdolls fall right after a kill. An inactive grenade rolling in a distant corner gets updated roughly three times per second.

When flow control decides to send a packet, the replication layer fills it in priority order. High-priority objects get in. Low-priority ones wait. If bandwidth is constrained, the game degrades gracefully, with less important objects updating more slowly, rather than stalling the whole simulation. The result is a system with no hard object cap, supporting over 2,000 synchronized entities in a 16-player match.

This kind of per-object, per-client visibility is hard-won. Edgegap's analytics give game developers a comparable layer of insight into server and network performance without requiring years of custom tooling investment, surfacing the data needed to make informed, actionable development decisions on live multiplayer.

Main takeaway: Prioritization is what turns semi-reliable protocols into a scalable system. Getting it right requires tuning weights against real player behavior, not just logical proximity. Getting it right also requires having the tooling to see what your network is actually doing in practice.

Mapping the Lag: Sequence Diagrams as a Design Tool

Before writing a line of network code for any mechanic, Aldridge's team drew a two-machine sequence diagram: client on one side, host on the other, with every message arrow tilted to represent one-way network latency in transit.

That tilt is the whole point. It makes every potential overlap, every vulnerability window, and every moment where two machines could disagree about game state visible before any code exists.

The grenade throw is the cleanest illustration. On a single machine the flow is simple: press trigger, wind-up animation, release frame, grenade launches. The question is how to introduce a second machine without creating artifacts.

• Option one: ask the host for permission before starting the animation. Mapping this out immediately reveals the problem. There's a full round-trip gap before the client gets any feedback on his button press. "Players hate this with a passion," as Aldridge put it. Completely unacceptable.

• Option two: throw locally and tell the host simultaneously. This approach has no visible lag window, which sounds good but means no host adjudication has actually occurred. That's latency debt accumulating silently, guaranteed to surface later as a desync.

The actual answer is a third path: predict the animation on button press, but hold grenade creation at the release frame. The client's arm moves immediately. The grenade vanishes at the release frame. A creation request goes to the host. The host's confirmation arrives approximately one round-trip later.

During that window, the player's oversized animated arm fills a third of the screen. Players are not looking at their hand during a grenade throw; they're aiming through their crosshair. They don't notice gaps up to 150 milliseconds. Casual players won't notice up to 200 milliseconds, according to Aldridge. Which explains why Bungie shipped grenade throws across three Halo titles.

Main takeaway: Sequence diagrams with two machines are one of the most practical tools available for networking design. Sketching out a mechanic with explicit latency arrows before writing any code will surface lag windows and latency debt that are nearly impossible to spot any other way.

[Editor’s Note: not everyone has the resources of Bungie on a AAA game like Bungie. Optimization is key, but pre-planning is a luxury. That’s why making sure to reserve time in your production to optimize your game server, networking, and overall backend is important for performance and cost efficiency.]

Where Is the Lag?

The sequence diagram approach David used with his team leads directly to the most important rule in the talk: always ask where you are hiding the lag.

"If you have host adjudication occurring, you will have lag somewhere. If you don't have lag somewhere, you don't have host adjudication - you have incurred latency debt."

It cannot be eliminated. It can only be placed. The design work is choosing where to put it, somewhere players won't notice, or where its perceptual impact is low enough to ship.

One meaningful lever every studio has access to is simply reducing baseline latency through server placement. Edgegap's orchestration platform reduces average latency by 58% by deploying game servers nearest to your actual player population. That doesn't eliminate the "where is the lag" question, but it substantially narrows the margin you're working in.

In other words, a 200 ms round-trip requires very different design tradeoffs than a 40 ms one. Smaller studios especially benefit, as less of the networking work needs to go into hiding latency that shouldn't have been there in the first place.

Main takeaway: Lag is not just a bug to be fixed; it is a budget to be spent wisely. Reducing your baseline round-trip time through smart server placement helps shrink that budget problem before your networking engineers ever have to touch it.

When the Best Netcode Fix Is a Game Design Fix

Four of Bungie's five major network “optimization wins” in Reach came from changing game mechanics, not networking code.

This is the most counterintuitive lesson of the talk, and arguably the most durable.

The armor lock example makes it concrete:

• The mechanic: press a button, play a three-frame intro animation, gain invulnerability and infinite mass.

• Two failed iterations preceded the shipping version.

• Both had a window where a grenade could detonate on the host during the intro animation and deal damage, leaving a player who had already seen the blue shield on their screen receiving damage they were certain they were immune to.

• Thousands of forum posts followed each beta.

The final version introduced one targeted change.

As Aldridge described it: "We went in and grabbed the frame delay number that the designers had so carefully tweaked and slammed over it for networking. We actually changed the way the game played." The host activates the shield early, shrinking the intro delay by the measured round-trip time between host and the activating client. When the client sees the shield appear, it lines up with their expectation. The inconsistency was shifted away from the player who cares most, the one using armor lock, and onto the host and other players, who barely register whether someone else's shield ticked in a couple frames early.

The assassination mechanic followed a similar arc. The shipping version used a visual-only interpolation blend of about three-quarters of a second to absorb position discrepancies on entry. In debug mode, the blend was visible and the animators flagged it immediately. In-game, it was invisible. The camera pulls out to third-person at the start of every assassination and travels at roughly 25 feet per second during that exact window. Players' spatial reference changes so fast that a 20-foot blend goes completely unnoticed. Their brains fill in the continuity.

The ragdoll solution took the principle furthest: stop networking ragdolls entirely. Sync only the initial death state across all peers. After that, let physics diverge locally. Two design concerns were resolved:

• first, ragdolls blocking bullets (solved by allowing full over-penetration with no side effects) and;

• a long-standing Halo community tradition of crouching over a fallen opponent's body, which required the ragdoll to be in roughly the right position.

Both were solvable, nobody noticed the changes, and the result was approximately 10 to 12% of bandwidth freed up.

Main takeaway: Your networking engineers and your game designers need to work together from the start. Some of the most effective latency solutions are not found in the networking layer at all. They are found in the design of mechanics themselves, in perceptual windows and player attention patterns that can absorb inconsistencies invisibly.

Build the Tools First, Then Optimize

Aldridge quoted a rule for optimization: "First rule of program optimization: don't do it. Second rule, for experts only: don't do it yet."

Bungie knew they needed to optimize, so they built the tools to do it safely before touching a line of networking code.

The bandwidth profiler tracked usage and priority results across the full simulation.

The real capability came from splicing profiler data into Halo's existing film system.

Films are deterministic gameplay recordings, a user-facing feature since Halo 3. Aldridge's team injected a debug blob after every gameplay frame containing all network state sampled during that tick, every packet sent and received, and every prioritization decision. "For the first time in Halo history," as he put it, they could analyze network performance after the fact, rewind to any moment, filter to a specific client, and examine exactly what was transmitted to whom and when. Total development time: roughly six weeks for the core tools.

That toolset directly enabled the over 80% bandwidth reduction from Halo 3 to Reach.

One example of what it surfaced: idle grenades rolling on the ground were consuming a disproportionate share of bandwidth at the priority layer. The root cause was a bug fix from the end of Halo 3 that gave equipment objects a large priority boost to address lag complaints. Through a design accident, grenades and equipment shared the same parent class. Every dropped grenade on every map inherited the boost and was being treated as high-priority at all times. A one-line fix (i.e., apply the boost only to active equipment) freed up approximately 20% of bandwidth.

For studios that don't have six weeks to build custom profiling infrastructure, Edgegap's analytics tooling surfaces the container and game server layers of live and historical performance data, helping teams catch the kind of systemic patterns, bandwidth anomalies, object-level priority issues, server frame time spikes, that Bungie's custom profiler was built to find.

Main takeaway: Networking entropy accumulates silently, and you cannot fix what you cannot see. Investing in deep inspection tooling before you optimize is not optional, as it is the work that makes optimization possible at all.

Turning Perceived Lag into a Science

Playtesting under simulated network conditions gave Bungie a controlled environment but the “match quality” measurement problem was harder. As Aldridge noted, players "can tell us whether they had a good time, which correlates almost perfectly with whether they won or not." That's not granular enough to drive engineering decisions.

The solution: a dedicated controller button in playtests that injects a timestamped debug event directly into the film. Every time a player feels lag, they press it. Engineers jump to that exact frame, examine the full network state, and investigate. When the team could run at their bandwidth targets and see zero button presses from playtesters, they knew they had succeeded.

A useful side effect emerged: players pressed the button not just for actual network issues, but whenever a game mechanic confused or disoriented them.

Getting killed in one shot by a grenade from nearly full health felt like lag. A death camera that didn't clearly explain the cause of death felt like lag. The engineering team would pull those film clips and bring them directly to designers, with data. Networking tooling became a feedback loop for game design.

Main takeaway: Perceived lag is a product signal, not just a networking metric. Building a way for playtesters to flag it precisely (when tied to reproducible game state) turns vague complaints into actionable data for both engineers and designers.

Smart Host Selection and the Cost of Host Migration

Host migration, namely the act of switching to a better host mid-session when the current host's connection degrades, is powerful when it works.

However, Aldridge acknowledged it could be its own dedicated talk as it is a significant engineering undertaking, and studios considering it should not underestimate the scope.

Highwire Game’s Michał Buras, Lead Networking Engineer on Six Days in Fallujah, breaks down in his talk the level of challenge that host migration complexity brings in peer-to-peer and relay-based multiplayer, which is a useful reference before committing to that path.

Dedicated servers sidestep the problem entirely. With dedicate servers who acts as the host, there is no host to migrate away from, and session continuity is thus managed at the infrastructure level.

Main takeaway: Who hosts a session matter as much as how you've engineered the session. Host migration in P2P or relay-based networking architecture carries an engineering cost that dedicated server infrastructure avoids entirely.

The Numbers, and What They Mean for Bandwidth Cost

Reach's final benchmark: 16-player games running solidly with no lag artifacts at 250 kbps, against a design goal of 384 kbps. An over 80% total bandwidth reduction from Halo 3.

Every kilobit saved matters twice:

• First for players, as lower bandwidth requirements mean more of your player base can run the game well across a wider range of connection types.

• Second for your infrastructure bill, as egress cost scales directly with how much data your servers transmit.

As such, optimizing replication, tickrate, and prioritization logic is also optimizing your cloud spend. For Unreal Engine developers looking for a concrete starting point, Edgegap has published an Unreal Engine server profiling and optimization checklist, with a Unity equivalent in development.

Main takeaway: Bandwidth optimization is not just a networking quality problem. It is a business cost problem directly impacting the profitability of the game itself. As such, every improvement to replication efficiency directly reduces egress spend, making it one of the few engineering investments that pays dividends in both player experience and infrastructure budget.

—

This article is based on and cites the original GDC 2011 talk by David Aldridge, published on the GDC YouTube channel. All rights in the original content are owned by their respective owners.