Подробный урок по Entity Component System в Unity

[@КонстантинЗеро-н3г]

Либо я ужасно владею поисковиком, либо ты выпустил 1й русскоязычный ролик с понятным примером кода по этой теме. Спасибо большое! Хотелось бы еще роликов с примерами ECS. В особенности "прелести" создания тайлмапов при таком способе создания мира. Мб все куда проще чем я загоняюсь, но я еще очень нуб _)

[@ZmastaZz]

очень приятно смотреть, хоть и ни чего не понятно)))пожалуйста не останавливайся

[@slava7522]

Замечательный урок, обязательно продолжай тему с ECS)

[@gydrazine]

Лайк просто сразу с порога.)

[@liroxyplay8068]

*Лайк не глядя!*

[@МаринаШафран-р2п]

Самый лучший урок по этой теме! Так хотелось бы увидеть продолжение!

[@samserious5483]

Спасибо за видео, все очень понятно, надо продолжать про нее рассказывать ещё, приводить примерв

[@Димас-ТвойРазработчикИгр]

Сначала лайк, потом просмотр)) Топчек

[@psy_gamer]

Вроде бы очень крутая система, но однозначно не так просто на нее перейти. Даже не в плане написания кода, а скорее осознать ее. А ролик крутой, лайк!)

[@insaneone-7220]

Согласен, так и есть. Но когда осознаешь (быстрее всего - попробовать самому), становится гораздо проще)

[@HuKuTa944]

7:20 Подумал, что же за ошибка такая страшная, а оказывается подчеркивание нижнее)) Работаю в кровавом backend enterprise java/kotlin разработчиком, но в качестве хобби решил вновь поставить юньку и побаловаться и наконец-то лично пощупать паттерн ECS. Видео очень сильно помогло вспомнить мою давнюю поделку на юнити и зарфакторить большущий класс контроллера игрока на компоненты и системы. Спасибо!

[@kotleni]

Лучшее обьяснение, спасибо.

[@mariacho8174]

Обычно при просмотре видео врубаешь ускорение, а тут замедление...)

[@gornakovanton]

Очень доступно всё объяснил. Спасибо!

[@goopi5885]

Потом буду буду рассказывать о своём проекте и упоминать это видео) Спасибочки!

[@WARGON123]

Спасибо за видео! Сам юзаю leoEcs, отличный фреймворк!

[@yatsuk_vitalii]

Как всегда на высоте

[@daniilparokonnyy7980]

Ждем еще новых роликов по ECS!

[@GGamess]

тут только на наследование настроился и теперь перенастраиваться)

[@vitaly6838]

Ну я только начал нормально в ООП разбираться 😂😂

[@SkyFlashGamer]

Изучил LeoEcs и получил работу в геймдеве, уже 3 месяца сижу на зарплате, так что всем советую :)

[@Leopotam]

А че, так можно было?!

[@MrTANgens180]

@@Leopotam очень иронично слышать это от самого создателя LeoEcs (может я чего то путаю, я хз)

[@Daniel48476]

@@MrTANgens180 Не-не, это он самый😁

[@insaneone-7220]

Привет! Пробую новый формат видео подлиннее. Даже в такой крупный ролик не удалось вместить всё, что хотелось сказать, но я надеюсь, что этой информации достаточно, чтобы дать общее понимание о том, как работает ECS и стоит ли его использовать :) Важно: в видео используется версия LeoECS, работающая на классах. Существует так же версия с использованием структур, но примеры из видео в ней работать не будут. Так же API может изменяться и примеры кода не сработают в новых версиях. Поэтому - изучайте внимательно описание Readme на GitHub.

[@modjaid3907]

И где этот новый формат?

[@ElChampi0]

Маленькие видосы лучше. Лучше разбивать по маленьким задачам. Ну а в больших видео (без них тоже не обойтись) добавлять таймкод, чтобы было содержание

[@insaneone-7220]

