Esempio di progettazione orientata ai dati

Non riesco a trovare una bella spiegazione del Design orientato ai dati per un gioco di zombi generico (è solo un esempio, un esempio abbastanza comune).

Potresti fare un esempio del Design orientato ai dati sulla creazione di una classe di zombi generica? È il seguente buono?

Classe dell'elenco di zombi:

class ZombieList {
    GLuint vbo; // generic zombie vertex model
    std::vector<color>;    // object default color
    std::vector<texture>;  // objects textures
    std::vector<vector3D>; // objects positions
public:
    unsigned int create(); // return object id
    void move(unsigned int objId, vector3D offset);
    void rotate(unsigned int objId, float angle);
    void setColor(unsigned int objId, color c);
    void setPosition(unsigned int objId, color c);
    void setTexture(unsigned int, unsigned int);
    ...
    void update(Player*); // move towards player, attack if near
}

Esempio:

Player p;

Zombielist zl;
unsigned int first = zl.create();
zl.setPosition(first, vector3D(50, 50));
zl.setTexture(first, texture("zombie1.png"));
...

while (running) { // main loop
    ...
    zl.update(&p);
    zl.draw(); // draw every zombie
}

O sarebbe la creazione di un contenitore mondiale generico che contiene ogni azione da bite(zombieId, playerId)a moveTo(playerId, vector)a createPlayer()a shoot(playerId, vector)a face(radians)/face(vector); e contiene:

std::vector<zombie>
std::vector<player>
...
std::vector<mapchunk>
...
std::vector<vbobufferid> player_run_animation;
...

essere un buon esempio?

Qual è il modo corretto di organizzare un gioco con DOD?

Non esiste un "gioco con DOD". Firmabile, quella parola d'ordine è un po 'confusa, perché ogni sistema è progettato orientato ai dati. Ogni programma funziona su un insieme di dati e apporta alcune trasformazioni ad esso. Impossibile farlo senza orientare il design verso i dati. Quindi non si escludono a vicenda con un design "normale", ma aggiunge vincoli nel layout della memoria e nel modo in cui si accede alla memoria rispettivamente.

L'idea alla base di DOD è di raggruppare e raggruppare i dati appartenenti a una funzionalità più vicini tra loro in un blocco di memoria continuo, al fine di avere meno errori di cache, eliminare funzioni virtuali e vtabili, parallelizzazione più semplice, nessun (o minimo) accesso casuale alla memoria e scrivere codice per processori altamente ottimizzati come le SPU di Cell nella PS3 con le sue risorse di memoria limitate, ottimizzando l'accesso alla memoria e i DMA da e verso la sua memoria principale.

Questo non significa semplicemente cambiare tutto da "Array-of-Structures" (AoS) a "Structure of Arrays" (SoA) come mostrato negli esempi qui. Può anche significare mescolare entrambi e interfogliare e comprimere i dati appartenenti a una funzionalità strettamente insieme, come ad esempio "posizione" e "velocità" per evitare di saltare in memoria per l'integrazione della posizione.

Tuttavia, i sistemi DOD puri sono molto difficili da implementare, poiché ogni accesso al puntatore è una violazione di quel concetto puro , poiché non si accede più a un blocco di memoria continuo, ma si fa un accesso casuale alla memoria dereferenziando un puntatore. Ciò è particolarmente importante per la scrittura di codice per la SPU quando si sposta ad esempio un sistema di particelle dalla CPU alla SPU, ma nel normale sviluppo del gioco quotidiano non è importante. È un modo per ottimizzare le funzionalità secondarie, non per scrivere giochi con esso (ancora, come spiega l'articolo di Noels).

Mike Acton di Insomniac Games ha un sacco di materiale di approfondimento relativo a questo argomento, puoi trovare alcune delle sue cose qui e gli articoli di Noel , entrambi altamente raccomandati.

Ho cercato anche un buon esempio di questo, ma con risorse limitate in rete e nessuno che mi dicesse come farlo correttamente, l'ho fatto con la seguente implementazione. (potrebbe non essere il migliore, ma segue l'idea di base)

Object
   //Basic data
   Vector3* Position;
   Vector3* Rotation;
   Vector3* Scale;



Car : Object
    float* acceleration;
    Object* GetObjectData();
    //invoke the updateCars, to update all cars.
    void    UpdateCar() { UpdateCars(Postion, Rotation, Scale);

    //Update all your objects in a big loop.
    void    UpdateCars(vector3* Position, vector3* Rotation, Vector3* scale);

Quindi l'implementazione è più o meno così: hai una classe di oggetti base, che contiene tutti i dati comuni. Quando la classe della tua auto viene costruita, specifichi quale quantità di dati vuoi mettere in comune e quindi hai abbastanza memoria per tutti gli oggetti.

da lì puoi offcourse aggiungere identificatori o qualsiasi cosa sia mai sentimentale per la tua implementazione. ma l'ho provato su un gioco più semplice e ha funzionato abbastanza bene.

Non è poi così lontano dal tuo progetto, e francamente non conosco un modo più efficace per farlo.