タグ付けされた質問 「databases」

人々は何らかの理由で独自のデータベースを作成しますか？

62 mmo  databases 

ほとんどのゲームはダイアログテキストをファイルに保存しますが、実際にコンテンツ（マップ、選択肢、プレーヤーコマンド、ストーリーテキスト）をゲームコードにプログラムするテキストベースのゲームもいくつか見ました。 いくつかの理由が考えられますが、テキストゲームでさえプログラム外のファイルにすべてを保持する主な理由は何ですか？ 実装の詳細は、一般的なXML形式のようなコンテンツを保持し、解析し、XMLファイルから作成された変数に基づいてマップを表示/表示し、XMLファイルを完全に放棄することでほとんど異なりません。これらは両方とも、画面に出力される文字列になります。違いは単なる表記ではありませんか？ ゲームの中には、コード内にグラフィック（ASCIIアート？）を保持するものさえあります。私はこれが正しくないことを知っており、それが悪い理由をいくつか推測できますが、主な理由もわかりません。 ほとんどのコンテンツをプログラム外に置くことは非常に人気があります。Dwarf Fortressでさえ実際のASCII文字を使用しませんが、メモリに読み込まれたASCII文字の画像を使用します。 私が主に尋ねるのは、XMLファイルを作成、解析、および操作するのが少しPITAであるためです。ご存知のように...すべてのユニークなダンジョン（コンテンツ）を独自のクラスにするという怠zyな選択肢と比較してください。

41 architecture  databases  text-based  content-generation  dialog-tree 

コンポーネントベースのゲームを実装する方法を検討しています。それはホットなものであるように思われ、このような柔軟なデザインのアイデアが気に入っています。このような設計の機能の1つは、データを介してゲームに新しいものを追加できることです。多くの場合、XMLなどのテキストファイルを介してコンテンツをロードすることで表示されます。これには、人間が読むことができ、テキストエディタで簡単に編集できるという利点があります。欠点として、テキストの処理が遅くなる可能性があり、データファイルの大規模なコレクションを管理する必要があります。JSONや設定ファイルのような類似のテキストベースの形式には、同様の利点があります。 反対側には、SQLiteやTokyo Cabinetなどの小さくてポータブルなデータベースがあります。人間が直接読むことはできませんが、これらのファイルは簡単にインターフェイスでき、ゲームコンテンツのデザインには何らかの編集ツールが適していると思います。DBを使用すると、構成情報を一貫して保存し、簡単に取得できます。ゲームを保存するために、データをDBにシリアル化することもできます。 パフォーマンスに関しては、一般的にXMLは小さいファイルの方が速いと思いますが、データベースは大量のデータに適しています。実際のゲームには、ゲームオブジェクトがたくさんあると思います。 質問：望ましいアプローチはどれですか？私はDBに傾いていますが、テキストファイルに隠れた落とし穴や本当に強い利点があるかどうかを知りたいです。または、これら以外の選択肢がある場合（バイナリ形式にシリアル化すると思いますか？）

29 component-based  databases  xml  data  configuration 

MMORPGSの大部分には、X時間ごとにすべてのキャラクターを保存するWorldsaveシステムがあります。理由はパフォーマンスだと思います。では、切断時にキャラクターを保存するよりもパフォーマンスの面で優れているのはなぜですか？

26 networking  mmo  databases 

