Модель базы данных игрового ландшафта

Я разрабатываю игру для Интернета. Карта этой игры будет минимум 2000км на 2000км. Я хочу иметь возможность кодировать высоту и тип местности с некоторым уровнем детализации - например, 100 м X 100 м.

Для карты размером 2000 х 2000 км, хранящей эту информацию в блоках размером 100 м2, это будет означать 20 000 x 20 000 элементов или 400 000 000 записей в базе данных.

Есть ли другой способ хранения такого типа информации?

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ

Сама карта никогда не будет отображаться целиком. Юниты будут перемещаться по карте в пошаговом режиме, и игроки получат обратную связь о том, где они находятся и как выглядит местность. Местность будет диктовать скорость и запрет на движение.

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


person Mel    schedule 28.11.2008    source источник


Ответы (5)


Я бы отнесся к этому по-другому, разделив тип местности и высоту.

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

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

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

person Eran Galperin    schedule 28.11.2008

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

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

person Andrew Rollings    schedule 28.11.2008

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

Вы можете попробовать двумерное вейвлет-преобразование, но это довольно сложно. Что-то вроде преобразования Фурье вполне подойдет. Кроме того, вы, вероятно, не станете хранить данные о местности с помощью одной записи на участок земли; имеет смысл иметь какое-то поле базы данных, в котором может храниться закодированная матрица.

person zvoase    schedule 28.11.2008

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

Вам не нужно получать доступ ко всей этой информации сразу — даже если каждое ведро площадью 100 м2 занимает один пиксель на экране, ни один из известных мне экранов не может одновременно отображать 20k x 20k пикселей.

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

Удачи!

person Drew Hall    schedule 28.11.2008

Это будет ужасно много информации, независимо от того, с какой стороны вы на это смотрите. 400 000 000 ячеек сетки возьмут свое.

Я вижу два способа обойти это. Во-первых, поскольку это сетевая игра, вы можете получить сервер с жестким диском приличного размера и хранить на нем 400 миллионов записей, как обычно. Или, что более вероятно, создайте какой-то собственный механизм хранения для повышения эффективности. Тогда вам нужно будет только разработать способ эффективного доступа к данным, что может быть сделано с учетом того факта, что вам вряд ли понадобится использовать их все сразу. ;)

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

person Vilx-    schedule 28.11.2008