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

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

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

UPD2: Сначала я пошел и назначил текстуру каждому новому экземпляру класса плиток, и это заняло так много памяти (также время загрузки). Теперь это занимает примерно в четыре раза меньше места. Спасибо всем, теперь я могу запускать огромные карты, даже не думая разбивать их на куски.

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

приложение падает, когда оно достигает 1,5 ГБ.

Это настоятельно говорит о том, что вы неправильно представляете свои плитки, так как это будет означать, что каждая плитка имеет размер ~ 80 байт.

Что вам нужно понять, так это то, что между игровой концепцией плитки и визуальной плиткой, которую видит пользователь, должно быть разделение . Эти два понятия не одно и то же .

Взять, к примеру, Террарию. Самый маленький мир Terraria занимает 4200x1200 плиток, что составляет 5 миллионов плиток. Теперь, сколько памяти нужно, чтобы представить этот мир?

Итак, у каждой плитки есть слой переднего плана, фоновый слой (фоновые стены), «слой проволоки», куда идут провода, и «слой мебели», куда идут предметы мебели. Сколько памяти занимает каждая плитка? Опять же, мы просто говорим концептуально, а не визуально.

Плитка переднего плана может быть легко сохранена в неподписанном коротком. Существует не более 65536 типов листов переднего плана, поэтому нет смысла использовать больше памяти, чем эта. Фоновые листы могут легко находиться в байте без знака, так как существует менее 256 различных типов фоновых листов. Слой проводов является чисто двоичным: либо в плитке есть провод, либо его нет. Так что это один бит на плитку. И слой мебели снова может быть байтом без знака, в зависимости от того, сколько существует различных предметов мебели.

Общий объем памяти на плитку: 2 байта + 1 байт + 1 бит + 1 байт: 4 байта + 1 бит. Таким образом, общий размер небольшой карты Terraria составляет 20790000 байт, или ~ 20 МБ. (примечание: эти расчеты основаны на Terraria 1.1. С тех пор игра значительно расширилась, но даже современная Terraria может умещаться в пределах 8 байт на ячейку или ~ 40 МБ. Все еще вполне терпимо).

Вы никогда не должны хранить это представление в виде массивов классов C #. Они должны быть массивами целых чисел или чем-то подобным. AC # struct также будет работать.

Теперь, когда приходит время рисовать часть карты (обратите внимание на акцент), Terraria необходимо преобразовать эти концептуальные тайлы в настоящие тайлы. Каждая плитка должна на самом деле выбрать изображение переднего плана, фоновое изображение, дополнительное изображение мебели и иметь изображение в виде провода. Здесь XNA входит со своими различными листами спрайтов и тому подобным.

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

Теперь видимая область листов должна быть разбита на различные фрагменты, чтобы вы не создавали спрайт-листы постоянно, когда камера движется. Таким образом, у вас могут быть куски мира размером 64х64 в виде спрайтов. Независимо от того, какие фрагменты мира размером 64x64 видны с текущей позиции игрока на экране, это фрагменты, которые вы рисуете. У любых других кусков даже нет листов спрайтов; если кусок падает с экрана, вы выбрасываете этот лист (примечание: вы на самом деле не удаляете его; вы сохраняете его и назначаете заново для нового фрагмента, который может стать видимым позже).

Я хотел бы, чтобы вся карта была обработана, по крайней мере, на серверном приложении (и на клиенте, если это возможно).

Вашему серверу не нужно знать или заботиться о визуальном представлении плиток. Все, о чем нужно заботиться, - это концептуальное представление. Пользователь добавляет плитку сюда, поэтому он изменяет индекс плитки.

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

Вы также можете использовать такие приемы, как создание экземпляров. Где, если все плитки одного типа просто имеют один экземпляр в памяти и нарисованы несколько раз во всех местах, где это необходимо.

Вы можете найти больше идей, как это здесь:

Как они это сделали: миллионы плиток в Террарии

«Зонирование» областей на большой карте тайлов, а также подземелий

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

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

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

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

Эффективный способ, который я использовал в игре XNA, был:

• используйте таблицы спрайтов, а не изображения для каждой плитки / объекта, и просто загрузите то, что вам нужно на этой карте;
• разбить карту на более мелкие части, скажем, на куски карты размером 500 x 200, если ваша карта в 4 раза больше этого размера, или что-то, что вы можете сложить;
• загрузить этот блок в память и закрасить только видимые части карты (скажем, видимые плитки плюс 1 плитку для каждого направления движения игрока) в закадровом буфере;
• очистить область просмотра и скопировать пиксели из буфера (это называется двойной буфер и сглаживает движение);
• когда вы перемещаете чар, отслеживайте облака карты и загружайте следующий фрагмент, когда он приближается к нему, и добавляйте текущий;
• как только игрок полностью на этой новой карте, вы можете выгрузить последнюю.

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

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

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

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

Совет здесь заключается в том, что я ни в коем случае не являюсь экспертом в разработке игр, и моя игра была сделана для финального проекта моей выпускной (который у меня был лучший результат), так что я могу быть не очень прав в каждой точке, но я исследовал сеть и такие сайты, как http://www.gamasutra.com и сайт создателей XNA creators.xna.com (в настоящее время http://create.msdn.com ), чтобы собрать знания и навыки, и это отлично сработало для меня ,

Или

• купить больше памяти
• представлять ваши структуры данных более компактно
• не храните все данные в памяти сразу.

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

В ответ на ваше обновление вы не можете распределять массивы по Int32.MaxValueразмеру. Вы должны разделить его на куски. Вы даже можете инкапсулировать его в класс-обертку, который предоставляет массивоподобный фасад: