6 ms·

ECS is often implemented in an OOP language. I know of no ECS languages. You have objects that you iterate over and apply changes to the struct or object's fie

ECS is often implemented in an OOP language. I know of no ECS languages. You have objects that you iterate over and apply changes to the struct or object's fields like x and y coordinates in a game tick for the "next state" Essentially you end up with lots of global functions and very large API space that has no ordering. There's inherent ordering to global function application to produce the correct result. So it produces complex APIs. If you move the global functions to the entity objects themselves, you end up with OOP. So I'm not really sure what the author is arguing for.

cout 5y ago
What would an ECS language look like? Would it differ substantially from an OO language? ECS seems to me more like a pattern than a paradigm.
- galangalalgol 5y ago
  And that pattern is easy to implement in C or fortran 77 without being unidiomatic. So I don't vthing you need anything special. Edit: to clarify, a system can just be a function, an entity just an ID and a component should be plain old data anyway, so a struct is perfect.
  - ratww 5y ago
    > a system can just be a function, an entity just an ID and a component should be plain old data anyway, so a struct is perfect. Correct. This is exactly how most ECS frameworks are implemented today (except when it's implemented in languages that doesn't have those features, of course).
- kazoomonger 5y ago
  I don't think ECS as such would really make a language on its own, but languages that use traits instead of inheritance would be approximately that. Both ECS and traits eschew using the inheritance-style "is-a" thinking. ECS goes for "has-a" thinking, and traits go for "acts-as" thinking. A few popular trait-based languages that would feel comfortable to someone familiar with ECS are Rust or Go.
hgs3 5y ago
> I know of no ECS languages. Any language with mixins and reflection can do ECS. e.g. Use mixins (components) and reflection to check which mixins an object (entity) has, then executing a code path (system) based upon that answer. Many dynamic languages, like Ruby, support this combination of features. I think the issue is many game developers work in C++ which lacks them. There is a school of thought that design patterns are actually missing language features [1]. ECS seems like a text book case. [1] http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
- anonymoushn 5y ago
  ECS is commonly implemented without reflection. What are these implementations missing?
  - hgs3 5y ago
    If the language in question has decent reflective capabilities, then I'd question why they don't use it. Perhaps they ran some benchmarks and found the language runtime performance lacking or maybe they are implementing the ECS pattern to the letter (e.g. using an integer to represent an "entity") as opposed to implementing ECS as a concept.
ratww 5y ago
ECS can also be implemented in functional or imperative languages, and it often is. The fact that ECS can be implemented in OOP languages doesn't make it an OOP pattern, only that OOP languages have Turing-completeness. You could also write Pure-FP code or implement Prolog in an OOP language, or vice-versa. > If you move the global functions to the entity objects themselves, you end up with OOP. You're probably talking about moving the global functions (also called Systems) into the the Component objects. Entities in ECS are normally just integers to which components are attached to, the global functions you're talking to correspond to This is possible for the simplest usages of ECS, however this is very limiting. One of the most important aspects of ECS, especially in modern frameworks, is the possibility of Systems (the "global functions") to operate in more than one kind of Component at a time. For example: a collision detection System might want to operate on both "Position" and "Visibility" Components to avoid performing collision detection on invisible components. This ability is crucial to ECS for two reasons: to have good separation of concerns, but also for performance. With your suggestion in OOP, you would have to do that with multiple inheritance, or maybe by picking one Component to host the System and break encapsulation.
- jayd16 5y ago
  Why do critics think looping over an array is somehow incomprehensible in OO and must be replaced with inheritance or something? Most ECS implementations are in OO languages. In Unity/C#, those systems are objects those arrays holding component information are even objects! Its really not a stretch for OOP. Its just a design pattern.
  - ratww 5y ago
    ECS is doing a bit more than looping over arrays, though. In modern production ECS systems there's often the case where a System acts over two or more Components is very common, and looping itself is not good enough for those cases (because you get O(n^2), O(n^3), O(n^4), etc, etc complexity), so it's nowhere near as simple as that. Like I said, it's possible to implement anything that is computable in any Turing-complete language. The fact that there are some ECS implementations in OOP languages speaks more to the popularity of those languages, rather than their capabilities or suitability to having ECS implemented in it. Of course ECS is going to need classes in languages that don't allow structs. Of course ECS is going to need classes in languages that don't allow freestanding functions. But that's doesn't mean that everything that is implemented in an OOP language can be considered just another OOP pattern. ECS is a more foundational way of organising code, in the same space as OOP itself. One of OOP features is encapsulation: data and methods living together. ECS enforces the complete opposite: complete separation. Another OOP feature is inheritance. ECS removes inheritance and replaces with composition. If one says that ECS a just another design pattern, then it's only fair to say that OOP is also just a design pattern in itself, since I could implement OOP itself in C (see Linux Kernel), Haskell or ECS if I wanted.
dkarl 5y ago
I agree. I think the author leans too much on the supposed incompatibility of OO style and ECS style, which they explain only by linking to the Wikipedia page for object-relational impedance mismatch. I've worked in many systems that satisfy the author's description of ECS in their treatment of the central domain objects, and they were all built in OO languages and were thoroughly OO in the rest of the codebase. I think the author was on the right track in recognizing OO as "a set of mechanics we can cherry pick," but I really don't follow how they think an embrace of ECS style would force programmers to abandon most or all OO mechanics.
cma 5y ago
> I know of no ECS languages. Shouldn't Unity's DOTS/Burst subset of C# count? It gets optimization from alias analysis that you can't get with an ECS in C++ or unrestricted C#. https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual/index.html https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...

