Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
en:toolworks:docs:apparatus:ecs [2021/04/02 22:58] – jispar | en:toolworks:docs:apparatus:ecs [2021/04/08 10:24] – vladius | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Introduction to ECS+ ====== | + | ====== Introduction to ECS ====== |
- | //ECS+ is a new programming | + | |
+ | Talking about object-oriented | ||
- | 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', | ||
{{ : | {{ : | ||
- | 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:// | + | By using the base class properties we can change the current state of the objects in the derived class. But the problem |
- | Apparatus provides all of the basic ECS idioms and even more. To be unambiguous | + | |
- | ^ ECS term ^ Apparatus | + | A solution to this game development problem is an approach called [[wp> |
+ | |||
+ | 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 | ||
| Entity | | Entity | ||
| Component | | Component | ||
Line 17: | Line 19: | ||
| Chunk | Belt | | | Chunk | Belt | | ||
- | ==== Source' | + | ==== 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). The term ECS+ in itself should be treated as more of a synonym for the " | ||
+ | |||
+ | Generally speaking, in our own philosophy, engineering should never be " | ||
+ | |||
+ | ==== Built-in Subjects ==== | ||
+ | |||
+ | At a lower level, | ||
+ | |||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | Those should be sufficient for the most cases, but you can easily implement your own additional subject classes in C++. | ||
+ | |||
+ | ==== Built-in Mechanisms ==== | ||
+ | |||
+ | The '' | ||
- | At the lower level, | + | * '' |
- | * 'SubjectiveActorComponent' | + | * '' |
- | * 'SubjectiveUserWidget' (based on 'UserWidget'), | + | * '' |
- | * 'SubjectiveActor' (based on 'Actor'). | + | |
- | If you open the source, you can see they actually implement an 'ISubjective' | + | |
- | 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++. |
- | * ' | + | |
- | * ' | + | |
- | * ' | + |