Существуют ли рамки на основе компонентов FOSS? [закрыто]


25

Компонентная парадигма программирования игр становится все более популярной. Мне было интересно, есть ли какие-нибудь проекты, которые предлагают многократно используемый компонентный каркас? На любом языке, я думаю, мне все равно. Это не для моего собственного проекта, мне просто любопытно.

В частности, я имею в виду, есть ли проекты, которые включают базовый Entityкласс, базовый Componentкласс и, возможно, некоторые стандартные компоненты? Тогда было бы намного легче начать игру, если вы не хотите изобретать велосипед, или, может быть, вы хотите создать GraphicsComponentспрайты с Direct3D, но вы полагаете, что это уже было сделано десятки раз.

Быстрый Googling появляется Рашер . Кто-нибудь слышал об этом / кто-нибудь этим пользуется? Если нет популярных, то почему бы и нет? Не слишком ли сложно сделать что-то подобное многоразовому, и они требуют серьезной настройки? В моей собственной реализации я обнаружил множество шаблонов, которые можно было бы запихнуть в каркас.


4
Вы должны быть первым, чтобы написать один! :)
Ricket

1
Ну, я написал один на C # для моего собственного проекта. Может быть, мы все могли бы внести свой вклад?
Tesserex

Я был бы полностью готов работать над этим проектом на C #. Да, нет единого мнения о том, как должен работать стандартный, но, возможно, мы могли бы сосредоточиться на XNA (что бы ни плавало на вашей лодке). То, что группа гигантов не объявила лучший способ сделать это, не означает, что мы не можем попробовать / поэкспериментировать.
Майкл Коулман

Возможно, потому что компонентный дизайн привлекает руководителей проектов больше, чем программистов
М.УТКУ АЛЬТИНКАЯ

Ответы:


45

Если нет популярных, то почему бы и нет?

Потому что нет ничего похожего на консенсус о том, как будет работать такая структура.

На ветке Gamedev.net я определил, что, когда люди говорят о компонентных игровых системах, на самом деле существует по крайней мере 8 возможных вариантов того, как они ожидают, что они будут работать, исходя из 3 различных факторов:

Внутренний и внешний - должны ли компоненты быть объединены в объект или они должны быть частью подсистемы и связаны только с идентификатором объекта?

Статическая или динамическая композиция - если объекты состоят из известного набора компонентов (например, 1 физика, 1 анимация, 1 AI и т. Д.), Которые могут взаимодействовать в коде через хорошо известные интерфейсы, или объекты могут добавлять произвольное количество компонентов к их (со связанными стратегиями для поиска других компонентов, представляющих интерес)

Данные о компоненте против данных об объекте. Должны ли данные храниться в компоненте, который в основном работает с ним? Или данные должны храниться на объекте в общем пространстве, доступном для всех компонентов?

Кроме того, есть дополнительные вопросы о том, как компоненты должны взаимодействовать (через общие данные? Через функциональные указатели? Через сигналы / слоты? Или вообще нет?), Как они должны обновляться (в фиксированном порядке, основанном на типе компонента? порядок объектов, определенный во время создания (на основе топологического вида взаимозависимостей компонентов?) и т. д.

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

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


1
Я ценю, что этот ответ старый, но теперь он неправильный: есть популярные фреймворки, и остается очень мало споров по этой теме. При написании игр большинство вышеприведенных вопросов не имеют значения: либо они не влияют на дизайн кода, либо один из них является быстрым и может использоваться повторно, а другие - нет. На практике существует множество популярных фреймворков - вики, на которую ссылается один из ответов, является хорошей отправной точкой (многие из нас поддерживают ее, чтобы упростить поиск реальных поставляемых игр + фреймворков)
Адам,

1
@ Adam: Я хотел бы получить ссылку на детали о подходе, который выиграл матч по эволюции Дарвина. когда я говорю подробности, я не хочу слышать о внутренних и внешних, я хочу слышать о хэш-картах, векторах, распределителях, private, public, loop, const ... детали низкого уровня.
v.oddou

@ v.oddou кто-то опубликовал ссылку на вики в качестве ответа (см. ниже). Вы хотите детали? Он полон исходного кода .
Адам

10

Есть вики, которая собирает примеры всего этого:

http://entity-systems.wikidot.com/

... наряду с объяснениями различий между различными подходами.


Ash и Artemis (оба в вики) оказались действительно популярными, они оба используются для разработки коммерческих игр, наряду с разработчиком хобби-игр.
Адам

4

Проверьте эти рамки, которые я обнаружил, связанные с этой архитектурой ...

www.burgerengine.com

PushButtonEngine

Arthemis Framework - https://github.com/artemis-esf/artemis-framework/tree/master/src/com/artemis

Посмотрите на Unity Api. Вы можете найти много вещей, касающихся архитектуры на основе компонентов. (Обновлю список, как только найду ещё ...)

Обновить:

      https://code.google.com/p/spartanframework/

Это хорошо объясняет системы сущностей ... http://piemaster.net/2011/07/entity-component-primer/


2

Для Flash есть движок с кнопками: http://pushbuttonengine.com/

И есть Panda3D для c ++ / python: panda3d dot com (извините, мне разрешено только 1 URL на пост как n00b)

Я уверен, что есть еще тонны там :)

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.