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

37

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

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

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

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

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

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

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

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

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

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

Изменить 2:

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

Плюсы:

  • это быстро

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

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

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

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

Минусы:

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

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

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

user697111
источник
3
значения, разделенные запятыми
Томас Эдинг
@Trinithis KISS - отличная вещь.
Nate
3
Не попадитесь в ловушку , что мышление CSV разбор легко: secretgeek.net/csv_trouble.asp
Тетрадь
Забавно, ProtoBuf был создан для поддержки возможности обновления.
Джонатан Дикинсон
ini для всего, что можно изменить, например, настройки и т.д .; и бинарный для всего остального.
Угур Гюмюшан,

Ответы:

38

Для отображения иерархических данных хорошими вариантами являются 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) использует такой подход.

Рафаэль Р.
источник
+1 За «контролируемую» двоичную сериализацию. Я использую это на работе, и это здорово!
NoobsArePeople2
1
Еще +1 за «контролируемую» двоичную сериализацию. Хотя я никогда не слышал этого названия раньше, я делаю нечто подобное в нескольких местах - все сделано правильно, у него есть преимущество в том, что он позволяет устанавливать значения по умолчанию для вновь добавленных полей, которых нет в файле данных, и игнорировать " мусор »в файле данных, когда поле удалено из модели.
Изката
Я использую что-то подобное в моей игре. Это работает хорошо! Я использую Java. Каждый объект имеет метод ToByteStream, который записывает в файловый поток, и конструктор, который читает из файлового потока. Мне не понравилась реализация Javas Serializable.
MichaelHouse
4
Или вы можете просто использовать Boost.Serialize и получить замечательные функции, такие как управление версиями и так далее.
Николь Болас
@Izkata Я придумал это имя, потому что понятия не имею, как вызывается этот метод.
Рафаэль Р.
9

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

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

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

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

AAAAAAAAAAAA
источник
6

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

Набор инструментов является одним из наиболее важных факторов при выборе формата файла игры. Если вы создаете двоичный формат , вы всегда должны убедиться, что у вас есть инструменты для ввода игровых данных. Это может быть так же просто, как шестнадцатеричный редактор, или так же сложно, как 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>

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

Ура, Рой =)

Рой
источник
5

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

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

basicer
источник
1
Хотя я думаю, что идея «двоичного JSON» хороша, я мало верю в BSON, но существует слишком много (избыточных) типов данных, и документация отстой.
аааааааааааа
2

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

jwenting
источник
1

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

Евгений
источник