Differences

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

--- en:toolworks:docs:apparatus:ecs [2021/04/08 00:57] – vladius
+++ en:toolworks:docs:apparatus:ecs [2021/04/14 14:56] – vladius
@@ Line 1: / Line 1: @@
-====== Introduction to ECS+ ======
+====== Introduction to ECS ======
-//ECS+ is a newer data-driven programming paradigm based on ECS and implemented in Apparatus.//
+===== OOP Quirks & Limitations =====
-Talking about OOP (object-oriented programming), we consider our practical task as multiplicity of special abstract things. In terms of Unreal Engine these abstractions are mainly called Objects (or ''UObjects'' code-wise). Furthermore we apply a principle like an inheritance upon them. We create some main abstraction layer called 'Base class', define some properties (i.e. variables and functions) and by deriving from that class we can create other abstractions which in turn get all the parent properties and define their own additional, distinctive ones. The most popular example for that approach is a tree of animal inheritance, where the base class represent any animal existing, but the others (derived from the base one) represent some separate animal sorts and kinds:
+Prior to discussing some ECS concepts, we have address the [[wp>Object-oriented_programming|object-oriented programming (OOP)]] and its issues, since the current state of Unreal Engine's user-level API is basically OOP-based. The actor's component model is also kind of limited and is mostly static in nature.
+While developing games (and software in general) OOP-way, we decompose of all the available entities and concepts into 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, so we create hierarchies of types (classes) derived from a single root ''UObject'' ancestor. Every time we create a new Blueprint (or a C++ class) it basically derives from this root class.
+As the time goes we notice that our classes become more and more in common and begin to [[wp>Code_refactoring|refactor]] the codebase (or the Blueprint assets), while extracting those common facilities into some separate base classes. Those in turn become the ancestors and we derive certain types from them, that should share their functionality.
+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 the base class properties we can change the current state of the objects in the derived class. But the problem is the game logic can become too scattered across those classes and layers.
+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.
-A solution to this game development problem is an approach called [[https://en.wikipedia.org/wiki/Entity_component_system|ECS]].
+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.
-Apparatus provides all of the basic ECS idioms and even more. To be unambiguous the framework it uses a different naming scheme as compared to 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            |
 ==== Built-in Subjects ====