Modèle de données d'échecs Star Trek 3D

Si vous êtes un fan de Star Trek, vous savez probablement que le capitaine Kirk et M. Spock jouent fréquemment à une variante des échecs appelée Tri-Dimensional Chess, ou échecs 3D, un jeu similaire aux échecs standard mais avec des différences notables. Dans cet article, nous allons créer un modèle de données pour une application d'échecs 3D qui permet aux joueurs de s'affronter. Téléportez-nous, Scotty !

Le concept d'échecs 3D

Alors que les échecs eux-mêmes sont déjà un jeu complexe, combiner des plateaux et plusieurs ensembles de pièces peut augmenter considérablement la complexité du jeu.

Dans les échecs 3D, les plateaux sont empilés en couches parallèles et des règles de mouvement spéciales s'appliquent à certaines pièces, en fonction de leur emplacement. Par exemple, les pions sur le plateau du milieu peuvent imiter le comportement d'une reine. Les pièces peuvent également se déplacer d'un plateau à l'autre, avec certaines restrictions appliquées, et les plateaux eux-mêmes peuvent même se déplacer et pivoter. Pas étonnant que Kirk et Spock aient tant aimé les échecs en 3D, cela demande beaucoup de finesse tactique !

Les échecs tridimensionnels s'écartent également des échecs standard en termes de propriétés de leurs échiquiers. Aux échecs 3D, il existe sept plateaux distincts avec des propriétés différentes. Trois de ces cartes sont 4x4, tandis que les quatre autres cartes sont 2x2. Vous pouvez déplacer ces planches plus petites.

Notre modèle de données couvrira, espérons-le, tout ce dont nous avons besoin pour jouer à une partie d'échecs en 3D dans une application Web. Nous partirons du principe que tout peut bouger et que les planches peuvent imposer différentes restrictions de mouvement sur les mêmes pièces. Cela devrait être suffisant pour couvrir toutes les variantes d'échecs 3D possibles. Passons directement au modèle de données !

Le modèle de données

Notre modèle de données se compose de trois sections :

Joueurs et jeux
Configuration du jeu
Correspondances

Nous allons maintenant discuter de chacun de ces domaines plus en détail.

Section 1 :Joueurs et jeux

Tout dans notre modèle est directement ou indirectement lié aux jeux. Bien sûr, un jeu ne peut pas se dérouler sans joueurs !

La liste de tous les joueurs est stockée dans le player table. Dans notre modèle, les joueurs sont tous les utilisateurs enregistrés de notre application. Pour chaque joueur, nous stockerons les informations suivantes :

first_name et last_name – le prénom et le nom du joueur, respectivement.
user_name – le nom d'utilisateur sélectionné par le joueur, qui doit être unique.
password – une valeur de hachage du mot de passe du joueur.
nickname – le pseudonyme du joueur qui, comme son nom d'utilisateur, doit être unique.
email – l'adresse e-mail du joueur, qu'il fournira lors du processus d'inscription. Le code requis pour terminer le processus d'inscription sera envoyé à cet e-mail.
confirmation_code – le code qui a été envoyé à l'adresse e-mail du joueur afin de terminer son processus d'inscription.
confirmation_date – l'horodatage du moment où le joueur a confirmé son adresse e-mail. Cet attribut stockera NULL jusqu'à ce que le joueur confirme son adresse e-mail.
current_rating – la note actuelle du joueur, calculée en fonction de ses performances face aux autres joueurs. Les joueurs commenceront avec une certaine valeur initiale, et leurs notes augmenteront ou diminueront en fonction des rangs de leurs adversaires et de leurs résultats de jeu.

Le result table est un dictionnaire qui stocke les valeurs de tous les résultats de jeu uniques possibles, à savoir "in_progress", "draw", "win" et "lose".

