什么是存储动态游戏对象的最有效容器？[关闭]

我正在做第一人称射击游戏，我知道很多不同的容器类型，但是我想找到最有效地存储动态对象的容器，该对象将在游戏中频繁添加和删除。EX子弹。

我认为在那种情况下，它将是一个列表，以便内存不连续并且永远不会进行任何大小调整。但随后我也正在考虑使用地图或集合。如果有人有任何有用的信息，我将不胜感激。

我是用c ++编写的。

另外，我想出了一个我认为可行的解决方案。

首先，我将分配一个大尺寸的向量。比如说1000个对象。我将跟踪此向量中最后添加的索引，以便知道对象的末尾在哪里。然后，我还将创建一个队列，该队列将保存从向量中“删除”的所有对象的索引。（不会进行实际的删除，我只知道该插槽是免费的）。因此，如果队列为空，我将添加到向量+ 1中最后添加的索引，否则，我将添加至队列前面的向量的索引。

答案总是使用数组或std :: vector。诸如链表或std :: map之类的类型在游戏中通常绝对是可怕的，并且肯定包括诸如游戏对象集合之类的情况。

您应该将对象本身（而不是指向它们的指针）存储在数组/向量中。

您需要连续的内存。您真的很想要它。遍历非连续内存中的任何数据通常会导致很多高速缓存未命中，并且使编译器和CPU无法进行有效的高速缓存预取。仅此一项就可以降低性能。

您还希望避免内存分配和释放。即使使用快速的内存分配器，它们也非常慢。我已经看到，只要删除每帧几百个内存分配，游戏就可以获得10倍FPS的提升。看起来应该没有那么糟糕，但事实可能如此。

最后，您关心的用于管理游戏对象的大多数数据结构可以比使用树或列表更有效地实现在数组或向量上。

例如，要删除游戏对象，您可以使用交换和弹出。可以轻松实现，例如：

std::swap(objects[index], objects.back());
objects.pop_back();

您也可以将对象标记为已删除，并在下次需要创建新对象时将它们的索引放在空闲列表中，但是进行交换和弹出效果更好。它使您可以对所有活动对象进行简单的for循环，而无需循环本身。对于子弹物理集成等而言，这可以显着提高性能。

更重要的是，您可以使用槽位图结构从稳定的唯一表中查找一对简单的表查询对象。

您的游戏对象的主数组中都有一个索引。仅使用此索引就可以非常有效地查找它们（比映射甚至是哈希表要快得多）。但是，索引在删除对象时由于交换和弹出而不稳定。

插槽映射需要两层间接寻址，但是两者都是具有恒定索引的简单数组查找。他们很快。真快。

基本思想是，您具有三个数组：主对象列表，间接列表和间接列表的空闲列表。您的主要对象列表包含您的实际对象，其中每个对象都知道自己的唯一ID。唯一ID由索引和版本标签组成。间接列表只是主对象列表的索引数组。空闲列表是指向间接列表的索引的堆栈。

在主列表中创建对象时，您会在间接列表中找到一个未使用的条目（使用空闲列表）。间接列表中的条目指向主列表中未使用的条目。您可以在该位置初始化对象，然后将其唯一ID设置为所选的间接列表条目的索引以及主列表元素中现有的版本标签加上一个。

销毁对象时，您可以照常进行交换和弹出操作，但同时还要增加版本号。然后，您还将间接列表索引（对象唯一ID的一部分）添加到空闲列表中。在将对象作为交换和弹出的一部分进行移动时，还可以将其在间接列表中的条目更新为新位置。

伪代码示例：

Object:
  int index
  int version
  other data

SlotMap:
  Object objects[]
  int slots[]
  int freelist[]
  int count

  Get(id):
    index = indirection[id.index]
    if objects[index].version = id.version:
      return &objects[index]
    else:
      return null

  CreateObject():
    index = freelist.pop()

    objects[count].index = id
    objects[count].version += 1

    indirection[index] = count

    Object* object = &objects[count].object
    object.initialize()

    count += 1

    return object

  Remove(id):
    index = indirection[id.index]
    if objects[index].version = id.version:
      objects[index].version += 1
      objects[count - 1].version += 1

      swap(objects[index].data, objects[count - 1].data)

间接层使您可以为压缩期间可以移动的资源（主对象列表）具有稳定的标识符（间接层的索引，其中条目不移动）。

版本标记允许您将ID存储到可能被删除的对象。例如，您有一个ID（10,1）。索引为10的对象将被删除（例如，子弹击中一个对象并被销毁）。然后，位于主对象列表中该内存位置中的对象的版本号会增加，即为（10,2）。如果尝试从一个过时的ID再次查找（10,1），则该查找通过索引10返回该对象，但可以看到版本号已更改，因此该ID不再有效。

