Хранение больших 2D-игр Worlds

Question

Я экспериментировал с различными идеями о том, как хранить 2D-игровой мир. Мне интересно слышать методы хранения большого количества объектов при управлении видимым множеством (скажем, 100 000 квадратных квадратов). Очевидно, что методы могут варьироваться в зависимости от того, как игра отображает это пространство.

Предположим, что мы описываем прокручивающийся мир 2d игры, а не экран, так как вы можете довольно легко выполнять рендеринг на основе экрана из такой установки, в то время как обратное немного более грязное.

Ищете агностические решения языка здесь, поэтому они более полезны для других.

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

Answer 1

Вы можете получить некоторые идеи о том, как реализовать это из некоторых пространственных структур данных, таких как деревья диапазона или kd.

Однако ответ на этот вопрос будет значительно отличаться в зависимости от того, как работает ваша игра.

Мы говорим о двумерном платформере с 10 врагами на экране, еще 20 на экране, но «активным», а неизвестное число более «неактивным»? Если это так, вы, вероятно, можете сохранить весь свой уровень в виде массива «экранов», где вы будете манипулировать ближайшими к вам.

Или вы имеете в виду настоящую 2D-игру с большим количеством движения вверх/вниз? Возможно, вам придется быть более осторожным.

Платформа также имеет важное значение. Если вы используете простой платформер для настольных ПК, вам, вероятно, не придется беспокоиться о производительности настолько, насколько это было бы на встроенном устройстве. Это не повод для наивности, но вам, возможно, и не нужно быть ужасно умным.

Это несколько интересный вопрос, который я думаю. Предположительно, кто-то умнее меня, у которого есть опыт работы с платформерами, уже думал об этом.

Answer 2

Quadtrees - довольно эффективное решение для хранения данных о большом двумерном мире и объектах внутри него.

Answer 3

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

Сколько данных хранится на плитки? Как быстро игроки могут перемещаться по миру? Каково поведение NPC и т. Д., Которые находятся вне экрана? Они просто перезагружаются, когда игрок возвращается (например, старые игры Zelda)? Они просто возобновляют, где они были? Они делают какой-то догоняющий сценарий?

Сколько разных данных визуализации потребуется для разных областей?

Сколько всего мира можно увидеть за один раз?

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

Answer 4

Предполагая, что ваша игра обновит только то, что видно, и область вокруг того, что видно, просто сломайте мир на «экранах» («экран» представляет собой прямоугольную область на плитке, которая может заполнять весь экран). Храните в памяти «экраны» вокруг видимой области (и еще немного, если вы хотите обновлять объекты, близкие к символу, - но нет причин для обновления объекта, который находится далеко), и остальное на диске с кешем во избежание загрузки/выгрузки обычно посещаемых областей при перемещении. Некоторые установки, как:

+---+---+---+---+---+---+---+ 
|FFF|FFF|FFF|FFF|FFF|FFF|FFF| 
+---+---+---+---+---+---+---+ 
|FFF|NNN|NNN|NNN|NNN|NNN|FFF| 
+---+---+---+---+---+---+---+ 
|FFF|NNN|NNN|NNN|NNN|NNN|FFF| 
+---+---+---+---+---+---+---+ 
|FFF|NNN|NNN|VVV|NNN|NNN|FFF| 
+---+---+---+---+---+---+---+ 
|FFF|NNN|NNN|NNN|NNN|NNN|FFF| 
+---+---+---+---+---+---+---+ 
|FFF|NNN|NNN|NNN|NNN|NNN|FFF| 
+---+---+---+---+---+---+---+ 
|FFF|FFF|FFF|FFF|FFF|FFF|FFF| 
+---+---+---+---+---+---+---+ 

Где «V» часть находится на «экран», где центр (герой или любой другой) есть, «N» части являются те, которые находятся рядом и активные (обновление) сущности, являются проверены на наличие столкновений и т. д., а части «F» - это дальние части, которые могут обновляться нечасто и подвержены «замене» (хранятся на диске). Конечно, вы можете использовать больше экранов «N», чем два :-).

Обратите внимание на то, что, поскольку 2D-игры обычно не содержат большого количества данных, а не сохраняют отдаленные части на диске, вы можете просто сохранить их в сжатой памяти.

Answer 5

Возможно, вы захотите использовать один массив int или byte, который ссылается на типы блоков. Если вам нужна дополнительная оптимизация, вам нужно будет ссылаться на более сложные структуры данных, такие как октальные деревья из вашего массива. Здесь есть хорошая дискуссия на форуме Java-игр: http://www.javagaming.org/index.php/topic,20505.30.html text

Все, что связано со ссылками, становится очень дорогостоящим, потому что указатель занимает примерно 8 байтов каждый, в зависимости от языка, поэтому в зависимости от того, как заполняется ваш мир, он может получить очень дорого (8 указателей на 8 байт каждый на 64 байта на элемент, а байтовый массив - 1 байт на элемент). Поэтому, если 1/64 вашего мира пуст, массив байтов будет намного лучшим вариантом. Вам также потребуется потратить много времени на итерацию по дереву всякий раз, когда вы будете искать столкновение или что-то еще - массив байтов будет мгновенным поиском.

Надеюсь, это достаточно подробно для вас. :-)