4 ms·

Hickey nails this one in his talks. When you make something a class, that's NOT an abstraction, that's a concretion. You make a Tool class, you haven't abstract

Hickey nails this one in his talks. When you make something a class, that's NOT an abstraction, that's a concretion. You make a Tool class, you haven't abstracted what a tool is, you've made a fixed decision about what it is. For games that want this level of complex interaction between components, entity component systems are the way to go.

oxfeed65261 5y ago
I’d love a reference to this talk.
- j-pb 5y ago
  "Maybe Not" talks about these compositional ideas: https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug
- blacktriangle 5y ago
  https://youtu.be/2V1FtfBDsLU?t=2268 https://youtu.be/2V1FtfBDsLU?t=2268 Goes until 43:25. The whole talk is worth watching. It's basically about the higher level problems of business app development, how to address them, and how Clojure does address them.
imtringued 5y ago
I would argue that if you have a "Item" class then it is the set of all concretions/specializations. By creating a tool class you haven't extended the set, you've instantiated a subset of the set of items that contains the items that are tools but nothing else. It's obvious why it is so difficult to represent a tool that is also e.g. a consumable item. The set of items that are both tools and consumables is a superset of the set of tools and set of items. You can't represent it through a second layer of inheritance because it only lets you create a subset of the items that are tools. You obviously have to use multiple inheritance for something like this because it will let you form the set of items that are both tools and consumables. Of course, multiple inheritance is very messy so you should try to avoid it.
Kinrany 5y ago
> For games that want this level of complex interaction between components, entity component systems are the way to go. Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well. One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components. Old writeup (not mine): https://github.com/kvark/froggy/wiki/Component-Graph-System https://github.com/kvark/froggy/wiki/Component-Graph-System
- blacktriangle 5y ago
  I think this is more of a language paradigm problem. Game programming is very much tied up in C++ and C# for historical and performance reasons, ECS is a way to try and graft what is entirely natural in a more value-based language into OOP mechanics and C++/C# type systems. ECS is so common and easy in lisps that it doesn't even warrant its own name.
  - Kinrany 5y ago
    Rust game engines are all based on ECS too.
  - pjmlp 5y ago
    Ironically, the ECS advocates kind of miss the part that ECS models are based on OOP literature. https://en.wikipedia.org/wiki/Component-based_software_engineering#Component_models https://en.wikipedia.org/wiki/Component-based_software_engin... "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/Component-Software-Beyond-Object-Oriented-Programming/dp/0201178885 https://www.amazon.com/Component-Software-Beyond-Object-Orie...
- ratww 5y ago
  > One promising direction is getting rid of entities. > > Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components You are essentially describing ECS here. In ECS, entities are nothing but a "handle" without any additional data, normally just an integer used to link common components together.

oxfeed65261 5y ago

I’d love a reference to this talk.

j-pb 5y ago
"Maybe Not" talks about these compositional ideas: https://www.youtube.com/watch?v=YR5WdGrpoug https://www.youtube.com/watch?v=YR5WdGrpoug
blacktriangle 5y ago
https://youtu.be/2V1FtfBDsLU?t=2268 https://youtu.be/2V1FtfBDsLU?t=2268 Goes until 43:25. The whole talk is worth watching. It's basically about the higher level problems of business app development, how to address them, and how Clojure does address them.

imtringued 5y ago

I would argue that if you have a "Item" class then it is the set of all concretions/specializations. By creating a tool class you haven't extended the set, you've instantiated a subset of the set of items that contains the items that are tools but nothing else. It's obvious why it is so difficult to represent a tool that is also e.g. a consumable item. The set of items that are both tools and consumables is a superset of the set of tools and set of items. You can't represent it through a second layer of inheritance because it only lets you create a subset of the items that are tools. You obviously have to use multiple inheritance for something like this because it will let you form the set of items that are both tools and consumables. Of course, multiple inheritance is very messy so you should try to avoid it.

Kinrany 5y ago

> For games that want this level of complex interaction between components, entity component systems are the way to go. Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well. One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components. Old writeup (not mine): https://github.com/kvark/froggy/wiki/Component-Graph-System https://github.com/kvark/froggy/wiki/Component-Graph-System

blacktriangle 5y ago
I think this is more of a language paradigm problem. Game programming is very much tied up in C++ and C# for historical and performance reasons, ECS is a way to try and graft what is entirely natural in a more value-based language into OOP mechanics and C++/C# type systems. ECS is so common and easy in lisps that it doesn't even warrant its own name.
- Kinrany 5y ago
  Rust game engines are all based on ECS too.
- pjmlp 5y ago
  Ironically, the ECS advocates kind of miss the part that ECS models are based on OOP literature. https://en.wikipedia.org/wiki/Component-based_software_engineering#Component_models https://en.wikipedia.org/wiki/Component-based_software_engin... "Component Software: Beyond Object-Oriented Programming" https://www.amazon.com/Component-Software-Beyond-Object-Oriented-Programming/dp/0201178885 https://www.amazon.com/Component-Software-Beyond-Object-Orie...
ratww 5y ago
> One promising direction is getting rid of entities. > > Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components You are essentially describing ECS here. In ECS, entities are nothing but a "handle" without any additional data, normally just an integer used to link common components together.