アセットを保存するときにバージョンの変更をどのように処理できますか？

私はしばらくRPGに取り組んでおり、2つの異なるシリアル化手法を使用しています。

• 敵、武器、アイテムはXMLとして保存されます。
• マップとイベントは「制御されたバイナリ」として保存されます（すべてのクラスが保存/ロードメソッドを取得し、保存/ロードするものを決定します）。

しかし、私はマップとイベントの選択に疑問を持ち始めました。私の懸念：

• 私はマップエディタを作成しましたが、ファイルを開くだけでは小さなことを変更できません。
• 混乱が大幅に変化します。変数をクラスに追加したいとします。すべてのマップを再度ロード/保存しないと、後で壊れます。

最初の懸念は、私のテクニックを変更せずに回避することは困難です。JSONへの変更を考えましたが、大変な作業です。また、[DataContract]属性と[DataMember]属性がいたるところにあると、見苦しく見えます。

それは私の第二の懸念を私に残し、私はそれをどのように処理できるのでしょうか？すべてのマップをループし、新しい変数でそれらを再保存する小さなプログラムを作成しますか？私は今、いくつかのマップを取得し始めており、それでも手動で取得しています。多くの追加作業が発生するため、変更を加えたいときは毎回2度考えさせられます。

バージョン管理の問題を処理する方法はたくさんあります。バージョンごとに1つのロード機能を使用してそれを行うことができます。（通常は属性を介して）アセット構造の経時的な変換を記述してプロセスの自動化を試みることができます。ロード/保存機能内でバージョン固有のチェックを実行できます。 。

私は「変更を説明する」アプローチが好きですが、属性を介してそれを実行しようとすると、ぎこちなく速くなることがわかりました。代わりに関数を使用します。バージョンのNデータをN + 1適切なすべてのバージョンのバージョンのデータに変換する関数を実装します。ロード時に、最新バージョンに対してバージョンを確認し、最新でない場合は、適切なすべてのバージョン管理関数を使用してデータを実行します。常に最新バージョンを保存してください。

これは、データがまだ実行時のキーと値の形式であるときに変換を行う場合に最適です。つまり、独自のバイナリ形式を持っている場合、JSONまたはXMLの基になるキーと値の形式を使用できないので、「プロパティのランタイムバッグ」アプローチであるデータの表現を実装することになるでしょう。これを行わない場合は、また醜い取得され、周りの古いクラス定義を維持する必要があるかもしれません。アセットをこのプロパティの不良フォーマットに含めることができることは、ゲームエディターの開発にも非常に役立ちます。

開発中にデータを反復処理すると、自然に最新バージョンにバブルアップし、最終的に古いバージョン管理機能を削除できます。これは、ギルドウォーズ2でアートアセット（マップなど）をバージョン管理するために使用した高レベルのアプローチとほぼ同じです。

さて、以上がすべてのことですが、アセットのテキストシリアル化とバイナリシリアル化の両方をサポートすると便利だと思います。開発中は、すべてのデータをXMLまたはJSONに基づいた人が読める形式にしてください。データの編集に関するそのような複雑なツールを構築する必要がないため、これにより反復能力が大幅に向上します。手で簡単に素早く調整できるように戻すことができます。

2つ目は、ゲームの出荷にバイナリ形式が必要な場合でも（ファイルサイズやファイルのIO時間を改善できるため、これは正当な目的です）、バージョン管理を処理するシリアル化APIとシリアル化解除APIを設計します。ある時点でアップデートまたはバグ修正を出荷したい場合があるため、バージョン管理は出荷のコンテキストでは依然として役立ちます。.NETシリアライゼーションとBoostのシリアライゼーションのバージョン管理機能を説明したドキュメントがいくつかあります。テキスト形式とバイナリ形式の両方をサポートする場合は、それらを時々テストするようにしてください（または、自動テストを作成して、それをさらに改善します）。

XMLやJSONなどの属性と値のペアでマークアップ言語を使用します。

パーサーは、理解できない属性を無視するか、見つからない属性のデフォルトを使用することができるため、後方互換性と前方互換性が非常に簡単になります。また、フォーマットは人間が読める形式なので、テキストエディターで簡単に編集できます。

XMLやJSONのような確立された言語を使用する場合、多くのスクリプト言語がそれをサポートしていることにも気づくでしょう。そのため、多数のファイルを編集するスクリプトを記述する必要がある場合は、はるかに簡単です。

これらの言語のほとんどの欠点は、非常に冗長であることです。つまり、結果のファイルは、最適化されたバイナリ形式の場合よりもはるかに大きくなります。現在、ほとんどの場合、ファイルサイズはそれほど重要ではありません。しかし、重要な場合は、zipなどのストックアルゴリズムでファイルを圧縮することにより、ファイルサイズを大幅に削減できる場合があります。

マークアップ言語では、ドキュメント全体がハードドライブから読み込まれて解析されない限り、ランダムアクセスが許可されないことがよくあります。しかし実際には、ハードドライブはシーケンシャルリードで最速であるため、これはそれほど重要ではありません。同じファイルの異なる部分をランダムに複数回シークすると、必要以上に多くのデータを読み取る場合でも、ファイルを一度に読み取るよりもはるかに遅くなることがよくあります。

protobufを使用できます。https://code.google.com/p/protobuf/ 下位互換性を維持しながら簡単に拡張できるjson / xmlの利点に加えて、バイナリであるという利点があります。ワークフローは、protobuf言語でデータ形式の説明を作成してから、シリアル化と逆シリアル化のソースコードを生成することです。ソースは複数の言語用に生成できます。また、読み取り/書き込みで暗黙的に指定が行われるjsonとは対照的に、シリアル化されたデータの明確な指定があることも大きな利点です。