Si eres fanático de Star Trek, probablemente sepas que el Capitán Kirk y el Sr. Spock juegan con frecuencia una variante de ajedrez llamada Tri-Dimensional Chess, o ajedrez 3D, un juego que es similar al ajedrez estándar pero con diferencias notables. En este artículo, construiremos un modelo de datos para una aplicación de ajedrez en 3D que permita a los jugadores competir entre sí. ¡Transpórtanos, Scotty!
El Concepto de Ajedrez 3D
Si bien el ajedrez en sí ya es un juego complejo, la combinación de tableros y múltiples conjuntos de piezas puede aumentar significativamente la complejidad del juego.
En el ajedrez 3D, los tableros se apilan en capas paralelas y se aplican reglas especiales de movimiento a ciertas piezas, dependiendo de dónde estén ubicadas. Por ejemplo, los peones en el tablero del medio pueden imitar el comportamiento de una reina. Las piezas también se pueden mover de un tablero a otro, con ciertas restricciones aplicadas, y los tableros mismos pueden incluso moverse y rotar. No es de extrañar que Kirk y Spock disfrutaran tanto del ajedrez en 3D, ¡requiere mucha delicadeza táctica!
El ajedrez tridimensional también se desvía del ajedrez estándar en cuanto a las propiedades de sus tableros. En el ajedrez 3D, hay siete tableros distintos con diferentes propiedades. Tres de estas tablas son de 4x4, mientras que las cuatro tablas restantes son de 2x2. Puedes mover estas tablas más pequeñas.
Esperamos que nuestro modelo de datos cubra todo lo que necesitamos para jugar una partida de ajedrez 3D en una aplicación web. Trabajaremos bajo el supuesto de que todo puede moverse y que los tableros pueden imponer diferentes restricciones de movimiento en las mismas piezas. Esto debería ser suficiente para cubrir todas las posibles variantes de ajedrez en 3D. ¡Pasemos directamente al modelo de datos!
El modelo de datos
Nuestro modelo de datos consta de tres secciones:
- Jugadores y juegos
- Configuración del juego
- Coincidencias
Ahora analizaremos cada una de estas áreas con mayor detalle.
Sección 1:Jugadores y Juegos
Todo en nuestro modelo está directa o indirectamente relacionado con los juegos. ¡Por supuesto, un juego no puede continuar sin jugadores!
La lista de todos los jugadores se almacena en el player mesa. En nuestro modelo, los jugadores son todos los usuarios registrados de nuestra aplicación. Para cada jugador, almacenaremos la siguiente información:
first_nameylast_name– el nombre y apellido del jugador, respectivamente.user_name– el nombre de usuario que seleccionó el jugador, que debe ser único.password– un valor hash de la contraseña del jugador.nickname– el nombre de pantalla del jugador, que, al igual que su nombre de usuario, debe ser único.email– la dirección de correo electrónico del jugador, que proporcionará durante el proceso de registro. El código requerido para completar el proceso de registro se enviará a este correo electrónico.confirmation_code– el código que se envió a la dirección de correo electrónico del jugador para completar su proceso de registro.confirmation_date– la marca de tiempo de cuando el jugador confirmó su dirección de correo electrónico. Este atributo almacenará NULL hasta que el jugador confirme su correo electrónico.current_rating– la valoración actual del jugador, calculada en función de su rendimiento frente a otros jugadores. Los jugadores comenzarán con un valor inicial y sus calificaciones aumentarán o disminuirán de acuerdo con los rangos de sus oponentes y los resultados de sus juegos.
El result table es un diccionario que almacena los valores de todos los posibles resultados únicos del juego, a saber, "en proceso", "empatar", "ganar" y "perder".
Quizás la tabla más importante de todo el modelo de datos es game , que almacena información sobre cada partida de ajedrez 3D. En este modelo, supondremos que dos jugadores humanos competirán entre sí y que pueden optar por guardar su estado de juego actual y reanudarlo en otro momento (por ejemplo, si quisieran hacer un movimiento por día, en en cuyo caso, los jugadores iniciarán sesión en la aplicación, verán el movimiento más reciente de su oponente, pensarán en su propio movimiento, ejecutarán su movimiento y luego cerrarán la sesión). Guardaremos los siguientes valores en esta tabla:
player_id_1yplayer_id_2– referencias alplayertabla que denota a ambos participantes de un juego. Como se mencionó, asumimos que un juego ocurrirá estrictamente entre dos jugadores humanos.number_of_moves– indica el número de movimientos que se han ejecutado hasta ahora en el juego actual. Cuando comienza el juego, este número se establece en 0 y aumenta en 1 cada vez que un jugador realiza un movimiento.player_id_next– una referencia al jugador que debe hacer el próximo movimiento en el juego actual.result_id_1yresult_id_2– referencias alresulttabla que almacena el resultado del juego para cada jugador.player_1_points_wonyplayer_2_points_won– indicar el número de puntos que se otorgaron a los jugadores, de acuerdo con el resultado del juego.
Discutiremos cómo los jugadores pueden realizar un seguimiento de todos los movimientos en la sección Partidos cerca del final de este artículo. Por ahora, pasaremos a la configuración del juego.
Sección 2:Configuración del juego
La sección Configuración del juego contiene una descripción de todos los tableros y piezas del ajedrez 3D, así como una lista de todos los movimientos legales que pueden realizar los jugadores.
Como mencionamos anteriormente, el ajedrez 3D a menudo involucra más de un tablero. Estos tableros pueden adherirse a las dimensiones estándar de 8x8 con posiciones fijas, pero ese no tiene por qué ser el caso. La lista de todos los tableros se almacena en el board mesa. Para cada tablero, almacenaremos un board_name único , la starting_position del tablero en relación con nuestras coordenadas 3D elegidas, y todos los details adicionales .
A continuación, definiremos todos los posibles tipos de piezas que podrían aparecer en nuestros tableros de ajedrez. Para ello, utilizaremos el piece_type diccionario. Además de su clave principal, este diccionario contiene solo un valor único, type_name. Para un juego de ajedrez estándar, esperamos ver los valores "peón", "torre", "caballo", "alfil", "rey" y "reina" en este diccionario.
La lista de todas las piezas individuales que se utilizan en un juego de ajedrez 3D se almacena en la piece mesa. Para cada pieza, almacenaremos la siguiente información:
piece_name– un nombre único que describa el tipo de pieza y su posición inicial.starting_position– un valor que indica el tablero y la casilla precisos en los que se coloca inicialmente la pieza.board_id– una referencia al tablero en el que se colocó originalmente la pieza.piece_type_id– una referencia que indica el tipo de pieza.
Finalmente, usaremos el move_type tabla para almacenar la lista de todos los movimientos posibles que pueden hacer las piezas en nuestros tableros (así como cualquier movimiento que pueden hacer los propios tableros). Recuerda de la introducción que ciertos tableros aplican reglas especiales de movimiento a sus piezas. Para cada movimiento, definiremos lo siguiente:
type_name– un nombre que usaremos para indicar el movimiento que se realizó, que no será un valor único (p. ej., podemos tener un "peón avanzado 1 casilla hacia adelante" tantas veces como sea necesario).piece_type_id– una referencia al tipo de pieza que se movió. Si este valor resulta ser NULL, entonces el movimiento se refiere a un tablero completo y no a una pieza en particular.board_id– indica el tablero en el que tendrá lugar este movimiento (si se está moviendo una pieza de ajedrez). Si el tablero en sí se está moviendo, este valor representará naturalmente el tablero que se está moviendo. Junto con los dos atributos anteriores, esto forma la clave única para esta tabla.is_piece_moveyis_board_move– indicar si un movimiento se refiere a una pieza de ajedrez o un tablero. Solo una de estas banderas puede establecerse en verdadero para un movimiento en particular.
Dado que hay demasiados movimientos de piezas y rotaciones para considerar, no almacenaremos todas esas posibilidades en nuestra base de datos. En cambio, solo almacenaremos los nombres de los movimientos e implementaremos la lógica real en la aplicación misma. Por ejemplo, definiremos que los peones pueden avanzar una sola casilla, avanzar dos casillas desde su posición inicial, reclamar piezas en diagonal, moverse de un tablero a otro y moverse como una reina en el tablero central. Por lo tanto, tendremos cinco tipos de movimientos posibles definidos para los peones, según el tablero en el que se coloquen y su posición actual.
Sección 3:Partidos
¡Ya casi terminamos! La última sección de nuestro modelo se llama Partidos y contiene tres tablas nuevas que usaremos para realizar un seguimiento del historial de movimientos en un juego de ajedrez en 3D. Las tablas restantes son solo copias de otras tablas de nuestro modelo de datos, lo que ayuda a evitar la superposición de relaciones. También almacenaremos las posiciones actuales de todos los tableros y sus piezas en esta área. Empecemos de lleno.
El move table es en realidad la tabla más compleja de esta sección. Contiene la lista de todos los movimientos ejecutados durante un juego. Esta tabla mostrará la lista de todos los movimientos de los jugadores, que luego se puede usar para revisar o analizar el partido. Para cada movimiento, almacenaremos lo siguiente:
game_id– una referencia algameen el que se realizó el movimiento.player_id– una referencia alplayerquién hizo el movimiento.move_in_the_game– el número ordinal del movimiento. Este número, combinado con la posición inicial de una pieza y todos los demás movimientos, se puede usar para recrear todo el juego. La idea es permitir que los jugadores simulen el juego una vez que se completa para que puedan analizar los resultados del partido.piece_id– una referencia a lapieceque se movió. Esto facilita el seguimiento del movimiento de una pieza de principio a fin (principalmente con fines de análisis).piece_type_id– una referencia al tipo de pieza que se movió. Si bien la referencia de una pieza siempre permanecerá constante, su tipo puede cambiar a lo largo del juego (por ejemplo, si se corona un peón). Si estamos moviendo el tablero, este atributo contendrá un valor de NULL.board_id– una referencia alboarden el que se realizó la mudanza.move_notation– una notación acordada que usaremos para representar movimientos.
Las dos tablas restantes nos permiten almacenar una instantánea del estado actual del juego en la base de datos, lo que es útil si los jugadores desean reanudar el juego en otro momento.
La current_board_position se utiliza para almacenar la posición de todos los tableros en nuestro sistema de coordenadas 3D. Esto es necesario para los juegos de ajedrez en 3D en los que al menos un tablero puede cambiar de posición. Para cada registro en esta tabla, almacenaremos una referencia al juego y tablero relacionados, así como la notación de la posición de un tablero. Dos pares de atributos específicos, game_id + board_id y game_id + position_notation , forman las claves únicas para esta tabla.
Nuestra última tabla es current_piece_position , que almacena referencias al juego relacionado, una pieza en particular, el tipo de pieza y una notación de posición para la pieza. Nuevamente tendremos dos pares de atributos que sirven como claves únicas para esta tabla:el game_id y piece_id par y el game_id y position_notation pareja.
Conclusión
Eso es todo para este modelo de datos:¡nos enorgullece anunciar que el Capitán Kirk y el Sr. Spock ahora pueden jugar ajedrez 3D en una computadora!
¿Tiene alguna sugerencia para mejorar nuestro modelo de datos? Siéntete libre de dejar tus comentarios abajo. Larga vida y prosperidad ??