这是具有绝对稳定的ID的绝对最快的数据结构，该ID允许对象在内存中移动，这对于数据局部性和缓存一致性非常重要。这比哈希表的任何实现都快。哈希表至少需要计算一个哈希（比表查找更多的指令），然后必须遵循哈希链（在std :: unordered_map的可怕情况下是一个链表，或者在其中是一个打开地址的列表）哈希表的所有非愚蠢实现），然后必须对每个键进行值比较（比版本标签检查更昂贵，但可能更便宜）。一个非常好的哈希表（不是STL的任何实现中的哈希表，因为STL要求哈希表针对与游戏对象列表有关的不同用例进行优化）可以节省一个间接访问，

您可以对基本算法进行各种改进。例如，对主对象列表使用类似std :: deque的东西；间接层的另一层，但允许将对象插入完整列表，而不会使您从插槽图获取的任何临时指针无效。

您还可以避免将索引存储在对象内部，因为可以从对象的内存地址（此-对象）计算索引，并且只有在删除对象时才需要更好，在这种情况下，您已经有了对象的ID（因此，索引）作为参数。

致歉 我认为这不是最清晰的描述。时间太晚了，如果不花比我更多的时间在代码示例上的时间，就很难解释。

固定大小的数组（线性内存），
带有内部空闲列表（O（1）分配/空闲，稳定的索引），
带有弱引用键（重复使用插槽无效键），
零开销解除引用（当已知有效时）

struct DataArray<T>
{
  void Init(int count); // allocs items (max 64k), then Clear()
  void Dispose();       // frees items
  void Clear();         // resets data members, (runs destructors* on outstanding items, *optional)

  T &Alloc();           // alloc (memclear* and/or construct*, *optional) an item from freeList or items[maxUsed++], sets id to (nextKey++ << 16) | index
  void Free(T &);       // puts entry on free list (uses id to store next)

  int GetID(T &);       // accessor to the id part if Item

  T &Get(id)            // return item[id & 0xFFFF]; 
  T *TryToGet(id);      // validates id, then returns item, returns null if invalid.  for cases like AI references and others where 'the thing might have been deleted out from under me'

  bool Next(T *&);      // return next item where id & 0xFFFF0000 != 0 (ie items not on free list)

  struct Item {
    T item;
    int id;             // (key << 16 | index) for alloced entries, (0 | nextFreeIndex) for free list entries
  };

  Item *items;
  int maxSize;          // total size
  int maxUsed;          // highest index ever alloced
  int count;            // num alloced items
  int nextKey;          // [1..2^16] (don't let == 0)
  int freeHead;         // index of first free entry
};

处理从子弹到怪物到纹理再到粒子等的所有内容。这是视频游戏的最佳数据结构。我认为它来自Bungie（在马拉松/神话时代），是我在暴雪中学到的，当时我认为它是游戏编程中的瑰宝。此时可能遍及整个游戏行业。

问：“为什么不使用动态数组？” 答：动态数组会导致崩溃。简单的例子：

foreach(Foo *foo in array)
  if (ShouldSpawnBaby(*foo))
    Foo &baby = array.Alloc();
    foo->numBabies++; // crash!

您可以想象情况更复杂的情况（例如深层调用堆栈）。对于所有类似数组的容器都是如此。在制作游戏时，我们对问题有足够的了解，可以迫使一切尺寸和预算以换取性能。

我不能说足够：确实，这是有史以来最好的事情。（如果您不同意，请发布更好的解决方案！注意事项-必须解决本文顶部列出的问题：线性内存/迭代，O（1）分配/空闲，稳定索引，弱引用，零开销deref或有一个令人惊讶的原因，为什么您不需要其中的一个;）

没有正确的答案。这完全取决于算法的实现。随便找一个您认为最好的人。不要在此早期阶段进行优化。

如果您经常删除对象并重新创建它们，建议您看一下对象池的实现方式。

编辑：为什么使带有插槽的东西变得复杂而没有。为什么不只使用堆栈并弹出最后一个项目并重复使用呢？因此，当您添加一个时，您将执行++，而当您弹出一个时，您将执行++-以跟踪结束索引。

这取决于您的游戏。容器在访问特定元素的速度，删除元素的速度和添加元素的速度方面有所不同。

• std :: vector-快速访问以及快速删除和添加到最后。从开头和中间删除比较慢。
• std :: list-遍历列表并不比向量慢很多，但是访问列表的特定点很慢（因为迭代基本上是您可以对列表执行的唯一操作）。在任何地方添加和删除项目都非常快捷。大多数内存开销。不连续。
• std :: deque-快速访问以及从末尾开始/删除/添加的速度很快，但在中间却很慢。

通常，如果您希望对象列表的排序方式不同于按时间顺序排序，并且因此必须插入新对象而不是追加对象，否则就需要使用列表。双端队列比矢量具有更大的灵活性，但实际上并没有太大的缺点。

如果您确实有很多实体，则应该看看“空间分区”。