@@ElChampi0 да, насчет таймкодов думал, надо будет добавлять)

[@vovanchik_ru4208]

всё круто, только компоненты нужно создавать структурами, чтобы они больше подходили принципу entity.

[@ВладиславИгоревич-в3с]

Спасибо за видео, почти всё понятно

[@evggg]

Очень доходчиво объяснил! Я считаю, что в базовый урок неплохо было бы добавить обработку коллизий. Иначе игра получается не завершенная, потому что враги не убивают игрока.

[@skippythemagnificent8103]

This is a really interesting video even though i dont speak Russian. Is there any possibility you can turn on CC for subtitles so i can force youtube to turn on translation, many thanks for the video and effort, its a great share : D

[@АлексейБуров-т7ц]

Спасиб конечно. Но я видимо уже слишком стар и для меня старого доброго ООП хватит за глаза ))

[@mr_ivanushka4287]

Как в ECS строить неявные зависимости? Как правильно подписывать компоненты на события? Например, как реализовать повышение атаки персонажа при получении урона?

[@rhapsodicmajor596]

Создавать компонент события и добавлять его на сущность, другая система если увидит на сущности этот компонент, то выполнит действие, после чего компонент можно удалить. Я еще не писал на ECS, я просто видел, что так советуют другие разрабы делать

[@PupsXD]

Потрясающий разбор, спасибо!

[@redmanone6963]

8:05 Блин, ну теперь мне придётся разбираться что такое scraptable objects

[@Daniel48476]

Scriptable Object)

[@guzezz]

Получается, что на каждый уровень нужно делать свою GameInitSystem. Либо писать супер-абстрактную систему, задавать там набор систем под каждый уровень и радоваться жизни. Но тогда у каждой системы должен быть какой-то хендлер инициализации, например, класс Extentions, который прописывает инициализацию объектов на сцене. Что думаете на этот счёт?

[@insaneone-7220]

Набор систем зависит не от уровня, а скорее от игрового режима. Если, например, на 10 разных уровнях геймплей не имеет радикальных отличий, то они все будут использовать один и тот же набор систем. Не стоит ничего переусложнять и придумывать абстракции, ECS как раз помогает от этого отойти и писать код проще.

[@guzezz]

@insaneone-7220 а что если у меня одна система генерирует стабильно 3 врага на уровне, Но на втором уровне у меня предполагается 4 врага и на других координатах. Лучше такие штуки задавать отдельным параметрами?

[@insaneone-7220]

@@guzezz системы работают с данными данных. А данные о том, где, какие и сколько врагов появится - хранятся в компонентах или конфигах. Соответственно, под разные уровни будет разный конфиг со всей необходимой информацией.

[@guzezz]

@@insaneone-7220 я улавливаю мысль. Спасибо за ответы! Очень полезно было. Я бы обрадовался, если бы вышли когда-нибудь новые ролики. Может у вас есть какая-то литература для изучения хорошей архитектуры в Юнити?

[@insaneone-7220]

@@guzezz к сожалению, актуальной полезной литературы по Unity не знаю, да и вообще по архитектуре книги зачастую устаревшие и/или не направленные на разработку игр. Лучше всё-таки изучить статьи в интернете, на мой взгляд. На английском можно найти больше интересных материалов, чем на русском)

[@muxailo289]

Порубили Моно на интерфейсы и назвали новой системой?

[@OOOJohnJ]

14:30 "У всех персонажей пропала анимация, как мы и ожидали" Персонажи: двигают ручками и ножками :)

[@arsenbabaev1022]

Как взаимодействовать с entity например наносить урон врагам в какой то точке подбирать предметы и тд? делать search подходящих целей по позициям явно не вариант

[@omicronperson]

Привет, у тебя классные видео, ставлю лайк под всеми). Освещаешь довольно узкие, но полезные вещи. Как тебе идея рассказать о Compute шейдерах? Перекладывать вычисления на видяху это же тоже способ оптимизации. По ним как раз мало подробной инфы, тем более хорошо оформленной.

