XML / JSON / Textまたはデータベースを使用してゲームコンテンツを保存する方が良いでしょうか？

コンポーネントベースのゲームを実装する方法を検討しています。それはホットなものであるように思われ、このような柔軟なデザインのアイデアが気に入っています。このような設計の機能の1つは、データを介してゲームに新しいものを追加できることです。多くの場合、XMLなどのテキストファイルを介してコンテンツをロードすることで表示されます。これには、人間が読むことができ、テキストエディタで簡単に編集できるという利点があります。欠点として、テキストの処理が遅くなる可能性があり、データファイルの大規模なコレクションを管理する必要があります。JSONや設定ファイルのような類似のテキストベースの形式には、同様の利点があります。

反対側には、SQLiteやTokyo Cabinetなどの小さくてポータブルなデータベースがあります。人間が直接読むことはできませんが、これらのファイルは簡単にインターフェイスでき、ゲームコンテンツのデザインには何らかの編集ツールが適していると思います。DBを使用すると、構成情報を一貫して保存し、簡単に取得できます。ゲームを保存するために、データをDBにシリアル化することもできます。

パフォーマンスに関しては、一般的にXMLは小さいファイルの方が速いと思いますが、データベースは大量のデータに適しています。実際のゲームには、ゲームオブジェクトがたくさんあると思います。

質問：望ましいアプローチはどれですか？私はDBに傾いていますが、テキストファイルに隠れた落とし穴や本当に強い利点があるかどうかを知りたいです。または、これら以外の選択肢がある場合（バイナリ形式にシリアル化すると思いますか？）

小規模な個人用ゲームではあまり出てこないかもしれませんが、ゲームデータに関して難しい問題の1つは、マルチユーザーの編集/バージョン管理です。ビルドプロセスによって少数のバイナリBLOBに焼き付けられる小さなテキストファイルを多数使用します。これにより、デザイナーはワークフローに非常に柔軟に対応できるため、デザイナーの作業が楽になります。CCPは反例として、すべての設計者が接続する中央編集データベースを使用します。これにより、ビルド手順が不要になります（または、少なくともはるかに簡単になります）が、すべてのバージョン管理機能とワークフロー機能を自分で実装する必要があるため、他のツールよりも簡単になります。どちらの場合でもパフォーマンスに対処できますが、実際の質問は、デザイナーワークフローに何を望み、どのようにそこに到達できるのでしょうか？

JSONは非常に軽量で理解しやすいです。ゲームに適していると思います。cJSONは本当に素晴らしいです。また、SQLliteと同じ方法でソースに組み込まれます。

XMLファイルは、ユーザーが考えるよりも編集するのが難しいです。そのルートに行けば、一般的な落とし穴を避けるのに役立つエディタを作成することができます。

ここでのパーティーに遅刻しましたが、私はこれを研究するために多くの時間を費やしました。

まず、以下を使用しない理由：

XML：非常に冗長です。大量の冗長性。フィールド名を繰り返しますか？キモい

JSON： JSONはUIレイアウトには最適ですが、データベースには最適だと思います。XML、冗長性、および深いネストと同じ問題が発生します。キモい。

SQL：設定の頭痛の種を管理する場合、これは素晴らしいオプションです。SQLデータベースにゲームデータをオンラインで保存するモバイルゲームを作成しました。テーブル形式は素晴らしいです。問題は、データベースをオンラインから取得する必要があり、その設定が面倒になる可能性があることでした。ただし、SQLは適切なソリューションです。Unityはこれをネイティブにサポートしておらず、私が試したプラグインには大きな問題がありました（バージョン管理で動作させようとするときは特に）。

最後に、私が使用することを選択したソリューションを次に示します（そして、私はそれを気に入っています）。

CSV：シンプル。テーブル形式を使用できます。更新する必要がある場合は、簡単に参照できます。すべての武器の表、すべての属性の列、および各タイプの武器の行を作成できます。

Microsoft Excelを使用できますが、保存する必要があるたびにこれらの愚かな警告を吐き出します。マクロを使用してそれをオーバーライドできますが、トラブルを避けてLibreOfficeを入手してください。無料で、CSV編集をサポートし、ファイルを開くと、列幅が名前に一致するようにロードされます（Excelはこれを行わず、私を夢中にさせました）。

