すべてのゲームデータを巨大なExcelテーブルに入力しますか？より良い方法はありますか？

MMORPGで、すべてのアイテムの巨大なテーブル、すべてのスキルの別のテーブル、さらにはすべてのMobの別のテーブルで作業することを好むゲームデザイナーの数を本当に知りたいです。また、これらのテーブルは数千のレコードで数百MBに拡大する可能性がありますが、ほとんどのレコードはテーブルのいくつかのフィールドのみを使用します。
一部のゲームデザイナーがこの方法で作業していることを知っています。より良い方法はありますか？

ここでは答えたくありませんでしたが、別の答え/コメントを見たとき、気が変わりました。SQLはこれの非常に良い解決策ではありません。SQLはテーブルを定義し、大量のデータをそのテーブルに挿入します。これはそうではありません。ゲームデザインを作成/テストする場合、大規模なシステムのバランスが取れているかどうかを確認する必要があります。つまり、相互に影響を与える多くのテーブルがあります。実際にはSQLに適したものはありません。あるいは、必要のないプログラミングを行う必要があるため、扱いは簡単ではありません。そして、ゲームデザイナーはそれを知る必要はありません。

ゲームプログラマー/開発者は、Excelとその用途を軽視することができますが、特にゲームデザイナーが適切に使用でき、ドキュメントが適切に作成されている場合は、このケースには非常に優れたツールです。

他のツールはお勧めできませんが、Excelを使用するプロのゲームデザイナーも知っていると言えます。だから私はそれが一般的なツールだと思います。

特にデザイナーにとって、スプレッドシートはまともな開発ツールになることがあるというほとんどの回答者に同意します。

このアプローチをさらに進めることに関心がある場合、Resolver Oneスプレッドシートプログラムはスクリプトにpythonを使用するため、複雑なモデリングとゲームに適したデータ形式へのエクスポートの両方を行うデザイナー向けのスプレッドシートを簡単に設定できます。ExcelのVBScriptよりも操作がはるかに簡単です。

Excelは優れたソリューションです。どうすればいいのかと思っていました。しかし、考えてみると、Excel は非常に人気のあるツールであり、この義務には十分適しているため、この方法はお勧めしません。さらに、@ notabeneが示唆するように、実際のデータベースには、実際には必要のない多くのオーバーヘッドが生じます。いくつかのオプションが表示されますが、そのうちの1つはExcelを使用するのと似ています。

• Open Office Calc：無料。Calc用のMySqlコネクターのダウンロード（私が信じているオープンソース）もあります。
• シリアル化されたデータ：XMLまたはバイナリ（暗号化）

...どちらにせよ、無料で、完全に制御できます。

個人的には、シリアル化および暗号化されたバイナリデータを使用する傾向があります。2つの理由：

• ゲームデータは簡単に改ざんできません
• 私は、DataTableのではなく、データセットのXMLシリアル化してすなわち作業することができ、私は選択肢を持っています。

専用の真のゲーム指向のデータライブラリが必要ですか？多分...誰かがそのようなライブラリがすでに存在していることを知らない限り。

OPの質問の要点として、各ページの csvファイルを、データベース内のテーブルのような単一のデータテーブルとして見てください。各ページファイルには、関連データが含まれている必要があります。

• スキル、または
• ギア、または
• NPC統計

これにより、データコンテンツの増加、ゲームコンテンツの拡大など、非常に重要な高度な組織を維持することができます。

編集
実際に.ODS（OpenOffice Calcファイル）の使用を試み、アプリケーションから接続した後は、OOサイトへの最初の投稿が暗示するため、実際には不可能です。実装に関するcodezを具体的に示すものは何も見つかりませんでした。

また、ゲームの開発中はExcelファイルを使用しても問題ないため、データベースのオーバーヘッドなしでデータを調整できます。ただし、これが重要であり、これを計画している場合は、Microsoft Excel Interop COMを参照できるようにMS Officeをインストールする必要があります。これは最初は有益かもしれませんが、アプリケーションをAlpha、Beta、またはRCの準備ができるようにコードの束を削除または変更したくありません。非常に単純化されたライブラリーは、私が有用だと考えるよりも多くの努力を必要とします。

初期のデータストレージには.CSVファイルを使用します。いくつかの欠点がありますが、全体的に、これははるかに良いオプションだと思います。すべてが私のライブラリに含まれています。.Netには、これらのテキストファイルを読み取るための非常に便利なクラスがあります。また、.CSVファイルとしてデータを簡単に操作できます。また、開発の後半の段階では、データファイルをXMLにシリアル化し、後で暗号化されたバイナリをシリアル化するだけで済みます。

データの性質により、あまりにも多くのフープを飛び越えることなく、スプレッドシートにデータを保存できる限り、特に開発作業では非常に優れたフォーマットになります。最後に、あなたが使用するため、他のフォーマットでそれを保存したいかもしれませんが、スプレッドシートは、あなたにすることができ、非常に強力なエディタ与えVERYあなたが何かを処理する方法を変更することを決定した場合には素敵なの！

Excelを使用している場合は、ASAPユーティリティのコピーを入手してください。スプレッドシートがさらに優れたエディターになります。

まあ、私にとって、speartesheetプログラムはそのようなものを正しく効果的に処理できないものです。RDBは、実際には、巨大なデータとテーブルを処理するために設計されました。現代のRDBは「巨大な」種類のものを処理するように設計されており、非常にうまくやっています。

ポイントは、RDBの最適な出力を得るには、データベースを正しい方法で設計する必要があるということです。データスキーマが不十分だったり、プロジェクトのすべてのデータをカバーしていなかったりすると、結果、パフォーマンス、出力が非常に悪くなります。

RDBのアイデアは、巨大なテーブルを小さなテーブルに分割して、パフォーマンスと可読性を向上させることです。非常に巨大なテーブル（属性に関してもレコードに関しても）または多くの再パーティションがあり、それらのほとんどを使用しない場合、DBの設計にいくつかのエラーがあります。

Huang F. Leiさんの質問で、MMORPGデータベースの設計を依頼された場合、1つのテーブルにすべてのスキルを追加し、1つのテーブルにすべてのMobを追加することはしません。スキルをクラスと使用法に応じてマルチテーブルに分割します。各スキルタイプには、独自のテーブルまたはテーブルがあります。モブについては、タイプに応じて、または異なる世界での位置に応じて、モブを分けます。等々。

このようにして、テーブルサイズを縮小し、データの追跡を容易にし、DBのパフォーマンスを向上させることができます。

一方、Excelでは、すべてのデータが1か所に「詰め込まれ」ます。そして、1つのデータを見つけることはほとんど不可能です。繰り返しのデータがある場合はそうです。さらに、データのサイズが大きくなると、ファイルのオープン時間が長くなります。

結局のところ、Excelは（私の意見では）、膨大な関連データを処理するには非常に貧弱な方法です。