cout 5y ago

What would an ECS language look like? Would it differ substantially from an OO language? ECS seems to me more like a pattern than a paradigm.

galangalalgol 5y ago
And that pattern is easy to implement in C or fortran 77 without being unidiomatic. So I don't vthing you need anything special. Edit: to clarify, a system can just be a function, an entity just an ID and a component should be plain old data anyway, so a struct is perfect.
- ratww 5y ago
  > a system can just be a function, an entity just an ID and a component should be plain old data anyway, so a struct is perfect. Correct. This is exactly how most ECS frameworks are implemented today (except when it's implemented in languages that doesn't have those features, of course).
kazoomonger 5y ago
I don't think ECS as such would really make a language on its own, but languages that use traits instead of inheritance would be approximately that. Both ECS and traits eschew using the inheritance-style "is-a" thinking. ECS goes for "has-a" thinking, and traits go for "acts-as" thinking. A few popular trait-based languages that would feel comfortable to someone familiar with ECS are Rust or Go.

hgs3 5y ago

> I know of no ECS languages. Any language with mixins and reflection can do ECS. e.g. Use mixins (components) and reflection to check which mixins an object (entity) has, then executing a code path (system) based upon that answer. Many dynamic languages, like Ruby, support this combination of features. I think the issue is many game developers work in C++ which lacks them. There is a school of thought that design patterns are actually missing language features [1]. ECS seems like a text book case. [1] http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures http://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures

anonymoushn 5y ago
ECS is commonly implemented without reflection. What are these implementations missing?
- hgs3 5y ago
  If the language in question has decent reflective capabilities, then I'd question why they don't use it. Perhaps they ran some benchmarks and found the language runtime performance lacking or maybe they are implementing the ECS pattern to the letter (e.g. using an integer to represent an "entity") as opposed to implementing ECS as a concept.

ratww 5y ago

ECS can also be implemented in functional or imperative languages, and it often is. The fact that ECS can be implemented in OOP languages doesn't make it an OOP pattern, only that OOP languages have Turing-completeness. You could also write Pure-FP code or implement Prolog in an OOP language, or vice-versa. > If you move the global functions to the entity objects themselves, you end up with OOP. You're probably talking about moving the global functions (also called Systems) into the the Component objects. Entities in ECS are normally just integers to which components are attached to, the global functions you're talking to correspond to This is possible for the simplest usages of ECS, however this is very limiting. One of the most important aspects of ECS, especially in modern frameworks, is the possibility of Systems (the "global functions") to operate in more than one kind of Component at a time. For example: a collision detection System might want to operate on both "Position" and "Visibility" Components to avoid performing collision detection on invisible components. This ability is crucial to ECS for two reasons: to have good separation of concerns, but also for performance. With your suggestion in OOP, you would have to do that with multiple inheritance, or maybe by picking one Component to host the System and break encapsulation.

jayd16 5y ago
Why do critics think looping over an array is somehow incomprehensible in OO and must be replaced with inheritance or something? Most ECS implementations are in OO languages. In Unity/C#, those systems are objects those arrays holding component information are even objects! Its really not a stretch for OOP. Its just a design pattern.
- ratww 5y ago
  ECS is doing a bit more than looping over arrays, though. In modern production ECS systems there's often the case where a System acts over two or more Components is very common, and looping itself is not good enough for those cases (because you get O(n^2), O(n^3), O(n^4), etc, etc complexity), so it's nowhere near as simple as that. Like I said, it's possible to implement anything that is computable in any Turing-complete language. The fact that there are some ECS implementations in OOP languages speaks more to the popularity of those languages, rather than their capabilities or suitability to having ECS implemented in it. Of course ECS is going to need classes in languages that don't allow structs. Of course ECS is going to need classes in languages that don't allow freestanding functions. But that's doesn't mean that everything that is implemented in an OOP language can be considered just another OOP pattern. ECS is a more foundational way of organising code, in the same space as OOP itself. One of OOP features is encapsulation: data and methods living together. ECS enforces the complete opposite: complete separation. Another OOP feature is inheritance. ECS removes inheritance and replaces with composition. If one says that ECS a just another design pattern, then it's only fair to say that OOP is also just a design pattern in itself, since I could implement OOP itself in C (see Linux Kernel), Haskell or ECS if I wanted.

dkarl 5y ago

I agree. I think the author leans too much on the supposed incompatibility of OO style and ECS style, which they explain only by linking to the Wikipedia page for object-relational impedance mismatch. I've worked in many systems that satisfy the author's description of ECS in their treatment of the central domain objects, and they were all built in OO languages and were thoroughly OO in the rest of the codebase. I think the author was on the right track in recognizing OO as "a set of mechanics we can cherry pick," but I really don't follow how they think an embrace of ECS style would force programmers to abandon most or all OO mechanics.

cma 5y ago

> I know of no ECS languages. Shouldn't Unity's DOTS/Burst subset of C# count? It gets optimization from alias analysis that you can't get with an ECS in C++ or unrestricted C#. https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual/index.html https://docs.unity3d.com/Packages/com.unity.burst@1.3/manual...