ゲームデータを保存するのに適したファイル形式は何ですか？[閉まっている]

いくつかのカスタムゲームデータを保存する必要があります。地図、プレーヤーなど

それらすべてに「サブオブジェクト」があります。たとえば、マップとマップにはタイルの「配列」があります。すなわち、階層データ。うまくいけばバイナリはありません。

これらに適したフォーマットは何でしょうか？

これまで私は考えてきました：

シリアル化：これは高速で簡単ですが、基になるクラスを変更すると壊れる傾向があります:(

XML：これを解析するのは本当に嫌いです。私のテストケースは100行以上のコードであり、非常に単純な形式でさえ、「忙しい仕事」のように思えました。

INI：階層データにとっては本当に不器用です。

Protobuf：使用したことはありませんが、クラスを変更した場合は、手作業で何度もいじり、中断する必要があることを読んでください。

別のオプション？だから私はここにいる！

編集：これはJava btwです。

編集2：

「Controlled Binary Serialization」に決めました（以下を参照）。

長所：

• これは速い

• （ディスク上）小さく、読み取り/書き込み中に簡単に圧縮/解凍できます。

• ゲームやツールセットからの読み取り/書き込みは非常に簡単です。

• オブジェクトに含める/除外するものを決定できます。

• オブジェクト/データはネストできます。

短所：

• 手動で編集することはできません（XML、YAMLなど）

• スクリプトで簡単に読み取り/変更できない

• デフォルトでは、Javaシリアル化は他の実装に比べてかなり遅い/肥大化していますが、安定して動作します

階層データを表示するには、YAML またはJSONが適切なオプションです。XMLよりもはるかに単純で解析しやすいです。

もう1つのオプションは、「制御された」バイナリシリアル化プロセスです。すべてのオブジェクトは、制御された方法で状態を書き出します。つまり、

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を使用することをお勧めします。これは簡単ですが、仕事はします。

ファイル形式の選択は、現在のツールセットと作成しようとしているゲームに大きく依存します。とは言うものの...

ツールセットは、ゲームファイル形式を決定する際の最も重要な要素の1つです。バイナリ形式を作成する場合、ゲームデータを入力するツールがあることを常に確認する必要があります。これは、16進エディタのように単純な場合もあれば、「Unreal」エディタのように複雑な場合もあります。

XML、YAML、またはその他の言語ファイルの主な利点は、テキストエディターで簡単に編集できることです。また、既存の標準を使用することで、間違いを起こさないことが保証されます。しかし、1000個のファイルがある場合、これは非常に退屈で、次のポイントに進みます。

ゲーム。どんなゲームを作っていますか？なぜこれがファイル形式に影響すると言うのですか？なぜなら、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の外部で多くのツールがサポートされているように見えることです。

編集：MsgPack（http://msgpack.org/）もBSONに似ており、さらに注目を集めているようです。

カスタムバイナリデータ形式はどうなりましたか？生のシリアライゼーションが怖い場合は、必要に応じてフィールドに書き込み、それらを読み戻す独自のシステムを作成します。xmlの必要はありません。これは、形式が提供する透過性を必要としない状況では実際に非常にかさばり、複雑です。明確に指定されたファイル形式を定義し、それに固執するだけで、各レコードのデータセットをヌル値でパディングすることでデータスペースを拡張する余地を残します（たとえば、100バイトのレコードがあり、今後の使用のために150にパディングします）。
バージョン番号とチェックサムを追加して、どのフィールドに入力する必要があるかを確認し、妥当性の健全性チェックを行うことができます。これで準備完了です。

特定のデータにXMLまたはその他の形式とBase64挿入を混在させることができます。また、読みやすいフィールドには通常のTEXTを使用できます