La table la plus importante de tout le modèle de données est peut-être game , qui stocke des informations sur chaque jeu d'échecs 3D. Dans ce modèle, nous supposerons que deux joueurs humains vont s'affronter et qu'ils peuvent choisir de sauvegarder leur état de jeu actuel et de reprendre plus tard (par exemple, s'ils souhaitent faire un mouvement par jour, dans auquel cas les joueurs se connecteront à l'application, verront le mouvement le plus récent de leur adversaire, penseront à leur propre mouvement, exécuteront leur mouvement, puis se déconnecteront). Nous stockerons les valeurs suivantes dans ce tableau :

player_id_1 et player_id_2 – références au player tableau désignant les deux participants d'un jeu. Comme mentionné, nous supposons qu'une partie se déroulera strictement entre deux joueurs humains.
number_of_moves – indique le nombre de coups qui ont été exécutés jusqu'à présent dans la partie en cours. Au début de la partie, ce nombre est mis à 0 et augmente de 1 à chaque fois qu'un joueur effectue un coup.
player_id_next – une référence au joueur qui doit effectuer le prochain coup dans la partie en cours.
result_id_1 et result_id_2 – références au result table qui stocke le résultat du jeu pour chaque joueur.
player_1_points_won et player_2_points_won – indique le nombre de points attribués aux joueurs, en fonction du résultat du jeu.

Nous discuterons de la manière dont les joueurs peuvent suivre tous les mouvements dans la section Matches vers la fin de cet article. Pour l'instant, nous allons passer à la configuration du jeu.

Section 2 :Configuration du jeu

La section Configuration du jeu contient une description de tous les échiquiers et pièces d'échecs en 3D, ainsi qu'une liste de tous les coups légaux que les joueurs peuvent effectuer.

Comme nous l'avons mentionné précédemment, les échecs 3D impliquent souvent plus d'un échiquier. Ces cartes peuvent respecter les dimensions standard 8x8 avec des positions fixes, mais cela n'est pas obligatoire. La liste de tous les tableaux est stockée dans le board table. Pour chaque tableau, nous stockerons un board_name unique , la starting_position de la carte par rapport à nos coordonnées 3D choisies, et tous les details supplémentaires .

Ensuite, nous définirons tous les types de pièces possibles qui pourraient apparaître sur nos échiquiers. Pour ce faire, nous utiliserons le piece_type dictionnaire. En plus de sa clé primaire, ce dictionnaire contient une seule valeur unique, type_name. Pour un jeu d'échecs standard, nous nous attendons à voir les valeurs "pion", "tour", "chevalier", "fou", "roi" et "reine" dans ce dictionnaire.

La liste de toutes les pièces individuelles utilisées dans une partie d'échecs 3D est stockée dans le piece table. Pour chaque pièce, nous stockerons les informations suivantes :

piece_name – un nom unique décrivant le type de pièce et sa position de départ.
starting_position – une valeur indiquant le plateau et le carré précis sur lesquels la pièce est initialement positionnée.
board_id – une référence au plateau sur lequel la pièce est positionnée à l'origine.
piece_type_id – une référence indiquant le type de la pièce.

Enfin, nous utiliserons le move_type table pour stocker la liste de tous les mouvements possibles que les pièces peuvent effectuer sur nos plateaux (ainsi que tous les mouvements que les plateaux eux-mêmes peuvent effectuer). Rappelons dès l'introduction que certains plateaux appliquent des règles de déplacement particulières à leurs pions. Pour chaque mouvement, nous définirons les éléments suivants :

type_name – un nom que nous utiliserons pour désigner le coup qui a été effectué, qui ne sera pas une valeur unique (par exemple, nous pouvons avoir « pion avancé d'une case en avant » autant de fois que nécessaire).
piece_type_id – une référence au type de pièce déplacée. Si cette valeur est NULL, alors le mouvement concerne tout un plateau et non une pièce en particulier.
board_id – désigne l'échiquier sur lequel ce mouvement aura lieu (si une pièce d'échecs est en mouvement). Si le plateau lui-même est en mouvement, cette valeur représentera naturellement le plateau qui est déplacé. Avec les deux attributs précédents, cela forme la clé unique de cette table.
is_piece_move et is_board_move – indique si un coup concerne une pièce d'échecs ou un échiquier. Un seul de ces indicateurs peut être défini sur vrai pour un mouvement particulier.

