Який хороший формат файлів для збереження ігрових даних? [зачинено]

Мені потрібно зберегти деякі власні дані гри. Карта, плеєр тощо.

Усі вони матимуть «під об’єкти». Наприклад, карта і карта матимуть "масив" плиток. тобто ієрархічні дані. Сподіваємось, нічого бінарного.

Який би це був гарний формат?

Поки я вважав:

Сераїлізація: Це швидке та просте, але має тенденцію до ламання, коли я змінюю основні класи :(

XML: Я дуже ненавиджу аналіз цього. У моєму тестовому випадку було понад 100 рядків коду і, здавалося, сподобалось багато "зайнятої роботи" навіть для дуже простого формату.

INI: було б справді незграбним щодо ієрархічних даних.

Протобуф: Ніколи не користувався ним, але читайте, що ви повинні зробити багато ручного перегляду і перерв, якщо ви зміните клас.

Інші варіанти? Тому я тут!

Редагувати: це Java btw.

Редагувати 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-бомбермена, ви можете піти з простого текстового файлу, як-от:

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

Іншими словами, завжди перейдіть до найбільш очевидного формату для ваших конкретних даних . RPG - це найскладніший ігровий жанр. Вони вимагають великої кількості даних. Але це не означає, що вам потрібно дотримуватися певного формату , будь то двійковий або текстовий на основі всіх даних у грі.

• Карти, частинки та інші графічні матеріали, як правило, використовують користувацький бінарний формат. Тому що це найпростіший спосіб її втілення . Немає людського розуму описувати карти текстуально. Зазвичай редагується через редактори карт / рівнів / частинок.
• Гравці, предмети, вороги, навички та квести - це статистика, яка впливає на ігровий баланс . Зазвичай вони вимагають багато і багато введення та налаштування. Мені подобається це робити, додаючи його у 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.

EDIT: MsgPack ( http://msgpack.org/ ) також схожий на BSON і, схоже, набирає більшої тяги.

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

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