スタートレックのファンなら、カーク船長とスポック氏が三次元チェスまたは3Dチェスと呼ばれる変則チェスを頻繁にプレイすることをご存知でしょう。このゲームは、標準のチェスに似ていますが、顕著な違いがあります。この記事では、プレーヤーが互いに競争できるようにする3Dチェスアプリケーションのデータモデルを構築します。チャーリー、転送を頼む！
3Dチェスの概念
チェス自体はすでに複雑なゲームですが、ボードと複数のピースのセットを組み合わせると、ゲームの複雑さが大幅に増す可能性があります。
3Dチェスでは、ボードは平行なレイヤーに積み重ねられ、特定のピースには、それらが配置されている場所に応じて特別な移動ルールが適用されます。たとえば、真ん中のボードのポーンは、女王の行動を模倣することができます。ピースは、特定の制限が適用された状態で、あるボードから別のボードに移動することもでき、ボード自体が動き回ったり回転したりすることもできます。カークとスポックが3Dチェスをとても楽しんだのも不思議ではありません。かなりの戦術的な技巧が必要です！
三次元チェスも、ボードの特性の点で標準のチェスとは異なります。 3Dチェスには、異なる特性を持つ7つの異なるボードがあります。これらのボードのうち3つは4x4で、残りの4つのボードは2x2です。これらの小さなボードを移動できます。
私たちのデータモデルは、Webアプリで3Dチェスのゲームをプレイするために必要なすべてをカバーすることを願っています。すべてが動き回ることができ、ボードが同じピースに異なる動きの制限を課すことができるという仮定の下で作業します。これは、考えられるすべての3Dチェスのバリエーションをカバーするのに十分なはずです。データモデルに飛び込みましょう！
データモデル
データモデルは3つのセクションで構成されています：
- プレーヤーとゲーム
- ゲームのセットアップ
- 一致
次に、これらの各領域について詳しく説明します。
セクション1：プレーヤーとゲーム
私たちのモデルのすべては、直接的または間接的にゲームに関連しています。もちろん、プレイヤーなしではゲームを進めることはできません。
すべてのプレーヤーのリストは、 playerに保存されます テーブル。私たちのモデルでは、プレイヤーはすべて私たちのアプリケーションの登録ユーザーです。プレーヤーごとに、次の情報を保存します：
-
first_nameおよびlast_name–それぞれプレーヤーの名前と名前。 -
user_name–プレーヤーが選択したユーザー名。一意である必要があります。 パスワード–プレーヤーのパスワードのハッシュ値。ニックネーム–プレーヤーのスクリーン名。ユーザー名と同様に、一意である必要があります。メール–登録プロセス中に提供されるプレーヤーのメールアドレス。登録プロセスを完了するために必要なコードは、このメールに送信されます。confirmation_code–登録プロセスを完了するためにプレーヤーのメールアドレスに送信されたコード。-
confirmation_date–プレーヤーがメールアドレスを確認したときのタイムスタンプ。この属性は、プレーヤーがメールを確認するまでNULLを保存します。 -
current_rating–他のプレイヤーに対するパフォーマンスに基づいて計算された、プレイヤーの現在の評価。プレイヤーは初期値から始め、対戦相手のランクとゲームの結果に応じてレーティングが増減します。
結果 tableは、「in_progress」、「draw」、「win」、「lose」など、考えられるすべての一意のゲーム結果の値を格納する辞書です。
おそらく、データモデル全体で最も重要なテーブルは game 、3Dチェスの各ゲームに関する情報を格納します。このモデルでは、2人の人間のプレーヤーが互いに競争し、現在のゲーム状態を保存して後で再開することを選択できると想定します（たとえば、1日に1つの動きをしたい場合など）。この場合、プレーヤーはアプリにログインし、対戦相手の最新の動きを確認し、自分の動きを考え、動きを実行してからログアウトします）。このテーブルには次の値が格納されます：
-
player_id_1およびplayer_id_2–playerへの参照ゲームの両方の参加者を示す表。前述のように、ゲームは2人の人間のプレーヤー間で厳密に行われると想定しています。 -
number_of_moves–現在のゲームでこれまでに実行された移動の数を示します。ゲームが開始されると、この数値は0に設定され、プレーヤーが移動するたびに1ずつ増加します。 -
player_id_next–現在のゲームで次の動きをしなければならないプレーヤーへの参照。 -
result_id_1およびresult_id_2–結果への参照各プレーヤーのゲームの結果を保存するテーブル。 -
player_1_points_wonおよびplayer_2_points_won–ゲームの結果に応じて、プレーヤーに与えられたポイント数を示します。
この記事の終わり近くにある「試合」セクションで、プレーヤーがすべての動きを追跡する方法について説明します。とりあえず、ゲームのセットアップに移ります。
セクション2：ゲームのセットアップ
ゲームセットアップセクションには、3Dチェスのすべてのボードとピースの説明、およびプレーヤーが行うことができるすべての合法的な動きのリストが含まれています。
先に述べたように、3Dチェスには複数のボードが含まれることがよくあります。これらのボードは、固定位置で標準の8x8寸法に準拠できますが、そうである必要はありません。すべてのボードのリストはボードに保存されます テーブル。ボードごとに、一意の board_nameを保存します 、 starting_position 選択した3D座標に関連するボードの数、およびすべての追加の詳細 。
次に、チェス盤に表示される可能性のあるすべての種類の駒を定義します。そのために、 piece_typeを使用します 辞書。このディクショナリには、主キーに加えて、type_nameという1つの一意の値のみが含まれています。標準のチェスセットの場合、この辞書には「ポーン」、「ルーク」、「ナイト」、「ビショップ」、「キング」、「クイーン」の値が表示されると予想されます。
3Dチェスのゲームで使用されるすべての個々の駒のリストは、駒に保存されます。 テーブル。各ピースについて、次の情報を保存します：
-
piece_name–ピースタイプとその開始位置を説明する一意の名前。 -
starting_position–ピースが最初に配置される正確なボードと正方形を示す値。 -
board_id–ピースが最初に配置されたボードへの参照。 -
piece_type_id–ピースのタイプを示す参照。
最後に、 move_typeを使用します ピースがボード上で実行できるすべての移動（およびボード自体が実行できる移動）のリストを格納するテーブル。イントロダクションから、特定のボードがそれらのピースに特別な移動ルールを適用することを思い出してください。移動ごとに、以下を定義します。
-
type_name–行われた移動を示すために使用する名前であり、一意の値にはなりません（たとえば、必要な回数だけ「1マス前方にポーンする」ことができます）。 -
piece_type_id–移動されたピースのタイプへの参照。この値がたまたまNULLの場合、移動は特定の部分ではなく、ボード全体に関係します。 -
board_id–この移動が行われるボードを示します（チェスの駒が移動している場合）。ボード自体が移動している場合、この値は移動中のボードを自然に表します。以前の2つの属性とともに、これはこのテーブルの一意のキーを形成します。 -
is_piece_moveおよびis_board_move–移動がチェスの駒とボードのどちらに関係するかを示します。特定の動きに対して、これらのフラグの1つだけをtrueに設定できます。
ピースの移動と回転が多すぎて考慮できないため、そのような可能性をすべてデータベースに保存することはしません。代わりに、移動名を保存し、アプリケーション自体に実際のロジックを実装します。たとえば、ポーンは1マス進むか、開始位置から2マス進むか、斜めに駒を要求するか、あるボードから別のボードに移動するか、中央のボードでクイーンとして移動できるかを定義します。そのため、ポーンが配置されているボードと現在の位置に応じて、ポーンに5つの可能な移動タイプを定義します。
セクション3：一致
ほぼ完成です！モデルの最後のセクションはMatchesという名前で、3Dチェスのゲームの移動履歴を追跡するために使用する3つの新しいテーブルが含まれています。残りのテーブルは、データモデルの他のテーブルのコピーであり、関係の重複を回避するのに役立ちます。また、この領域のすべてのボードとそのピースの現在の位置も保存します。さっそく飛び込みましょう。
移動 テーブルは、実際にはこのセクションで最も複雑なテーブルです。ゲーム中に実行されたすべての動きのリストが含まれています。このテーブルには、プレーヤーへのすべての動きのリストが表示されます。これは、後で試合を確認または分析するために使用できます。移動ごとに、以下を保存します：
-
game_id–ゲームへの参照移動が行われた場所。 -
player_id–playerへの参照誰が動きましたか。 -
move_in_the_game–移動の序数。この数字をピースの開始位置や他のすべての動きと組み合わせて、ゲーム全体を再現するために使用できます。アイデアは、ゲームが完了したらプレーヤーがゲームをシミュレートできるようにして、試合の結果を分析できるようにすることです。 -
piece_id–pieceへの参照感動しました。これにより、ピースの動きを最初から最後まで簡単に追跡できます（主に分析目的で）。 -
piece_type_id–移動されたピースのタイプへの参照。ピースの参照は常に一定のままですが、そのタイプはゲーム全体で変わる可能性があります（ポーンが昇格した場合など）。ボードを移動する場合、この属性にはNULLの値が含まれます。 -
board_id–ボードへの参照移動が行われた場所。 -
move_notation–動きを表すために使用する合意された表記法。
残りの2つのテーブルを使用すると、現在のゲームの状態のスナップショットをデータベースに保存できます。これは、プレーヤーが後でゲームを再開したい場合に役立ちます。
current_board_position すべてのボードの位置を3D座標系に保存するために使用されます。これは、少なくとも1つのボードがその位置を変更できる3Dチェスゲームに必要です。この表の各レコードについて、関連するゲームとボードへの参照、およびボードの位置の表記を保存します。 2つの特定の属性ペア、 game_id + board_id およびgame_id + position_notation 、このテーブルの一意のキーを形成します。
最後のテーブルはcurrent_piece_position 、関連するゲームへの参照、特定のピース、ピースのタイプ、およびピースの位置表記を格納します。このテーブルの一意のキーとして機能する2組の属性、 game_idが再びあります。 およびpiece_id ペアとgame_id およびposition_notation ペア。
結論
このデータモデルについては以上です。カーク船長とスポック氏がコンピューターで3Dチェスをプレイできるようになったことをお知らせします。
データモデルを改善するための提案はありますか？以下にコメントを残してください。長生きして繁栄する??