Differences

This shows you the differences between two versions of the page.

--- en:toolworks:docs:apparatus:ecs [2021/04/02 22:55] – jispar
+++ en:toolworks:docs:apparatus:ecs [2021/04/08 11:03] – vladius
@@ Line 1: / Line 1: @@
-====== Introduction to ECS+ ======
+====== Introduction to ECS ======
-//ECS+ is a new programming paradigm based on ECS and implemented in Apparatus.//
+Talking about object-oriented programming (OOP), we consider our practical task as multiplicity of special abstract things. In terms of Unreal Engine these abstractions are mainly called Objects, or ''UObjects'' if we are talking about C++ coding. Furthermore we apply a common principle like an inheritance model upon them. We create some main abstraction layer called 'base class', define some properties (i.e. variables and functions) in it and then by deriving a new type from that class we create other abstractions which in turn get all the parental properties and also define their own additional, distinctive ones. A quite popular example for that approach is a tree of animal inheritance, where a base class represents any animal existing, while the others (derived from the base one) represent some separate animal sorts and kinds:
-Talking about OOP, we consider our practical task as multiplicity of special abstract things. In terms of UE4 these abstractions are named UObjects and over them we can apply such a principle like an inheritance. We create some main abstraction called 'Base class', define properties (i.e. variables and functions) and by deriving from that class we can create other abstractions which will get all the parent properties and define their own additional or distinctive ones. The most popular example in that way is the tree of animals inheritance, where the base class represent any animal exist, but the others (derived from the base one) represent separate animal sorts:
 {{ :en:toolworks:docs:oop-example.jpg?nolink |}}
-By using base class properties we can change current state of objects of derived class. But the problem is the game logic can become too scattered across the classes.
-In game development there is such an approach named [[https://en.wikipedia.org/wiki/Entity_component_system|ECS]].
+By altering the base class properties we also change the current state of the whole object of a derived type. We can also use some "virtual" overridable methods to modify the behavior for the derived classes. The problem here is that a game logic can become too scattered across those classes and layers, essentially making those layers horizontal as opposed to a vertical inheritance.
-Apparatus' new ECS+ paradigm may remind you an ECS approach with additions to common OOP technics provided with UE4. Apparatus uses some ECS features, but it has its own peculiarities. To understand all the theme, just view the next table:
+A solution to this game development problem could be an approach called [[wp>Entity_component_system|ECS]].
+Apparatus provides all of the basic ECS idioms and even more. To be unambiguous (and self-sustained, actually) our framework uses a different naming scheme as compared to the classic ECS. Here is the list of analogous terms:
+^ ECS Term            ^ Apparatus Term  ^
+| Entity              | Subject         |
+| Component           | Detail          |
+| System              | Mechanic        |
+| A group of Systems  | Mechanism       |
+| Archetype           | Fingerprint     |
+| Chunk               | Belt            |
+==== About ECS+ ====
+Apparatus takes a broader approach on ECS that we essentially call ECS+ over here. It introduces a greater amount of flexibility with the help of detail (component) inheritance support and sparse expandable, dynamic belts (chunks and archetypes), subject (entity) booting, etc. The term ECS+ in itself should be treated as more of a synonym for the "Apparatus" wording itself, since the product actually implements it and uses a different terminology from the ground up.
+Generally speaking, in our own development philosophy, engineering should never be "pure" or "mathematically correct" but mainly applicable and useful to the end user and/or the developer. Unreal Engine in itself is actually a good demonstration of this approach with so many special cases and design patterns. By having both OOP and ECS patterns combined Apparatus takes the best of three worlds, with UE's blueprint world counted.
+==== Built-in Subjects ====
+At a lower level, ''Subjective'' is an interface and any class that implements it may be called a ''Subject''. There are several subjects already implemented in the framework:
+  * ''SubjectiveActorComponent'' (based on ''ActorComponent''),
+  * ''SubjectiveUserWidget'' (based on ''UserWidget''),
+  * ''SubjectiveActor'' (based on ''Actor'').
+Those should be sufficient for the most cases, but you can easily implement your own additional subject classes in C++.
-^ ECS term   ^ Apparatus term  ^
+==== Built-in Mechanisms ====
-| Entity     | Subject      |
-| Component  | Detail          |
-| System     | Mechanic        |
-==== Source' explanation ====
+The ''Mechanical'' class is also an interface, with the most useful mechanisms already implemented:
-At the lower level, 'Subjective' is an UE4 interface and any class that implements it have an array of enabled/disabled details. If the detail is enabled, then it's 'bIsAvtive' bool variable is set to true. In the Plugin there are several implemented subjects which are:
+  * ''MechanicalActor'' (inherited from ''Actor''),
-  * 'SubjectiveActorComponent' (based on 'ActorComponent'),
+  * ''MechanicalGameModeBase'' (''GameModeBase''),
-  * 'SubjectiveUserWidget' (based on 'UserWidget'),
+  * ''MechanicalGameMode'' (''GameMode'').
-  * 'SubjectiveActor' (based on 'Actor').
-If you open the source, you can see they actually implement an 'ISubjective' interface. So it means you can use these classes as base classes for your own Blueprints and thus easily add to them necessary details.
-Mechanism class is also an interface, and there are also some of them done:
+You would hardly ever need to implement your own mechanisms. Should you wish to, you can also do it in C++.
-  * 'MechanicalActor' (inherited from 'Actor'),
-  * 'MechanicalGameModeBase' ( - 'GameModeBase'),
-  * 'MechanicalGameMode' ( - 'GameMode').