Exemplo de Projeto Orientado a Dados

Não consigo encontrar uma boa explicação do Design Orientado a Dados para um jogo genérico de zumbi (é apenas um exemplo, um exemplo bastante comum).

Você poderia fazer um exemplo do Design Orientado a Dados para criar uma classe zumbi genérica? O seguinte é bom?

Classe da lista de zumbis:

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
}

Exemplo:

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
}

Ou seria a criação de um recipiente Mundial genérico que contém todas as ações de bite(zombieId, playerId)para moveTo(playerId, vector)para createPlayer()para shoot(playerId, vector)para face(radians)/face(vector); e contém:

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

ser um bom exemplo?

Qual é a maneira correta de organizar um jogo com o DOD?

Não existe um "jogo com DOD". Primeiramente, essa palavra da moda é um pouco confusa, porque cada sistema é projetado para dados. Cada programa trabalha em um conjunto de dados e faz certas transformações nele. Impossível fazer isso sem orientar o design para os dados. Portanto, não é mutuamente exclusivo no design "normal", mas adiciona restrições no layout da memória e na maneira como a memória é acessada, respectivamente.

A idéia por trás do DOD é empacotar e agrupar dados pertencentes a uma funcionalidade mais próximos em um bloco de memória contínuo, a fim de ter menos falhas de cache, livrar-se de funções virtuais e vtables, paralelização mais fácil, nenhum (ou mínimo) acesso aleatório à memória e escrever código para processadores altamente otimizados, como as SPUs da Cell no PS3, com recursos limitados de memória, otimizando o acesso à memória e os DMAs para e da memória principal.

Isso não significa simplesmente mudar tudo de "Array-of-Structures" (AoS) para "Structure of Arrays" (SoA), como mostrado nos exemplos aqui. Também pode significar misturar e intercalar e empacotar os dados pertencentes a uma funcionalidade, como por exemplo "posição" e "velocidade" para evitar pular na memória para a integração da posição.

No entanto, os sistemas DOD puros são muito difíceis de implementar, pois cada acesso ao ponteiro é uma violação desse conceito puro , pois você não acessa mais um bloco de memória contínuo, mas faz acessos aleatórios à memória desreferenciando um ponteiro. Isso é particularmente importante para escrever código para a SPU ao mover, por exemplo, um sistema de partículas da CPU para a SPU, mas no desenvolvimento diário normal de jogos não é importante. É uma maneira de otimizar a sub-funcionalidade, não para escrever jogos com ela (ainda, como o artigo de Noels explica).

Mike Acton, da Insomniac Games, tem um monte de material intestinal relacionado a esse tópico, você pode encontrar algumas coisas dele aqui , além dos artigos de Noel , ambos altamente recomendados.

Eu tenho procurado um bom exemplo disso também, mas com recursos limitados na rede e ninguém para me dizer como fazê-lo corretamente, eu fiz isso com a seguinte implementação. (pode não ser o melhor, mas segue a ideia básica)

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);

Portanto, a implementação é mais ou menos assim: você tem uma classe de objeto base, que contém todos os dados comuns. Quando sua classe de carro é construída, você especifica a quantidade de dados que deseja agrupar e, portanto, possui memória suficiente para todos os objetos.

a partir daí, você pode adicionar identificadores fora do curso ou o que for necessário para sua implementação. mas tentei isso em um jogo mais simples, e funcionou bem legal.

Também não está muito longe do seu design e, francamente, não conheço nenhuma maneira mais eficaz de fazer isso.