====== Apparatus Glossary ====== Apparatus provides all of the basic ECS idioms and even more. To be unambiguous (and self-sustained) our framework uses a somewhat different naming scheme as compared to the classic ECS. Here is the list of the terms used throughout this manual: ^ Common Term ^ Term ^ Description ^ Known ECS Term ^ | Subject | [[en:toolworks:docs:apparatus:subject|Subject]] | The low-level composition of Traits. | Entity | | ::: | [[en:toolworks:docs:apparatus:subjective|Subjective]] | The higher-level part of a Subject containing Details. | N/A | | Component | [[en:toolworks:docs:apparatus:trait|Trait]] | The struct-based building data block. | Component | | ::: | [[en:toolworks:docs:apparatus:detail|Detail]] | The class-based building data block. | N/A | | Iterable | [[en:toolworks:docs:apparatus:chunk|Chunk]] | The storage for Subjects Slots and Traits. | Chunk | | ::: | [[en:toolworks:docs:apparatus:belt|Belt]] | The storage for Subjective Slots. | Chunk | | N/A | [[en:toolworks:docs:apparatus:slot|Slot]] | A single element in an Iterable. | N/A | | ::: | [[en:toolworks:docs:apparatus:flagmark|Flagmark]] | The manual bit mask specification of the Subject. | N/A | | ::: | [[en:toolworks:docs:apparatus:traitmark|Traitmark]] | The traits composition specification of the Subject. | Archetype | | ::: | [[en:toolworks:docs:apparatus:detailmark|Detailmark]] | The details composition specification of the Subjective. | N/A | | ::: | [[en:toolworks:docs:apparatus:fingerprint|Fingerprint]] | The full specification of a Subject's topology. | N/A | | ::: | [[en:toolworks:docs:apparatus:filter|Filter]] | The including/excluding selector for the Subjects. | Query | | ::: | [[en:toolworks:docs:apparatus:mechanic|Mechanic]] | The processing logic for the Subjects. | System | | ::: | [[en:toolworks:docs:apparatus:mechanism|Mechanism]] | The world-based subset of Subjects and Mechanicals. | N/A | | ::: | [[en:toolworks:docs:apparatus:machine|Machine]] | The global runtime state of the framework. | N/A | ===== Reasoning (Rationale) ===== Why did we chose the non-conventional naming scheme in the first place? Well, we obviously consider ours to be a better one overall and here is why. "Entity" is a much broader term, that is usually reserved for some general-purpose objects and is quite useful as a general documentation term. On the other hand the word "Subject" is better associated with something that is not autonomous by its own and is actually dependent, subordinate. The word "system" is also so much broader and could denote almost anything, e.g. particle system, saving/loading system, system library, etc. "Mechanic" is clearly something deeply related to the game ticking and the game design as a whole. As of "component" – this is basically already reserved by Unreal Engine [[ue>components-in-unreal-engine/|itself]]. "Detail"/"Trait" are free to use and are quite obvious to be Components of something (i.e. Subjects). We still use the Component term when referring to both Traits and Details at the same time. It may be hard to remember at first, but you'll get used to it and the logic behind the terms will eventually become your own. Just to sum this all up, the "Entity Component System" is basically transformed into the "Subject Trait/Detail (or Component) Mechanic". Please, get back to this article from time to time if you get lost easily within our world of things.