Различия

Показаны различия между двумя версиями страницы.

--- ru:toolworks:docs:apparatus:ecs [2021/04/16 12:25] – создано. надо перевести jispar
+++ ru:toolworks:docs:apparatus:ecs [2021/12/18 15:19] (текущий) – обновил в соответствии с англоязычной версией jispar
@@ Строка 1: / Строка 1: @@
-====== Краткое введение в ECS ======
+====== Введение в ECS ======
-===== Причуды и ограничения ООП =====
+===== Неудобства ООП: причуды и ограничения =====
-Прежде
+Прежде чем переходить к обсуждению ECS, стоит обратиться к [[wp>Object-oriented_programming|Объектно-ориентированному программированию (ООП)]] и его проблемам, так как пользовательский API Unreal Engine'а основан именно на парадигмах ООП. Actor-component модель тоже, в некотором смысле, ограничена, и по своей натуре в большей степени является статичной. Не следует путать эти подходы с data-ориентированным, который мы вам предлагаем.
-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.
+Большая часть C++ - это тоже ООП, что и стало основной причиной такого дизайна языка. Похоже, основная архитектуры UE верхнего уровня была в большой степени базирована на особенностях C++, или, по крайней мере, /* сейчас будет что-то плохо-русское, надо подумать, как красивее написать */ была вдохновлена ими. Если задуматься, это довольно логично.
+В конце концов, C++ - это основной язык, на котором строятся технологии.
+Unreal build toolset (а конкретней UBT - UnrealBuildTool - и UHT - UnrealHeaderTool) реализован на C#, который, к слову, тоже объектно-ориентированный.
-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.
+Итак, программируя игры (или программное обеспечение вообще) в стиле ООП, мы разбиваем всевозможные сущности и концепции в иерархию их соответствующих типов. В терминах Unreal Engine все эти абстракции называются Объектами (или ''[[ue>API/Runtime/CoreUObject/UObject/UObject|UObjects]]'', если мы говорим про С++ составляющую). Мы создаём иерархию классов, где каждый класс определяет новые свойства и методы, одновременно наследуя свойства и методы родительского класса. В конечном счёте, все классы Unreal-а наследуются от единого корня - ''UObject'' предка. Каждый созданный новый блупринт (или С++ класс) является наследником этого базового класса.
-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:
+По истечении некоторого времени разработки мы замечаем, что наши классы начинают всё более и более походить друг на друга. Тогда мы проводим так называемый [[wp>Code_refactoring|рефакторинг]] кода (или Blueprint-ассетов), выделяя схожие свойства в отдельный базовый класс и устанавливая связи наследства в дочерних классах. Уже эта задача может быть довольно сложной, так как объектная модель Unreal-а не позволяет множественное наследование (в то время как C++ позволяет), поэтому вы не можете наследоваться от двух или более классов. В любом случае, новые родительские классы могут иметь много общего, и тогда вводится новый ещё более общий класс, и процесс повторяется.
+Довольно известный пример этом подходу - дерево наследования животных, где классом-корнем выступает абстракция, представляющая собой любое живое существо (аналог ''UObject''), а остальные абстракции являются отдельными животными видами:
 {{ :en:toolworks:docs:oop-example.jpg?nolink |}}