Comme il y a trop de mouvements et de rotations de pièces à prendre en compte, nous ne stockerons pas toutes ces possibilités dans notre base de données. Au lieu de cela, nous allons simplement stocker les noms de mouvement et implémenter la logique réelle dans l'application elle-même. Par exemple, nous définirons que les pions peuvent soit avancer d'une seule case, avancer de deux cases depuis leur position de départ, réclamer des pièces en diagonale, se déplacer d'un plateau à l'autre et se déplacer en tant que reine sur le plateau central. Nous aurons donc cinq types de mouvements possibles définis pour les pions, en fonction du plateau sur lequel ils sont placés et de leur position actuelle.

Section 3 :Correspondances

Nous avons presque terminé ! La dernière section de notre modèle s'appelle Matches et contient trois nouvelles tables que nous utiliserons pour suivre l'historique des mouvements dans une partie d'échecs en 3D. Les tables restantes ne sont que des copies d'autres tables de notre modèle de données, ce qui permet d'éviter les relations qui se chevauchent. Nous stockerons également les positions actuelles de tous les tableaux et de leurs pièces dans cette zone. Allons-y.

Le move table est en fait la table la plus complexe de cette section. Il contient la liste de tous les coups exécutés pendant une partie. Ce tableau affichera la liste de tous les mouvements des joueurs, qui pourra ensuite être utilisée pour revoir ou analyser le match. Pour chaque mouvement, nous stockons les éléments suivants :

game_id – une référence au game dans lequel le déplacement a été effectué.
player_id – une référence au player qui a fait le déplacement.
move_in_the_game – le numéro ordinal du coup. Ce nombre, combiné avec la position de départ d'une pièce et tous les autres mouvements, peut être utilisé pour recréer l'ensemble du jeu. L'idée est de permettre aux joueurs de simuler le jeu une fois qu'il est terminé afin qu'ils puissent analyser les résultats du match.
piece_id – une référence au piece qui a été déplacé. Cela facilite le suivi du mouvement d'une pièce du début à la fin (principalement à des fins d'analyse).
piece_type_id – une référence au type de pièce déplacée. Alors que la référence d'une pièce restera toujours constante, son type peut changer tout au long du jeu (comme si un pion est promu). Si nous déplaçons le tableau, cet attribut contiendra une valeur de NULL.
board_id – une référence au board sur lequel le déménagement a eu lieu.
move_notation – une notation convenue que nous utiliserons pour représenter les coups.

Les deux tables restantes nous permettent de stocker un instantané de l'état actuel du jeu dans la base de données, ce qui est utile si les joueurs souhaitent reprendre le jeu ultérieurement.

Le current_board_position est utilisé pour stocker la position de toutes les planches dans notre système de coordonnées 3D. Ceci est nécessaire pour les jeux d'échecs 3D dans lesquels au moins un échiquier peut changer de position. Pour chaque enregistrement de ce tableau, nous stockerons une référence au jeu et au plateau associés, ainsi que la notation de la position d'un plateau. Deux paires d'attributs spécifiques, game_id + board_id et game_id + position_notation , forment les clés uniques de cette table.

Notre dernière table est current_piece_position , qui stocke les références au jeu associé, une pièce particulière, le type de pièce et une notation de position pour la pièce. Nous aurons à nouveau deux paires d'attributs qui serviront de clés uniques pour cette table :le game_id et piece_id paire et le game_id et position_notation paire.

Conclusion

C'est à peu près tout pour ce modèle de données :nous sommes fiers d'annoncer que le capitaine Kirk et M. Spock peuvent désormais jouer aux échecs en 3D sur un ordinateur !

Avez-vous des suggestions pour améliorer notre modèle de données ? N'hésitez pas à laisser vos commentaires ci-dessous. Vivez longtemps et prospérez ??