Пример ориентированного на данные дизайна

Кажется, я не могу найти хорошее объяснение Data Oriented Design для обычной игры зомби (это всего лишь пример, довольно распространенный пример).

Не могли бы вы привести пример Data Oriented Design для создания универсального класса зомби? Это хорошо?

Класс списка зомби:

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
}

Пример:

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
}

Или создать общий Всемирный контейнер , который содержит все действия от bite(zombieId, playerId)до moveTo(playerId, vector)до createPlayer()до shoot(playerId, vector)до face(radians)/face(vector); и содержит:

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

быть хорошим примером?

Как правильно организовать игру с DOD?

Не существует такой вещи, как «игра с DOD». Во-первых, это модное слово немного нечетко, потому что каждая система ориентирована на данные. Каждая программа работает с набором данных и вносит в него определенные преобразования. Это невозможно сделать, не ориентируя дизайн на данные. Таким образом, он не является взаимоисключающим с «нормальным» дизайном, но добавляет ограничения в структуру памяти и способ доступа к памяти соответственно.

Идея DOD состоит в том, чтобы упаковать и сгруппировать данные, относящиеся к одной функции, ближе друг к другу в непрерывный блок памяти, чтобы уменьшить количество кеш-памяти, избавиться от виртуальных функций и виртуальных таблиц, упростить распараллеливание, отсутствие (или минимальное) случайного доступа к памяти и писать код для высокооптимизированных процессоров, таких как SPU Cell в PS3 с его ограниченными ресурсами памяти, оптимизируя доступ к памяти и DMA в и из основной памяти.

Это не просто означает изменить все с «массива структур» (AoS) на «структуру массивов» (SoA), как показано в примерах здесь. Это также может означать смешивание и для чередования, и для объединения и упаковки данных, принадлежащих одной функциональности, например, «положение» и «скорость», чтобы избежать скачков в памяти для интеграции положения.

Однако системы с чистым DOD очень сложно реализовать, поскольку каждый доступ к указателю является нарушением этой чистой концепции, поскольку вы больше не обращаетесь к непрерывному блоку памяти, а делаете произвольный доступ к памяти, разыменовывая указатель. Это особенно важно для написания кода для SPU при перемещении, например, системы частиц из CPU в SPU, но при обычной ежедневной разработке игр это не важно. Это способ оптимизировать подфункцию, а не писать игры с ней (пока, как объясняется в статье Noels).

Майк Актон из Insomniac Games имеет много intesting материала по этой теме, вы можете найти некоторые его вещи здесь , а также статей Ноэля , и настоятельно рекомендуется.

Я искал хороший пример этого, но с ограниченными ресурсами в сети, и никто не сказал мне, как это сделать правильно, я сделал это со следующей реализацией. (это может быть не самым лучшим, но оно следует основной идее)

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

Таким образом, реализация более или менее похожа на это: у вас есть базовый объектный класс, который содержит все общие данные. Когда ваш автомобильный класс создается, вы указываете, какой объем данных вы хотите объединить, и поэтому у вас будет достаточно памяти для всех объектов.

оттуда вы можете добавить идентификаторы или что-то, что когда-либо кажется необходимым для вашей реализации. но я попробовал это на более простой игре, и она работала довольно аккуратно.

Это не так далеко от вашего дизайна, и, честно говоря, я не знаю более эффективного способа сделать это.