男に魚を与えて、あなたは一日彼を養います。男に魚を教えると、あなたは一生彼を養います。 - 中国のことわざ 実際のプロジェクトにどのようなデータストレージを使用すべきかを尋ねることができますが、釣りを学びたいので、新しいプロジェクトを始めるたびに魚を求める必要はありません。 そのため、ゲーム以外のプロジェクトにデータを保存するためにXMLファイルとリレーショナルデータベースの2つの方法を使用するまでは。NoSQLのような他の種類のデータベースもあることを知っています。しかし、私が利用できる選択肢が他にあるかどうか、または最初に任意に選択する以外にどのように選択するかはわかりません。 質問は次のとおりです。ゲームプロジェクトのデータストレージの種類はどのように選択すればよいですか。 そして、私は選択するときに次の基準に興味があります： プロジェクトのサイズ。 ゲームが対象とするプラットフォーム、および使用される開発プラットフォーム。 データ構造の複雑さ。 多くのプロジェクト間でデータの移植性を追加しました。 追加 2異なるプロジェクト間でのデータの無制限の使用。（つまり、ユーザーデータ） データにアクセスする頻度を追加しました 同じアプリケーションに複数のタイプのデータを追加 追加2複数のデータストレージを備えた構成。 何を使用するかを決定する際に、あなたが考える他のポイントは興味深いものです。 編集私は知っていますXML / JSON / Textまたはデータベースを使用してゲームコンテンツを保存する方が良いでしょうか？、しかし、それは私のポイントを正確に扱っていないと思った。今私が間違っていれば、私は私の方法でエラーを喜んで表示されます。 EDIT2関連性があると思われるいくつかのポイントを追加しました。さらに、フラットファイルストレージとリレーショナルデータベースは別として、他にどのようなオプションが利用可能かを聞きたいと思います。たとえば、非リレーショナルデータベースはどうでしょうか。前述のその他のオプションよりもこのようなデータベースを使用することが適切な場合は？

25 databases  data  xml 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 6年前に閉鎖されました。 機会と退屈から、友人と私はウェブベースのゲームを作ることにしました。通常、私はジャンゴでウェブアプリをプログラムするので、これは私が作る最初の「ゲーム」です。 ゲームに同じフレームワークを使用することを選択しましたが、将来の要件とDB関連の問題を予測することができないため、データストレージについては完全にはわかりません。最近、noSQLの動きが勢いを増しているので、その領域について調べたいと思います。 したがって、次の質問があります。 noSQLデータストレージ（MongoDBなどのドキュメントベース）は、Webベースのゲームに適していますか？ MySQLなどの従来のRDBMSを使用して発生する可能性のある問題は何ですか？ ゲームプレイ中またはcronジョブなどの定期的なイベントで、MongoDBを使用するユーザー間でデータの一貫性を保証する方法は？ ゲームの概要：モンスターと戦い、アイテムなどを獲得する典型的なアドベンチャーゲーム。 アイテム、武器、ポーション、マップなど、一部のデータはすべてのプレーヤーで静的です。 プレーヤーに関連付けられたいくつかのデータ：インベントリ、メトリック（統計）、進行状況など プレイヤーは他のプレイヤーの統計と状態を知る必要があるかもしれません スケジュールされたタスクは特定の時間間隔で実行されます

20 architecture  web  python  databases 

ほとんどの企業には、ゲーム内の要素を微調整するためのエディターまたは可変制御システムがありますが、この問題に対するミドルウェアソリューションはありますか？私は過去にこのようなシステムを2つ作成し、5つ、場合によっては6つの異なるシステムで作業しましたが、いずれも市販されていませんでした。 これらの自家製のソリューションにはそれぞれ、値を検索し続けることから、変数の現在の状態を保存できないことまで、さまざまな問題がありました。 成熟した構成/実行時変数制御ライブラリ/アプリはありますか？ 私は通常C ++でコーディングしますが、任天堂のもの以外の現在の開発ハードウェアはすべてサーバーと通信するメカニズムを提供するため、成熟した設定/変数エディターはおそらくソケットベースです（したがって、ある程度言語に依存しません）。コードの実装も非常にシンプルである必要があります（Oskarが共有しているhot_var / TweakableConstantsの記事が好きですが、パッケージではありません）

19 tools  assets  databases  editors 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Game Development Stack Exchangeで話題になるようにします。 4年前に閉鎖されました。 SFMLを使用してC ++で記述された2Dゲームがあります。ファイルまたはデータベースに行/エントリ/行を追加することで、アイテムやエンティティなどのコンテンツを簡単に追加できるように、ゲームを拡張可能にしたいと考えています。 プログラムにコンパイルする必要はないが、実行時に読み書きできるものを探しています。データベースを使用するのが適切な場合

16 c++  sfml  databases 

