データの保存方法の選択方法

男に魚を与えて、あなたは一日彼を養います。男に魚を教えると、あなたは一生彼を養います。 - 中国のことわざ

実際のプロジェクトにどのようなデータストレージを使用すべきかを尋ねることができますが、釣りを学びたいので、新しいプロジェクトを始めるたびに魚を求める必要はありません。

そのため、ゲーム以外のプロジェクトにデータを保存するためにXMLファイルとリレーショナルデータベースの2つの方法を使用するまでは。NoSQLのような他の種類のデータベースもあることを知っています。しかし、私が利用できる選択肢が他にあるかどうか、または最初に任意に選択する以外にどのように選択するかはわかりません。

質問は次のとおりです。ゲームプロジェクトのデータストレージの種類はどのように選択すればよいですか。

そして、私は選択するときに次の基準に興味があります：

• プロジェクトのサイズ。
• ゲームが対象とするプラットフォーム、および使用される開発プラットフォーム。
• データ構造の複雑さ。
• 多くのプロジェクト間でデータの移植性を追加しました。
• 追加 2異なるプロジェクト間でのデータの無制限の使用。（つまり、ユーザーデータ）
• データにアクセスする頻度を追加しました
• 同じアプリケーションに複数のタイプのデータを追加
• 追加2複数のデータストレージを備えた構成。
• 何を使用するかを決定する際に、あなたが考える他のポイントは興味深いものです。

編集私は知っていますXML / JSON / Textまたはデータベースを使用してゲームコンテンツを保存する方が良いでしょうか？、しかし、それは私のポイントを正確に扱っていないと思った。今私が間違っていれば、私は私の方法でエラーを喜んで表示されます。

EDIT2関連性があると思われるいくつかのポイントを追加しました。さらに、フラットファイルストレージとリレーショナルデータベースは別として、他にどのようなオプションが利用可能かを聞きたいと思います。たとえば、非リレーショナルデータベースはどうでしょうか。前述のその他のオプションよりもこのようなデータベースを使用することが適切な場合は？

膨大な数のジャンルがあるため、あなたの質問は本当に広範ですが、ここにプロのソフトウェア開発者の視点があります。

使用するデータ永続化メカニズムを決定するために使用する基準のリストを提供しました。それらは：

• プロジェクトのサイズ。
• ゲームがターゲットとするプラットフォーム。
• データ構造の複雑さ。
• 多くのプロジェクト間でのデータの移植性。
• データにアクセスする頻度
• 同じアプリケーションの複数のタイプのデータ
• 何を使用するかを決定する際に、あなたが考える他のポイントは興味深いものです。

まず、どのオプションを使用できるかを確立する必要があります。言語やテクノロジを指定しなかったため、正確に言うのは難しいですが、おそらくXMLとリレーショナルデータベースストレージのどちらを使用するかを決めようとしているでしょう。

重要な違いは、XMLは実際にはシリアル化技術ほどストレージメカニズムではないということです。これは、ゲームのメモリ内構造を表現する方法です。それを考えると、あなたは本当にフラットファイル対リレーショナルデータベースストレージについて話している。これらは唯一のオプションではありませんが、最も一般的であるため、使用します。

フラットファイルの場合：

• XML
• JSON
• YAML
• XAML
• プレーンテキスト

データベースの場合：

• SQLサーバー
• MySQL
• DB2
• オラクル
• もっともっと

編集：あなたは、ファイルとリレーショナルデータベース以外の他のタイプのメカニズムについて尋ねました。私が定期的に使用しているのを見た唯一の他の注目すべきタイプのデータベースは、本質的にキーバリューベースの「バークレースタイル」データベースです。これらは、Bツリーを使用してデータを構造化する傾向があるため、検索が高速になります。これらは、必要なものを正確に把握している構成/設定の検索に最適です（たとえば、 "レベル1"のすべてのテレメトリデータを提供します）。

これですべての基本事項が完了したので、いくつかの基準を見てみましょう。

プロジェクトのサイズ。

