Зареєструвати компоненти ігрових об’єктів у ігрових підсистемах? (Компонентний дизайн ігрового об'єкта)

Я створюю компонентну систему ігрових об'єктів . Деякі поради:

GameObjectце просто список Components.
Є GameSubsystems. Наприклад, візуалізація, фізика тощо. Кожен GameSubsystemмістить вказівники на деякі з Components. GameSubsystemце дуже потужна і гнучка абстракція: вона представляє будь-який фрагмент (або аспект) ігрового світу.

Існує потреба в механізмі реєстрації Componentsв GameSubsystems(коли GameObjectстворюється і складається). Існує 4 підходи :

1: Схема ланцюжка відповідальності . Кожному Componentпропонується кожен GameSubsystem. GameSubsystemприймає рішення, які Componentsреєструвати (і як їх організувати). Наприклад, GameSubsystemRender може реєструвати передавальні компоненти.

профі. Componentsнічого не знаю про те, як вони використовуються. Низька муфта. A. Ми можемо додати нове GameSubsystem. Наприклад, додамо GameSubsystemTitles, який реєструє всі ComponentTitle і гарантує, що кожен заголовок є унікальним і забезпечує інтерфейс до запитуючих об'єктів за заголовком. Звичайно, ComponentTitle в цьому випадку не слід переписувати чи успадковувати. В. Ми можемо реорганізувати існуючі GameSubsystems. Наприклад, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter можна об'єднати в GameSubsystemSpatial (розмістити все аудіо, випромінювач, візуалізувати Componentsв одній ієрархії та використовувати перетворення, пов'язані з батьками).

кон. Кожна перевірка. Дуже неефективно.

кон. Subsystemsзнати про Components.

2: Кожен Subsystemпошук Componentsконкретних типів.

профі. Кращі показники, ніж у Approach 1.

кон. Subsystemsдосі знаю про Components.

3: Componentреєструється в GameSubsystem(s). Ми знаємо, що під час компіляції існує GameSubsystemRenderer, тому давайте ComponentImageRender буде називати щось на зразок GameSubsystemRenderer :: register (ComponentRenderBase *).

профі. Продуктивність. Немає зайвих перевірок, як у Approach 1.

кон. Componentsпогано поєднуються GameSubsystems.

4: Шаблон посередника . GameState(що містить GameSubsystems) може реалізувати registerComponent (Компонент *).

профі. Componentsі GameSubystemsнічого не знають один про одного.

кон. У C ++ це виглядало б як потворне і повільне типу-перемикача.

Запитання: Який підхід краще і в основному застосовується в компонентному дизайні? Що говорить практика? Будь-які пропозиції щодо впровадження Approach 4?

Дякую.

c++ architecture component-based

— прямолінійний
джерело

Я пахну надмірною технікою. Компоненти зареєструються в GameObject. Якщо GameSubsystem є такою, якою я думаю, що вона є, то це просто список компонентів, який можна відразу додати до GameObject. Як ви описуєте це звучить так, ніби існує якась "магія", як GameObjects і Components збираються разом (вони шукають один одного? Чому?). Я також відчуваю, що ви намагаєтеся використовувати компоненти для всього вашого двигуна, що я також хотів би переглянути. Для чого це варто, я б розглядав лише варіанти 3 або 4.

— LearnCocos2D

@GamingHorror, реєстрація Componentsв GameObjectsвиходить за рамки мого питання. Читайте статті про компонентний підхід або задайте собі запитання на цьому веб-сайті, якщо вас це цікавить. Те, про що ви думаєте GameSubsystem, абсолютно неправильно.

— точний

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

— LearnCocos2D

Так, "Компонентні ігрові об'єкти" та "Компонентно-орієнтоване програмування" - це різні терміни, це може заплутати. Не будьте упередженими, краще будьте "урізаними": scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— відверто

Двері номер 3 ... Компонент реєструється в GameSubsystem (s)

Компонент встановлений для того, щоб з’єднати абстрагуватися від самого GameObject. Якось десь щось насправді потрібно взаємодіяти з підсистемами, і це є складовою та його призначенням.

Зв'язок насправді не є поганою справою в цьому випадку.

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

Нарешті, якщо одна підсистема потребує реагування на іншу (візуалізація, фізика, аудіо всі повинні робити речі, коли щось відбувається), компоненти можуть полегшити це один одному через ігровий об’єкт і зберегти цей конкретний тип перехресних системних зв'язків керувати компоненти.

— Рік
джерело

Добре. Але як компоненти знають про GameSubsystems? Чи всі підсистеми одинакові? Це не негарно? ... Я думаю про інше рішення, як-от введення залежності ... але коли і хто передає екземпляр підсистеми кожному компоненту?

— Дані

@Dani Components не потребує доступу безпосередньо до примірника підсистеми, їм просто потрібно надіслати повідомлення з проханням зробити реєстрацію, їм не потрібно знати, що таке підсистема (але, швидше за все, вони будуть) І чому вони були б одиночними? Це не є вимогою, навіть якщо в більшості випадків вам знадобиться лише один екземпляр підсистеми для кожної підсистеми.

— Пабло Аріель

@Pablo - згоден.

— Рік