次に、CSVファイルをゲームに解析するだけです。私はUnityを使用しているので、やらなければならないのは、この気の利いたC＃CSVパーサーを使用することだけです：

CSVパーサーの例

CSVファイルをゲーム内のデータオブジェクトに変換すると、準備完了です。Unityを使用すると、これらをScriptableObjectsに変換できます。だから私のワークフローは：CSVを更新-> CSVをスクリプト化可能なオブジェクトに解析->ゲームにScriptableObjectsのデータを使用

これに対する答えは、ゲームに使用している言語によって異なります。

C ++を使用している場合は、既存のXMLライブラリ（TinyXmlやeXpatなど）のいずれかを使用することをお勧めします。

一方、PHPを使用している場合は、MySQLやSQLiteなどのデータベースサーバーを非常に簡単に使用できます。（このルートに進むと、データベースサーバーが別のプロセスとして実行され、MySQLなどのより大きなデータベースアプリケーションが実行中に大量のRAMを消費する可能性があるため、より多くのリソースが必要になることに注意してください。）

JSONが勢いを増しており、アプリケーションが複数の言語を使用して記述されている場合、確かに最良の選択です。

要するに、それはあなたの言語で簡単に使えるものに依存します。

XMLの領域にとどまりたい場合は、バイナリXMLを使用してロードパフォーマンスを向上させることができます。

たとえば、Fast Infosetはバイナリxmlの実装です

Fast InfosetはXMLのgzipと考えることができますが、FIはドキュメントサイズと処理パフォーマンスの両方を最適化することを目指していますが、gzipはサイズのみを最適化します。元のフォーマットは失われますが、XMLからFIへの変換およびXMLへの変換で情報が失われることはありません。

私は何年もデータベースを設計し、多くのゲームのアイデアをいじりました。現時点で私の個人的なお気に入りは、構成のための何らかのテキストベースの人間が読める形式ですが、これらの「遅いスクリプト」をより実行可能なものに解析します。JAVAや.NETがランタイムバイトコードにコンパイルされるのとよく似ています。

同じ考えがここにあります。コンポーネントの「ソース」バージョンがあり、プリコンパイラ/パーサーがこれらを実行します。それらがあまりにも多くのメモリを使用する場合は、何らかの高速なSQLデータベースに配置するか、バイナリファイルとして保存できます。しかし、私のポイントは、メモリまたはSQLデータベースをワークスペース/キャッシュとして使用し、スクリプトを何度も解析する必要がないようにすることです。コンパイラを作成し、解析したファイルを「source-lib」に移動すると、プリコンパイラもバージョン管理を実行できます（ロールバックのために以前のファイルを保持します）。

「無制限のハードドライブ容量」の場合は、DropboxやAmazon S3などにサインアップして同期します。

だから私のための計画は現在です：

1. config / scripts / xml（人間が読める形式）をテキストファイルとして（ソースコードと同じように）
2. 新しいスクリプトを実行し、ルールに従っていることを確認するパーサー/バリデーター
3. バイナリまたはSQL行を元のファイルから作成するコンパイラー。これにより、これらのファイルの取得が高速+実行が高速になります。

安定性については、現在、データベースを「コロケーションホスト」として構築し、複数の場所間で自動同期しているため、1つの場所でネットワーク/ハードウェア障害が発生した場合、他のサイトでも同じトラフィック/ゲーム状態。

couchdbを使用する場合、基本的にすべてをJSON構造として保存します。Couchdbは、（複数の）ユーザーのデータをほぼ無痛で複製します。

手順を見つけることができます Unity WikiでPHP、MySQL、C＃/ JavaScriptを使用しその目的には適しています。

3つのステップで構成されています

1. 空のMySQLデータベースとテーブルを作成します。
2. PHPサーバー側のスクリプトを作成します（これにより、MySQLテーブルに接続し、Unityスクリプトからデータを受信し（ステップ3）、データベースを照会します（データの挿入または選択のいずれかです））
3. Unityコントローラースクリプトを作成します（手順2で作成したPHPスクリプトに接続します）