意見の相違はあるかもしれませんが、プロジェクトのサイズが必ずしもデータ永続化メカニズムに大きな影響を与えるとは限りません。必要なメカニズムからのデータを保存/ロードする関数の再利用可能なライブラリを構築する必要があります。必要に応じて永続化メカニズムを簡単に変更できるように、抽象化レイヤーを実装することもお勧めします（アダプターパターンを確認してください）。

とはいえ、小規模なプロジェクトでは、ファイルシステムでXMLを使用することで十分に機能する可能性がありますが、プレーヤーがデータを自由に変更できないように、セキュリティの問題（暗号化など）に対処する必要があります。

ゲームがターゲットとするプラットフォーム。

プラットフォームも大きな問題にはなりません。ターゲットプラットフォームよりも開発プラットフォームの方が重要です。その理由は、一部の言語では、特定のタイプのマークアップまたはデータベースを他の標準のボックスよりも適切に処理できるためです。これは、ほとんどの言語で上記のいずれも使用できなかったということではありませんが、使用可能なサポートされているツールを使用することが最適な場合があります。どのプラットフォームでもフラットファイルとXMLの解析がサポートされますが、モバイルプラットフォームでは、可能であればバイナリシリアル化を検討するか、少なくともXMLをストレージ用に最適化することをお勧めします。

データ構造の複雑さ。

これは一種のトリッキーなものです。リレーショナルデータベースは、エンティティとその関係を保存するだけの場合に最適です。ファイルシステム上のファイルを使用するよりも、リレーショナルストレージリポジトリを使用して構造を強化する能力が優れています。エンティティ間の関係のタイプと、それらを変更する頻度、または関連するエンティティを見つける頻度を考慮してください。非常に複雑な構造の場合は、データベースルートを使用することをお勧めします。

多くのプロジェクト間でのデータの移植性。

移植性に関しては、データベースはファイルよりも当然重いという事実を考慮する必要があります。インストールと設定のオーバーヘッドがあり、プラットフォームごとに異なるデータベースを使用できます。SQLiteはこれを回避するのに非常に良い方法です。ただし、移植性に関しては、XMLのようなファイルベースのソリューションを使用する方が簡単です。

編集：あなたのコメントの一つであなたが移植性について言及した他のいくつかの懸念があります。最終的には、データを製品やファイルの種類に強く結びつけたくありません。コンパイルまたはロード時にデータベース/ファイルシステムに簡単に解析および保存できる何らかの抽象形式（タブ区切りファイル、XMLなど）でストックデータ（レベル、敵など）を保存できる場合、最終的に最適です。時間。これは、気まぐれにストレージメカニズムを交換し、解析部分を書き換えることができることを意味します。

データにアクセスする頻度

何らかのキャッシュメカニズムがない限り、大量のデータアクセスは大量のI / Oを意味します。データベースは構造をメモリに保持し、データの操作と取得に最適です。データを常に永続化している場合は、データベースを使い続けることをお勧めします。

同じアプリケーションの複数のタイプのデータ

ボリュームは確かに考慮事項ですが、数千または数百万のオブジェクトを永続化することを話さない限り、ファイルシステムはソリューションとして受け入れられます。

ゲームの種類

構築するゲームのタイプは、選択するプラットフォームに大きな影響を与える可能性があります。ええ、ほとんどのクライアント専用のシングルプレイヤーゲームの場合、圧縮または暗号化されたファイルシステムベースのソリューションを使用しても問題ありません。ただし、オンラインコンポーネントを使用したゲームの場合、それはおかしいでしょう。データベースのルートに移動して、頭痛の種を省いてください。バックエンドクラスタを使用して、サーバーにすべてのデータを管理させます。

このフィードバックの一部が役に立てば幸いです。それは決して完全に包括的なものではなく、決定を下すのは最終的にあなた次第ですが、私の解説はあなたに考えるべきいくつかのことを与えるべきです。

