4 ms·

Games are actually moving away from OOP by separating out state into a data oriented system.

by ummonk 5y ago

deleted 5y ago
[deleted]
Wohlf 5y ago
In my experience many game companies were never big on OOP in the first place.
kaba0 5y ago
Weren’t games already written with entity component systems?
- ummonk 5y ago
  I’m happy to be corrected as I’ve only really dabbled with Indie game development on and off but my general impression is that the paradigms have gone procedural -> object oriented -> ECS. For example, Unity is designed around GameObjects but is now adding building out the DOTS framework stack that’s more of a first party ECS system.
  - seanmcdirmid 5y ago
    Nobody has ever been able to convince me that these informal object systems (eg ECS) aren’t really just OOP with different extensibility mechanisms and/or a different place to stow away object state (oh, and let’s call the objects entities instead). The only real diversion from objects in games that I’ve seen is the work in Andrew Kennedy’s thesis on FRP for games.
    - ummonk 5y ago
      Yes and no. The EC part of ECS is definitely object oriented - more so than mainstream object-oriented systems / languages, in that it favors composition over inheritance (i.e. entities are compositions of components). But the S in ECS breaks the most fundamental tenet of object-oriented programming - encapsulation of state. And this separation between entities/components and systems is what makes data oriented programming so much cleaner and more powerful than OOP.
      - seanmcdirmid 5y ago
        If the state is encapsulated somewhere else, why is it no longer OOP? I don’t think Alan Kay would say that having each object simply be a handle into a table of values meant they could no longer be called objects. Heck, if we take the FactoryFactory example as being the bad thing about OOP, and consider that this comes from the GoF design pattern book, there is already a pattern in that book that closely resembles ripping the state out of an object and putting it somewhere else. Again, it is definitely not strawman OOP, but not very many programming systems are, especially modern ones.
        ummonk 5y ago
        Encapsulation in OOP terms means the state is encapsulated with the logic that fetches / mutates it. ECS explicitly is designed to do the opposite. It’s really that simple. The issue isn’t about how you store the objects but about whether the framework logically encapsulates object data with its associated logic.
        seanmcdirmid 5y ago
        > Encapsulation in OOP terms means the state is encapsulated with the logic that fetches / mutates it. No it doesn't. There are plenty of examples in OO where that isn't true or no physics engine that's been build in the last two decades would work at all. The only core thing needed for OO is that objects have unique identities that then enable a notion of associated state at all. A pure system would not allow for an unbounded number of unique identities at all, you would not really be able to talk about objects at all (or entities or whatever object synonym is preferred).
        ummonk 5y ago
        > No it doesn't. Yes, yes it does. > There are plenty of examples in OO where that isn't true or no physics engine that's been build in the last two decades would work at all. It would be surprising if most physics engines were built in an object-oriented way. The only one I'm familiar with, ODE, certainly isn't object-oriented. > The only core thing needed for OO is that objects have unique identities that then enable a notion of associated state at all. A pure system would not allow for an unbounded number of unique identities at all, you would not really be able to talk about objects at all (or entities or whatever object synonym is preferred). No, objects in OOP have not just their own unique identities but have their own behavior. Encapsulation is the most fundamental pillar of object-oriented programming. Without that, any procedural C code that makes use of structs could be called object-oriented, since structs would then be synonymous with "objects".
    - rawoke083600 5y ago
      I'm no expert, but here are my 2cents. One of my "ahhh moments" with ECS was when someone pointed out. The ECS has a very 'strict' boundary on DATA(attributes,entities,components) VS BEHAVIOR (methods,systems,functions). The 'traditional OOP' usually 'smash/hide/design/encapsulate' these two conflicting powers into one 'Entity' I think it's 'easier' to write a ball-of-mud in OOP for games, then it is to write ball-of-mud with ECS. *NOTICE I said 'easier' not 'impossible' I love the distinctions between BEHAVIOR and DATA, from an organizational point of view. The bigger the whole system is the more value I think a good programmer can get with ECS. Imagine having to "implement" gravity for 100 different types of 'Objects'. Sure The ECS way would be to have a System(Gravity) that executes the 'same computing' on all entities with a 'MassComponents' and 'PosComponents' for example. The Entity would usually not need to know ANYTHING about Gravity. Sure the OOP way one can inherit but eventually you inherit yourself into a corner (diamond-problem). My 2cents - YMMY TL;DR (just squint hard enough) ECS ~= (Data | Behavior) OOP ~ (Data + Behavior)
    - sirwhinesalot 5y ago
      ECS is a type of relational model, it has nothing to do with OO. EDIT: just to make it clearer, both Simula Style OO and Smalltalk Style OO bundle data and behavior together. The Entity owns the Components and the System. ECSs are much more like relational databases where an entity is a primary key, components are tables and systems are queries (that also mutate the database). The entity is subservient to the systems, not the other way around. If somehow a relational database is in any way equivalent to OO then we've reached peak clown world as far as terminology goes.
