Overwatch Gameplay Architecture and Netcode

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] [VIDEO] (Netcode talk starts at 22:22)

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: [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).

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. [VIDEO]

> 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: [VIDEO]

[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 - [VIDEO]

> running a simulation (what OOP was invented for) I used to believe that. I no longer do. Among other things, I watched this talk about Overwatch's architecture and it really seems like you have to go against your OO instincts to create larger simulations: [VIDEO]

Since you generally want to keep a set number of time steps the commonly used data structure for this is a ring buffer. No garbage and all you do is increment the index (with wraparound) every step. Not a lot of technical details, but this video has a great general overview [VIDEO]