Comments 12
Эх, эту бы статью да на пару лет раньше. В интернете ходят целые архивы книг, где описана куча алгоритмов поиска пути, каждый раз пережевывается как столкнуть два прямоугольника и тп, но о структуре самого движка ничего дальше абстрактной мысли о разделении подсистем и простого игрового цикла нет. Думаю почти все разработчики игровых движков рано или поздно приходят к этому, находя информацию по крупицам в литературе или вникая в кармаковские исходники. Во многом именно из-за этого многие новички в геймдеве плодят монолитного и бажного монстра, которого невозможно сопровождать. Глава подобная этой должна быть в каждом учебнике по геймдеву.
Очень жалко, что так происходит
Почти ни в одной книге не описаны принципы движка, из-за этого, владея хорошей учебной базой по DirectX или OpenGL, и читая статьи по разработки движков (которых в интернете раз, два и все), новоиспеченные девелоперы пишут весь код игры чуть ли не в int main()
Подскажи мне кто, что для сущностей можно создать интерфейс с функциями start, update, destroy, и для каждого объекта создавать наследника этого интерфейса, а потом записывать его в менеджер объектов, мне бы не пришлось полгода назад изобретать велосипед 19 века
Почти ни в одной книге не описаны принципы движка, из-за этого, владея хорошей учебной базой по DirectX или OpenGL, и читая статьи по разработки движков (которых в интернете раз, два и все), новоиспеченные девелоперы пишут весь код игры чуть ли не в int main()
Подскажи мне кто, что для сущностей можно создать интерфейс с функциями start, update, destroy, и для каждого объекта создавать наследника этого интерфейса, а потом записывать его в менеджер объектов, мне бы не пришлось полгода назад изобретать велосипед 19 века
gameprogrammingpatterns.com/
Оставлю это здесь, возможно, кому-то пригодится. Книга в процессе написания, можно подписаться на обновления.
Оставлю это здесь, возможно, кому-то пригодится. Книга в процессе написания, можно подписаться на обновления.
UFO just landed and posted this here
Странно, что не натыкались на эту книгу.
Конечно там компонентная модель развита в меньшей степени, но процессы, компоненты и сущности именно в том виде как в статье там есть, к тому же книга на C++.
Конечно там компонентная модель развита в меньшей степени, но процессы, компоненты и сущности именно в том виде как в статье там есть, к тому же книга на C++.
blog.gamedeff.com/?p=91 — 8 лет назад, консоли. очень похожие яйца, вид в профиль.
По ссылке описано какое-то очень мощное колдунство очень непонятным (мне) образом. Но в общем да, если думать о реализации на С++, то копать нужно через шаблоны.
А в целом — да, подобная архитектура используется уже очень давно, но среди новичков (да и не только) о ней мало кто знает.
А в целом — да, подобная архитектура используется уже очень давно, но среди новичков (да и не только) о ней мало кто знает.
Да, у них там все по хардкору. Я и сам не все понял, честно говоря.
Если я правильно понял, у них там примерно следующее: компонентная архитектура без изоляции компонентов ради снижения runtime costs и эффективной командной разработки. Вся кодобаза на плюсах, никаких скриптов.
Entity из компонентов клеятся как раз шаблонами, особое внимание уделено интересным случаям, когда, например, в одной из веток условия может быть вызван метод компонента, которого может и не быть. Очень грубый пример:
template class IRenderObject { void SetColor( Color ); };
template class IPhysiscObject { void OnCollide ( void ) { if (Is(RenderObject) && Is(Ball)) Access(RenderObject)->SetColor(RED); };
class CInvisibleBall: public IPhysiscObject, public IGameObject {};
Или что-то вроде того. Формально, компилятор должен сказать «да вы там офигели вконец?», но фактически он этого не делает, потому что dead code elimination или как-то так.
Выглядит это все очень брутально, но впечатления оставляет очень заманчивые.
Если я правильно понял, у них там примерно следующее: компонентная архитектура без изоляции компонентов ради снижения runtime costs и эффективной командной разработки. Вся кодобаза на плюсах, никаких скриптов.
Entity из компонентов клеятся как раз шаблонами, особое внимание уделено интересным случаям, когда, например, в одной из веток условия может быть вызван метод компонента, которого может и не быть. Очень грубый пример:
template class IRenderObject { void SetColor( Color ); };
template class IPhysiscObject { void OnCollide ( void ) { if (Is(RenderObject) && Is(Ball)) Access(RenderObject)->SetColor(RED); };
class CInvisibleBall: public IPhysiscObject, public IGameObject {};
Или что-то вроде того. Формально, компилятор должен сказать «да вы там офигели вконец?», но фактически он этого не делает, потому что dead code elimination или как-то так.
Выглядит это все очень брутально, но впечатления оставляет очень заманчивые.
Это называется Компонентно-ориентированное программирование. И его частный случай для игровых сущностей в геймдеве. Unity3D использует такой подход и некоторые другие движки.
Вот пара ссылок на русском:
Это перевод:
gameinstitute.ru/tutorials/razvivaem-svoyu-ierarhiyu/
Это с геймдевру:
www.gamedev.ru/code/forum/?id=145339
www.gamedev.ru/code/forum/?id=136011
Вот пара ссылок на русском:
Это перевод:
gameinstitute.ru/tutorials/razvivaem-svoyu-ierarhiyu/
Это с геймдевру:
www.gamedev.ru/code/forum/?id=145339
www.gamedev.ru/code/forum/?id=136011
Кто-нибудь использовал какие-либо Entity Component System фреймворки на C++? Буду рад, если поделитесь своим опытом в комментариях.
Зачем? В чем сложность написания своего?
Зачем? В чем сложность написания своего?
Если есть какая-то программная задача, то уже существует её готовое решение на плюсах. Аксиоматично. И ничего писать не надо, соответственно, не нужно, соответственно, больше времени останется на доработку геймплея, что интереснее (имхо) написания кода. С другой стороны, написание велосипедов улучшает навыки языка, на котором эти велосипеды пишутся, что есть очень хорошо.
В общем-то задача не самая сложная, и я за вечер накатал что-то похожее на фреймворк, который успешно справляется с прототипом игры. Другое дело, что со временем могут обнаружиться различные грустные вещи, вроде утечек памяти или тормозов. Вот потому и спрашиваю.
В общем-то задача не самая сложная, и я за вечер накатал что-то похожее на фреймворк, который успешно справляется с прототипом игры. Другое дело, что со временем могут обнаружиться различные грустные вещи, вроде утечек памяти или тормозов. Вот потому и спрашиваю.
Пол года назад под впечатлением этого движка (Ash) сделал порт на javascript, добавив механизм DI от AngularJS. Изменив api на более CraftyJS подобный.
http://darlingjs.github.io
Исходники и докуменация в комплекте ;)
Ядро уже в стабльном состоянии, сейчас в свободное время добавляю модули под разные нужды. Буду рад отзывам, вопросам, предложениям :)
http://darlingjs.github.io
Исходники и докуменация в комплекте ;)
Ядро уже в стабльном состоянии, сейчас в свободное время добавляю модули под разные нужды. Буду рад отзывам, вопросам, предложениям :)
Sign up to leave a comment.
Что такое Entity System Framework и зачем он нужен в геймдеве?