編集：ハイブリッドなアプローチをとることが非常に理にかなっている場合があります。たとえば、MMORPGを開発しているとします。クライアント側では、他のプレーヤーに関するキャッシュデータを非リレーショナルデータベースに格納できます（前述のとおり）。サーバー側では、すべてのゲームデータをリレーショナルデータベースに保存して永続化します。そして、クライアント側では、アクセスしやすくするために、おそらくログデータや構成データなどをXML /フラットファイルに保存します。

別のポスターは、データベースに本番用のデータを保存している場合でも、代わりに開発用にフラットファイルを使用できる方法があると便利な場合があることを述べています...ミックスから別の製品を削除する方が簡単です。

最近、リレーショナルデータベースへの追加の厳格さ/難しさに制約されていることに気付きました。ゲーム、状態、および柔軟性に非常に適していると思われるため、ドキュメントベースのデータベース（couchdbなど）を探索したいと思います。しかし、小さなプロジェクトに複数のデータベースタイプを設定することは実際的ではありません。その結果、データベースの特定のフィールドでバイナリblobフィールドを使用するのと同様のハックを設定しました。

私がやっていることは、データベースでjsonエンコードされたデータを使用し、データをjsonに変換し、必要に応じてバックアウトするラッパーです。したがって、データベースでは基本的なキャラクタープロファイルは次のようになります。

{"char_id":24,"char_name":"tchalvak","level":43,"profile":"Some profile here."}

Jsonはまだデータベースでうまく読み込めるので、SQLでむき出しの作業をしていて、時にはデータベースに直接アクセスする場合、必要に応じて手動で変更できます。

さて、それはすべてハックであり、コピーすることはお勧めしませんが、全体的なポイントは次のとおり です。1つのシステムだけに依存しないでください。 リレーショナルデータベースを使用して、システムを操作します。または、2つの異なるタイプのデータストレージシステム（フラットファイルとリレーショナルデータベースなど）を使用して、両方のメリットを最大限に活用できるようにします。人々が何を提案したとしても、どのシステムを使用するにしても、他のアプローチがより適切に機能する状況を見つけ出すので、代替手段を追加して、それがあなたを導く場所を確認する準備をしてください。

RTS遺伝子では、ゲームデータはファイルに保存されています。

ユニットと属性はINIファイルまたはXMLファイルまたはその他のテキストベースの形式で保存され、モデルはバイナリ形式またはテキストベースの形式、テクスチャとサウンド、その他のメディアが主流形式で混在しています。時には、粗雑な暗号化を備えたコンテナに入っていることがあります-Westwoodのミックスフォーマットが思い浮かびます。しかし、これはほとんど難読化です-それらの中を見ると、それらは扱いやすい形式の単なる普通のファイルです。

オンラインプレイの出現により、インストール後にゲームデータがインターネット経由でプロビジョニングされることがますます一般的になっていますが、多くの場合、これはまだファイルシステムに保存されています。

データストレージの1つの方法を使用する理由

ほとんどの場合、世界にリリースするゲームは、開発中にゲームが必要とするのと同じデータストレージ機能を必要としません。

ここにいくつかのリリース/開発要件の比較があります-

Requirement      |  Release  |  Development  |  QA
==================================================
Multi user       |    No     |      Yes      |  No
Writable         |    No     |      Yes      |  No
Revision Control |    No     |      Yes      | Yes (but only reading)
Compact          |   Yes     |       No      |  No
Fast             |   Yes     |       No      |  No

理想的には、データロードモジュールへのインターフェイスを定義し、それぞれが特定のニーズに合わせた複数のバージョンを作成します。

私が何年も前に取り組んだプロジェクトの1つで、CDからのレベルデータのロードに非常に長い時間がかかっていました（HDからのデータも素晴らしいものではありませんでした）。そこで、次のことを思いつきました。レベルデータをロードする方法は3つありました。

1. 通常のロード-アセットが変更された開発時
2. プレリリース-通常のデータを高速読み込みデータに変換する方法
3. リリース-高速データのみ（編集不可）

これにより、ロード時間が数分から数秒に短縮されました。