[@insaneone-7220]

Есть такое в мыслях, да)

[@succubhunter1910]

Спасибо за хорошее видео. Я попытался повторить те же действия, но встретился с рядом трудностей. Не мог бы ты выкладывать публичные репозитории, что бы можно было поковырять написаное. Заранее спасибо.

[@МаксимМурич-у8к]

+

[@Андрей-в7и6ь]

+

[@AlexStraga]

"Сложна, сложна, них не понятно!")) Чел, ты прям радуешь такими крутыми штуками. Давно интересно было подробнее про это узнать и рад буду еще примеры глянуть. Вопрос же в данном случае - мы все руками прописываем, а локацию как тогда создавать если там будут монобихейверы какие? Или есть вариант конвертировать их при старте? З. Ы. Может сделаешь сравнение скорости этой демки этак на 500-1000 преследователей в стандартном варианте и в есс?

[@insaneone-7220]

ECS действительно больше ориентирован на "прописать всё в коде" в текущем виде, ну в принципе для каких-то вещей, которые проще расставлять, можно действительно monobehaviour "указатели" сделать. В этом плане, возможно, больше понравится Actors, он позволяет настраивать энтити прямо на префабах, что привычнее. Но в остальном он мне кажется менее удобным, чем LeoECS. Насчёт теста 1000 сущностей, можно было бы это записать, но в целом от самих юнити были примеры игры с симуляцией огромных толп типа Ultimate Epic Battle Simulator (или как он там называется)).

[@AlexStraga]

@@insaneone-7220 о, это на этом написано? Круто

[@ЕрболТоктыбаев-э5у]

@@insaneone-7220 Лайк и подписка, хороший контент. А в чем, по вашему Actors менее удобен?

[@insaneone-7220]

@@ЕрболТоктыбаев-э5у тут скорее дело в размере фреймворка. ЛеоECS очень компактный и там сразу всё понятно. Акторс более объемный и содержит больше функционала. Для юнити-разработчика, возможно, это действительно потенциально лучший выбор, если хорошо понять все его функции. ЛеоECS же более универсальный - работает и без юнити, все доп. функции ставятся на него отдельно. Для обучения принципам ECS я считаю это более подходящим вариантам. А когда разобрался, можно выбрать уже более осознанно то, что тебе нужно.

[@ЕрболТоктыбаев-э5у]

@@insaneone-7220 Спасибо за ответ.

[@АнтонАндреевич-в5з]

Спасибо!

[@DeadRabbitCanDance]

Очень здорово всё рассказал, но насколько я понимаю, одна из важных идей, преследуемых паттерном дата-ориентированного дизайна - отделение той небольшой части данных, используемых в вычислениях от всех остальных данных, относительно статичных (геометрия, текстуры и т.д) для того, чтобы эти данные, используемые в вычислениях были скомпонованы в памяти более компактно и попадали в кэш процессора и в совокупности с тем, что их обрабатывать будут jobы, которые могут работать параллельно - получить существенный прирост в производительности при выполнении большого количества одинаковых операций. И тут наверно лучше использовать ту реализацию ECS/DOTS, которую разрабатывает команда UNITY, а не другие реализации этой парадигмы.

[@adrew4]

Вот я тоже сижу не понимаю, какое преимущество дает данный подход с LeoECS кроме тотальной декомпозиции компонентов. Это наоборот создает предпосылки к нарушению принципов правильной архитектуры, а именно любой компонент может получить доступ до любой системы вне зависимости от иерархии насколько я понимаю, в обход наследования и интерфейсов, то есть просто вот мне нужно и я беру че хочу. Такой подход оправдан когда он работает в стеке с JOBS\DOTS и каждый такой скрипт потенциально может отработать в своем потоке процессора, и будет скопанован в памяти как вы упомянули. Но, я не понимаю в чем кардинальное преимущество именно LeoECS и подобных, которые сейчас активно все почему то начали юзать.

