Ох, вовремя нашёл. Лучше поздно, чем очень поздно. Отдельно отмечу подачу. Прямо кайф. Талантливо!

Отличный доклад и хороший разбор вопросов! Много интересного, Спасибо!

Отличный доклад и шикарные вопросы/ответы! Спасибо большое! :3

смотрю об этом в 2021 --___--

ECS makes perfect sense to me. Awesome.

yay, likereactivesystem just went 100 after my input changed the pool :) great talk ! cheers from Morocco !

Отличная лекция! Благодарю!

@JosefKneht

4 жыл бұрын

Не знал, Андрюха, что ты кроме 3Д еще и программированием занимаешься )

Подскажите есть ли что-то общее между системами трюков и обработчиками в паттерне(Chain of Responsibility)?

A very good lecture.

@DevGAMMchannel

2 жыл бұрын

Thank you!

Для совсем начинающих в архитектуру, есть на русском / наглядные диаграммы? Или видео уроки / курсы?

@drVatman

5 жыл бұрын

Не знаю, поможет ли, но есть хорошая статья про другой 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 для магазина.

@iceX33

6 жыл бұрын

Если есть ООП модель и не хочется её полностью зеркалить в компонентах, то стоит создать как минимум компонент которой держит ссылку на головной объект модели. Плюс, эвенты из модели нужно прозеркалить как компоненты, тогда реактивные системы смогут работать при изменениях в ООП модели.

Я вот не понимаю, как использовать фичи Юнити, пользуясь ECS Как использовать коллайдеры тогда? OnCollisionEnter например И как эти компоненты лепить на объекты вообще?

@bogdan4760

9 ай бұрын

Монобех обработчик. Создайте монобех компонент с OnCollisionEnter(), который в себе уже будет помечать привязанную к этому геймобджекту энтити как столкнувшуюся: entity.isCollided = true; entity.AddCollisionId(*id энтити которая столкнулась с этим геймобджектом*)

Попал на этот видос ибо всегда писал игры одним классом)

@kristophergunnar9551

2 жыл бұрын

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

@kelvinleonidas3449

2 жыл бұрын

@Kristopher Gunnar Yup, been watching on InstaFlixxer for since december myself =)

@felixduke8754

2 жыл бұрын

@Kristopher Gunnar Yup, have been using InstaFlixxer for since november myself :)

Ну шо потомки, как у вас с ECS спустя 5 лет?!)))

27:05 ок, го 😀

дайте пример на зверях в консоли )))

Я разбил компоненты на группы, каждая группа обрабатывается своей системой, но что делать, если для обработки одной группы требуются данные из другой группы? У меня есть 2D спрайты в 3D окружении и мне нужно поворачивать их лицом к камере (игроку). Для этого системе, которая поворачивает спрайты нужно знать позицию камеры (игрока). То есть уже не получается счастливый мир в котором система просто берет одну группу компонентов и обрабатывает её. Теперь ей нужны две разные группы компонентов, чтобы выполнить свои вычисления. Об этом почему-то нигде не пишут вообще, как это правильно делать и можно ли как-то избежать этой проблемы.

@user-vw2sb6wi2m

4 жыл бұрын

Система принимает на вход какие-то данные и что-то делает. Все. Если тебе нужны данные, которые не приходят на вход - значит у тебя там неправильная архитектура. Easy.

@5_funger

2 ай бұрын

Не нужно стараться распихивать компоненты по абстракциям(группам) Проблема, когда одна система должна знать о данных, которые обрабатывает(изменяет, пишет) другая система - это не проблема, это не запрещено. Самое главное соблюдать принцип: в одни данные ПИШЕТ только ОДНА система, а ЧИТАТЬ могут сколько угодно систем Если позиция игрока изменяется одной системой, то системе, которая работает с камерой не запрещено читать позицию игрока

Как абстрагировать бизнес логику в системах от остального кода ? Меняется инфраструктурный код, лезем менять и бизнес логику в системах ? Например реализация вектора может меняться соответсвенно нельзя его напрямую инстанциировать в системе, а если вектор скрыт за компонентом то нельзя инстанциировать компонент в системе иначе будет зависимость от реализации, а это нарушение принципа OCP из SOLID.

@sasichkamega

4 жыл бұрын

Ну да, вектор же каждый день меняется.

@xfg9183

4 жыл бұрын

@@sasichkamega вектор и его реализация вещи несколько разные. Можно взять готовую библиотеку где уже есть реализация векторов, матриц, кватернионов и т.д. Если использовать ее нарямую то будет зависимость, а библиотеку могут забросить, может выйти более современная и еще сотни причин по которой ее возможно потребуется заменить. Можно конечно написать свою математическую реализацию этого всего но зачем если уже есть готовое.

@sasichkamega

4 жыл бұрын

@@xfg9183 а в чем тогда, собственно, проблема, если интерфейс остался не тронутым?

@sasichkamega

4 жыл бұрын

@@xfg9183 взял ты библиотеку с реализованным вектором, написал proxy класс, вдруг библиотеку забросили, но твой код завязан на интерфейс прокси класса, взял да переписал его на другой вектор из другой не заброшенной библиотеки. А вообще не вижу смысла использовать не std::vector.

@xfg9183

4 жыл бұрын

@@sasichkamega я об этом же. Но как-то странно передавать в систему обьект вектора, чтобы потом через него же пытаться создавать новые экземпляры векторов внутри системы. Хотел просто увидеть как другие делают. Реализации вроде std::vector не во всех языках.

30:36 тестовое задания кто нибудь нашёл?

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

@user-fe1nr3ws1z

5 жыл бұрын

В ECS код заранее сломан, так как сущности могут изменяться хаотично. Поэтому системы ничего не знают о сущностях (для систем сущность - это лишь номер). И соотвественно задача систем определить: является ли данный номер адекватным для обработки.

@xfg9183

5 жыл бұрын

​@@user-fe1nr3ws1z согласно шаблону всё понятно, в компонентах - данные, в системах - логика. На деле же у всех сделано по разному, в unity полно синглтон сервисов типа Input, в компонентах полно инфраструктурного кода, а коллизии между объектами вообще просчитываются где-то на уровне самого движка и бросаются события. Я не понимаю как в конечном счете должен быть структурирован код в этой архитектуре, чтобы всё это не превратилось в кашу.

ECS в Юнити работает с самого начала (с 2005 года), только корявая немного. В Анриле она тоже есть, но смешана с ООП. Не понимаю, зачем писать для Юнити одно и тоже, тем-более корявее, когда в Юнити эта система есть и работает. Более подробно я написал тут: www.gamedev.ru/code/forum/?id=215818&page=4#m47 www.gamedev.ru/code/forum/?id=215818&page=4#m51

@iceX33

6 жыл бұрын

Забавно читать такие комменты в 2018 году, когда в 2017 "CTO" Unity на Unite Europe огласил, что только началась разработка Unity ECS. А на GDC 2018 они представили несколько докладов, оглашая ECS как будушее скриптинга в Unity. www.twitch.tv/videos/241945353

@DmitryKozlovtsev

6 жыл бұрын

Блин, я не думал, что ты говоришь по-русски, может ещё и Саймон тоже? )

@iceX33

6 жыл бұрын

Не Саймон, не говорит. А я made in Саратов, хотя большую часть жизни провел в Германии.