How Overwatch Uses ECS for Gameplay and Netcode

TL;DR

Overwatch uses an Entity Component System to control complexity by separating state into components and behavior into systems. Its client architecture includes about 46 systems and 103 component types, while client-side prediction and server reconciliation keep play responsive by rolling back mis-predictions and replaying inputs. Read on to see how entities, singleton components, utility functions, deferment, and authoritative server states fit together.

Transcript

hello everybody this is overwatch gameplay architecture and netcode standard rules apply silence your phones fill out the session in feedback form switch off hans only get on the payload my name is tim ford on the lead gameplay programmer on overwatch I've worked on overwatch in that capacity since its inception in the summer of 2013 before that I ... Read More

Key Insights

• Overwatch uses an Entity Component System (ECS) architecture to manage complexity and maintainability in its codebase.
• ECS separates components (state) from systems (behavior), allowing for more modular and decoupled code.
• Singleton components are used to store state that is accessed by multiple systems, reducing coupling.
• Shared utility functions help manage common behaviors across systems, minimizing code duplication.
• Deferment is used to handle large side effects, such as creating impact effects, at a single point in the frame.
• Netcode in Overwatch leverages ECS to handle client-side prediction and server reconciliation effectively.
• Predictive systems on the client simulate player input ahead of the server to maintain responsiveness.
• Mis-predictions are corrected by rolling back to server-authoritative states and replaying inputs.

Questions & Answers

Q: How does Overwatch use ECS for gameplay and netcode?

Overwatch separates game state into components and behavior into systems, with entities serving as IDs tied to collections of components. The same architecture supports netcode by organizing client-side prediction, server reconciliation, and corrections when the client mis-predicts.

Q: What is an entity in Overwatch's ECS architecture?

An entity is an ID corresponding to a collection of components. In Overwatch, the entity admin stores a hash map of entities keyed by an unsigned 32-bit entity ID, and an entity may also hold an optional resource handle pointing to its entity definition.

Q: How do components and systems differ in Overwatch's ECS?

Components store game state and are intended to contain no behavior, while systems contain behavior and store no game state. Systems operate only on the relevant subset of components, regardless of whether an entity has 2, 3, or 30 components.

Q: How is Overwatch's ECS implementation organized?

The world is represented by an entity admin that stores an array of systems and a hash map of entities. Rather than iterating over fixed component tuples, a system selects a primary component, iterates over it, and retrieves other required components through siblings.

Q: How large is the Overwatch client ECS described in the talk?

The client breakdown shown in the talk contains about 46 systems and 103 component types. Some systems operate on many components, while others use only a few.

Q: What are singleton components used for in Overwatch?

Singleton components store shared state that multiple systems need to access. Centralizing that state reduces direct dependencies between systems and helps limit coupling.

Q: Why does Overwatch defer large side effects?

Overwatch defers large side effects, such as creating impact effects, so they can be handled at a single point in the frame. This localizes major side effects instead of allowing them to spread across multiple systems.

Q: How does Overwatch correct client-side mis-predictions?

The client predicts player input ahead of the server to preserve responsiveness. When a prediction differs from the server-authoritative result, the client rolls back to the authoritative state and replays its inputs to catch up.

Q: Why doesn’t Overwatch put AFK tracking in a connection component update function?

Overwatch keeps AFK tracking in a system because the connection component represents state used for multiple behaviors, not one behavior of its own. Different systems can interpret that state for AFK enforcement, network broadcasts, player names, or persistence records.

Q: How does Overwatch decide which player entities receive AFK behavior?

The player connection system applies AFK behavior only to entities with the complete set of required components, including connection, input stream, and stats. An AI bot may have a stats component, but without the other required components it is not subject to that behavior.

Q: How does the Overwatch server detect and handle an inactive player?

The player connection system checks the player’s input stream and stats to determine whether they pressed a button or contributed to the game. It resets the AFK timer when activity is found; otherwise, it uses the connection handle to send the player a message to move.

Summary & Key Takeaways

• Overwatch employs ECS architecture to manage its complex gameplay systems, separating state from behavior to reduce code coupling and simplify maintenance. This approach allows for efficient handling of components and systems, enhancing the game's responsiveness and consistency.

• The game uses singleton components to store shared state, and utility functions to manage common behaviors, which helps in minimizing code duplication and inter-system dependencies.

• Netcode in Overwatch is designed to ensure responsive gameplay through client-side prediction and server reconciliation, correcting mis-predictions by rolling back to authoritative states and replaying inputs.