Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
en:toolworks:docs:apparatus:ecs [2021/04/08 10:24] – vladius | en:toolworks:docs:apparatus:ecs [2021/12/18 15:19] (current) – поправил некоторые слова jispar | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== Introduction to ECS ====== | ====== Introduction to ECS ====== | ||
- | Talking about object-oriented programming (OOP), we consider our practical task as multiplicity | + | ===== OOP Quirks & Limitations ===== |
+ | |||
+ | Prior to exploring the ECS main concepts, we should address the [[wp> | ||
+ | |||
+ | 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 | ||
+ | |||
+ | 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> | ||
+ | |||
+ | A quite popular example for that approach is a tree of animal inheritance, | ||
{{ : | {{ : | ||
- | By using the base class properties we can change the current state of the objects | + | The descendant types inherit the properties of their respective base types, so by altering |
- | A solution | + | 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 " |
- | Apparatus provides all of the basic ECS idioms and even more. To be unambiguous the framework it uses a different naming scheme as compared | + | ===== ECS to The Rescues ===== |
- | ^ ECS Term ^ Apparatus Term ^ | + | A solution to this hassle could be an approach called [[wp> |
- | | Entity | + | |
- | | Component | + | 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 // |
- | | System | + | |
- | | A group of Systems | + | Want your RPG character become a poison damage dealer? Add a '' |
- | | Archetype | + | |
- | | Chunk | Belt | | + | Systems are remote to the details they operate upon. That's also a feature |
+ | |||
+ | 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: | ||
==== About ECS+ ==== | ==== 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 " | + | 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 " |
+ | |||
+ | Generally speaking, in our own development philosophy, engineering should never be " | ||
- | Generally speaking, in our own philosophy, engineering should never be " | ||
==== Built-in Subjects ==== | ==== Built-in Subjects ==== | ||
Line 44: | Line 59: | ||
You would hardly ever need to implement your own mechanisms. Should you wish to, you can also do it in C++. | 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> | ||
+ | {{youtube> | ||
+ | {{youtube> | ||
+ | |||
+ | === Russian === | ||
+ | |||
+ | These are in Russian, but you may still want watch them with automatically-generated subtitles. | ||
+ | |||
+ | {{youtube> | ||
+ |