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:57] – [Table] 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 is the game logic can become too scattered across those classes and layers. |
- | Apparatus' | + | |
- | ^ 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++. |
- | * ' | + | |
- | * ' | + | |
- | * ' | + |