Подробный урок по Entity Component System в Unity
Вставка
- Опубліковано 9 лип 2020
- В этом видео я объясняю, что такое Entity Component System (ECS), зачем он нужен и где применяется. А так же показываю, как преобразовать код обычного Unity-проекта в подход Entity Component System.
В видео используется версия LeoECS, работающая на классах. Существует так же версия с использованием структур, но примеры из видео в ней работать не будут. Читайте внимательно описание на GitHub.
Проект из этого видео будет доступен подписчикам Patreon и Boosty.
Поддержать канал на русскоязычном Boosty: boosty.to/insaneone
Или на Patreon: / insaneone
Discord-сервер канала: / discord
Группа VK: insaneoneblog
#Unity #РазработкаИгр #ECS
У меня на канале регулярно выходят новые видео с уроками по Unity и разработке игр, а так же другими интересными темами, связанными с геймдевом. Подписывайся!
Не забывай оставлять комментарий, если у тебя появились вопросы или предложения по видео :)
Либо я ужасно владею поисковиком, либо ты выпустил 1й русскоязычный ролик с понятным примером кода по этой теме. Спасибо большое!
Хотелось бы еще роликов с примерами ECS. В особенности "прелести" создания тайлмапов при таком способе создания мира.
Мб все куда проще чем я загоняюсь, но я еще очень нуб _)
Спасибо за видео, все очень понятно, надо продолжать про нее рассказывать ещё, приводить примерв
Самый лучший урок по этой теме! Так хотелось бы увидеть продолжение!
Потом буду буду рассказывать о своём проекте и упоминать это видео) Спасибочки!
очень приятно смотреть, хоть и ни чего не понятно)))пожалуйста не останавливайся
Ждем еще новых роликов по ECS!
Очень доступно всё объяснил. Спасибо!
Лайк просто сразу с порога.)
Спасибо за видео! Сам юзаю leoEcs, отличный фреймворк!
Замечательный урок, обязательно продолжай тему с ECS)
Сначала лайк, потом просмотр)) Топчек
Потрясающий разбор, спасибо!
Спасибо за видео, почти всё понятно
Как всегда на высоте
*Лайк не глядя!*
Вроде бы очень крутая система, но однозначно не так просто на нее перейти. Даже не в плане написания кода, а скорее осознать ее.
А ролик крутой, лайк!)
Согласен, так и есть. Но когда осознаешь (быстрее всего - попробовать самому), становится гораздо проще)
Ну я только начал нормально в ООП разбираться 😂😂
Очень доходчиво объяснил! Я считаю, что в базовый урок неплохо было бы добавить обработку коллизий. Иначе игра получается не завершенная, потому что враги не убивают игрока.
Спасибо!
Обычно при просмотре видео врубаешь ускорение, а тут замедление...)
тут только на наследование настроился и теперь перенастраиваться)
7:20
Подумал, что же за ошибка такая страшная, а оказывается подчеркивание нижнее))
Работаю в кровавом backend enterprise java/kotlin разработчиком, но в качестве хобби решил вновь поставить юньку и побаловаться и наконец-то лично пощупать паттерн ECS.
Видео очень сильно помогло вспомнить мою давнюю поделку на юнити и зарфакторить большущий класс контроллера игрока на компоненты и системы.
Спасибо!
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
Как взаимодействовать с entity например наносить урон врагам в какой то точке подбирать предметы и тд? делать search подходящих целей по позициям явно не вариант
Привет, у тебя классные видео, ставлю лайк под всеми). Освещаешь довольно узкие, но полезные вещи. Как тебе идея рассказать о Compute шейдерах? Перекладывать вычисления на видяху это же тоже способ оптимизации. По ним как раз мало подробной инфы, тем более хорошо оформленной.
Есть такое в мыслях, да)
8:05 Блин, ну теперь мне придётся разбираться что такое scraptable objects
Scriptable Object)
Допустим у меня есть ГОАП скрипт ИИ. Каждый НПС там имеет некоторые уникашьные свойства, например свои обьекты для взаймодкйстия, сообственные диалоги для других НПС. Можно ли перевести ее на ЕЦС??? Он же обьектный целиком. Ужасная производительность.
Изучил LeoEcs и получил работу в геймдеве, уже 3 месяца сижу на зарплате, так что всем советую :)
А че, так можно было?!
@@Leopotam очень иронично слышать это от самого создателя LeoEcs (может я чего то путаю, я хз)
@@MrTANgens180 Не-не, это он самый😁
А как в указанном примере можно удалить компонент с сущности из кода? Те же инвентари, события и т.д. только через EventComponent делать, так понимаю.
На GitHub только RemoveComponent в блоге автора упоминается, который для классовой системы просто не существует.
2:01 Не пойму, чем здесь отличаеться Move Component от Move?
Спасибо за хорошее видео. Я попытался повторить те же действия, но встретился с рядом трудностей. Не мог бы ты выкладывать публичные репозитории, что бы можно было поковырять написаное. Заранее спасибо.
+
+
Привет! Пробую новый формат видео подлиннее. Даже в такой крупный ролик не удалось вместить всё, что хотелось сказать, но я надеюсь, что этой информации достаточно, чтобы дать общее понимание о том, как работает ECS и стоит ли его использовать :)
Важно: в видео используется версия LeoECS, работающая на классах. Существует так же версия с использованием структур, но примеры из видео в ней работать не будут. Так же API может изменяться и примеры кода не сработают в новых версиях. Поэтому - изучайте внимательно описание Readme на GitHub.
И где этот новый формат?
Маленькие видосы лучше. Лучше разбивать по маленьким задачам. Ну а в больших видео (без них тоже не обойтись) добавлять таймкод, чтобы было содержание
@@ElChampi0 да, насчет таймкодов думал, надо будет добавлять)
всё круто, только компоненты нужно создавать структурами, чтобы они больше подходили принципу entity.
"Сложна, сложна, них не понятно!"))
Чел, ты прям радуешь такими крутыми штуками. Давно интересно было подробнее про это узнать и рад буду еще примеры глянуть.
Вопрос же в данном случае - мы все руками прописываем, а локацию как тогда создавать если там будут монобихейверы какие? Или есть вариант конвертировать их при старте?
З. Ы. Может сделаешь сравнение скорости этой демки этак на 500-1000 преследователей в стандартном варианте и в есс?
ECS действительно больше ориентирован на "прописать всё в коде" в текущем виде, ну в принципе для каких-то вещей, которые проще расставлять, можно действительно monobehaviour "указатели" сделать. В этом плане, возможно, больше понравится Actors, он позволяет настраивать энтити прямо на префабах, что привычнее. Но в остальном он мне кажется менее удобным, чем LeoECS.
Насчёт теста 1000 сущностей, можно было бы это записать, но в целом от самих юнити были примеры игры с симуляцией огромных толп типа Ultimate Epic Battle Simulator (или как он там называется)).
@@insaneone-7220 о, это на этом написано? Круто
@@insaneone-7220 Лайк и подписка, хороший контент. А в чем, по вашему Actors менее удобен?
@@user-bu6ym7mz5m тут скорее дело в размере фреймворка. ЛеоECS очень компактный и там сразу всё понятно. Акторс более объемный и содержит больше функционала. Для юнити-разработчика, возможно, это действительно потенциально лучший выбор, если хорошо понять все его функции. ЛеоECS же более универсальный - работает и без юнити, все доп. функции ставятся на него отдельно. Для обучения принципам ECS я считаю это более подходящим вариантам. А когда разобрался, можно выбрать уже более осознанно то, что тебе нужно.
@@insaneone-7220 Спасибо за ответ.
Спасиб конечно. Но я видимо уже слишком стар и для меня старого доброго ООП хватит за глаза ))
Куда движется Юнити? ECS в будущем заменит Монобихейвер? Или они они будут существовать параллельно?
Порубили Моно на интерфейсы и назвали новой системой?
14:30 "У всех персонажей пропала анимация, как мы и ожидали"
Персонажи: двигают ручками и ножками :)
Вроде делаю все правильно, однако не понимаю почему я не имею метода Set(), как показано тут 7:34, получаю Cannot resolve symbol 'Set'. Есть ли решение этой проблемы увас?
Можно попробовать Get(). У версий ECS отличается API. Рекомендую обратить внимание на справку версии, которая используется.
Очень здорово всё рассказал, но насколько я понимаю, одна из важных идей, преследуемых паттерном дата-ориентированного дизайна - отделение той небольшой части данных, используемых в вычислениях от всех остальных данных, относительно статичных (геометрия, текстуры и т.д) для того, чтобы эти данные, используемые в вычислениях были скомпонованы в памяти более компактно и попадали в кэш процессора и в совокупности с тем, что их обрабатывать будут jobы, которые могут работать параллельно - получить существенный прирост в производительности при выполнении большого количества одинаковых операций. И тут наверно лучше использовать ту реализацию ECS/DOTS, которую разрабатывает команда UNITY, а не другие реализации этой парадигмы.
Вот я тоже сижу не понимаю, какое преимущество дает данный подход с LeoECS кроме тотальной декомпозиции компонентов. Это наоборот создает предпосылки к нарушению принципов правильной архитектуры, а именно любой компонент может получить доступ до любой системы вне зависимости от иерархии насколько я понимаю, в обход наследования и интерфейсов, то есть просто вот мне нужно и я беру че хочу. Такой подход оправдан когда он работает в стеке с JOBS\DOTS и каждый такой скрипт потенциально может отработать в своем потоке процессора, и будет скопанован в памяти как вы упомянули. Но, я не понимаю в чем кардинальное преимущество именно LeoECS и подобных, которые сейчас активно все почему то начали юзать.
У меня вопрос а как работать к примеры с Триггерами и Коллайдерами в таком случае ?
Нужно сделать MonoBehaviour, который будет взаимодействовать с ECS и пробрасывать туда эту инфу. Это минус большинства текущих реализаций ECS - всё, что связано непосредственно с компонентами Unity, выглядит не очень удобно. По-моему, официальный ECS от Unity меньше подвержен влиянию этой проблемы, но точной информации у меня нет.
@@insaneone-7220 Почему для меня это похоже на огромный костыль?) Всю жизнь пытались так не работать с кодом, а сейчас такие костыли приветствуются) Для меня это сложно осознать) Я чувствую там много проблем может быть, если это завернуть в визуальное программирование может быть ещё нормально воспринималось бы)
@@_VladMir_ костыль, если не уметь пользоваться. Можешь глянуть декомпиляцию игры Rimworld, которая реализована на ecs (причём на самописном, от разработчика, вроде как), всё там отлично работает, так ещё и удобно пользоваться подобным, например в модинге, не говоря уже о самой разработке.
@@_VladMir_ почему костыль то?
Слушай, если будет 3д модель с 100 полигонами, это комп не нагружает, верно?
100 полигонов - это вообще ни о чем. А 100 000 полигонов на модельку - многовато.
Нет, никаких проблем с таким количеством полигонов)
Гипотетически, современная видюха выдерживает до нескольких миллионов полигонов, но это без учёта текстур и постпроцесинга, но все равно 100 полигонов никак не повлияют
@@insaneone-7220 Кстате, а почему когда я ставлю материал с текстуркой на объект, там сплошной цвет?
@@who-1880 возможно, у модели некорректно сделана UV-развёртка. Цвет совпадает с какой-то из частей текстуры?
Откуда взялся PlayerComponent и что в нём находится?
он может быть полностью пустым, главное что по его наличию мы определяем что это игрок
А почему он переменную объявляет так: " var x :float = ..." ?
что значит эта ":float" и как отличается от " float x =..."
Понял, это Rider дорисовывает тип переменной var
Пожалуйста, сделайте уже урок по unity ecs 1.0.
Все что для 0.5 не актуальны, а официальная документация с багами в примерах.
Единственный англоязычный урок сделан дилетантом, который в один аспект запихнул чуть ли не все компоненты игры.
Нашел что-нибудь ?
Выдает такую ошибку:
'EcsEntity' does not contain a definition for 'Set'
Код:
var test = _world.NewEntity();
test.Set();
вместо этого напиши: test.Get(); он создаст такой компонент, если его нет
@@yerigoth Имею такую же проблему что описана выше, но ваш ответ не решил ее, есть ли еще какие-то советы?
все классно, но для компонентов пришлось использовать структуры. С классами не шло
почему?
А зачем вообще оставил GameObject префабы?
Куда пропал...
На рутубе нету ни одного адекватного туториала по патчфайндингу и А*, может пришло время устранить это допущение?)))
давно есть куча. Посмотри Себастиана, он очень доступно объясняет с примером и открытым кодом
@@nightyonetwothree оказалось я уже смотрел его, но не очень понял
допущение?
Я за 3 дня уже 50 реклам посмотрел на этом ролике
В итоге я отказался от есs недоделанная хрень ( leo + unity ) если вы делаете симулятор подсчета цифр в мультитреде да если делаете игру в 2021 анивэй стандарт лучше.
Если не понравился LeoECS, есть ещё default ECS, ME ECS, Actors, Morpeh - возможно, один из них больше подойдет. Если же не нравится сама концепция или её ограничения в Unity, то да, стандарт лучше. :)
Ecs это не противопоставление ООП, а просто шаблон разделения кода на данные и системы, работающие с данными и имеет свои плюсы и минусы. И ныне используемая в юнити система, это тоже ECS, только не имеющая встроенного обработчика систем. А разделять данные и поведение, это вообще необходимость
Это определение начинает сыпаться как только попытаемся сделать наследование классическим способом. Ецс предполагает плоскую модель типов и composition over inheritance.
@@Leopotam ага, что лучше, кожаный салон(ECS) или автомобиль(ООП)?)) Вы создаете любой класс, и уже используете наследование; без ООП, ECS работать не будет в принципе - чтобы система узнала о сущности, эта сущность должна как минимум наследовать какой-то интерфейс; А то что вы описываете, это как лучше писать, слева направо или наоборот.
@@DarkIllusoire разумеется сущность не должна наследовать никакого интерфейса (наверное разговор не про сущность, а про компонент) и будет работать безо всякой дополнительной абстракции через конечные типы (можно посмотреть в качестве примера тот же leoecs). В этом основное отличие ецс от ооп - никакой абстракции, строго работа с конечными типами.
@@Leopotam лол.. вы путаете наследование, ООП, шаблоны. ecs это шаблон ооп, который позволяет отказаться от наследования.
@@DarkIllusoire Сделаем проще. Являются ли GoLang / Rust языками с поддержкой ООП? Реализация ecs не этих языках невозможна?
в GameInitSystem какаято мешанина ппц
Видео хорошее, а ECS - штука мутная
@@user-ex9ex2hs5k напоминает sql, только в фильтрах компоненты, а не таблицы
Проверил на 8к кубах, хрень ECSLeo Lite, скорость хуже чем у монобеха.
Подход выглядит интересным, но зачем такие неподходящие, путающие названия? Данные - называются компонентом, вместо данных. Действия называются Системами...
Гораздо очевиднее было бы, если бы подход назывался EDA = Entity-Data-Actions
ya pishu na go
Искал урок по ESC Unity, Заголовок Подробный урок по Entity Component System в Unity, а о Leo узнаю в середине ролика. Хотел оскорбить автора, но силы тратить на это в лом...
Извини, чувак, но это не подробный урок) Чтобы эту тему вдуплить надо в 2 раза медленнее объяснять и каждое выражение комментировать, зачем оно нужно. Мозг с трудом то ООП перерабатывает, а тут такое))
Это будет подробный урок по программированию. А здесь конкретная тема
@@viacheslav1392 и все равно это не подробный урок. Показан лишь простейший пример. Все ещё непонятно, как создать взаимодействие между объектами, которые не известны на момент компиляци. Например, открытие дверей. И это только один из многих вопросов. Слишком мало озвучено, тут нужен целый цикл уроков
Согл я просто сижу и слушаю а потом думаю а может пошёл ты вот в оф уроках по юнити я схватывал настолько жадно насколько возможно а тут 0
Зря неофф использовать начал, так как многим приятнее юзать то, что более расширеное
Не хочу душнить, но ты на 6:45 сказал "достаточно наследовать класс от нужного интерфейса", а это не совсем правильно, потому что интерфейсы не наследуются, а реализуются, и строго говоря интерфейс невозможно наследовать.
ага, крч все тоже самое что юнити предоставляет своими компонентами только отвязав от юнити? И зачем такое надо? единственный плюс этого, только то что можно использовать многопоточность? И то, есть другие способы включить многопоточность в юнити, без таких странных усложнений.. В общем. не понял я прикола этого.
не то же самое, юнити использует компоненты с логикой, там данные не отделены от логики, а в ecs отделены
@@OOOJohnJ Тебе ничего не мешает данные хранить данные отдельно. Ты мжешь даже логику отдельно прописать не в наследуясь от MonoBehavior. Вообще не вижу в этом смысла. Не вижу в ECS ничего что нельзя сделать в стандартном юнити. Только дополнительный менингит по изучению и составлению этого всего
@@PrizrakSHIZA вы правы что и в обычном подходе можно отделить данные от логики, но в ECS кроме этого логика вообще не связана с объектами напрямую, а зависит лишь от текущего набора компонент у объекта, таким образом, компоненты могут добавляться и удаляться в рантайме, меняя поведение объекта и при этом не придётся ничего менять в коде. Конечно, вы и так можете написать системы, которые так работают в юнити, тогда вы приблизитесь к ECS, но смысл, если есть специлизированная система, которая помогает находить нужные объекты с компонентами, следит какие куда добавились/удалились и передаёт их системам. То есть если вы всё это будете реализовывать сами, то просто реализуете свой аналог ECS, когда можно использовать уже готовые реализации данного подхода
@@OOOJohnJ А в чем проблема добавлять и убирать компоненты моно в рантайме? И я спрошу от обратного: зачем изобретать велосипед когда он уже есть? Если вам надо менять компоненты в рантайме - пожалуйста. юнити это позволяет. Зачем учить какую-то другую систему, со странными особенностями кода для присвоения, если это все можно сделать с вашими базовыми знаниями юнити? Вот этого я не понимаю. Система ради системы.
@@PrizrakSHIZA так я и говорю что можно убирать, но такой гибкой выборки нужных компонентов на чистом юнити вы не реализуете, а значит вы будете вынуждены сообщать логике о компонентах, которые она должна обрабатывать, что увеличит связанность и вероятность необходимости лезть в работающую логику при добавлении новых возможностей
Спустя годы пересматриваю, и всё равно ничего не понятно. Даже на английском уроки более понятные.
Нужная тема. Подписка. Дизлайк. Все понравилось
Дизлайк?
Абсолютно не ясно зачем надо выделять компоненты в отдельные штуки, а не использовать уже существующий в юнити компонентный подход. Какое-то дублирование подходов. Поиск и создание сущностей в юнити уже существует. Зачем дублировать уже реализованную юнитеками логику я не знаю.
лайк конечно поставлю но)) ЭКС для Юни как Ассемблер для Си - пятая ножка стулу для тяжких пассажиров, а я предпочитаю легковесные программы. так что если ЭКС заполонит всем мозги - то я уйду в продавцы строительного или продуктового маркета)) а без меня вы нормальных игр не напишите и скоро будете кричать под окном мол прости нас Леопольд.. и без ЭКС мощности хватало делать наляпистые игры от перенасыщенности объектами - а теперь я так понял можно сделать чтобы атомы пылюки под ногами прорисовывались по всей вселенной. это неправильный курс - давайте лучше делать стратегии где раз в месяц приходит 1 враг ито с женой и мы с ним от скуки дружно бухаем итд. ума придумать сюжет задающий механики вот цель красивых игр а не сделать ещё в 10000000000 раз больше мобов. по чертам Юнити видно что она задумана первично как простенький редактор игр из квадратов - вот КрайЭнжн макросредство типа накидал ботов и дал им маршруты с заданиями, настроил характеры.. а теперь Юнити перегажена - она то и без того уже тормозит. Юнити 2020-2021 итак никуда не годная из-за потери 30 сек на перекомпиляции при каждой подмене в коде - получается вперёд идти это к полупроцедурному ЭКС и тормозам редактора а назад значит к старым не поддерживаемым версиям. чую всё это саботаж Юнити которую скоро постигнет судьба КрайЭнжна который опротивел перенасыщенностью стандартного демо-ассета и как Юнити подгадивший в Край-сторе. Юню уже еле держит на плаву Юнити-стор дающий нам фичи которые должны быть из коробки, в виде временного подаяния для нищих. В редакторе фишек какбы не убывает в отличии от Края но это всё больше похоже на мусорник уже. А свято место пусто не бывает - ща вот Амазон увидел засранство юнити со стором и тормозами и вот уже делает вой движок, кстати Амазон богат достаточно если не выкупить ставших ненужными запутавшихся разрабов Юнити, то по крайней может их оплатить у них саботаж на что и похоже. почитайте ответы разрабов на вопрос чего компиляци настолько долгая стала что уже почти добавили часики как в Вин-95 - скоро суко табличку добавят типа "Откиньтесь удобно на спинку кресла и сели час глухо то перезагрузите комп и перенапишите все скрипты заново". Так вот разрабы сказали что тормоза от некого волшебного дебага который теперь встроен и даст прозрачность - и тут я вспомнил что Юня стала с 2020-2021 не показывать в чём суть ошибки и даже неверно указывать где ошибка. так что отмазка таксебе
"а не сделать ещё в 10000000000 раз больше мобов" Жалко, что люди насмотрелись того, что на коде ecs можно создать 10000000 объектов. ecs это ПАТТЕРН проектирования, а не способ оптимизации кода. Просто при таком проектировании кода, как ecs, следствует хорошая поддержка кода, так как поскольку все данные отделены от логики, легкость в расширении кода и весь код имеет малое кол-во взаимосвязей. между собой. Производительность и многопоточность является лишь плюсом этого проектирования. Я бы посмотрел на вас, если бы вас попросили убрать что-нибудь критичное из программы. В ecs же достаточно будет убрать определенную систему.
@@evilvirraZzz это так только говориться - сколько себя помню одни и те же слова были про то что привносят процедуры, потом классы а потом интерфейсы... да приносят на порядок большее могущество - ощутив его мы лезем в большие дебри, вместо быстрой сборки простенького весёлого продукта. моей жене в первый раз понравился уровень из примитивов Юнити где просто ходишь - потому что там не было реальности и никто тебя не пресует, а было всё необычное, прыгал просто сод-пёсн. когда я это всунул в ВР то снова её привлекло - никак не вот эти супер-реалистичные механики из-за которых вечно нужно подключать или убавлять компоненты. да разумеется из-за того что я этим не занимался а ходил на подработки то очутился в роли программера крупной конторы - теперь меня эксплуатируют делать что хочет шеф или клиент, и конечно они хотят пожирнее, ещё сами не знают что такое ЕКС но уже требуют. а вот способнейший напарник класса синьор уж 5 лет - говорит что штука быстрая и классная но окончательно порекомендовать затрудняется, просто говорит выучил по привычке всё использовать первей всех. и то что после ЭКС он стряпает проекты на Анриале мне тоже о чём-то говорит)) он гребёт технологии, патерны, структуры кода изобретает.. и научил меня всё делать интерфейсами - вот честно не вижу нужды ни в чём. и кстати я сделал больше шедевров чем супер-мега синьор ток потому что не занят постоянным скилапом под завязку. лучше бы разрабы сделали Юню 2021 менее тормознутой. ато я добавляю в код просто комментарий а оно ЧТОТО перекомпилирует - рука-лицо, я Юню терплю уже с последних сил и учу другие движки параллельно, останутся они со своим ЭКС в гордом одиночестве есь так плевать на потребителя
Видео хорошее, но ты сильно спешишь и просто не успеваю вникнуть в суть.
Сколько можно плодить видео типо "вот так не надо делать", "а это лучше не использовать", не предлагая альтернативы,обучающее видео или вредных советов.
зачем это использовать если не для многопоточности...всё испортил
Хорошая архитектура. Но чот многовато сахара )
блин это надо смотреть на 0.25