In che modo i componenti fisici o grafici sono generalmente integrati in un sistema orientato ai componenti?

Ho trascorso le ultime 48 ore a leggere sui sistemi Object Component e mi sento abbastanza pronto per iniziare a implementarlo. Ho creato le classi di oggetti e componenti di base, ma ora che ho bisogno di iniziare a creare i componenti effettivi sono un po 'confuso. Quando penso a loro in termini di HealthComponent o qualcosa che sarebbe sostanzialmente una proprietà, ha perfettamente senso. Quando è qualcosa di più generale come componente di Fisica / Grafica, mi confondo un po '.

La mia classe di oggetti è così simile (se noti cambiamenti che dovrei fare per favore fammi sapere, ancora nuovo a questo) ...

typedef unsigned int ID;

class GameObject
{
public:

    GameObject(ID id, Ogre::String name = "");
    ~GameObject();

    ID &getID();
    Ogre::String &getName();

    virtual void update() = 0;

    // Component Functions
    void addComponent(Component *component);
    void removeComponent(Ogre::String familyName);

    template<typename T>
    T* getComponent(Ogre::String familyName)
    {
        return dynamic_cast<T*>(m_components[familyName]);
    }

protected:

    // Properties
    ID m_ID;
    Ogre::String m_Name;
    float m_flVelocity;
    Ogre::Vector3 m_vecPosition;

    // Components
    std::map<std::string,Component*> m_components;
    std::map<std::string,Component*>::iterator m_componentItr;
};

Ora il problema che sto incontrando è che cosa metterebbe la popolazione in componenti come Fisica / Grafica? Per Ogre (il mio motore di rendering) gli oggetti visibili saranno costituiti da più Ogre :: SceneNode (possibilmente multipli) per collegarlo alla scena, Ogre :: Entity (possibilmente multipli) per mostrare le mesh visibili, e così via. Sarebbe meglio aggiungere più GraphicComponent all'Oggetto e lasciare che ogni GraphicComponent gestisca un SceneNode / Entity o è necessaria l'idea di avere uno di ciascun Component?

Per la fisica sono ancora più confuso. Suppongo che forse crei un RigidBody e tenga traccia di massa / interia / ecc. avrebbe senso. Ma ho problemi a pensare a come inserire effettivamente i dettagli in un componente.

Una volta che avrò fatto un paio di questi componenti "richiesti", penso che avrà molto più senso. A partire da ora, anche se sono ancora un po 'perplesso.

Prima di tutto, è quando i sistemi basati su componenti di compilazione, non si deve prendere l'approccio di trasformare tutto ciò in un componente. In effetti, in genere non dovresti - è una specie di errore neofita. Nella mia esperienza, il modo migliore per collegare i sistemi di rendering e fisica in un'architettura basata su componenti è quello di rendere quei componenti poco più che contenitori stupidi per il rendering reale o l'oggetto primitivo della fisica.

Ciò ha l'ulteriore vantaggio di mantenere i sistemi di rendering e fisica disaccoppiati dal sistema componente.

Per i sistemi fisici, ad esempio, il simulatore fisico tiene generalmente una grande lista di oggetti del corpo rigido che manipola ogni volta che spunta. Il tuo sistema di componenti non scherza con questo: il tuo componente di fisica memorizza semplicemente un riferimento al corpo rigido che rappresenta gli aspetti fisici dell'oggetto a cui appartiene il componente e traduce tutti i messaggi dal sistema di componenti in opportune manipolazioni del corpo rigido.

Allo stesso modo con il rendering - il tuo renderer avrà qualcosa che rappresenta i dati dell'istanza da rendere, e il tuo componente visivo semplicemente tiene un riferimento a quello.

È relativamente semplice: per qualsiasi motivo sembra confondere le persone, ma spesso perché ci pensano troppo. Non c'è molta magia lì. E poiché è molto importante fare le cose piuttosto che agonizzarsi per il design perfetto, dovresti considerare fortemente un approccio in cui almeno alcuni dei componenti hanno interfacce definite e sono membri diretti dell'oggetto di gioco, come ha suggerito momboco. È un approccio altrettanto valido e tende a essere più facile da capire.

Altri commenti

Questo non è correlato alle tue domande dirette, ma queste sono cose che ho notato guardando il tuo codice:

Perché stai mescolando Ogre :: String e std :: string nel tuo oggetto di gioco, che è apparentemente un oggetto non grafico e quindi non dovrebbe avere una dipendenza da Ogre? Suggerirei di rimuovere tutti i riferimenti diretti a Ogre tranne nel componente di rendering stesso, dove dovresti fare la tua trasformazione.

