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

Question

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

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

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

Дополнительная информация

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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

Удачи вам!

Answer 5

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

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

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