Войти
ПрограммированиеФорумГрафика

ECS во все поля

Страницы: 1 2 3 4 5 6 Следующая »
#0
(Правка: 16:52) 16:52, 10 апр. 2020

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

Начну с пары примеров, которые я затрудняюсь, как представить в виде компонент, объектов и систем:
1) Предположим, есть автомобиль с физикой, от которого могут отваливаться куски при повреждении. Принято ли каждый кусок считать отдельным объектом с одним компонентом-графическим представлением, либо весь автомобиль — один объект, но у него есть много компонентов, соответствующих каждому куску, либо весь автомобиль — один объект, и у него есть один компонент — "разрушаемый объект"? Или всё зависит от задачи и чётких правил нет?
2) Существуют игровые сущности, которые не являются обособленными объектами. Например, дождь, или отладочный рендер, который рендерит всё, что только можно. Или, например, логгер. Приянто ли такие сущности называть системами (хотя они не будут объедияь собой группы компонентов объектов)? Или их лучше делать каким-то отдельным паттерном, обособленно от ECS?

#1
18:10, 10 апр. 2020
Не верится что Суслег создал этот тред, даже мне -
мамкиному кодерку-теоретику видится решение слишком зависящим от,
чтоб оно было единоверным на все случаи жизни.
#2
18:15, 10 апр. 2020

просто я знаю, что в ECS всё не так просто, как может показаться не первый взгляд. есть продвинутые системы, где он практикуется дольше, чем в гейдеве, и там есть много, чем поучиться. но если я загоняюсь, то всегда, конечно, можно сделать хоть как-то.

#3
18:23, 10 апр. 2020

Посмотри на ютубе презентацию про ecs в overwatch

#4
19:06, 10 апр. 2020

Много в ECS не шарю, но игру делаю как раз на нем и тоже доморощенный. Геймплей логика на ECS. Мета-игра на гибриде ecs и mvc. За рендер отвечает двиг (cocos2d-x), тут ecs и не пахнет. Потому объективно могу сравнить эти подходы.

1. Затрудняюсь ответить. Но в простом случае отвалившийся кусок - это новая сущность с компонентами нужного типа (меш + трансформ + остальная необходимая физика). Изначально делать компонент, состоящим из кучи кусков - перегруз. Хотя очень многое зависит от того, что есть и что нужно получить.
2. Дождь - компонент. Рендер уже отдельная архитектура, как и логгер. Зачем их то к ECS притягивать? ECS хорошо ложится на геймплей логику. А все остальное, системное, это натягивание совы на глобус. Можно конечно, но зачем?

> Приянто ли такие сущности называть системами
Система - это же как раз логика для обработки одного (и связанных с ним) типа компонента. Систем может быть несколько на каждый компонент, но каждая система в идеале делает ровно одну задачу.


BingoBongo
А есть где почитать?

#5
(Правка: 19:21) 19:21, 10 апр. 2020

BingoBongo
> Посмотри на ютубе презентацию про ecs в overwatch
лул, в районе 11:00 он обсуждает практически в той же формулировке то, что я в нульпосте спросил

Запустить видео по клику - Как делать игрыЗапустить видео по клику - Как делать игры
#6
19:42, 10 апр. 2020

Suslik
> 1) Предположим, есть автомобиль с физикой, от которого могут отваливаться куски
> при повреждении. Принято ли каждый кусок считать отдельным объектом с одним
> компонентом-графическим представлением, либо весь автомобиль — один объект, но
> у него есть много компонентов, соответствующих каждому куску, либо весь
> автомобиль — один объект, и у него есть один компонент — "разрушаемый объект"?
> Или всё зависит от задачи и чётких правил нет?
Автомобиля в ECS не существует. Есть данные описывающие движение чего-то с колёсами по дороге с моделькой. Такая машинка может быть представлена доброй сотней entity например. Данные первичны, думать надо о них, а не об объектах.

#7
20:06, 10 апр. 2020

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

Т.е. проблемы нет, если сущность Rain будет в общей системе ентитей и иметь уникальный Id. Но и особенного волшебного профита тоже мало.

#8
20:13, 10 апр. 2020

Каждый кусок отдельная ентити с геометрией. Чтоб отвалилась меняешь индекс парента на world (вместо vehicle) и sleep = false. Больше никак. Если еще учитывать, что всё зааллоцировано заранее.

#9
(Правка: 20:22) 20:19, 10 апр. 2020

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

короче, TL;DR, они как раз рассказывают про то, как ввели паттерн singleton component, который им показался полезным для инпута (потому что им тоже показалось странным для всех объектов хранить копию инпута или хранить один объект с компонентом ипута) и ВНЕЗАПНО у них 40% всех компонентов переехало в этот паттерн. в то же время мне очень странно, почему никто больше про эти же самые проблемы не говорит, когда они, очевидно, имеют место быть и их необходимо как-то решать.