[@fomgleb]

2:01 Не пойму, чем здесь отличаеться Move Component от Move?

[@dumitruiordachi]

Выдает такую ошибку: 'EcsEntity' does not contain a definition for 'Set' Код: var test = _world.NewEntity(); test.Set();

[@yerigoth]

вместо этого напиши: test.Get(); он создаст такой компонент, если его нет

[@pengw1negames]

@@yerigoth Имею такую же проблему что описана выше, но ваш ответ не решил ее, есть ли еще какие-то советы?

[@ІванПригара-о2й]

У меня вопрос а как работать к примеры с Триггерами и Коллайдерами в таком случае ?

[@insaneone-7220]

Нужно сделать MonoBehaviour, который будет взаимодействовать с ECS и пробрасывать туда эту инфу. Это минус большинства текущих реализаций ECS - всё, что связано непосредственно с компонентами Unity, выглядит не очень удобно. По-моему, официальный ECS от Unity меньше подвержен влиянию этой проблемы, но точной информации у меня нет.

[@_VladMir_]

@@insaneone-7220 Почему для меня это похоже на огромный костыль?) Всю жизнь пытались так не работать с кодом, а сейчас такие костыли приветствуются) Для меня это сложно осознать) Я чувствую там много проблем может быть, если это завернуть в визуальное программирование может быть ещё нормально воспринималось бы)

[@_cyp4ik_201]

@@_VladMir_ костыль, если не уметь пользоваться. Можешь глянуть декомпиляцию игры Rimworld, которая реализована на ecs (причём на самописном, от разработчика, вроде как), всё там отлично работает, так ещё и удобно пользоваться подобным, например в модинге, не говоря уже о самой разработке.

[@OOOJohnJ]

@@_VladMir_ почему костыль то?

[@IgorKu-m4o]

Куда движется Юнити? ECS в будущем заменит Монобихейвер? Или они они будут существовать параллельно?

[@stepanshnder1850]

Допустим у меня есть ГОАП скрипт ИИ. Каждый НПС там имеет некоторые уникашьные свойства, например свои обьекты для взаймодкйстия, сообственные диалоги для других НПС. Можно ли перевести ее на ЕЦС??? Он же обьектный целиком. Ужасная производительность.

[@RoGa766]

Откуда взялся PlayerComponent и что в нём находится?

[@OOOJohnJ]

он может быть полностью пустым, главное что по его наличию мы определяем что это игрок

[@pengw1negames]

Вроде делаю все правильно, однако не понимаю почему я не имею метода Set(), как показано тут 7:34, получаю Cannot resolve symbol 'Set'. Есть ли решение этой проблемы увас?

[@insaneone-7220]

Можно попробовать Get(). У версий ECS отличается API. Рекомендую обратить внимание на справку версии, которая используется.

[@Catkinddesign]

А как в указанном примере можно удалить компонент с сущности из кода? Те же инвентари, события и т.д. только через EventComponent делать, так понимаю. На GitHub только RemoveComponent в блоге автора упоминается, который для классовой системы просто не существует.

[@who-1880]

Слушай, если будет 3д модель с 100 полигонами, это комп не нагружает, верно?

[@gydrazine]

100 полигонов - это вообще ни о чем. А 100 000 полигонов на модельку - многовато.

[@insaneone-7220]

Нет, никаких проблем с таким количеством полигонов)

[@yatsuk_vitalii]

Гипотетически, современная видюха выдерживает до нескольких миллионов полигонов, но это без учёта текстур и постпроцесинга, но все равно 100 полигонов никак не повлияют

[@who-1880]

@@insaneone-7220 Кстате, а почему когда я ставлю материал с текстуркой на объект, там сплошной цвет?

[@insaneone-7220]

@@who-1880 возможно, у модели некорректно сделана UV-развёртка. Цвет совпадает с какой-то из частей текстуры?

[@АлександрЛи-ы2н]