update () è un puro virtuale, il che implica che bisogna sottoclassare GameObject, che in realtà è esattamente l'opposto della direzione in cui si vuole andare con un'architettura componente. Il punto principale dell'utilizzo dei componenti è preferire l'aggregazione delle funzionalità piuttosto che l'ereditarietà.

Potresti beneficiare di un certo uso di const(in particolare dove stai tornando per riferimento). Inoltre, non sono sicuro che tu voglia davvero che la velocità sia uno scalare (o se esso, e la posizione, dovessero essere presenti nell'oggetto di gioco nel tipo di metodologia di componente eccessivamente generica che sembra stia cercando).

Il tuo approccio all'utilizzo di una grande mappa di componenti e una update()chiamata nell'oggetto di gioco è piuttosto subottimale (e una trappola comune per coloro che costruiscono prima questo tipo di sistemi). Garantisce una scarsa coerenza della cache durante l'aggiornamento e non consente di sfruttare la concorrenza e la tendenza verso il processo in stile SIMD di grandi quantità di dati o comportamenti contemporaneamente. Spesso è meglio usare un design in cui l'oggetto di gioco non aggiorna i suoi componenti, ma piuttosto il sottosistema responsabile del componente stesso li aggiorna tutti in una volta. Questo potrebbe valere la pena di essere letto.

L'architettura dei componenti è un'alternativa per evitare le grandi gerarchie ottenute ereditando tutti gli elementi da uno stesso nodo e i problemi di accoppiamento che portano.

Stai mostrando un'architettura di componente con componenti "generici". Hai la logica di base per collegare e scollegare componenti "generici". Un'architettura con componenti generici è più difficile da realizzare perché non sai quale componente sia. I vantaggi sono che questo approccio è estensibile.

Un'architettura di componente valida si ottiene con componenti definiti. Con definito intendo, l'interfaccia è definita, non l'implementazione. Ad esempio, GameObject può avere un IPhysicInstance, Transformation, IMesh, IAnimationController. Questo ha il vantaggio di conoscere l'interfaccia e GameObject sa come gestire ogni componente.

Rispondere al termine di generalizzazione eccessiva

Penso che i concetti non siano chiari. Quando dico componente, non significa che tutti i componenti di un oggetto gioco debbano ereditare da un'interfaccia componente o qualcosa di simile. Tuttavia, questo è l'approccio per i componenti generici, penso che sia il concetto che si chiama come componente.

L'architettura del componente è un'altra delle architetture esistenti per il modello a oggetti di runtime. Non è l'unico e non è il migliore per tutti i casi, ma l'esperienza ha dimostrato che ha molti vantaggi, come un basso accoppiamento.

La caratteristica principale che distingue l'architettura del componente è convertire la relazione is-a in has-a. Ad esempio un'architettura a oggetti è-a:

Invece di un'architettura a oggetti has-a (componenti):

Esistono anche architetture incentrate sulla proprietà:

Ad esempio, una normale architettura di oggetti è così:

• Object1

  • Posizione = (0, 0, 0)
  • Orientamento = (0, 43, 0)

• Object2

  • Posizione = (10, 0, 0)
  • Orientamento = (0, 0, 30)

Un'architettura incentrata sulla proprietà:

• Posizione

  • Object1 = (0, 0, 0)
  • Object2 = (10, 0, 0)

• Orientamento

  • Object1 = (0, 43, 0)
  • Object2 = (0, 0, 30)

È meglio l'architettura modello a oggetti? Dal punto di vista delle prestazioni, è meglio incentrato sulle proprietà perché è più compatibile con la cache.

Il componente è riferito alla relazione is-a anziché has-a. Un componente può essere una matrice di trasformazione, un quaternione, ecc. Ma la relazione con l'oggetto di gioco è una relazione è -a, l'oggetto di gioco non ha la trasformazione perché ereditata. L'oggetto gioco ha (relazione has-a) la trasformazione. La trasformazione è quindi un componente.

L'oggetto di gioco è come un hub. se vuoi un componente che è sempre lì, allora forse il componente (come la matrice) dovrebbe essere all'interno dell'oggetto e non un puntatore.

Non esiste un oggetto di gioco perfetto per tutti i casi, dipende dal motore, dalle librerie che il motore utilizza. Forse voglio una macchina fotografica che non ha una maglia. Il problema con is-a architecture è che se l'oggetto game ha una mesh, la telecamera che eredita dall'oggetto game deve avere una mesh. Con i componenti, la fotocamera ha una trasformazione, un controller per il movimento e tutto ciò di cui hai bisogno.

Per ulteriori informazioni, il capitolo "14.2. Runtime Object Model Architecture" dal libro "Game Engine Architecture" di "Jason Gregory" tratta specificamente questo argomento.

I diagrammi UML vengono estratti da lì