Registrare i componenti degli oggetti di gioco nei sottosistemi di giochi? (Progettazione di oggetti di gioco basati su componenti)

Sto creando un sistema di oggetti di gioco basato su componenti . Alcuni suggerimenti:

GameObjectè semplicemente un elenco di Components.
Ci sono GameSubsystems. Ad esempio, rendering, fisica ecc. Ognuno GameSubsystemcontiene puntatori ad alcuni Components. GameSubsystemè un'astrazione molto potente e flessibile: rappresenta qualsiasi fetta (o aspetto) del mondo di gioco.

V'è la necessità di un meccanismo di registrazione Componentsa GameSubsystems(quando GameObjectè stato creato e composto). Esistono 4 approcci :

1: modello di catena di responsabilità . Ognuno Componentè offerto a tutti GameSubsystem. GameSubsystemprende una decisione su quale Componentsregistrarsi (e su come organizzarli). Ad esempio, GameSubsystemRender può registrare componenti di rendering.

pro. Componentsnon sapere come vengono utilizzati. Accoppiamento basso. A. Possiamo aggiungere nuovi GameSubsystem. Ad esempio, aggiungiamo GameSubsystemTitles che registra tutti i ComponentTitle e garantisce che ogni titolo sia unico e fornisca l'interfaccia per eseguire query sugli oggetti per titolo. Naturalmente, ComponentTitle non deve essere riscritto o ereditato in questo caso. B. Possiamo riorganizzare esistenti GameSubsystems. Ad esempio, GameSubsystemAudio, GameSubsystemRender, GameSubsystemParticleEmmiter possono essere uniti in GameSubsystemSpatial (per posizionare tutto l'audio, l'emettitore, il rendering Componentsnella stessa gerarchia e utilizzare trasformazioni relative al genitore).

con. Ogni controllo. Molto inefficiente

con. Subsystemssapere Components.

2: Ciascuno Subsystemcerca Componentstipi specifici.

pro. Prestazioni migliori rispetto a Approach 1.

con. Subsystemsancora sapere Components.

3: si Componentregistra in GameSubsystem(s). Sappiamo al momento della compilazione che esiste un GameSubsystemRenderer, quindi ComponentImageRender chiamerà qualcosa come GameSubsystemRenderer :: register (ComponentRenderBase *).

pro. Prestazione. Nessun controllo non necessario come in Approach 1.

con. Componentssono accoppiati male con GameSubsystems.

4: modello mediatore . GameState(che contiene GameSubsystems) può implementare registerComponent (Component *).

pro. Componentse GameSubystemsnon sanno nulla l'uno dell'altro.

con. In C ++ sembrerebbe brutto e lento switch-typeid.

Domande: quale approccio è migliore e maggiormente utilizzato nella progettazione basata su componenti? Cosa dice la pratica? Qualche suggerimento sull'implementazione di Approach 4?

Grazie.

c++ architecture component-based

— in alto a destra
fonte

Sento un eccesso di ingegneria. I componenti si registrano con GameObject. Se GameSubsystem è quello che penso che sia, allora è solo un elenco di componenti che possono essere aggiunti contemporaneamente a un GameObject. Come lo descrivi sembra che ci sia una sorta di "magia" nel modo in cui GameObjects e Components si uniscono (si cercano l'un l'altro? Perché?). Ho anche la sensazione che tu stia provando a usare i componenti praticamente per qualsiasi cosa nel tuo motore, che vorrei riconsiderare. Per quello che vale prenderei in considerazione solo le opzioni 3 o 4.

— LearnCocos2D,

@GamingHorror, Registrazione Componentsin GameObjectsè fuori della portata della mia domanda. Leggi articoli sull'approccio basato sui componenti o poni la tua domanda su questo sito se sei interessato. Quello che pensi GameSubsystemè totalmente sbagliato.

— piedi il

Sono orientato allo sviluppo di componenti per la logica di gioco, non di componenti del motore, e la tua descrizione sembra puntare in quella direzione. Capisco molto bene i sistemi di componenti, sto pensando di essere stato scartato perché non ho familiarità con la terminologia che hai usato, in particolare GameSubsystem. Da quello che ho letto, sembrava che tu stessi cercando di costruire tutto (ad esempio l'intero motore) solo dai componenti.

— LearnCocos2D

Sì, "oggetti di gioco basati su componenti" e "programmazione orientata ai componenti" sono termini diversi, può essere fonte di confusione. Non essere di parte, meglio essere "bilasati": scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.ppt

— partire dal

Porta numero 3 ... Il componente si registra in GameSubsystem (s)

Il componente è in posizione per mantenere l'accoppiamento astratto dal GameObject stesso. In qualche modo, da qualche parte qualcosa deve effettivamente interagire con i sottosistemi e questo è il componente e il suo scopo.

L'accoppiamento non è in realtà una cosa negativa in questo caso.

Le prestazioni sono essenzialmente richieste in questo caso se si prevede di avere qualche complessità nel proprio sistema, non è possibile permettersi gli approcci di stile di ricerca delle altre opzioni.

Infine, se un sottosistema deve essere reattivo a un altro (renderer, fisica, audio devono tutti fare cose quando succede qualcosa) i componenti possono facilitarli l'uno con l'altro attraverso l'oggetto di gioco e mantenere gestibile questo particolare tipo di accoppiamento incrociato tra sistemi componenti.

— pagliaio
fonte

Quello è buono. Ma come fanno i componenti a conoscere GameSubsystems? Tutti i sottosistemi sono singleton? Non è brutto? ... Sto pensando a un'altra soluzione come l'iniezione di dipendenza ... ma quando e chi passa l'istanza del sottosistema a ciascun componente?

— Dani

I componenti @Dani non devono accedere direttamente all'istanza del sottosistema, devono solo inviare un messaggio che richiede la registrazione, non hanno bisogno di sapere che cos'è il sottosistema (ma molto probabilmente) E perché sarebbero dei single? Non è un requisito, anche se nella maggior parte dei casi sarà necessaria un'unica istanza di sottosistema per ciascun sottosistema.

— Pablo Ariel,

@Pablo - d'accordo.

— Rick,