Пожалуйста, сделайте уже урок по unity ecs 1.0. Все что для 0.5 не актуальны, а официальная документация с багами в примерах. Единственный англоязычный урок сделан дилетантом, который в один аспект запихнул чуть ли не все компоненты игры.

[@BlackHole-ei9mi]

Нашел что-нибудь ?

[@GameDev55]

все классно, но для компонентов пришлось использовать структуры. С классами не шло

[@OOOJohnJ]

почему?

[@Sviborg_v]

А почему он переменную объявляет так: " var x :float = ..." ? что значит эта ":float" и как отличается от " float x =..."

[@Sviborg_v]

Понял, это Rider дорисовывает тип переменной var

[@funny_shorts1281]

Не хочу душнить, но ты на 6:45 сказал "достаточно наследовать класс от нужного интерфейса", а это не совсем правильно, потому что интерфейсы не наследуются, а реализуются, и строго говоря интерфейс невозможно наследовать.

[@ZmastaZz]

На рутубе нету ни одного адекватного туториала по патчфайндингу и А*, может пришло время устранить это допущение?)))

[@nightyonetwothree]

давно есть куча. Посмотри Себастиана, он очень доступно объясняет с примером и открытым кодом

[@ZmastaZz]

@@nightyonetwothree оказалось я уже смотрел его, но не очень понял

[@OOOJohnJ]

допущение?

[@gaidzin2]

А зачем вообще оставил GameObject префабы?

[@Андрей-в7и6ь]

Извини, чувак, но это не подробный урок) Чтобы эту тему вдуплить надо в 2 раза медленнее объяснять и каждое выражение комментировать, зачем оно нужно. Мозг с трудом то ООП перерабатывает, а тут такое))

[@viacheslav1392]

Это будет подробный урок по программированию. А здесь конкретная тема

[@ДаниилЕфименко-е7ч]

@@viacheslav1392 и все равно это не подробный урок. Показан лишь простейший пример. Все ещё непонятно, как создать взаимодействие между объектами, которые не известны на момент компиляци. Например, открытие дверей. И это только один из многих вопросов. Слишком мало озвучено, тут нужен целый цикл уроков

[@ФІ-92ІванМудрак]

Куда пропал...

[@DarkIllusoire]

Ecs это не противопоставление ООП, а просто шаблон разделения кода на данные и системы, работающие с данными и имеет свои плюсы и минусы. И ныне используемая в юнити система, это тоже ECS, только не имеющая встроенного обработчика систем. А разделять данные и поведение, это вообще необходимость

[@Leopotam]

Это определение начинает сыпаться как только попытаемся сделать наследование классическим способом. Ецс предполагает плоскую модель типов и composition over inheritance.

[@DarkIllusoire]

@@Leopotam ага, что лучше, кожаный салон(ECS) или автомобиль(ООП)?)) Вы создаете любой класс, и уже используете наследование; без ООП, ECS работать не будет в принципе - чтобы система узнала о сущности, эта сущность должна как минимум наследовать какой-то интерфейс; А то что вы описываете, это как лучше писать, слева направо или наоборот.

[@Leopotam]

@@DarkIllusoire разумеется сущность не должна наследовать никакого интерфейса (наверное разговор не про сущность, а про компонент) и будет работать безо всякой дополнительной абстракции через конечные типы (можно посмотреть в качестве примера тот же leoecs). В этом основное отличие ецс от ооп - никакой абстракции, строго работа с конечными типами.

[@DarkIllusoire]

@@Leopotam лол.. вы путаете наследование, ООП, шаблоны. ecs это шаблон ооп, который позволяет отказаться от наследования.

[@Leopotam]

@@DarkIllusoire Сделаем проще. Являются ли GoLang / Rust языками с поддержкой ООП? Реализация ecs не этих языках невозможна?

[@OOOJohnJ]

