Differences

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

--- en:toolworks:docs:apparatus:ecs [2021/04/02 22:13] – Add some dummy text jispar
+++ en:toolworks:docs:apparatus:ecs [2021/12/18 15:19] (current) – поправил некоторые слова jispar
@@ Line 1: / Line 1: @@
-==== Introduction to ECS+ ====
+====== Introduction to ECS ======
-Talking about OOP (object-oriented programming) 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. What does it mean? 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:
+===== OOP Quirks & Limitations =====
+Prior to exploring the ECS main concepts, we should address the [[wp>Object-oriented_programming|object-oriented programming (OOP)]] pattern and some of the issues related to it. That's because the current state of Unreal Engine's user-level API is basically OOP-based. Even the actor's component model is somewhat limited and is mostly static in nature. It really shouldn't be confused with a data-oriented approach we're presenting you with.
+A large portion of C++ language is also OOP and it was one of the main reasons behind its original design. It seems like the general top-level UE's architecture was heavily based on C++ some features, or at least was heavily inspired by them. That's quite logical if you think of it. In the end C++ is the main language behind the tech. The Unreal build toolset (UBT and UHT) is implemented in C# which is also an OOP language by the way.
+So, when we develop games (and software in general) the OOP-way, we usually decompose all of the available entities and concepts into the hierarchies of their corresponding types. In terms of Unreal Engine those are mainly called Objects (or ''[[ue>API/Runtime/CoreUObject/UObject/UObject|UObjects]]'' if we are talking about C++ coding part). We create the hierarchies of those classes where each class introduces some new properties and methods while also inherting the properties and methods of its parent (base) class. All of Unrealean classes are derived from a single root Object (''UObject'') ancestor class in the end. Every time we create a new Blueprint (or a new C++ class) it basically derives from this root class.
+As the time developing our game goes we usually start to notice that some of our classes tend to have more and more in common. So we begin to [[wp>Code_refactoring|refactor]] the codebase (or the Blueprint assets), extracting those common properties and methods into some separate base classes and try to derive the other classes from them. This task can already be quite sophisticated since Unreal's object model does not support multiple inheritance (while C++ actually does), so you basically can't derive your class from the two common ones. Anyways, those new common classes in turn may become too common so the new common common class is introduced and the process repeats.
+A quite popular example for that approach is a tree of animal inheritance, where a root class represents basically any animal existing (something like ''UObject''), while others derived represent some separate animal sorts and kinds on their own:
 {{ :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 ECS (that is [[https://en.wikipedia.org/wiki/Entity_component_system|Entity component system]]).
-So what are the main concepts? Here we make an attempt to understand each abstraction as individual entity. Globally, there are some states each entity may be in or not. From this point of view, each entity can be represented as vector of 1-es and 0-es, where each vector's component represents if the entity at the current moment is in the defined state or not. That's more: some entities may be constructed in such a way that they fundamentally can't go to certain states. For example, let us say we declare state 'swimming' and the entity 'house' then (that's quite logical) we can't move 'house' entity to the 'swimming' state. So then each vector now have different components number depending on which entity it represents. Now let's call vector component representing certain state type as 'detail'. Each entity has a variety of details and each detail of the entity has the value 0 ('disabled') if the entity isn't in the detail state right now, and the value 1('enabled') if the entity is in the corresponding state.
+The descendant types inherit the properties of their respective base types, so by altering the base class properties we also change the current state of the objects, if they are of some derived descendant type. We can also introduce some [[wp>Virtual_function|"virtual"]] overridable methods to be able to modify their behavior in the derived classes.
+All of that functionality surely look quite useful and nice, isn't it? Well yes it is, until you have like 100 classes. The problem here is that your game logic becomes too scattered across the class-layers in the hierarchy. You tend to forget what is defined on what level, what is overridable and what's not. The amount of coupling between the entities becomes scary and error-prone. Your coding partners who wrote some aspect of the base classes, become the keepers of some "secret knowledge". The time of refactoring sky-rockets for this every-growing hierarchy. This "ceremonial" job becomes your job itself, but not the development of the final end-user features. Not a good thing at all, considering how limited the time and resources can be.
+===== ECS to The Rescues =====
+A solution to this hassle could be an approach called [[wp>Entity_component_system|Entity–component–system (or ECS for short)]].
+There are no hierarchies in terms of ECS, as every game object (i.e. //entity//) is basically flat in its nature. It consists of data-only parts called //components//. You can combine those arbitrary on a per-entity basis.
+Want your RPG character become a poison damage dealer? Add a ''poisonous'' component to it and consider it done, as long as you also implement a //system// that actually solves the poison mechanic.
+Systems are remote to the details they operate upon. That's also a feature of ECS. They are like distant code blocks that take certain details as their operands and evaluate a certain result. Systems are run after other systems and together they form a complete pipeline of your game.
+That's basically it. But how come such a useful concept is not implemented in Unreal Engine yet? Well, it actually is, take Niagara as an example. The rendering pipeline can also be considered a pipeline. In other words, that may be all sorts of specific data-driven approaches taken in Unreal Engine, but none of them are as general-purpose as its OOP nature. We provide such approach for any of the user-available side of the Engine!
+Make sure your read our [[en:toolworks:docs:apparatus:ecs-glossary|Apparatus to ECS Glossary]] to get to know our terminology.
+==== 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++.
+==== Built-in Mechanisms ====
+The ''Mechanical'' class is also an interface, with the most useful mechanisms already implemented:
+  * ''MechanicalActor'' (inherited from ''Actor''),
+  * ''MechanicalGameModeBase'' (''GameModeBase''),
+  * ''MechanicalGameMode'' (''GameMode'').
+You would hardly ever need to implement your own mechanisms. Should you wish to, you can also do it in C++.
+==== Third-Party Resources ====
+Together with our community we have gathered a collection of useful information regarding ECS and data-oriented in general.
+You may study it for a broader view on the subject:
+=== English ===
+{{youtube>tONOW7Luln8?medium}}
+{{youtube>W3aieHjyNvw?medium}}
+{{youtube>g1TsP60z2OQ?medium}}
-You can imagine each entity as a box of details.
+=== Russian ===
-These details have the bool variable 'bActive' and if it's set to 0 - then the detail is disabled and is enabled otherwise. There is ability to remove and add details dynamically if it's necessary. For example 'man' can get hurt from the pistol shot in the chest but only not when he has the bulletproof vest (technically you can declare such a detail like 'getting a pistol shot' what will be something like 'temporary state' and immediately should be replaced by other detail like 'injured' one).
-Ok, we have some entities which contain different details. Furthermore we can apply some changes to all the entities based on which details they have and if these details are enabled or not. For example, for each entity which has the details 'burnable' and 'burning' both enabled, we can decrease their health (or armor) and then disable (or absolutely remove) 'burning' details from them (simply speaking, the fire went out).
+These are in Russian, but you may still want watch them with automatically-generated subtitles.
-As you understand these changes are actually defining the whole game logic and we have to run them continuously during the playing to keep dynamics of states. It's also quite clear we can place all the code which will apply these changes in the one class, so it becomes easier to view and modify them. That class called 'Mechanism' and it's responsible for applying changes to each object depending on which details it has. Now the whole picture is next:
+{{youtube>IsJmBiRWBj8?medium}}
-{{ :en:toolworks:docs:ecs-example.jpg?nolink |}}
-Here disabled details are crossed out, but details which will produce some changes are highlighted. Of course a mechanism can't process entities parallelly, instead it iterate other each entity and check determined cases. Each case declares which details should the entity has and which of them should be enabled or disabled. If an entity complies with the case requirements, some changes will be applied to it, else the next case will be checked out and so so on. Thus, the 'case' is something contains a vector of 0-es and 1-es representing 'being in certain states':
-{{ :en:toolworks:docs:apparatus-case-examples.png?nolink |}}
-A programmer declares cases and what actions to undertake for each entity what complying with the case. **You should also understand that the 'another case' in the example above will determine what to execute over the entities what have the detail 'hurt' disabled and the entities what haven't this detail.**
-You also may say the iteration across all the entities is **slower** than the use of UE4 dispatchers or simple function calling, but on the low level it's coded in the most optimized way, so actually there is no any difference.