¿Registrar componentes de objetos de juego en subsistemas de juego? (Diseño de objetos de juego basado en componentes)

Estoy creando un sistema de objetos de juego basado en componentes . Algunos consejos:

GameObjectes simplemente una lista de Components.
Hay GameSubsystems. Por ejemplo, renderizado, física, etc. Cada uno GameSubsystemcontiene punteros a algunos de Components. GameSubsystemes una abstracción muy poderosa y flexible: representa cualquier porción (o aspecto) del mundo del juego.

Existe la necesidad de un mecanismo de registro Componentsen GameSubsystems(cuando GameObjectse crea y se compone). Hay 4 enfoques :

1: Patrón de cadena de responsabilidad . Todos Componentse ofrecen a todos GameSubsystem. GameSubsystemtoma una decisión sobre qué Componentsregistrar (y cómo organizarlos). Por ejemplo, GameSubsystemRender puede registrar Componentes Renderables.

Pro. ComponentsNo sé nada acerca de cómo se usan. Bajo acoplamiento. A. Podemos agregar nuevos GameSubsystem. Por ejemplo, agreguemos GameSubsystemTitles que registra todo ComponentTitle y garantiza que cada título es único y proporciona una interfaz para buscar objetos por título. Por supuesto, ComponentTitle no debe reescribirse o heredarse en este caso. B. Podemos reorganizar los existentes GameSubsystems. Por ejemplo, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter se pueden combinar en GameSubsystemSpatial (para colocar todo el audio, el emisor, el render Componentsen la misma jerarquía y usar transformaciones relativas a los padres).

estafa. Cheque de todos a todos. Muy ineficiente.

estafa. Subsystemssaber acerca Components.

2: Cada uno Subsystembusca Componentstipos específicos.

Pro. Mejor rendimiento que en Approach 1.

estafa. SubsystemsTodavía lo sé Components.

3: se Componentregistra en GameSubsystem(s). Sabemos en tiempo de compilación que hay un GameSubsystemRenderer, así que ComponentImageRender llamará a algo como GameSubsystemRenderer :: register (ComponentRenderBase *).

Pro. Actuación. No hay controles innecesarios como en Approach 1.

estafa. Componentsestán mal acoplados con GameSubsystems.

4: patrón de mediador . GameState(que contiene GameSubsystems) puede implementar registerComponent (Component *).

Pro. Componentsy GameSubystemsno saben nada el uno del otro.

estafa. En C ++ se vería como un interruptor typeid feo y lento.

Preguntas: ¿Qué enfoque es mejor y se usa principalmente en el diseño basado en componentes? ¿Qué dice la práctica? ¿Alguna sugerencia sobre la implementación de Approach 4?

Gracias.

c++ architecture component-based

— parte superior derecha
fuente

Huelo sobre ingeniería. Los componentes se registran con GameObject. Si GameSubsystem es lo que creo que es, entonces es solo una lista de componentes que se pueden agregar a un GameObject a la vez. Cómo lo describe parece que hay algún tipo de "magia" en la forma en que GameObjects y Componentes se unen (¿se buscan entre sí? ¿Por qué?). También tengo la sensación de que estás tratando de usar componentes para básicamente todo en tu motor, lo que también reconsideraría. Para lo que vale, solo consideraría las opciones 3 o 4.

— LearnCocos2D

@GamingHorror, su registro Componentsen GameObjectsestá fuera del alcance de mi pregunta. Lea artículos sobre el enfoque basado en componentes o haga su propia pregunta en este sitio si está interesado en él. Lo que piensas GameSubsystemestá totalmente mal.

— arriba

Me inclino por desarrollar componentes para la lógica del juego, no componentes del motor, y su descripción parece apuntar en esa dirección. Entiendo muy bien los sistemas de componentes, creo que me desviaron del curso porque no estoy familiarizado con la terminología que usó, específicamente GameSubsystem. Por lo que leí, parecía que estabas tratando de construir todo (por ejemplo, todo el motor) solo a partir de componentes.

— LearnCocos2D

Sí, "Objetos de juego basados en componentes" y "Programación orientada a componentes" son términos diferentes, puede ser confuso. No seas parcial, mejor sé "engañado": scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— hasta el

Puerta número 3 ... El componente se registra en GameSubsystem (s)

El componente está en su lugar para mantener el acoplamiento abstraído del propio GameObject. De alguna manera, en algún lugar, de hecho, algo necesita interactuar con los subsistemas y este es el componente y su propósito.

El acoplamiento no es realmente algo malo en este caso.

El rendimiento se requiere esencialmente en este caso si espera tener alguna complejidad en su sistema, simplemente no puede permitirse los enfoques de estilo de búsqueda de las otras opciones.

Finalmente, si un subsistema necesita ser reactivo a otro (el renderizador, la física, el audio deben hacer cosas cuando algo sucede), los componentes pueden facilitar esto entre sí a través del objeto del juego y mantener este tipo particular de acoplamiento cruzado del sistema manejable a través del componentes.

— Almiar
fuente

Eso es bueno. Pero, ¿cómo saben los componentes sobre GameSubsystems? ¿Todos los subsistemas son singletons? ¿Eso no es feo? ... Estoy pensando en otra solución como la inyección de dependencia ... pero ¿cuándo y quién pasa la instancia del subsistema a cada componente?

— Dani

Los componentes de @Dani no necesitan acceder directamente a la instancia del subsistema, solo necesitan enviar un mensaje pidiendo que se realice el registro, no necesitan saber qué es el subsistema (pero lo más probable) y por qué ¿Serían solteros? Eso no es un requisito, incluso si en la mayoría de los casos solo necesitará una única instancia de subsistema para cada subsistema.

— Pablo Ariel

@Pablo: de acuerdo.

— Rick