Подход выглядит интересным, но зачем такие неподходящие, путающие названия? Данные - называются компонентом, вместо данных. Действия называются Системами... Гораздо очевиднее было бы, если бы подход назывался EDA = Entity-Data-Actions

[@CrazySovietIngeneere]

Видео хорошее, а ECS - штука мутная

[@ВячеславПеревышин]

@@user-ex9ex2hs5k напоминает sql, только в фильтрах компоненты, а не таблицы

[@ilyaplekhanov2373]

Я за 3 дня уже 50 реклам посмотрел на этом ролике

[@arsenbabaev1022]

В итоге я отказался от есs недоделанная хрень ( leo + unity ) если вы делаете симулятор подсчета цифр в мультитреде да если делаете игру в 2021 анивэй стандарт лучше.

[@insaneone-7220]

Если не понравился LeoECS, есть ещё default ECS, ME ECS, Actors, Morpeh - возможно, один из них больше подойдет. Если же не нравится сама концепция или её ограничения в Unity, то да, стандарт лучше. :)

[@orcan377]

в GameInitSystem какаято мешанина ппц

[@immeasurability]

Искал урок по ESC Unity, Заголовок Подробный урок по Entity Component System в Unity, а о Leo узнаю в середине ролика. Хотел оскорбить автора, но силы тратить на это в лом...

[@PrizrakSHIZA]

ага, крч все тоже самое что юнити предоставляет своими компонентами только отвязав от юнити? И зачем такое надо? единственный плюс этого, только то что можно использовать многопоточность? И то, есть другие способы включить многопоточность в юнити, без таких странных усложнений.. В общем. не понял я прикола этого.

[@OOOJohnJ]

не то же самое, юнити использует компоненты с логикой, там данные не отделены от логики, а в ecs отделены

[@PrizrakSHIZA]

@@OOOJohnJ Тебе ничего не мешает данные хранить данные отдельно. Ты мжешь даже логику отдельно прописать не в наследуясь от MonoBehavior. Вообще не вижу в этом смысла. Не вижу в ECS ничего что нельзя сделать в стандартном юнити. Только дополнительный менингит по изучению и составлению этого всего

[@OOOJohnJ]

@@PrizrakSHIZA вы правы что и в обычном подходе можно отделить данные от логики, но в ECS кроме этого логика вообще не связана с объектами напрямую, а зависит лишь от текущего набора компонент у объекта, таким образом, компоненты могут добавляться и удаляться в рантайме, меняя поведение объекта и при этом не придётся ничего менять в коде. Конечно, вы и так можете написать системы, которые так работают в юнити, тогда вы приблизитесь к ECS, но смысл, если есть специлизированная система, которая помогает находить нужные объекты с компонентами, следит какие куда добавились/удалились и передаёт их системам. То есть если вы всё это будете реализовывать сами, то просто реализуете свой аналог ECS, когда можно использовать уже готовые реализации данного подхода

[@PrizrakSHIZA]

@@OOOJohnJ А в чем проблема добавлять и убирать компоненты моно в рантайме? И я спрошу от обратного: зачем изобретать велосипед когда он уже есть? Если вам надо менять компоненты в рантайме - пожалуйста. юнити это позволяет. Зачем учить какую-то другую систему, со странными особенностями кода для присвоения, если это все можно сделать с вашими базовыми знаниями юнити? Вот этого я не понимаю. Система ради системы.

[@OOOJohnJ]

@@PrizrakSHIZA так я и говорю что можно убирать, но такой гибкой выборки нужных компонентов на чистом юнити вы не реализуете, а значит вы будете вынуждены сообщать логике о компонентах, которые она должна обрабатывать, что увеличит связанность и вероятность необходимости лезть в работающую логику при добавлении новых возможностей

[@saurontheblack6566]

Проверил на 8к кубах, хрень ECSLeo Lite, скорость хуже чем у монобеха.

[@redmanone3724]

Спустя годы пересматриваю, и всё равно ничего не понятно. Даже на английском уроки более понятные.

