正直に言うと、私たちは皆、特にコンピューターでゲームをするのが大好きです。インターネットが普及するまで、私たちのほとんどは、通常はAIの対戦相手に対して、自分たちでコンピューターゲームをプレイしていました。楽しかったですが、ゲームプレイの仕組みがどのように機能するかを理解するとすぐに、ゲームはその魔法のほとんどを失いました。
インターネットの発展により、ゲームはオンラインに移行しました。これで、人間の対戦相手と対戦し、対戦相手のスキルをテストできます。これ以上のゲームプレイはありません！
その後、大規模なマルチプレイヤーオンライン（MMO）ゲームが登場し、すべてが変わりました。何千人ものプレイヤーが同じゲームの世界にいることに気づき、リソースをめぐって競争し、交渉し、取引し、戦いました。そのようなゲームを可能にするために、すべての関連情報を保存できるデータベース構造が必要でした。
この記事では、MMOゲームで見られる最も一般的な要素を組み込んだモデルを設計します。使用方法、その制限、および考えられる改善について説明します。
MMOゲームのデータモデルの概要
今日、非常に人気のあるMMOゲームはたくさんあり、それらにはあらゆる種類のシナリオが含まれます。ここでは、 Ogameのような戦略ゲームに焦点を当てます。 、トラビアン 、スパルタ ：帝国の戦争 およびインペリアオンライン 。これらのゲームは、計画、構築、戦略化に関するものであり、直接行動に関するものではありません。
MMOゲームはさまざまな世界に設定されており、視覚的にも異なり、多かれ少なかれ異なるゲームプレイオプションを使用します。それでも、いくつかのアイデアは同じです。プレイヤーは場所を争い、彼らのために戦い、他のプレイヤーと（そして他のプレイヤーと）同盟を結びます。彼らは構造を構築し、リソースを収集し、技術を研究します。彼らはユニット（戦士、戦車、トレーダーなど）を構築し、それらを使用して味方との取引や敵との戦いを行います。これらすべてをデータベースでサポートする必要があります。
これらのゲームは、多くのインデックス付きの正方形を備えたオンラインボードゲームと考えることができます。各正方形には、さまざまなアクションを関連付けることができます。一部のアクションには、複数の正方形が含まれます。ユニットまたはリソースをある場所から別の場所に移動するとき。
データベースは5つの主要な領域に分かれています：
Players / UsersAlliancesLocations and StructuresResearch and ResourcesUnits
残りの7つのグループ化されていないテーブルはユニットに関連しており、ユニットの位置とゲーム内の動きを説明しています。 プレーヤーから始めて、これらの各領域についてさらに詳しく見ていきます。 および同盟 。
プレイヤーとアライアンス
間違いなく、プレーヤーはどのゲームでも最も重要な部分です。
player テーブルには、ゲームインスタンスに参加しているすべての登録済みプレーヤーのリストが含まれています。プレーヤーのユーザー名、パスワード、スクリーン名を保存します。これらはuser_nameに保存されます 、password 、およびnickname それぞれ属性。
新規ユーザーは、登録時にメールアドレスを提供する必要があります。確認コードが生成されて送信され、返信されます。 confirmation_dateを更新します ユーザーが自分のメールアドレスを確認するときの属性。したがって、このテーブルには3つの一意のキーがあります。user_name 、nickname およびemail 。
ユーザーがログインするたびに、新しいレコードがlogin_history テーブル。この表のすべての属性は自明です。 logout_time 具体的です。ユーザーの現在のセッションがアクティブな場合、またはユーザーが技術的な問題のために（ログアウトせずに）ゲームを終了した場合は、NULLになる可能性があります。 login_data内 属性には、プレーヤーの地理的な場所、IPアドレス、プレーヤーが使用するデバイスとブラウザなどのログインの詳細が保存されます。
ほとんどのMMOゲームでは、他のプレイヤーと協力することができます。プレイヤーの協力の標準的な形式の1つは、同盟です。プレイヤーはゲーム内の「プライベートデータ」（オンラインステータス、計画、都市や植民地の場所など）を他の人と共有して、仲間の行動から利益を得て、それを楽しむことができます。
alliance テーブルには、ゲームアライアンスに関する基本情報が格納されています。それぞれに固有のalliance_nameがあります 保存します。 date_foundedというフィールドもあります 、アライアンスが設立されたときに保存します。アライアンスが解散した場合、その情報をdate_disbandedに保存します 属性。
alliance_member 表は、プレイヤーと同盟を関連付けています。プレイヤーは同じ同盟に複数回参加および離脱することができます。このため、player_id – alliance_id ペアは一意のキーではありません。プレーヤーがアライアンスに参加する時期と、プレーヤーがdate_fromに参加する時期（場合）に関する情報を保持します およびdate_to 田畑。 membership_type_id 属性はmembership_type 辞書;アライアンスでのプレーヤーの権利の現在のレベルを保存します。
同盟におけるプレーヤーの権利は、時間の経過とともに変化する可能性があります。 membership_actions 、membership_type およびactions_allowed 表は一緒に、同盟メンバーのすべての可能な権利を定義します。このモデルでは、プレーヤーがアライアンスで独自の権利レベルを定義することはできませんが、membership_type 辞書とそれらが関連している同盟に関する情報を保存します。
要約すると、これらのテーブルに格納されている値は、初期設定時に定義されます。新しいオプションを導入した場合にのみ変更されます。
membership_history テーブルには、アライアンス内のプレーヤーの役割または権利に関するすべてのデータが格納されます。これには、これらの権利が有効だったときの範囲も含まれます。 （たとえば、彼は1か月間「初心者」の権限を持ち、その時点から「完全なメンバーシップ」を持つことができます。）date_to 現在アクティブな権限がまだ終了していないため、属性はNULL可能です。
membership_actions 辞書には、プレイヤーが同盟で行うことができるすべてのアクションのリストが含まれています。各アクションには独自のaction_nameがあります ゲームロジックはこれらの名前を中心に構築されています。 「メンバーリストを表示」のような値が期待できます 、「メンバーのステータスを表示」 および「メッセージの送信」 ここ。
membership_type 辞書には、ゲームで使用されるアクショングループの一意の名前が含まれています。 actions_allowed テーブルは、メンバーシップタイプにアクションを割り当てます。各アクションは、タイプに1回だけ割り当てることができます。したがって、membership_action -membership_type ペアは、このテーブルの一意のキーを形成します。
場所と構造
ゲームの場所は、プレイヤーがリソースを収集し、構造とユニットを構築する領域です。一部のゲームには事前定義された範囲の可能な場所がありますが、他のゲームではユーザーが自分の場所を定義できる場合があります。
3D空間では、場所は[x：y：z]座標で定義できます。ゲームに事前定義された範囲がある場合、プレーヤーは3つの軸すべてに範囲[0：1000]の範囲外の場所を使用できない可能性があるため、1000 * 1000*1000のスペースに制限されます。
一方、プレーヤーが新しい場所の正確な座標を入力できるようにしたい場合もあります。 [1001：2073：4] –そして私たちはゲームが彼らのためにそれを処理することを望んでいます。
ゲームのインスタンスで使用されるすべての場所のリストをlocation テーブル。それぞれの場所には独自の名前がありますが、名前は一意ではありません。一方、coordinates 属性には一意の値のみを含める必要があります。場所の座標はテキスト値として保存されるため、3Dゲームの座標は[112：72：235]として保存できます。 2Dゲームの座標は、<1102：98>として保存できます。
一部のゲームでは、場所に構造物やユニットを収容するために使用されるいくつかの正方形があります。その情報はdimensionに保持されます テキストフィールドである属性。寸法は、2Dまたは3Dグリッド内の単純な正方形の数にすることができます。 player_id 属性は、その場所の現在の所有者に関する情報を格納します。場所が事前定義されていて、プレーヤーがそれらを占有するために競合する場合は、NULLになる可能性があります。
structure 表には、さまざまなゲームの場所で構築できるすべての構造のリストが含まれています。構造は、より良いユニットの作成、新しいタイプの調査の実行、より多くのリソースの作成などを可能にする改善を表しています。ゲームで使用される各構造には、独自のstructure_nameがあります。 。いくつかの可能なstructure_name 値は「農場」、「鉱石鉱山」、「太陽光発電所」、「研究センター」です。
各構造は複数回アップグレードされることが予想されるため、現在のレベルに関する情報も保存します。アップグレードするたびに構造の出力が向上するため、より多くのリソースが生成されるか、ゲームで新しい機能を使用できるようになります。アップグレードの最大レベルを事前に知ることはできないため、レベルに関連するすべてのもの（コスト、アップグレード時間、生産）を式で定義します。 データベースに保存されているすべての数式はゲームの仕組みの中核であり、それらの調整はゲームバランスとゲームプレイ全般にとって非常に重要です。
これは、upgrade_time_formulaにも当てはまります。 属性。このフィールドの値の例は、“
ほとんどの場合、プレーヤーが特定のアクションを実行する前に満たす必要のある要件があります。新しい構造を構築する前に、またはその逆の前に、定義された量の調査を完了する必要があるかもしれません。構造を構築するために必要な調査レベルをprerequisite_research テーブル。さまざまな調査を開始するために必要な関係と構造レベルは、prerequisite_structure テーブル。両方のテーブルで、外部キーresearch_id およびstructure_id ペアになって一意のキーを形成します。 level_required 属性が唯一の値です。
これらの2つのテーブル、prerequisite_research およびprerequisite_structure 、ゲームの中核も形成します。
構造ごとに、前提条件のリストを定義します。他の構造と、プレイヤーが構築を開始するために必要な最小レベルです。このデータはstructure_required テーブル。ここでは、structure_id 構築したい構造を表します。 structure_required_id 前提条件の構造への参照であり、level 必要なレベルです。
structure_built テーブルには、特定の場所の現在の構造レベルに関する情報が格納されます。 upgrade_ongoing upgrade_end_timeが現在進行中の場合にのみ、属性が設定されます。 アップグレードが完了すると、属性にはタイムスタンプが含まれます。
structure_formula 表は構造とリソースに関連しています。このテーブルの外部キーペアは、その一意のキーを形成します。このテーブルには、パラメータとしてupgrade_time_formulaに似ています 。各構造の構築に費やされるリソースを定義する必要があるため、これらが必要です。構造がリソースを生成する場合は、アップグレード後にリソースの生成も定義する必要があります（つまり、鉱石が
研究とリソース
ゲームの研究（またはテクノロジー）は通常、他の機能を作成するために必要です。特定のレベルの調査がなければ、新しい構造やユニットタイプを構築することはできません。研究にも独自の要件があります。最も一般的なものの1つは、通常「リサーチラボ」と呼ばれる特定の構造のレベルです。あるいは、プレイヤーは新しい研究を始める前に、ある程度の研究を完了する必要があるかもしれません。これらの要件はすべて、このセクションで処理されます。以下に、研究とリソースのデータモデルを示します。
research 表には、ゲームで可能なすべての調査アクションのリストが含まれています。 structure テーブル。 research_name 属性はテーブルの一意のキーであり、upgrade_time_formula フィールドには、パラメータとしてupgrade_formulaで定義されています。 research_formula テーブル。
構造と同様に、別のタイプの調査を開始する前に完了する必要がある他のすべての調査とそのレベルのリストを定義します。このデータはresearch_required テーブル、ここでresearch_id 希望する研究を表します。 research_required_id 前提条件の調査への参照であり、level 必要なレベルです。
調査は個々のプレーヤーに関連しており、各プレーヤー–再調査 chペアは、プレイヤーの現在の研究レベルと進行中のアップグレードステータスを保存する必要があります。この情報は、research_level structure_built テーブル。
木材、鉱石、宝石、エネルギーなどの資源は、採掘または収集され、後で構造物やその他の改良を構築するために使用されます。ゲーム内のすべてのリソースのリストをresource 辞書。ここでの唯一の属性はresource_nameです フィールドであり、テーブルの一意のキーでもあります。
各場所の現在のリソース量を追跡するには、resources_on_location テーブル。ここでも、外部キーのペア（resource_id およびlocation_id ）はテーブルの一意のキーを形成し、number 属性は現在のリソース値を格納します。
ユニットと動き
リソースはユニットの生産に使用されます。ユニットは、資源の輸送、他のプレイヤーの攻撃、または一般的な略奪と燃焼に使用できます。
ゲームで使用されるユニットタイプのリストは、unit 値が1つだけの辞書unit_name;その属性は、このテーブルの一意のキーです。一般的なゲームユニットには、「剣士」、「巡洋戦艦」、「グリフィン」、「ジェット戦闘機」、「戦車」などがあります。
各ユニットを特定の特性で説明する必要があります。考えられるすべての特性のリストがcharacteristic 辞書。 characteristic_name フィールドには一意の値が含まれます。このフィールドの値には、「攻撃」、「防御」、「ヒットポイント」が含まれます。 unit_characteristic 関係。 unit_idの外部キーペア およびcharacteristic_id テーブルの一意のキーを形成します。 valueという1つの属性のみを使用します 、目的の値を保存します。
research_unit 表には、特定のユニットタイプの生産を開始する前に終了する必要があるすべての研究活動のリストが含まれています。 unit_cost 表は、単一のユニットを作成するために必要なリソースを定義します。両方のテーブルには、外部キーペア（research_id）で構成される一意のキーがあります またはresources_id unit_idと組み合わせる ）と1つの値フィールド（cost およびlevel_required 。
そして今、楽しい部分。制作は楽しいですが、ユニットを動かして行動を起こすことはさらに良いことです。 unit テーブルですが、他のテーブルとの関係があるため、ここでは保持します。
ユニットは場所に配置されているか、場所間を移動しています。 player_idを追加する フィールドは、場所または場所間を移動するグループの所有者を決定します。
ユニットが特定の場所に配置されている場合は、その場所とそこに配置されているユニットの数を保存します。そのために、units_on_location テーブル。
ユニットが配置されていないときは、動き回っています。出発地と目的地を保存する必要があります。さらに、移動中に可能なアクションを定義する必要があります。このようなアクションはすべて、movement_type 辞書。 type_name allows_waitの間、属性は一意です 属性は、アクションが宛先ポイントでの待機を許可するかどうかを決定します。
単一のユニットタイプを移動できますが、ほとんどの場合、いくつかの異なるユニットタイプの多くのユニットを移動します。そのグループは共通のデータを共有し、それらをgroup_movement テーブル。この表では、次の項目を定義します。
- そのアクションを開始したプレーヤー
- アクションタイプ
- 出発点
- 目的地
-
arrival_time目的地で -
return_time出発点まで -
wait_time目的地で
return_time これが一方通行の場合、属性はNULLになる可能性があり、wait_time プレイヤーによって定義されます。グループに属するユニットは、units_in_group テーブル。 units_idの外部キーペア およびgroup_moving_id テーブルの一意のキーを形成します。グループ内の同じタイプのユニットの数は、numberで定義されます。 属性。
各移動は、ある場所から別の場所にリソースを転送できます。したがって、group_movement およびresources テーブル。主キーと外部キーに加えて、resources_in_group テーブルにはnumberのみが含まれます 属性。このフィールドには、プレーヤーが開始点から目的地まで移動するリソースの量が格納されます。
ほとんどの場合、プレイヤーは他の人に電話して冒険に参加することができます。これをサポートするために、2つのテーブルを使用します：allied_movement およびallied_groups 。 1人のプレーヤーが共同アクションを開始し、それによってallied_movement テーブル。味方のアクションに参加するユニットのすべてのグループは、allied_groups テーブル。各グループは、関連するアクションに1回だけ割り当てることができるため、外部キーがこのテーブルの一意のキーを形成します。
このモデルは、MMO戦略ゲームを構築するために必要な基本構造を提供します。これには、場所、構造、リソース、調査、ユニットなど、最も重要なゲーム機能が含まれています。また、それらを関連付け、データベースで前提条件を定義し、ほとんどのゲームロジックをデータベースに保存します。
これらのテーブルにデータが入力されると、ほとんどのゲームロジックが定義され、新しい値が追加されることはありません。ほとんどすべてのテーブルには、機能名または外部キーペアのいずれかの一意のキー値があります。ユニットの特性と生産/コストの計算式を変更すると、データベースレイヤーのゲームバランスを変更できます。
このモデルをどのように変更しますか？あなたは何が好きですか、そしてあなたは何を変えますか？コメント欄で教えてください！