But, assuming it isn't, you would make that portion of things it's own component/trait of the entity. Components that rely on it could be declared to require it (in Unity, there is a RequireComponent annotation). So you can be sure if that component exists, that its required component also exists on the entity. I think this is a reasonably satisfying solution.
ECS is a specific software architecture where (among other things) there is no entity level property because an entity is just an identifier--all properties are stored in logicless, data only components. Unity DOTS has an implementation of this.
that's a very very video game centric point of view. If a pattern only works in a couple fields of application, it's not a very good pattern..
> Entity–component–system (ECS) is a software architectural pattern that is mostly used in video game development.
ECS was invented for and is primarily used by videogames.
> If a pattern only works in a couple fields of application, it's not a very good pattern.
I completely and totally disagree. How would you even define a "field of application" without there being patterns and practices that are unique to it? If every domain uses the same techniques, what is the difference?
Off the top of my head, here are some patterns that I rarely see outside of their primary domain:
Programming languages and compilers:
* Recursive descent
* Top-down operator parsing
* The visitor pattern
* Mark-sweep garbage collection and the tri-color abstraction
Game and simulation programming:
* ECS
* Per-frame arena allocators
* Game loops
* Double buffering
* Spatial partitioning
In principle, yes. In practice, I've almost never seen the visitor pattern used outside of programming languages. Maybe once or twice in UI frameworks.
> methods and techniques maybe. These words don't mean the same thing, a pattern is much more general than a technique !
What's your definition of a "pattern" and why wouldn't the things I list fit in it?