[@Barlog2012]

Имхо, это извращение над нормальным программированием. Но за ролик спасибо.

[@michaelfinne617]

Абсолютно не ясно зачем надо выделять компоненты в отдельные штуки, а не использовать уже существующий в юнити компонентный подход. Какое-то дублирование подходов. Поиск и создание сущностей в юнити уже существует. Зачем дублировать уже реализованную юнитеками логику я не знаю.

[@serveladik]

Зря неофф использовать начал, так как многим приятнее юзать то, что более расширеное

[@xotamxudoyberganov5847]

ya pishu na go

[@anroiddevel5597]

Почему то когда я начинаю наблюдать в коде публичные поля, да еще и названые с маленькой буквы, мне становится все равно, что говорит оратор, какими бы умными не казались его речи.

[@insaneone-7220]

@@anroiddevel5597 ну, наверное ты и Unity не пользуешься, ведь почти всё их api имеет публичные поля (или проперти), названные с маленькой буквы.

[@anroiddevel5597]

@@insaneone-7220 У этого есть несколько причин. 1. Unity разрабатывалась и эволюционировала с течением времени, и разработчики следовали определённым внутренним стандартам, которые стали традицией. Эти стандарты помогали поддерживать согласованность в коде и документации. 2.Многое в Unity направлено на упрощение работы разработчиков игр, включая тех, кто может быть не знаком с продвинутыми принципами программирования. 3.Unity имеет огромное количество существующего кода и проектов, и изменение соглашений об именовании могло бы привести к проблемам совместимости. Поддержание текущих соглашений помогает избежать этих проблем. А у Вас нет никаких причин использовать устаревшие правила.

[@chosonminhang]

Использую camelCase для констант и переменных, PascalCase для методов. А ещё скобку { не переношу на следующую линию. Мне так нравится.

[@gh0stpot]

Нужная тема. Подписка. Дизлайк. Все понравилось

[@ifelru]

Дизлайк?

[@MDVonlineStore]

Видео хорошее, но ты сильно спешишь и просто не успеваю вникнуть в суть.

[@Thur1nor]

честно говоря смотрел видос с целью понять в чем же преимущество перед стандартной компонентной системой, и честно говоря так и не догнал. Все дико неудобно и костыльно. плюс такие мощные инструменты как наследование и полиморфизм идут нахер, все поведение обьектов нужно настраивать через код, что неудобно если работаете с геймдизайнерами которые сами в юньке могут что то собирать

[@pashadjoystick]

лайк конечно поставлю но)) ЭКС для Юни как Ассемблер для Си - пятая ножка стулу для тяжких пассажиров, а я предпочитаю легковесные программы. так что если ЭКС заполонит всем мозги - то я уйду в продавцы строительного или продуктового маркета)) а без меня вы нормальных игр не напишите и скоро будете кричать под окном мол прости нас Леопольд.. и без ЭКС мощности хватало делать наляпистые игры от перенасыщенности объектами - а теперь я так понял можно сделать чтобы атомы пылюки под ногами прорисовывались по всей вселенной. это неправильный курс - давайте лучше делать стратегии где раз в месяц приходит 1 враг ито с женой и мы с ним от скуки дружно бухаем итд. ума придумать сюжет задающий механики вот цель красивых игр а не сделать ещё в 10000000000 раз больше мобов. по чертам Юнити видно что она задумана первично как простенький редактор игр из квадратов - вот КрайЭнжн макросредство типа накидал ботов и дал им маршруты с заданиями, настроил характеры.. а теперь Юнити перегажена - она то и без того уже тормозит. Юнити 2020-2021 итак никуда не годная из-за потери 30 сек на перекомпиляции при каждой подмене в коде - получается вперёд идти это к полупроцедурному ЭКС и тормозам редактора а назад значит к старым не поддерживаемым версиям. чую всё это саботаж Юнити которую скоро постигнет судьба КрайЭнжна который опротивел перенасыщенностью стандартного демо-ассета и как Юнити подгадивший в Край-сторе. Юню уже еле держит на плаву Юнити-стор дающий нам фичи которые должны быть из коробки, в виде временного подаяния для нищих. В редакторе фишек какбы не убывает в отличии от Края но это всё больше похоже на мусорник уже. А свято место пусто не бывает - ща вот Амазон увидел засранство юнити со стором и тормозами и вот уже делает вой движок, кстати Амазон богат достаточно если не выкупить ставших ненужными запутавшихся разрабов Юнити, то по крайней может их оплатить у них саботаж на что и похоже. почитайте ответы разрабов на вопрос чего компиляци настолько долгая стала что уже почти добавили часики как в Вин-95 - скоро суко табличку добавят типа "Откиньтесь удобно на спинку кресла и сели час глухо то перезагрузите комп и перенапишите все скрипты заново". Так вот разрабы сказали что тормоза от некого волшебного дебага который теперь встроен и даст прозрачность - и тут я вспомнил что Юня стала с 2020-2021 не показывать в чём суть ошибки и даже неверно указывать где ошибка. так что отмазка таксебе