nomel 5y ago
I think I need help understanding this. My understanding of data oriented systems is there's a desire to put related data physical close, in memory. It doesn't remove state, it just packs it differently. To be honest, I'm confused by most of the comments here.
- ummonk 5y ago
  One of the benefits of a data oriented ECS setup is that it's much more cache optimal due to the way data is packed, but that's not necessarily the primary reason to use it. In fact, on the data packing implementation side, there are actually differing ways in which the data can be packed, with differing performance pros and cons depending on type of data / access pattern. Really, the primary benefit is that you get a much cleaner paradigm to work with. Here's a good basic overview of the point of an ECS system: https://iolivia.me/posts/entity-component-system-explained/ https://iolivia.me/posts/entity-component-system-explained/ In particular I'll point to the key quote in that post that distinguishes ECS from OOP encapsulation: "The whole idea is separating behaviour from logic, so all the data goes in components and all the behaviour goes into systems."
  - jay_kyburz 5y ago
    I bet save / load is a lot easier too! :)
_9omd 5y ago
But aren't they doing that mostly for performance via better memory layout and thus better cache locality? ie: arrays of objects vs objects of arrays. It's a sacrifice of code architecture for performance. I feel like games are actually a good example where OOP makes sense, since there is inherently so much state and encapsulation is useful.
- skavi 5y ago
  Bevy is an ECS based engine, and it’s actually very nice to use. It adds a lot of ergonomics to that experience.
- dragonwriter 5y ago
  > I feel like games are actually a good example where OOP makes sense Intuitively, yes. In practice, I think once you actually use an ECS for a game you won't want to program them in the traditional OOP way.
- lewispollard 5y ago
  It's every game dev's first mistake to start adding, say, weapon types to their game by first creating an Item class, then creating a Weapon subclass, Sword inherits that, Shortsword inherits that... And so on. Makes sense, right? It's exactly what OO is for. Except games rarely have that rigid a structure, and maybe you want a sword that also has laser gun features, or an axe that's also a magic staff. That's a lot of subclassing and further dividing up your game objects into rigid hierarchies that become difficult to modify later without unintentionally breaking stuff (was it the logic in the Sword class that grants that damage bonus, or in the Weapon class?) It's nicer to be able to say "I have a weapon entity, I'm going to attach the `SliceDamage" component, the "MagicAttack" component, and so on, and call it a magic axe. It's easier to maintain, it can change at runtime, and the behaviour code only exists in a component file that only does that behaviour, rather than nestled in some lowest common denominator of a hierarchy of classes.

Games are actually moving away from OOP by separating out state into a data oriented system.

by ummonk 5y ago

Games are actually moving away from OOP by separating out state into a data oriented system.

deleted 5y ago

[deleted]

Wohlf 5y ago

In my experience many game companies were never big on OOP in the first place.

kaba0 5y ago

Weren’t games already written with entity component systems?

