4 ms·

> You take a set of components and compose an object called an entity. That’s an overly broad definition of “object”, since under that same definition a record

> You take a set of components and compose an object called an entity. That’s an overly broad definition of “object”, since under that same definition a record type (C struct) or any other blob of memory is an object. In the common type of “components only store data” ECS, the entity is an ID (think a foreign key) that connects multiple records together and systems are independent functions (they are not tied to nor live in an entity) that operate on collections of subsets of these components. That sounds a lot more like old school C-like procedural programming to me than it does like OOP. There’s more to OOP than the data attributes a class contains (eg the associated methods) I suppose it depends on your game engine and your ECS, but since entities don’t contain logic, it’s the systems that communicate between each other (either by sending messages or by accessing the other entities components or by just calling functions of other systems). This isn’t all that different from different parts of a procedural program communicating. Although I do personally think that making a system be an OOP object does makes sense, but it doesn’t have to be. With that said, it seems pretty common in games to use a component system that isn’t “pure ECS” (like the default Unity components prior to their new ECS), which definitely seems like typical OOP to me, just decomposed a bit more.

meheleventyone 5y ago
> That’s an overly broad definition of “object”, since under that same definition a record type (C struct) or any other blob of memory is an object. I think that's because you seem to have stopped at the second sentence the rest is important as well. I'm also talking about a level above the ECS implementation. What is the running thing actually doing. > With that said, it seems pretty common in games to use a component system that isn’t “pure ECS” (like the default Unity components prior to their new ECS), which definitely seems like typical OOP to me, just decomposed a bit more. Yes this also models much the same thing at runtime.
- dkersten 5y ago
  How is the running thing operating on components any different from functions in a purely procedural language like C operating on records/structs? > Yes this also models much the same thing at runtime. In a different way, though. It also generally misses out on the data-oriented benefits of an ECS.
  - meheleventyone 5y ago
    It's the conceptual organization. The Entity is defined by data (components) that bring along behavior (systems). So an entity executing at runtime (say you're making Pacman and it's the Red Ghost) is an object and is defined by the combination of data and behavior. The underlying implementation is irrelevant basically. You could implement the ECS in an OOP style and the same it true. You could do it in a functional style and it would be true. You could do it in straight bytecode for some obscure hobby VM and it would be true.
    - dkersten 5y ago
      Unlike traditional OOP, the data and behavior are decoupled though. Similar to data and functions. That is, you can add components that don’t get operated on by any particular systems because the entity doesn’t have the other prerequisite components and you can have systems that don’t operate on the components. You can have many systems operate on one particular component and many components operated on by a system. In OOP, the data and the operations are packaged to whether as one. You also typically have encapsulation and it’s considered bad practice for one class to operate on another classes data directly. It seems that both models achieve similar things, but they’re far from the same thing. Just like how procedural or functional programming achieve similar things to OOP, and you can do OOP in these paradigms or these paradigms in OOP. There’s a lot of cross over, but that doesn’t make them all the same thing. If anything, I’d say that ECS are a relational model but with a very limited query system compared to something like SQL.
      - meheleventyone 5y ago
        > Unlike traditional OOP, the data and behavior are decoupled though. Similar to data and functions. Except the data and behavior aren't decoupled. The components are decoupled from the systems, but the systems are still very much dependent on the components. Just like a method is usually dependent on the instances data or a function is dependent on the data passed in. > That is, you can add components that don’t get operated on by any particular systems because the entity doesn’t have the other prerequisite components and you can have systems that don’t operate on the components. You can have many systems operate on one particular component and many components operated on by a system. You can have a member that isn't operated on by any methods and methods that don't operate on members. At the level your talking about there isn't much difference between a function and a method. It's mostly syntax. method(instancedata); verses instancedata.method(); Really we're getting caught up in implementation details because a class definition isn't the be all of how to define an object. There is really no reason we couldn't define objects in a programming language through composition. ECS very much is a relational model and you're right it's very limited in comparison to things like SQL because it's trying to model something very simple. Game Objects! The relations defined are exactly what brings data and behavior together under to create the runtime object we call an Entity under the pattern conventions.

meheleventyone 5y ago

> That’s an overly broad definition of “object”, since under that same definition a record type (C struct) or any other blob of memory is an object. I think that's because you seem to have stopped at the second sentence the rest is important as well. I'm also talking about a level above the ECS implementation. What is the running thing actually doing. > With that said, it seems pretty common in games to use a component system that isn’t “pure ECS” (like the default Unity components prior to their new ECS), which definitely seems like typical OOP to me, just decomposed a bit more. Yes this also models much the same thing at runtime.

dkersten 5y ago
How is the running thing operating on components any different from functions in a purely procedural language like C operating on records/structs? > Yes this also models much the same thing at runtime. In a different way, though. It also generally misses out on the data-oriented benefits of an ECS.
- meheleventyone 5y ago
  It's the conceptual organization. The Entity is defined by data (components) that bring along behavior (systems). So an entity executing at runtime (say you're making Pacman and it's the Red Ghost) is an object and is defined by the combination of data and behavior. The underlying implementation is irrelevant basically. You could implement the ECS in an OOP style and the same it true. You could do it in a functional style and it would be true. You could do it in straight bytecode for some obscure hobby VM and it would be true.
  - dkersten 5y ago
    Unlike traditional OOP, the data and behavior are decoupled though. Similar to data and functions. That is, you can add components that don’t get operated on by any particular systems because the entity doesn’t have the other prerequisite components and you can have systems that don’t operate on the components. You can have many systems operate on one particular component and many components operated on by a system. In OOP, the data and the operations are packaged to whether as one. You also typically have encapsulation and it’s considered bad practice for one class to operate on another classes data directly. It seems that both models achieve similar things, but they’re far from the same thing. Just like how procedural or functional programming achieve similar things to OOP, and you can do OOP in these paradigms or these paradigms in OOP. There’s a lot of cross over, but that doesn’t make them all the same thing. If anything, I’d say that ECS are a relational model but with a very limited query system compared to something like SQL.
    - meheleventyone 5y ago
      > Unlike traditional OOP, the data and behavior are decoupled though. Similar to data and functions. Except the data and behavior aren't decoupled. The components are decoupled from the systems, but the systems are still very much dependent on the components. Just like a method is usually dependent on the instances data or a function is dependent on the data passed in. > That is, you can add components that don’t get operated on by any particular systems because the entity doesn’t have the other prerequisite components and you can have systems that don’t operate on the components. You can have many systems operate on one particular component and many components operated on by a system. You can have a member that isn't operated on by any methods and methods that don't operate on members. At the level your talking about there isn't much difference between a function and a method. It's mostly syntax. method(instancedata); verses instancedata.method(); Really we're getting caught up in implementation details because a class definition isn't the be all of how to define an object. There is really no reason we couldn't define objects in a programming language through composition. ECS very much is a relational model and you're right it's very limited in comparison to things like SQL because it's trying to model something very simple. Game Objects! The relations defined are exactly what brings data and behavior together under to create the runtime object we call an Entity under the pattern conventions.