Overwatch Gameplay Architecture and 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

▶ 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)

> 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

There is a fantastic GDC video about Blizzard's use of ECS in Overwatch and how it made it far easier to understand the system due to all of the interacting subsystems. ▶ 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)

Have you seen the presentation from GDC 2017 on the architecture of Overwatch [0]? If you watch the video in detail -- stepping through frame-by-frame at some points -- it provides a nearly complete schematic of the game's architecture. That's probably why the video has since been made unlisted. [0]: ▶ this video

Isn’t there a ton of prior art? I’ve seen tech talks about ecs implementations for years. From the top of my head, here’s a great tech talk about overwatch. ▶ this video Here’s a tech talk by Bob Nystrom (the game programming patterns guy) that mentions ecs from years ago link Edit: letsInvalid in another thread above linked to an article from 2013: link

Your comment made me feel compelled to mention a Blizzard talk I came across recently on the ECS (Entity Component System) architecture they used for Overwatch. It looks suspiciously like a function first architecture in that they don't allow mixing of data and functions. I'm not sure how purely functional it is, but it certainly strikes me as the kind of architecture that Carmack would appreciate in dealing with complexities that lead him to a more functional programming style. This talk is 3 years after release, and includes all the hindsight they gained from that. Also, the parts talking about the netcode are quite amazing, and the precision of their predictors that they attribute to using ECS. ▶ this video

This is a next step for my project as I'm trying to figure out how to generalize client side predictions in a sane way. Basically, I'm happy with my latency (for board games) which I hope to migrate closer to people as more edge compute offerings emerge. However, I'm wondering what the path is to find some of these ideas in more latency sensitive applications. The explanation for how the net-code behind Overwatch is a good explanation: ▶ this video and I'm just trying to figure out how to build the reactive tree in a way to support it sanely.

For anyone curious to know more about usage of ECS in Overwatch, check out this GDC talk from one of the developers: ▶ this video

▶ this video I think this talk on how an ECS actually reduced coupling in the case of Overwatch would be a good concrete real world example to look at. It enabled some architectural benefits for implementing replay cameras or for networking code in their game through actual reduced coupling between input ->commands and commands->simulation.