ummonk 5y ago
I’m happy to be corrected as I’ve only really dabbled with Indie game development on and off but my general impression is that the paradigms have gone procedural -> object oriented -> ECS. For example, Unity is designed around GameObjects but is now adding building out the DOTS framework stack that’s more of a first party ECS system.
- seanmcdirmid 5y ago
  Nobody has ever been able to convince me that these informal object systems (eg ECS) aren’t really just OOP with different extensibility mechanisms and/or a different place to stow away object state (oh, and let’s call the objects entities instead). The only real diversion from objects in games that I’ve seen is the work in Andrew Kennedy’s thesis on FRP for games.
  - ummonk 5y ago
    Yes and no. The EC part of ECS is definitely object oriented - more so than mainstream object-oriented systems / languages, in that it favors composition over inheritance (i.e. entities are compositions of components). But the S in ECS breaks the most fundamental tenet of object-oriented programming - encapsulation of state. And this separation between entities/components and systems is what makes data oriented programming so much cleaner and more powerful than OOP.
    - seanmcdirmid 5y ago
      If the state is encapsulated somewhere else, why is it no longer OOP? I don’t think Alan Kay would say that having each object simply be a handle into a table of values meant they could no longer be called objects. Heck, if we take the FactoryFactory example as being the bad thing about OOP, and consider that this comes from the GoF design pattern book, there is already a pattern in that book that closely resembles ripping the state out of an object and putting it somewhere else. Again, it is definitely not strawman OOP, but not very many programming systems are, especially modern ones.
      - ummonk 5y ago
        Encapsulation in OOP terms means the state is encapsulated with the logic that fetches / mutates it. ECS explicitly is designed to do the opposite. It’s really that simple. The issue isn’t about how you store the objects but about whether the framework logically encapsulates object data with its associated logic.
        seanmcdirmid 5y ago
        > Encapsulation in OOP terms means the state is encapsulated with the logic that fetches / mutates it. No it doesn't. There are plenty of examples in OO where that isn't true or no physics engine that's been build in the last two decades would work at all. The only core thing needed for OO is that objects have unique identities that then enable a notion of associated state at all. A pure system would not allow for an unbounded number of unique identities at all, you would not really be able to talk about objects at all (or entities or whatever object synonym is preferred).
        ummonk 5y ago
        > No it doesn't. Yes, yes it does. > There are plenty of examples in OO where that isn't true or no physics engine that's been build in the last two decades would work at all. It would be surprising if most physics engines were built in an object-oriented way. The only one I'm familiar with, ODE, certainly isn't object-oriented. > The only core thing needed for OO is that objects have unique identities that then enable a notion of associated state at all. A pure system would not allow for an unbounded number of unique identities at all, you would not really be able to talk about objects at all (or entities or whatever object synonym is preferred). No, objects in OOP have not just their own unique identities but have their own behavior. Encapsulation is the most fundamental pillar of object-oriented programming. Without that, any procedural C code that makes use of structs could be called object-oriented, since structs would then be synonymous with "objects".
  - rawoke083600 5y ago
    I'm no expert, but here are my 2cents. One of my "ahhh moments" with ECS was when someone pointed out. The ECS has a very 'strict' boundary on DATA(attributes,entities,components) VS BEHAVIOR (methods,systems,functions). The 'traditional OOP' usually 'smash/hide/design/encapsulate' these two conflicting powers into one 'Entity' I think it's 'easier' to write a ball-of-mud in OOP for games, then it is to write ball-of-mud with ECS. *NOTICE I said 'easier' not 'impossible' I love the distinctions between BEHAVIOR and DATA, from an organizational point of view. The bigger the whole system is the more value I think a good programmer can get with ECS. Imagine having to "implement" gravity for 100 different types of 'Objects'. Sure The ECS way would be to have a System(Gravity) that executes the 'same computing' on all entities with a 'MassComponents' and 'PosComponents' for example. The Entity would usually not need to know ANYTHING about Gravity. Sure the OOP way one can inherit but eventually you inherit yourself into a corner (diamond-problem). My 2cents - YMMY TL;DR (just squint hard enough) ECS ~= (Data | Behavior) OOP ~ (Data + Behavior)
  - sirwhinesalot 5y ago
    ECS is a type of relational model, it has nothing to do with OO. EDIT: just to make it clearer, both Simula Style OO and Smalltalk Style OO bundle data and behavior together. The Entity owns the Components and the System. ECSs are much more like relational databases where an entity is a primary key, components are tables and systems are queries (that also mutate the database). The entity is subservient to the systems, not the other way around. If somehow a relational database is in any way equivalent to OO then we've reached peak clown world as far as terminology goes.

nomel 5y ago

I think I need help understanding this. My understanding of data oriented systems is there's a desire to put related data physical close, in memory. It doesn't remove state, it just packs it differently. To be honest, I'm confused by most of the comments here.

ummonk 5y ago
One of the benefits of a data oriented ECS setup is that it's much more cache optimal due to the way data is packed, but that's not necessarily the primary reason to use it. In fact, on the data packing implementation side, there are actually differing ways in which the data can be packed, with differing performance pros and cons depending on type of data / access pattern. Really, the primary benefit is that you get a much cleaner paradigm to work with. Here's a good basic overview of the point of an ECS system: https://iolivia.me/posts/entity-component-system-explained/ https://iolivia.me/posts/entity-component-system-explained/ In particular I'll point to the key quote in that post that distinguishes ECS from OOP encapsulation: "The whole idea is separating behaviour from logic, so all the data goes in components and all the behaviour goes into systems."
- jay_kyburz 5y ago
  I bet save / load is a lot easier too! :)

_9omd 5y ago

But aren't they doing that mostly for performance via better memory layout and thus better cache locality? ie: arrays of objects vs objects of arrays. It's a sacrifice of code architecture for performance. I feel like games are actually a good example where OOP makes sense, since there is inherently so much state and encapsulation is useful.

skavi 5y ago
Bevy is an ECS based engine, and it’s actually very nice to use. It adds a lot of ergonomics to that experience.
dragonwriter 5y ago
> I feel like games are actually a good example where OOP makes sense Intuitively, yes. In practice, I think once you actually use an ECS for a game you won't want to program them in the traditional OOP way.
lewispollard 5y ago
It's every game dev's first mistake to start adding, say, weapon types to their game by first creating an Item class, then creating a Weapon subclass, Sword inherits that, Shortsword inherits that... And so on. Makes sense, right? It's exactly what OO is for. Except games rarely have that rigid a structure, and maybe you want a sword that also has laser gun features, or an axe that's also a magic staff. That's a lot of subclassing and further dividing up your game objects into rigid hierarchies that become difficult to modify later without unintentionally breaking stuff (was it the logic in the Sword class that grants that damage bonus, or in the Weapon class?) It's nicer to be able to say "I have a weapon entity, I'm going to attach the `SliceDamage" component, the "MagicAttack" component, and so on, and call it a magic axe. It's easier to maintain, it can change at runtime, and the behaviour code only exists in a component file that only does that behaviour, rather than nestled in some lowest common denominator of a hierarchy of classes.