Загрузка плиток для 2D-игры

Question

Я пытаюсь сделать 2D онлайн-игру (с позициями Z), и в настоящее время я работаю с загрузкой карты из текстового файла.У меня есть три разных файла карты.Один содержит int для каждой плитки, указывающий, какой тип пола, один говорит, что это за украшение, а другой - что может покрывать плитку.Проблема в том, что текущая карта (20, 20, 30) загружается за 200 мс, и я хочу, чтобы она была намного больше.Я попытался найти хорошее решение для этого и до сих пор выдвигал некоторые идеи.

Недавно я думал о хранении всех плиток в отдельных файлах, по одному файлу на плитку.Я не уверен, что это хорошая идея (она почему-то кажется неправильной), но это будет означать, что мне не нужно будет хранить ненужные плитки в виде «-1» в текстовом файле, и я смогу просто выбратьПравильная плитка из папки легко во время выполнения (прочитайте файл с именем mapXYZ).Если плитка пуста, я бы просто смог поймать исключение FileNotFoundException.Может ли кто-нибудь сказать мне причину этого плохого решения?Другие решения, о которых я думал, это разделить карту на более мелкие части или прочитать карту во время запуска в BackgroundWorker.

Answer 1

Вы загружаете файл с удаленного сервера? Если так, вот почему это так долго. Вместо этого вы должны встроить файл в игру. Я говорю это потому, что вы, вероятно, занимает 2-3 байта на плитку, поэтому размер файла около 30 КБ и 200 мс звучит как разумное время загрузки для файла такого размера (включая накладные расходы и т. Д., И в зависимости от вашего интернет-соединения).

Относительно того, как уменьшить размер файла - я могу придумать два простых метода, которые немного уменьшат размер файла:

1) Если у вас есть в основном пустые квадраты и только несколько значимых, ваша карта часто называется «скудной». При хранении разреженного массива данных вы можете использовать простую технику сжатия (формально известную как «кодирование по длине прогона»), при которой каждый раз, когда вы сталкиваетесь с пустыми квадратами, вы указываете, сколько их будет. Так например вместо {0,0,0,0,0,0,0,0,0,0,1,1,2,3,0,0,0,0,0,0,0,0, 0,0,0,0,1} вы можете хранить {10 0, 1, 1, 2, 3, 12 0, 1}

2) Для экономии места я рекомендую хранить все как двоичные данные. Точная настройка файла в основном зависит от того, сколько возможных типов листов существует, но это лучшее решение, чем хранение символов ascii, соответствующих представлению чисел в base-10, разделенных разделителями.

---

Пример двоичного формата

• Файл организован в сегменты длиной 3 или 4 байта, как описано ниже.

• Первый сегмент указывает версию игры, для которой была создана карта. Длина 3 байта.

• Сегменты 2, 3 и 4 указывают размеры карты (x, y, z). 3 байта каждый.

• Все остальные сегменты указывают либо номер фрагмента, и его длина составляет 3 байта, а MSB равен 0. Исключением является следующее.

• Если один из сегментов элемента мозаичного изображения является пустым элементом мозаичного изображения, он имеет длину 4 байта с MSB, равным 1, и указывает число пустых элементов мозаичного изображения, включая этот последующий элемент мозаичного изображения.

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

Answer 2

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

Если я вас понимаюпредлагаемое решение (открытие одного файла на координаты X, Y или X, Y, Z одной карты), это плохая идея по двум причинам:

• Для открытия стольких будет значительная нагрузкаfiles.
• Поймать исключение FileNotFoundException и съесть его будет значительно медленнее - на самом деле много перегрузок с перехватом исключений, поэтому вы не должны полагаться на них при выполнении логики приложения.