Компонентная парадигма программирования игр становится все более популярной. Мне было интересно, есть ли какие-нибудь проекты, которые предлагают многократно используемый компонентный каркас? На любом языке, я думаю, мне все равно. Это не для моего собственного проекта, мне просто любопытно.
В частности, я имею в виду, есть ли проекты, которые включают базовый Entityкласс, базовый Componentкласс и, возможно, некоторые стандартные компоненты? Тогда было бы намного легче начать игру, если вы не хотите изобретать велосипед, или, может быть, вы хотите создать GraphicsComponentспрайты с Direct3D, но вы полагаете, что это уже было сделано десятки раз.
Быстрый Googling появляется Рашер . Кто-нибудь слышал об этом / кто-нибудь этим пользуется? Если нет популярных, то почему бы и нет? Не слишком ли сложно сделать что-то подобное многоразовому, и они требуют серьезной настройки? В моей собственной реализации я обнаружил множество шаблонов, которые можно было бы запихнуть в каркас.
источник
Ответы:
Потому что нет ничего похожего на консенсус о том, как будет работать такая структура.
На ветке Gamedev.net я определил, что, когда люди говорят о компонентных игровых системах, на самом деле существует по крайней мере 8 возможных вариантов того, как они ожидают, что они будут работать, исходя из 3 различных факторов:
Внутренний и внешний - должны ли компоненты быть объединены в объект или они должны быть частью подсистемы и связаны только с идентификатором объекта?
Статическая или динамическая композиция - если объекты состоят из известного набора компонентов (например, 1 физика, 1 анимация, 1 AI и т. Д.), Которые могут взаимодействовать в коде через хорошо известные интерфейсы, или объекты могут добавлять произвольное количество компонентов к их (со связанными стратегиями для поиска других компонентов, представляющих интерес)
Данные о компоненте против данных об объекте. Должны ли данные храниться в компоненте, который в основном работает с ним? Или данные должны храниться на объекте в общем пространстве, доступном для всех компонентов?
Кроме того, есть дополнительные вопросы о том, как компоненты должны взаимодействовать (через общие данные? Через функциональные указатели? Через сигналы / слоты? Или вообще нет?), Как они должны обновляться (в фиксированном порядке, основанном на типе компонента? порядок объектов, определенный во время создания (на основе топологического вида взаимозависимостей компонентов?) и т. д.
Каждый из этих вариантов совершенно произвольный, и все, что вы можете сделать с одной системой, можно сделать с другой. Но способ, которым вы должны кодировать, в каждом случае совершенно разный. И у людей, кажется, есть твердое мнение о том, какой путь работает лучше для них.
Прямо сейчас люди все еще слишком увлечены идеей, что компоненты каким-то образом заменяют объектную ориентацию (которой они не являются), а также воображают, что они являются огромным изменением от того, как традиционно создавались игры (что, опять же, они не были - люди разрабатывают различные подсистемы в своих сущностях целую вечность), поэтому существует много гипербол и мало согласия. Возможно, через несколько лет все уляжется, и люди примут один или два достаточно стандартных подхода.
источник
Есть вики, которая собирает примеры всего этого:
http://entity-systems.wikidot.com/
... наряду с объяснениями различий между различными подходами.
источник
Проверьте эти рамки, которые я обнаружил, связанные с этой архитектурой ...
www.burgerengine.com
PushButtonEngine
Arthemis Framework - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis
Посмотрите на Unity Api. Вы можете найти много вещей, касающихся архитектуры на основе компонентов. (Обновлю список, как только найду ещё ...)
Обновить:
Это хорошо объясняет системы сущностей ... http://piemaster.net/2011/07/entity-component-primer/
источник
Для Flash есть движок с кнопками: http://pushbuttonengine.com/
И есть Panda3D для c ++ / python: panda3d dot com (извините, мне разрешено только 1 URL на пост как n00b)
Я уверен, что есть еще тонны там :)
источник