Зарегистрировать компоненты игровых объектов в игровых подсистемах? (Компонентный дизайн игровых объектов)

Я создаю компонент на основе системы игры объекта . Некоторые советы:

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

Существует необходимость в механизме регистрации Componentsв GameSubsystems(когда GameObjectсоздается и в составе). Есть 4 подхода :

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

профи. Componentsничего не знаю о том, как они используются. Низкая связь. А. Мы можем добавить новое GameSubsystem. Например, давайте добавим GameSubsystemTitles, который регистрирует все ComponentTitle и гарантирует, что каждый заголовок уникален и предоставляет интерфейс для запроса объектов по заголовку. Конечно, ComponentTitle не должен быть переписан или унаследован в этом случае. Б. Мы можем реорганизовать существующие GameSubsystems. Например, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter могут быть объединены в GameSubsystemSpatial (чтобы поместить все аудио, emmiter, рендеринг 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 (Component *).

профи. Componentsи GameSubystemsничего не знаем друг о друге.

против. В C ++ это выглядело бы как уродливый и медленный переключатель типа.

Вопросы: Какой подход лучше и чаще всего используется в компонентном проектировании? Что говорит практика? Есть предложения по внедрению Approach 4?

Спасибо.

c++ architecture component-based

— в правом верхнем углу
источник

Я чувствую чрезмерную инженерию. Компоненты регистрируются в GameObject. Если GameSubsystem - это то, что я думаю, то это просто список компонентов, которые можно сразу добавить в GameObject. Как вы описываете, звучит так, будто существует некая «магия», как GameObjects и Компоненты собираются вместе (они ищут друг друга? Почему?). У меня также возникает ощущение, что вы пытаетесь использовать компоненты практически для всего вашего движка, что я бы тоже пересмотрел. Что бы это ни стоило, я бы рассмотрел только варианты 3 или 4.

— LearnCocos2D

@GamingHorror, регистрация Componentsв GameObjectsвыходит за рамки моего вопроса. Прочитайте статьи о компонентном подходе или задайте свой вопрос на этом сайте, если он вам интересен. Что вы думаете о GameSubsystemсовершенно неправильно.

— topright

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

— LearnCocos2D

Да, «Компонент на основе игровых объектов» и «Компонент-ориентированное программирование» разные термины, это может привести к путанице. Не быть предвзятым, лучше быть «bilased»: scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— topright

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

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

Муфта на самом деле не плохая вещь в этом случае.

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

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

— стог
источник

Это хорошо. Но как компоненты знают о GameSubsystems? Являются ли все подсистемы синглетонами? Это не уродливо? ... Я думаю о другом решении, таком как внедрение зависимостей ... но когда и кто передает экземпляр подсистемы каждому компоненту?

— Дани

Компонентам @Dani не нужен прямой доступ к экземпляру подсистемы, им просто нужно отправить сообщение с просьбой о регистрации, им не нужно знать, что такое подсистема (но они, скорее всего, будут) и почему они будут одиночками? Это не является обязательным требованием, даже если в большинстве случаев вам потребуется только один экземпляр подсистемы для каждой подсистемы.

— Пабло Ариэль

@ Пабло - согласен.

— Рик