Кирилл Надеждин (Kumo Kairo) - ECS в разработке игр - хорошая архитектура приложений для всех
ฝัง
- เผยแพร่เมื่อ 28 ธ.ค. 2017
- Убираем ООП и заменяем его ECS (Компонентной системой сущностей). Кирилл расскажет вам об отличной архитектуре приложений для всех.
Презентация: www.slideshare.net/flashgamm/...
Доклады Кирилла:
- Unity Scriptable Render Pipeline. В кастомизацию рендеринга с головой (2019) - • Кирилл Надеждин (SWAG ...
- Оптимизация мобильной графики в Unity - полевые исследования (2018) - • Кирилл Надеждин (SWAG ... - เกม
Ох, вовремя нашёл. Лучше поздно, чем очень поздно.
Отдельно отмечу подачу. Прямо кайф. Талантливо!
ECS makes perfect sense to me. Awesome.
Отличный доклад и хороший разбор вопросов!
Много интересного, Спасибо!
Отличный доклад и шикарные вопросы/ответы! Спасибо большое! :3
Отличная лекция! Благодарю!
Не знал, Андрюха, что ты кроме 3Д еще и программированием занимаешься )
смотрю об этом в 2021 --___--
yay, likereactivesystem just went 100 after my input changed the pool :) great talk ! cheers from Morocco !
A very good lecture.
Thank you!
Подскажите есть ли что-то общее между системами трюков и обработчиками в паттерне(Chain of Responsibility)?
Я вот не понимаю, как использовать фичи Юнити, пользуясь ECS
Как использовать коллайдеры тогда? OnCollisionEnter например
И как эти компоненты лепить на объекты вообще?
Монобех обработчик. Создайте монобех компонент с OnCollisionEnter(), который в себе уже будет помечать привязанную к этому геймобджекту энтити как столкнувшуюся: entity.isCollided = true; entity.AddCollisionId(*id энтити которая столкнулась с этим геймобджектом*)
Для совсем начинающих в архитектуру, есть на русском / наглядные диаграммы? Или видео уроки / курсы?
Не знаю, поможет ли, но есть хорошая статья про другой ECS www.ibm.com/developerworks/ru/library/os-Ash/index.html . А вот тут его исходники и пример демо проекта github.com/richardlord/Ash .
Там правда фреймворк для флеша. Но язык сильно похож на C# и я думаю особых сложностей не будет.
И еще, код самого того движка понять сложно (там происходит довольно неочевидная магия), поэтому если вы новичёк то смотрите только демо проект и статью.
Отличная лекция! Присматриваюсь к Entitas и возник вопрос, поднимал его в чате entitas, но пока не получил точного ответа. Собственно вопрос в том, можно ли подружить ООП модель данных с ECS логикой и как это сделать, или этого делать не стоит?
Пример: Есть third party бэкенд фреймворк включающий ООП модель данных для внутриигрового магазина и инвентаря игрока, реализованную в виде классов Shop, ShopItem, Inventory, InventoryItem. И мы хотим построить ECS UI для магазина.
Если есть ООП модель и не хочется её полностью зеркалить в компонентах, то стоит создать как минимум компонент которой держит ссылку на головной объект модели. Плюс, эвенты из модели нужно прозеркалить как компоненты, тогда реактивные системы смогут работать при изменениях в ООП модели.
Попал на этот видос ибо всегда писал игры одним классом)
Dont know if anyone cares but if you guys are stoned like me during the covid times then you can stream pretty much all the latest movies on instaflixxer. Have been watching with my girlfriend for the last couple of months xD
@Kristopher Gunnar Yup, been watching on InstaFlixxer for since december myself =)
@Kristopher Gunnar Yup, have been using InstaFlixxer for since november myself :)
27:05 ок, го 😀
Я разбил компоненты на группы, каждая группа обрабатывается своей системой, но что делать, если для обработки одной группы требуются данные из другой группы? У меня есть 2D спрайты в 3D окружении и мне нужно поворачивать их лицом к камере (игроку). Для этого системе, которая поворачивает спрайты нужно знать позицию камеры (игрока). То есть уже не получается счастливый мир в котором система просто берет одну группу компонентов и обрабатывает её. Теперь ей нужны две разные группы компонентов, чтобы выполнить свои вычисления. Об этом почему-то нигде не пишут вообще, как это правильно делать и можно ли как-то избежать этой проблемы.
Система принимает на вход какие-то данные и что-то делает. Все. Если тебе нужны данные, которые не приходят на вход - значит у тебя там неправильная архитектура. Easy.
Не нужно стараться распихивать компоненты по абстракциям(группам)
Проблема, когда одна система должна знать о данных, которые обрабатывает(изменяет, пишет) другая система - это не проблема, это не запрещено.
Самое главное соблюдать принцип: в одни данные ПИШЕТ только ОДНА система, а ЧИТАТЬ могут сколько угодно систем
Если позиция игрока изменяется одной системой, то системе, которая работает с камерой не запрещено читать позицию игрока
дайте пример на зверях в консоли )))
Ну шо потомки, как у вас с ECS спустя 5 лет?!)))
30:36 тестовое задания кто нибудь нашёл?
Как абстрагировать бизнес логику в системах от остального кода ? Меняется инфраструктурный код, лезем менять и бизнес логику в системах ? Например реализация вектора может меняться соответсвенно нельзя его напрямую инстанциировать в системе, а если вектор скрыт за компонентом то нельзя инстанциировать компонент в системе иначе будет зависимость от реализации, а это нарушение принципа OCP из SOLID.
Ну да, вектор же каждый день меняется.
@@sasichkamega вектор и его реализация вещи несколько разные. Можно взять готовую библиотеку где уже есть реализация векторов, матриц, кватернионов и т.д. Если использовать ее нарямую то будет зависимость, а библиотеку могут забросить, может выйти более современная и еще сотни причин по которой ее возможно потребуется заменить. Можно конечно написать свою математическую реализацию этого всего но зачем если уже есть готовое.
@@xfg9183 а в чем тогда, собственно, проблема, если интерфейс остался не тронутым?
@@xfg9183 взял ты библиотеку с реализованным вектором, написал proxy класс, вдруг библиотеку забросили, но твой код завязан на интерфейс прокси класса, взял да переписал его на другой вектор из другой не заброшенной библиотеки.
А вообще не вижу смысла использовать не std::vector.
@@sasichkamega я об этом же. Но как-то странно передавать в систему обьект вектора, чтобы потом через него же пытаться создавать новые экземпляры векторов внутри системы. Хотел просто увидеть как другие делают. Реализации вроде std::vector не во всех языках.
ECS в Юнити работает с самого начала (с 2005 года), только корявая немного. В Анриле она тоже есть, но смешана с ООП. Не понимаю, зачем писать для Юнити одно и тоже, тем-более корявее, когда в Юнити эта система есть и работает.
Более подробно я написал тут:
www.gamedev.ru/code/forum/?id=215818&page=4#m47
www.gamedev.ru/code/forum/?id=215818&page=4#m51
Забавно читать такие комменты в 2018 году, когда в 2017 "CTO" Unity на Unite Europe огласил, что только началась разработка Unity ECS. А на GDC 2018 они представили несколько докладов, оглашая ECS как будушее скриптинга в Unity. www.twitch.tv/videos/241945353
Блин, я не думал, что ты говоришь по-русски, может ещё и Саймон тоже? )
Не Саймон, не говорит. А я made in Саратов, хотя большую часть жизни провел в Германии.
В этой архитектуре глобальное состояние, которое может менять кто угодно. Это тоже самое, что использовать глобальные переменные. Любое изменение в одной системе может приводить к сайд эффектам в других. Хрупкий, зависимый и ломкий код. Инкапсуляция разрушена. Это же хаос.
В ECS код заранее сломан, так как сущности могут изменяться хаотично.
Поэтому системы ничего не знают о сущностях (для систем сущность - это лишь номер).
И соотвественно задача систем определить: является ли данный номер адекватным для обработки.
@@user-fe1nr3ws1z согласно шаблону всё понятно, в компонентах - данные, в системах - логика. На деле же у всех сделано по разному, в unity полно синглтон сервисов типа Input, в компонентах полно инфраструктурного кода, а коллизии между объектами вообще просчитываются где-то на уровне самого движка и бросаются события. Я не понимаю как в конечном счете должен быть структурирован код в этой архитектуре, чтобы всё это не превратилось в кашу.