GDC Festival of Gaming
16 HN recommenders · recommended in 13 months, 2019–2025
1:04:04 · 196K views · Feb 8, 2019
Blizzard's Timothy Ford explains in this 2017 GDC session how Overwatch uses an Entity Component System architecture for layered gameplay. He also covers its server-authoritative netcode with client-side prediction and how they keep the game responsive and fair.
HN treats it as the best real-world AAA example of ECS and game netcode, and cites it constantly in discussions of data-oriented design.
20 comments from Hacker News
> The components on the entity define not only it's data but also it's behavior by the set of systems that act on the corresponding components. And you can take these object definitions and inherit them to add additional behavior or change the existing behavior by adding more components to the new definition. This seems to miss what ECS actually is, unless you're just referring to the old-school way of doing entity components and not the data-oriented way. Data-oriented ECS way of doing things is to separate state and behaviour. Entity components essentially become structs where their only behaviour is potentially some getter/setter utilities. Behaviours are then state-less systems (just functions, essentially) which act on a set of components. For example, a PhysicsUpdateBehaviour might take in a RigidBodyComponent and a HealthComponent to perform a physics update and apply physics/fall based damage. The main benefit of ECS (imo) isn't even really performance. It makes code in complicated game projects much easier to manage by clarifying the game loop and by making it much more obvious how and when entity state is being modified. It's the kind of thing that potentially complicates a smaller project, but makes larger more complex projects easier to manage. This Overwatch GDC talk is the best breakdown/example of data-oriented ECS in a AAA game that I know of: this video
Entities are a collection of component instances and nothing more. Components in ECS are data-only. Systems in ECS are logic-only. If you follow this strictly, then you cannot support encapsulation or data-hiding. There is no sole definition of OOP, but it is widely accepted that the ability to do encapsulation, including data-hiding, is a key part of OOP. Therefore, ECS is not OOP. QED If you’ve not seen the Overwatch team’s talk in which they discuss ECS, I can highly recommend it as a good resource to learn about ECS: this video There may be models commonly used in those languages you mentioned that are similar to ECS, but you seem to be implying that ECS is a form of OOP; it is not. Even if you implemented OOP using Structs of Arrays, a thread per object, or whatever you like, you cannot strictly conform with ECS’s requirement that “components have no logic” while also strictly conforming with OOP’s requirement that “objects should not know about each others’ internals” (object hierarchy).
Overwatch allows none of that and seems to have some pretty well-designed netcode. Clients only send their controller inputs and the server has full authority of what actually happens. Blizzard's GDC talk about it is really good if you want an explanation of how to make a game feel responsive and fair without giving clients authority over everything [1]. Ofc this does not eliminate aimbot or wallhacks, but it gets rid of pretty much all other forms of cheating. [1] this video (Netcode talk starts at 22:22)
this video "In this 2017 GDC session, Blizzard's Timothy Ford explains how Overwatch uses the Entity Component System (ECS) architecture to create a rich variety of layered gameplay." (My favorite resource to explain ECS + NetCode)
There's an awesome talk by someone in the overwatch team in youtube. It's about ECS but it has a big section on networking that had some useful tips. Edit: here it is - this video