MMORPGでプレイヤーの位置をどのように追跡しますか？データベースを使用するか、座標をファイルに保存できることを読みました。データベースを使用してみましたが、時間がかかりました。ファイルを使用してプレーヤーの位置を追跡するにはどうすればよいですか？

14 multiplayer  mmo  databases 

データベースを必要とするリアルタイムのマルチプレイヤーゲームに取り組んでいます（プレイヤープロファイル、フレンド、ロック解除、ニュースなどの機能用）。これは標準のPCゲーム（ブラウザベースではない）であり、クライアントサーバーを使用します。建築。私はデータベースを使用するのが初めてであり、過去数日間、白熱した議論につまずいたとき、RDBMS対NoSQLのいくつかの研究を行ってきました。現在、私はNoSQLに傾いていますが、それぞれの使用法（RDBMSとNoSQL）を読んだ後、両方を使用したいと思っています。それは奇妙に思えるかもしれませんが、私の状況を説明させてください。 私のチームは、無制限のmySQLストレージと帯域幅を提供する共有Webホスティングパッケージを持っていますが、唯一の注意点は、一度に25の接続しか開けないことです（共有ホスティングルール）。ニュースの更新を投稿したり、コミュニティ機能（コメント、ファンアートのアップロードなど）をサポートしたりするために、これを自分のWebサイト（間違いなく通常の使用方法）で使用するつもりです。それはすべて大丈夫です-しかし！これは物事が面白くなるところです...私はゲーム内で私のウェブサイトに投稿されたこの同じ情報を表示したいです。これは、Webサイトとゲームの両方でmySQLを使用することを意味します。ニュースの投稿などに加えて、ゲーム内でチャットやサーバーリストなどに使用する予定です。私はその25接続ルールについてほとんど心配しています。 質問＃1を尋ねるに至ります：これは機能しますか？ これに加えて、NoSQLのパフォーマンスとリアルタイムゲームに適していることについて読みました（間違っている可能性があります。私はここに到達するために巨大なRDBMSとNoSQLのフレーム戦争を経験し、おそらく火傷します）。基本的に、すべてのゲームオブジェクトデータにMongoDBを使用します。 繰り返しになりますが、何らかのコンテキストを提供すると役立ちます。240MBのMongoDBパッケージを無料で提供するホスト（MongoLab）を見つけました。アップグレードが必要になるまで使用します。240MBを考えると、約60,000人のプレーヤーを保存できると計算しました（各プレーヤーが約4KBで、保存される可能性のある他のものを無視する場合）。記憶域、および将来的にもっとお金を払わなければならない場合（ゲームが成功する場合）は問題ではありません。私が現在すべてのゲームオブジェクトデータにMongoDBを使用する唯一の理由は、このゲームオブジェクトデータにアクセスする頻度（プレーヤーが殺されたとき、アイテムを拾ったとき、銃を撃ったときなど）のためです。また、単純なスキーマフリードキュメント（ゲームオブジェクトデータのマッピングを容易にする）も好きです。かつて、 私は自分のWebサイトで同じMongoDBを使用して、プレーヤーのプロファイル情報を表示するつもりです（完全な一貫性は気にしません。ゲーム内の更新からの遅延は問題ありません）。2番目の質問、質問2に進みます。これは良いアイデアですか、それとももっと良い方法がありますか？ このゲームは、次のような起動エクスペリエンスを備えています。 クライアントのログイン（MongoDB） クライアントは、チャットルーム（MySQL）のあるゲーム内のホームページにあります。 クライアントはサーバーリストに移動します（MySQL） クライアントはサーバーに接続して再生します サーバーはすべてのプレーヤーの更新を通信します（MongoDB） これは私がそれが機能すると想像した方法です。これはあなたによく見えますか、またはこの計画をどのように改善できるかについての提案がありますか？

12 multiplayer  performance  client-server  databases 