-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.
+Потомственные типы наследуют свойства их соответствующих базовых типов, и, таким образом, изменяя свойства базового класса, мы также меняем поведение всех потомков. Мы можем так же ввести такую технологию, как "перегружаемые методы" ([[wp>Virtual_function|"virtual overridable methods"]]), чтобы иметь возможность переопределять поведение функций в классах-потомках.
-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.
+Весь этот кипишь выглядит довольно неплохо, разве нет? Да, всем этим можно пользоваться, но лишь до тех пор, пока у вас нету 100 классов. Проблема в том, что игровая логика становится очень размазанной по всем уровням иерархии. Вы всё чаще забываете, что было определено в конкретном классе, какие методы можно перегружать, какие нет. Количество взаимосвязей катастрофически увеличивает возможность ошибки, а неразбериха только усугубляется. Ваши коллеги, писавшие код используемых классов, становятся хранителями каких-то "тайных знаний". С ростом дерева классов время, требуемое на рефакторинг, увеличивается с экспоненциальной скоростью. Этот "ритуал" становится неотъемлемой частью работы, но к самой разработке утилит для целевого пользователя всё это мало относится. Совершенно неприемлемый подход, учитывая то, как ограничено бывает время и ресурсы.
-===== ECS to The Rescues =====
+===== Спасительный ECS =====
-A solution to this hassle could be an approach called [[wp>Entity_component_system|Entity–component–system (or ECS for short)]].
+Решением этих хлопот может быть такой подход, как [[wp>Entity_component_system|Entity–component–system (или кратко - ECS)]].
-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.
+В ECS нету никаких иерархий, каждый объект игры (т.е. //сущность// - англ. //entity//) изначально нейтральный. Он состоит только из частей данных, называемых //компонентами//. Вы можете комбинировать их на конкретной сущности произвольным образом.
-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.
+Вы хотите дать своему RPG-герою возможность наносить урон ядом? Просто добавьте компонент ''отравляющий'' и, считай, дело сделано; конечно, если была реализована соответствующая //система//, которая эту логику определяет.
-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.
+Система - это удалённый агент, оперирующий над деталями. В этом ещё одна особенность ECS. Системы представляют собой что-то наподобие внешнего кода, который берёт определённые компоненты, как свои входные данные, и, оперируя над ними, возвращает результат. Системы выполняются одна за другой и вместе формируют то, что называется игровым механизмом.
-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!
+На этом всё. Но как такой простой, удобный и гибкий принцип не был реализован в Unreal Engine до сих пор? Ну, на самом деле был: возьмите Niagara, например. Устройство рендера так же может быть рассмотрено как разработанный софт. Другими словами, какие сорта специальных data-ориентированных подходов в UE не возьми, ни один из них не является настолько выделенным, настолько универсальным, ни один из них не удовлетворял бы критериям общего назначения, как это делает Unreal-овская природа ООП. Мы предлагаем подход, обладающий всеми этими качествами и пригодный для //любой// доступной разработчику стороны Unreal Engine!
-Make sure your read our [[en:toolworks:docs:apparatus:ecs-glossary|Apparatus to ECS Glossary]] to get to know our terminology.
+Убедитесь в том, что вы прочитали [[ru:toolworks:docs:apparatus:ecs-glossary|Словарь Apparatus]], чтобы различать введённые нами новые термины.
-==== About ECS+ ====
+==== Про ECS+ ====
+Apparatus берёт более широкое направление, чем обычный ECS, поэтому мы и называем его ECS+. Вводится бóльшая гибкость при помощи поддержки наследования деталей (компонентов), динамических расширяемых belt-ов (наравне с более статичными //chunk//-ми и //archetype//-ми), subject-booting и др. Само понятие ECS+ должно рассматриваться как синоним слову "Apparatus", так как плагин реализует и полноценно использует именно эту терминологию с самого своего начала.
-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.
+Вообще говоря, в нашей философии разработки, проектирование никогда не должно быть "математически корректным", но, напротив, - более применимым и удобным в использовании как для конечного пользователя, так и для программиста. Unreal Engine, конечно, является хорошим примером такого подхода со всеми своими концепциями и паттернами. Соединяя в себе оба паттерна ООП и ECS, дополняя функционал в UE-блупринтах, Apparatus включает всё самое лучшее из 3-х миров, /* это уже от меня */ тем самым становясь незаменимым инструментом разработки.
-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.
+==== Встроенные сущности ====
+На низком уровне, ''Subjective'' - это интерфейс, и любой класс, который его имплементирует, может быть назван сущностью (''Subject''). Есть несколько встроенных в фреймворк subject-ов:
-==== Built-in Subjects ====
+  * ''SubjectiveActorComponent'' (на базе ''ActorComponent''),
+  * ''SubjectiveUserWidget'' (на базе ''UserWidget''),
+  * ''SubjectiveActor'' (на базе ''Actor'').
-At a lower level, ''Subjective'' is an interface and any class that implements it may be called a ''Subject''. There are several subjects already implemented in the framework:
+Этого должно хватить в подавляющем большинстве случаев использования, но вы, естественно, можете реализовать свои subject-классы в C++.
-  * ''SubjectiveActorComponent'' (based on ''ActorComponent''),
+==== Встроенные механизмы ====
-  * ''SubjectiveUserWidget'' (based on ''UserWidget''),
-  * ''SubjectiveActor'' (based on ''Actor'').
-Those should be sufficient for the most cases, but you can easily implement your own additional subject classes in C++.
+Класс ''Mechanical'' - это также интерфейс, с уже реализованными основными, самыми полезными механизмами:
-==== Built-in Mechanisms ====
+  * ''MechanicalActor'' (наследованный от ''Actor''),
-The ''Mechanical'' class is also an interface, with the most useful mechanisms already implemented:
-  * ''MechanicalActor'' (inherited from ''Actor''),
   * ''MechanicalGameModeBase'' (''GameModeBase''),
   * ''MechanicalGameMode'' (''GameMode'').
-You would hardly ever need to implement your own mechanisms. Should you wish to, you can also do it in C++.
+Очень вряд ли вам потребуется дополнять функционал своими механизмами. Если такая потребность возникнет, вы также можете достичь этого также при помощи C++.
+==== Сторонние ресурсы ====
+Вместе с нашим сообществом мы собрали коллекцию полезной информации, касающейся ECS и вообще data-ориентированного подхода в целом.
+Вы можете изучить её для углубления своих знаний.
+=== Ресурсы на русском ===
+{{youtube>IsJmBiRWBj8?medium}}
+=== Англоязычные ресурсы ===
+Здесь на английском, но вы всё равно можете посмотреть их, периодически пользуясь переводчиком.
+{{youtube>tONOW7Luln8?medium}}
+{{youtube>W3aieHjyNvw?medium}}
+{{youtube>g1TsP60z2OQ?medium}}