Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision Next revisionBoth sides next revision | ||
en:toolworks:docs:apparatus:ecs [2021/04/02 22:10] – created jispar | en:toolworks:docs:apparatus:ecs [2021/12/03 21:05] – vladius | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | New ECS paradigm called | + | ====== Introduction to ECS ====== |
+ | |||
+ | ===== 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 those are mainly called Objects (or '' | ||
+ | |||
+ | 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, | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | 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> | ||
+ | |||
+ | 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 " | ||
+ | |||
+ | ===== ECS to The Rescues ===== | ||
+ | |||
+ | A solution to this hassle could be an approach called [[wp> | ||
+ | |||
+ | 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 // | ||
+ | |||
+ | Want your RPG character become a poison damage dealer? Add a '' | ||
+ | |||
+ | 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: | ||
+ | |||
+ | ==== 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), | ||
+ | |||
+ | Generally speaking, in our own development 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 '' | ||
+ | |||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | You would hardly ever need to implement your own mechanisms. Should you wish to, you can also do it in C++. |