500プレーヤー以上のオープンワールドで、20更新/プレーヤー/秒の速さでデータが変化することを想像してください。前回同様のMMORPGで作業したときはSQLを使用していたため、常にDBにクエリを実行できませんでした。代わりに、すべてのプレーヤーをDBからメモリにC ++オブジェクトとしてロードして使用しました。つまり、垂直方向にスケーリングされました。代わりにそのサーバーを水平方向にスケーラブルにすることは可能でしょうか？その量の更新を同時にサポートするように設計されたデータベースはありますか？

11 mmo  data-structure  databases  scalability 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、ゲーム開発スタック交換のトピックになるようにします。 6年前に閉鎖されました。 Minecraftはどのようなデータベースを使用していますか？リレーショナルデータベースですか、MySQLのような一般的なものですか？私たちは彼が何を使っているかも知っていますか？ そして、もっと良い質問かもしれませんが、彼はそのようにすべきですか？どのタイプのデータベースを使用する必要がありますか？

11 databases  minecraft-modding 

私のC ++ターンベースのゲームサーバー（データベースを使用）は、現在の平均的なクライアント（プレーヤー）の量に対抗できないため、すべてのクライアントが依然として存在する複数（1以上）のコンピューターとデータベースに拡張したいと考えています。単一のゲームの世界（サーバーは互いに通信し、複数のデータベースを使用する必要があります）。 最良の方法でそれを行う方法を説明するいくつかのチュートリアル/本/共通の標準はありますか？

11 server  databases 

したがって、私はwww.ninjawars.netでアイテムの使用を拡大することに取り組んでおり、私たちが使用しているリレーショナルデータベースでそれらを柔軟に表現する方法が正確にわかりません。 私は間違ったツリーを吠えているかもしれないので、他の方向に遠慮なく提案してください。しかし、現在、各アイテムには関係する「タグ」が必要だと思っています。 たとえば、現在、カタナは「アイテム」データベースの行です。それを武器にして保持可能なものにするために、私は「特性」のデータベースと、それらの間を単純にリンクするitem_traitsテーブルがあると考えていました。 // Objects and their basic data item_id | item 1 | Naginata // Things that objects can do trait_id | trait 1 | weapon 2 | holdable // How those objects do those things, e.g. powerfully, weakly, while on fire _item_id | _trait_id | item_trait_data 1 | …

10 architecture  web  databases 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ゲーム開発スタック交換のトピックになるようにします。 2年前休業。 ゲームエンジンの開発 コンピュータゲームとそのエンジンを計画しています。一人称視点の3次元の世界があり、現時点ではシングルプレーヤーになります。プログラミング言語はC ++で、OpenGLを使用しています。 データ中心の設計決定 私の設計上の決定は、グローバルイベントマネージャーとグローバルデータマネージャーがあるデータ中心型アーキテクチャを使用することです。物理、入力、サウンド、レンダラー、aiなどの多くのコンポーネントがあります。各コンポーネントは、イベントをトリガーしてリッスンできます。さらに、各コンポーネントはデータの読み取り、編集、作成、削除を行うことができます。 問題はデータマネージャーについてです。 リレーショナルデータベースを使用するかどうか SQLiteやMySQLなどのSQLデータベースを使用してゲームデータを保存する必要がありますか？これには、アイテム、キャラクター、インベントリなどの実質的にすべてのゲームコンテンツが含まれます。さらにパフォーマンスに関連するメッシュとテクスチャを除いて、メモリに保持します。 SQLデータベースは、動くキャラクターの位置などのゲーム情報をリアルタイムで読み書きするのに十分な速度ですか？また、プラットフォーム間の互換性にも注意する必要があります。すべてをメモリに保持する以外に、どのような代替手段がありますか？ 利点は MySQLのようなリレーショナルデータベースを使用する利点は、高速な計算を可能にするデータ指向の構造です。エンティティを表すためのオブジェクトは必要ありません。レンダリングに必要なプレーヤーの近くのオブジェクトのデータを簡単にクエリできました。そして、遠くにあるオブジェクトのデータを気にする必要はありません。さらに、ホールゲームの状態はデータベースに保存されるため、savegamesは必要ありません。最後に重要なことですが、ホールゲームの状態が格納されている場所が既にあるため、ゲームをオンラインゲームに拡張することは比較的簡単です。

9 architecture  performance  databases