Какой формат файла подходит для сохранения игровых данных? [закрыто]

Мне нужно сохранить некоторые пользовательские данные игры. Карта, игрок и т. Д.

Все они будут иметь «подобъекты». Например, карта и карта будут иметь «массив» плиток. т.е. иерархические данные. Надеюсь, ничего двоичного.

Какой будет хороший формат для них?

До сих пор я считал:

Serailization: это БЫСТРО и легко, но имеет тенденцию ломаться, когда я изменяю базовые классы :(

XML: я действительно ненавижу разбор этого. Мой тестовый пример содержал более 100 строк кода и казался тоннами «занятой работы» даже для очень простого формата.

INI: было бы очень неуклюже для иерархических данных.

Protobuf: Никогда не использовал его, но читайте, вам придется много разводить вручную и ломаться, если вы меняете класс.

Другие опции? Вот почему я здесь!

Изменить: это Java, кстати.

Изменить 2:

Я остановился на «Контролируемой двоичной сериализации» (см. Ниже).

Плюсы:

• это быстро

• он небольшой (на диске) и может быть легко сжат / распакован во время чтения / записи.

• это супер легко читать / писать из игры и набора инструментов.

• Я могу решить, что включить / исключить объект.

• Объекты / Данные могут быть вложенными.

Минусы:

• Невозможно редактировать вручную (например, XML, YAML и т. Д.)

• Не могу легко прочитать / изменить его с помощью сценариев

• Сериализация Java по умолчанию довольно медленная / раздутая по сравнению с другими внедрениями, но она стабильна и работает

Для отображения иерархических данных хорошими вариантами являются YAML или JSON . Они намного проще и легче разбираются, чем XML.

Другим вариантом будет «контролируемый» процесс двоичной сериализации. Каждый объект записывает свое состояние контролируемым образом, т.е.

void player::save(savegame &sgm)
{
    sgm.write(this->position);
    sgm.write(other properties);
    inventory.save(sgm);
}

id Tech 4 (движок Quake 4 / Doom 3) использует такой подход.

Хорошо сделанный двоичный формат действительно обладает всеми преимуществами: он быстрый, достаточно маленький и настолько гибкий, насколько вы его делаете.

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

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

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

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

Набор инструментов является одним из наиболее важных факторов при выборе формата файла игры. Если вы создаете двоичный формат , вы всегда должны убедиться, что у вас есть инструменты для ввода игровых данных. Это может быть так же просто, как шестнадцатеричный редактор, или так же сложно, как Unreal Editor.

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

Игра. Какую игру вы делаете? Почему я говорю, что это повлияет на формат файла? Потому что, если вы делаете что-то вроде 2D Bomberman, вы можете получить простой текстовый файл, например:

*********
*1     2*    1,2,3,4  - start point of players 1, 2, 3, 4
* + + + *    *        - walls
*       *    +        - crates
* + + + *
*3     4*
*********

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

• Карты, частицы и другие графические объекты обычно используют собственный двоичный формат. Потому что это самый простой способ реализовать это. Это не по-человечески разумно описывать карты в текстовом виде. Обычно редактируется с помощью редактора карт / уровней / частиц.
• Игроки, предметы, враги, навыки и квесты - это статистика, которая влияет на игровой баланс . Они обычно требуют много-много ввода и настройки. Мне нравится делать это, помещая его в XML-файл для простоты реализации, но при этом имея дизайнерский редактор для дизайнеров. Лучший из обоих миров .

Как правило, вы хотите описать текст в текстовом формате, а графику в двоичном формате. Следующее должно дать вам пример:

<Skill>
    <Name>Fireball</Name>
    <Animation>fireball.dat</Animation> <!-- Graphics described in another file -->
    <Attack>1.3</Attack>
    <Cooldown>15</Cooldown>
</Skill>

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

Ура, Рой =)

BSON довольно хороший. http://bsonspec.org/ . Проанализировать легче, чем JSON, и лучше содержать двоичные данные, но при этом иметь хорошую структуру. Это несколько похоже на буферы протокола. Недостатком является то, что за пределами mongodb, похоже, существует большая поддержка инструментов.

РЕДАКТИРОВАТЬ: MsgPack ( http://msgpack.org/ ) также похож на BSON и, кажется, набирает обороты.

Что случилось с вашим собственным двоичным форматом данных? Если вы боитесь необработанной сериализации, напишите свою собственную систему, которая записывает поля по мере необходимости и считывает их обратно. Нет необходимости в xml, который действительно слишком громоздок и сложен в ситуациях, когда вам не нужна прозрачность, которую обеспечивает формат. Просто определите четко определенный формат файла и придерживайтесь его, оставляя, возможно, некоторое пространство для расширения вашего набора данных в каждой записи, заполняя их нулевыми значениями (скажем, у вас есть 100-байтовая запись сейчас, добавьте 150 к будущему использованию.
Добавьте номер версии и, возможно, контрольную сумму, чтобы вы могли знать, какие поля должны быть заполнены и иметь проверку на корректность, и все готово.

Вы можете смешивать XML или другой формат со вставками Base64 для некоторых конкретных данных, а для полей, где вам нужна читабельность, вы можете использовать обычный текст