лампового обсуждения bevy 0.9, современного перспективного open source движка https://bevyengine.or
Аноним
04/12/22 Вск 14:11:13
№
1
https://bevyengine.org/news/bevy-0-9/
на эту тему распространяется следующее пользовательское соглашение:
• любой пользователь доски имеет право инициировать новые обсуждения на любые темы в рамках тематики раздела и свободно общаться с теми, кому интересна эта тема, в пределах этого обсуждения
• тема в рамках тематики раздела является равноценной участнией обсуждения тематики и не может препятствовать и ограничивать обсуждения в других темах, ее существование не является негативным фактором для пользователей; индивидуальная неприязнь темы отдельными пользователями не должна является основанием для жалоб, удаления
• наличие похожей темы не должно являться основанием для жалобы на или удаления темы, поскольку разные группы пользователей имеют право обсуждать одну тему в разном ключе и рамках заданного в теме этикета
• это частная тема, запрещается присваивать этой теме административный статус любыми способами, в том числе: "закреплять", указывать ссылку на эту тему в других "закрепленных" темах и т.д.
• запрещается указывать другим пользователям что писать в этой теме, нарушая право пользователей на свободу выражения
• запрещается жаловаться на и удалять обычные сообщения(1) пользователей, препятствуя свободному общению
• читая эту тему вы принимаете условия этого соглашения
___
(1) обычное сообщение это любое вновь придуманное сообщение написанное настоящим пользователем в рамках темы и тематики раздела в любой форме - серьезной, шуточной, ироничной и т.д.,- не содержащее порнографии, политических призывов, других сведений нарушающих закон РФ
Примеры игр? Где скачать? Легко ли вкатиться по сравнению с уже существующими движками? Стоит ли пробовать? Долго ли делать первую примитивную игру?
кал
раст + ECS слишком сложная комбинация для создания игр
На расте нельзя сделать ничего кроме ECS для игр. А на ECS нельзя в принципе сделать игру, потому что оно хорошо только в теории, а на практике быстро превращается в неконтролируемую лапшу с невозможностью отследить цикл обновления.
Движок без редактора. Добавлять объекты в игру в коде максимально недружелюбно.
Пока что bevy это просто игрушечный проект, которому фанбои раста накрутили звезд на гитхабе
Единственный способ изменить компоненты другой entity из системы - это как-то передать инфу, которая будет флагом, в другую систему. Либо навесить новый компонент, либо добавить какой-то объект в специальную коллекцию (хак типа почтового ящика)
Вы понимаете что это означает, да?
Надо проверить столкновение? Пилишь систему и добавляешь компонент.
Надо отнять HP? Пилишь систему и добавляешь компонент.
Таким образом в игре легко будут сотни бесполезных систем с одной строчкой кода, который будут просто в холостую обновляться каждый кадр
во всей это лапше из систем потом будет совершенно невозможно разобраться
Ты зачем свою аватарку прикрепил? Тут аватарок не любят.
>нельзя в принципе сделать игру
Сделать игру можно даже на ассемблере под микроконтроллеры.
>фанбои раста накрутили звезд на гитхабе
Ну а что ты возбудился-то? Пусть местные растисты порадуются.
Это мое экспертное мнение о движке bevy
Для разработки игр не годится из-за непрактичности
>Таким образом в игре легко будут сотни бесполезных систем с одной строчкой кода, который будут просто в холостую обновляться каждый кадр
Таки в этом суть и философия ECS. Движок должен каким-то образом оптимизировать последовательность обновлений систем, чтобы не гонять их вхолостую. Также обновления систем, по идее, должны быть дешевле обновления ООП-объектов, потому что данные, необходимые системам, по DOD-у должны целиком умещаться в кэш процессора, избавляя от беспорядочных запросов к RAM.
Сравни, ООП-подход:
1. Последовательно обходим список объектов в куче.
1.1. Каждый объект отдельно ищется в RAM и грузится в кэш процессора.
1.2. Процессор не может угадать, какой объект мы будем грузить дальше.
2. Каждому объекту вызываем process(), input() и т.д.
2.1. Это, в свою очередь, вызывает подгрузку из RAM других объектов...
2.2. Которые могут обращаться к произвольным данным в RAM...
3. Повторяем с шага 1.
И ECS/DOD-подход:
0. Заранее загружаем в кэш процессора все имеющиеся системы.
1. Последовательно обходим список категорий компонентов в куче.
1.1. В кэш процессора отправляются сразу все компоненты одного списка.
2. Последовательно натравливаем каждую систему на каждый компонент.
3. Повторяем с шага 1.
На практике, конечно, вся эта фигня с DOD-ом ломается, когда тебе нужно больше одного компонента для работы системы или когда данные всех компонентов одного типа слишком большие, чтобы уместиться в кэш целиком. Хотя в последнем случае процессор, в теории, может предсказать, какой блок данных потребуется ему дальше, и заранее запросить этот следующий блок у RAM. То есть данные в кэш могут поступать раньше, чем процессор выполнит операции с предыдущим блоком данных.
С точки зрения геймдизайна я абсолютно согласен с тем, что ООП намного более естественная и приятная концепция, чем ECS. В плане гибкости ООП ничем не уступает ECS, а все претензии к системе наследования ООП контраргументируются тем, что наследование в ООП не обязательно и никто не запрещает делать свои игровые сущности через композицию или агрегацию. Более того, в ООП мы можем использовать наследование, когда нам это удобно, а чистый ECS не допускает этого, заставляя делать всё через агрегацию (сборка сущностей из компонентов).
Кроме того, крайне сомнительна польза от загрузки всех компонентов в кэш процессора, когда одинаковых компонентов мало. Существенный прирост производительности стоит ожидать только когда у тебя в игре десятки тысяч сущностей одного класса... Но в ООП мы можем оптимизировать этот момент, собрав все такие сущности в один массив и работая с ним как диды - т.е. процедурно. Такой массив в ООП будет целиком грузиться в кэш не хуже компонентов в ECS.
Да эта оптимизация цикла обновления в 99% игр как-раз не дает никакого преимущества. Но усложняет организацию кода.
С объектами хорошо то, что они отлично ложатся на интуитивную ментальную модель человека. Вот есть в реальности физический объект солдатик. А есть в компьютерной игре виртуальные объекты солдатиков со своими свойствами и поведениями. У солдатика есть компонент перемещения, он держит объект оружия, у которого есть компонент с поведением как это оружие стреляет. Это все натурально.
ООП никак не ограничивает разработчика, а только ведет его в правильную сторону. ECS наоборот очень неинтуитивный и накладывает серьезные ограничения на то, как надо решать задачи.
Самое главное что я имел ввиду, это то, у подхода с объектами из-за их композиции поток обновления игры имеет иерархическую форму. То есть некая точка входа в программу, в которой все начинается, она вызывает какие-то методы одного объекта, у этого объекта есть другой вложенный объект, у которого вызывается метод и т.д.
Цикл обновления представляет собой дерево, которое легко проследить, изменить, переделать.
В ECS все системы одноуровневые и взаимодействуют между собой посредством сигналов, направления которых в коде нельзя проследить (нельзя тыкнуть во вложенный метод, перейти в него, тыкнуть в другой вложенный метод и т.д.), поэтому распутать сложную игру с сотнями систем, что-то добавить, переделать, становится почти нереальной задачей. Это то же самое что т.н. callback hell.
>как-раз не дает никакого преимущества. Но усложняет организацию кода.
>отлично ложатся на интуитивную ментальную модель человека
>ООП никак не ограничивает разработчика
Да, я именно это и имел в виду.
>поток обновления игры имеет иерархическую форму
Необязательно. Если ты хочешь получить преимущества многоядерных процессоров, то есть как минимум двухядерных (сейчас вообще остались одноядерные модели?), а лучше четырёхядерных (по-моему, это новый минимум на рынке, даже в бюджетных процессорах либо 4 ядра, либо 2 + 2 виртуальных), то ты будешь создавать дополнительные потоки выполнения, которые могут задерживаться или опережать основной поток. Либо такие потоки будет создавать твой движок, но в играх также может быть необходимо разделить на потоки высокоуровневые системы (ИИ, чанки). Кроме того, при разработке игры в любом случае тебе невыгодно связывать все объекты жёсткими ссылками друг на друга, поэтому лучше использовать обработчики событий/сигналов: объект просто испускает сигнал, и ему не важно, кто обработает этот сигнал и обработает ли вообще. Если кому-то важен этот сигнал, он просто на него подписывается в любой момент и ждёт.
>Это то же самое что т.н. callback hell.
Погуглил, это что-то из JS. Советуют разбивать код на функции и функции паковать в модули, чтобы код был читабельным и его можно было использовать повторно. Или ты о чём-то другом?
> а на практике быстро превращается в неконтролируемую лапшу
А не надо писать код в компонентах. Компоненты это данные.
>с невозможностью отследить цикл обновления.
Каждая система - это функция, они запускаются в строго определённом порядке, так что цикл линейный.
>это функция, они запускаются в строго определённом порядке, так что цикл линейный
90% процентов систем в игре это if с одной строчкой кода, которые будут пропукиваться 99% игры вхолостую, тратя ценные ресурсы процессора
смотри пример >>843358
важно не то, что они выполняются линейно. важно то, что условия внутри них не линейные и имеют хаотические зависимости
Общение через события - это совершенно нормально. И, кстати, укладывается в изначальную парадигму ООП - "объекты обмениваются сообщениями". Тут системы - это именно такие объекты.
>if
кроме if условием выполнения системы еще может являться query по специально добавленному компоненту
сообщение это растяжимое понятие. в строго типизированных языках "сообщение" это вызов метода объекта
когда 90% кода это отправка сообщений непонятно кому - это это ненормально
>в играх также может быть необходимо разделить на потоки высокоуровневые системы (ИИ, чанки)
bevy из коробки распараллеливает только системы. Генерацию чанков придется делать самому все равно через тред пул какой нибудь, ECS тут никак не поможет.
Многопоточность игровой логики сильно переоценена
>>843358
>>843353
Мне вообще нравится смешение архитектур обычного ООП и ECS, когда структура движка у нас обычная геймобджект и дочерние объекты. Но к каждому геймобджекту мы еще можем добавлять сущности которые управляют поведением объекта, мувер, абилки, какие-нибудь таймеры с колбэками, пораждающие сущности и тд. Тогда действительно удобно вводить изменения в игре не трогая архитектуру самой игры. Потребовалось прикрутить абилку по клику на объект, добавил сущность. надо тчоб хз ... какой-нибудь объект из декораций начал двигаться, добавил ему мувер и погнал, и не надо тебе плодить бесконечные классы ради одной фишки. Слабо себе представляю как такое делается на расте. Но в классических ООП языках как по мне самый удачный подход
>Но к каждому геймобджекту мы еще можем добавлять сущности которые управляют поведением объекта, мувер, абилки, какие-нибудь таймеры с колбэками, пораждающие сущности и тд.
Так это не ЕЦС, а просто композиция.
Насколько читаемые исходники? Легко ли восстановить в голове архитектуру игры глядя на исходники?
https://jabuwu.itch.io/shanty-quest
https://github.com/jabuwu/shanty-quest
Раст это си-подобный язык. Читать-то его не сложно. Его сложно писать из-за анальных статических анализаторов кода.
>На практике, конечно, вся эта фигня с DOD-ом ломается, когда тебе нужно больше одного компонента для работы системы
Потому что DOD и ECS - это разные вещи. Можно делать DOD с помощью компонентов, но не обязательно. В оригинальной книге вообще ничего нет про компоненты или какую-то глобальную архитектуру, там написано, как данные располагать так, чтобы было удобно для кэша:
https://www.dataorienteddesign.com/dodbook/
Вообще основной смысл книги в том, что нужно плясать от данных игры, то есть оптимизировать имея уже готовый дизайн игры с пониманием, где узкие места. ECS, наоборот, предлагает готовую архитектуру, под которую пользователь должен подстраиваться при дизайне приложения.