Есть ли хорошая альтернатива мировой структуре данных в мире?

Как вы избегаете одной большой структуры данных, содержащей все текущее мировое состояние?

Давайте притворимся, что мы в стратегической игре в режиме реального времени, как бы вы написали умение, которое уменьшало ману единиц вокруг него?

С мировым состоянием это будет выглядеть так:

 class MySpell : ISkillWithoutTarget
{
  void Cast(Unit caster, World world)
  {
    foreach (Unit target in world.Units)
    {
      if (target.distanceWith(caster) <= N)
      {
        target.Mana -= X;
      }
    }
  }
}

Итак, мой вопрос: существует ли хорошая альтернатива «мировому объекту»? Или объект мира - лучший способ справиться с такими взаимодействиями?

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

5 голосов | спросил anopse 10 AM00000010000001631 2014, 01:42:16

1 ответ


5

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

Эти структуры полезны, поскольку они позволяют исключать большое количество объектов из запросов просто на основе их приблизительных местоположений. Например, с октетом или сеткой вам нужно только иметь дело с объектами в ячейках, которые пересекают ваш объем запросов, и вы можете отбросить объекты в других ячейках, что позволит вам обрезать множество объектов, используя только несколько проверок AABB .

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


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

ответил jmegaffin 10 AM00000020000002031 2014, 02:24:20

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132