Чи існують рамки на основі компонентів FOSS? [зачинено]


25

Парадигма ігрового програмування набуває все більшої популярності. Мені було цікаво, чи існують проекти, які пропонують багаторазовий компонентний каркас? З будь-якої мови, я думаю, мені це не байдуже. Це не для власного проекту, мені просто цікаво.

Я маю на увазі, чи є проекти, які включають базовий Entityклас, базовий Componentклас і, можливо, деякі стандартні компоненти? Тоді було б набагато простіше запустити гру, якщо ви не хотіли винаходити колесо, або, можливо, ви хочете, GraphicsComponentщо спрацьовує з Direct3D, але ви вважаєте, що це вже робилося десяток разів.

Швидкий Гуглінг виявляється більш суворим . Хтось чув про це / хтось ним користується? Якщо популярних немає, то чому б і ні? Чи занадто складно зробити щось подібне для багаторазового використання, і їм потрібна велика налаштування? У власній реалізації я знайшов багато котельних плит, які можна було засунути в рамки.


4
Ви повинні бути першим, хто написав! :)
Ricket

1
Що ж, я написав його в C # для власного проекту. Може, ми могли всі внести свій внесок?
Тессерекс

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

Можливо, тому, що дизайн на основі компонентів приваблює керівників проектів більше, ніж програмістів
М. Утку АЛТІНКАЯ

Відповіді:


45

Якщо популярних немає, то чому б і ні?

Тому що немає нічого подібного до консенсусу щодо того, як діятиме така структура.

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

Внутрішній та позаборсовий - чи слід агрегувати компоненти в сукупність, чи вони повинні бути частиною підсистеми та лише пов'язані з ідентифікатором сутності?

Статичний та динамічний склад - якщо об'єкти складаються з відомого набору компонентів (наприклад, 1 Фізика, 1 Анімація, 1 AI тощо), які можуть спілкуватися в коді через добре відомі інтерфейси, чи можуть суб'єкти мають довільну кількість компонентів, доданих до їх (із пов'язаними стратегіями пошуку інших цікавих компонентів)

Дані про компонент та дані про сутність - Чи повинні зберігати дані компонент, який в основному працює над ним? Або дані повинні зберігатись на об'єкті у спільному просторі, доступному всім компонентам?

Крім цього, виникають додаткові запитання щодо того, як компоненти повинні спілкуватися (через спільні дані? Через покажчики функцій? Через сигнали / слоти? Чи взагалі не?), Як вони повинні оновлюватись (у встановленому порядку на основі типу компонента? A на -порядок цілісності, визначений під час створення? на основі топологічного роду взаємозалежності компонентів?) тощо.

Кожен з цих варіантів є абсолютно довільним, і все, що ви можете зробити з однією системою, можна зробити і з іншою. Але спосіб, яким ви повинні його кодувати, є абсолютно різним у кожному випадку. І люди, схоже, мають думки щодо того, який спосіб найкраще їм подобається.

Зараз люди все ще занадто захоплені думкою, що компоненти є якось заміною орієнтації на об'єкти (чого вони не є), а також уявляють, що вони є масовою зміною від того, як традиційно робили ігри (що, знову ж таки, вони не були - люди розробляли різні підсистеми у своїх сутностях протягом століть), тож багато гіперболи і не багато згоди. Можливо, через кілька років все налагодиться, і люди оселяться за одним-двома досить стандартними підходами.


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

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

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

10

Існує вікі, який збирає приклади всього цього:

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

... разом з поясненнями відмінностей між різними підходами.


Еш і Артеміда (обидва на вікі) справді виявилися популярними, обидва вони використовуються для розробки комерційних ігор, а також розробників ігор для хобі.
Адам

4

Перевірте ці рамки, які я дізнався, пов'язані з цією архітектурою ...

www.burgerengine.com

PushButtonEngine

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

Поглянувши на Єдність Апі. Ви можете знайти багато матеріалів щодо архітектури на основі компонентів. (Оновлять список, як тільки я знайду щось більше ...)

Оновлення:

      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.