[@evilvirraZzz]

"а не сделать ещё в 10000000000 раз больше мобов" Жалко, что люди насмотрелись того, что на коде ecs можно создать 10000000 объектов. ecs это ПАТТЕРН проектирования, а не способ оптимизации кода. Просто при таком проектировании кода, как ecs, следствует хорошая поддержка кода, так как поскольку все данные отделены от логики, легкость в расширении кода и весь код имеет малое кол-во взаимосвязей. между собой. Производительность и многопоточность является лишь плюсом этого проектирования. Я бы посмотрел на вас, если бы вас попросили убрать что-нибудь критичное из программы. В ecs же достаточно будет убрать определенную систему.

[@pashadjoystick]

@@evilvirraZzz это так только говориться - сколько себя помню одни и те же слова были про то что привносят процедуры, потом классы а потом интерфейсы... да приносят на порядок большее могущество - ощутив его мы лезем в большие дебри, вместо быстрой сборки простенького весёлого продукта. моей жене в первый раз понравился уровень из примитивов Юнити где просто ходишь - потому что там не было реальности и никто тебя не пресует, а было всё необычное, прыгал просто сод-пёсн. когда я это всунул в ВР то снова её привлекло - никак не вот эти супер-реалистичные механики из-за которых вечно нужно подключать или убавлять компоненты. да разумеется из-за того что я этим не занимался а ходил на подработки то очутился в роли программера крупной конторы - теперь меня эксплуатируют делать что хочет шеф или клиент, и конечно они хотят пожирнее, ещё сами не знают что такое ЕКС но уже требуют. а вот способнейший напарник класса синьор уж 5 лет - говорит что штука быстрая и классная но окончательно порекомендовать затрудняется, просто говорит выучил по привычке всё использовать первей всех. и то что после ЭКС он стряпает проекты на Анриале мне тоже о чём-то говорит)) он гребёт технологии, патерны, структуры кода изобретает.. и научил меня всё делать интерфейсами - вот честно не вижу нужды ни в чём. и кстати я сделал больше шедевров чем супер-мега синьор ток потому что не занят постоянным скилапом под завязку. лучше бы разрабы сделали Юню 2021 менее тормознутой. ато я добавляю в код просто комментарий а оно ЧТОТО перекомпилирует - рука-лицо, я Юню терплю уже с последних сил и учу другие движки параллельно, останутся они со своим ЭКС в гордом одиночестве есь так плевать на потребителя

[@Хреновастенько]

Сколько можно плодить видео типо "вот так не надо делать", "а это лучше не использовать", не предлагая альтернативы,обучающее видео или вредных советов.

[@sagrgywejhxcvx]

зачем это использовать если не для многопоточности...всё испортил

[@Baannia]

Хорошая архитектура. Но чот многовато сахара )