lookid
> Каждый кусок отдельная ентити с геометрией. Чтоб отвалилась меняешь индекс
> парента на world (вместо vehicle) и sleep = false. Больше никак. Если еще
> учитывать, что всё зааллоцировано заранее.
проблема не в parenting'е, а в случае, если что-то оказывается привязно к чему-то посредством чего-то. например, если от машины дверь отвалилась, но не полностью и держится на проводе, то провод считать отдельной энтитей?

#10
(Правка: 21:28) 21:24, 10 апр. 2020

Suslik
> короче, TL;DR, они как раз рассказывают про то, как ввели паттерн singleton
> component

А в чем собсна новизна то? Они открыли для себя DI?

>проблема не в parenting'е, а в случае, если что-то оказывается привязно к чему-то посредством чего-то.

Послушай, ну в любой проге чтото к чему то чем то да привязано. Где мясо идеи, специфики именно геймдева. Патерн singleton  - он же кросспредметный, че гейма че мабайл клиент для VS - один хрен , везде можно применить, еслив с умом. MVVM - тоже самое, ООП - тоже самое.

>Приянто ли такие сущности называть системами

Это было ПриЯтно или ПриНято ? Хотя не важно.. Конкретно к системе лога мне бы удобно было так

Systems.Get<Log>().МетодLogСистемы(); //c#
или сразу так
Systems.Log.МетодLogСистемы(); //c#


>посмотри доклад выше

Пересмотрел несколько. Ну не вижу где суть, в чем. Эти игры в архитектуры они ж на вкус и цвет. И все с какими то минусами. Обсуждение объектной модели, чего у тебя там, движок, фреймворк - эт другое дело. Да и там в общем то пути протоптаны по десять раз уже.

#11
1:55, 11 апр. 2020

Suslik
> посмотри доклад выше, там у ребят явно опыт больше, чем у тебя и у меня вместе
> взятых и они так не считают

Эм, ну смотря в чем.

> короче, TL;DR, они как раз рассказывают про то, как ввели паттерн singleton
> component, который им показался полезным для инпута (потому что им тоже

Я посмотрел-полистал немножко, но до того места где паттерн синглтон круто включается в ECS и начинает приносить профит, не осилил.
Это конечно грейт ревелейшн - "мы тут обмазывались всякими паттернами, а оказывается синглтоны крутая штука". Но я это всегда знал, ты можешь еще помнить темы которые я создавал 12 лет назад :).

#12
6:26, 11 апр. 2020

лол, уже двое услышали слово "синглтон" и решили, что знают, о чём идёт речь. там слово "component" во фразе "singleton component" там не для красоты. энивей, все эти вопросы имеет смысл себе задавать уже после того, как ты уже разочаровался в обычном actor-based подходе, в наследовании и полиморфизме, когда ты уже пробовал ECS и прочувствовал, в чём он даёт профит и где он мешает, итп. например:

slepov
> Systems.Get<Log>().МетодLogСистемы();
нет у систем состояния, поэтому у них не может быть методов, которыми должен обладать логгер. только не надо меня спрашивать, почему у систем нет состояния и какая разница.

#13
10:46, 11 апр. 2020

недавно столкнулся с гибридной ECS

т.е. выглядит типично как иерархия классов в каком-нибудь UE4, но под капотом поля находятся в ECS, скажем трансформы и даже указатели на физобъекты

по-хорошему надо писать stateless физику как это делают юнитехи, но не у всех есть ресурсы под это, отсюда просто указатели из физикса

#14
(Правка: 10:55) 10:52, 11 апр. 2020

Suslik
1. Я думаю правильная ECS архитектура выглядит так:

  • Компоненты это просто база данных (айди меша, материала и тд)
  • системы создают свою, оптимизированную репрезентацию. Нужна иерархия - собирают граф зависимостей, нужно кэшировать пайплайны для вулкана - цепляют компонент с пайплайном.
  • Есть несколько групп, которые не пересекаются. Например есть несколько камер, для каждой нужен список рендер компонентов с разной детализацией, если все хранить в одной большой ECS, то получатся частые смены архетипов, что плохо, поэтому для камеры либо создается отдельный реестр, либо альтернативная реализация вообще без ECS. Вообще это надо отдельно все расписывать, но можешь почитать как это сделано в destiny, там не тру ECS, но архитектура хорошо продумана.

  • destiny data flow | ECS во все поля

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

    что почитать:
    https://github.com/SanderMertens/ecs-faq

    от создателей танков (тут есть про сингл компоненты)
    https://habr.com/ru/company/wargaming/blog/245321/
    https://habr.com/ru/post/469709/

    flecs и unity используют подход с архетипами, что сейчас наиболее правильное решение, доки полезно почитать)

    ссылку на доки по юнити не могу нормально вставить, так что через гугл
    Страницы: 1 2 3 4 5 6 Следующая »
    ПрограммированиеФорумГрафика