Modelo de Dados de Xadrez 3D de Jornada nas Estrelas

Se você é fã de Star Trek, provavelmente sabe que o Capitão Kirk e o Sr. Spock frequentemente jogam uma variante de xadrez chamada Tri-Dimensional Chess, ou xadrez 3D, um jogo semelhante ao xadrez padrão, mas com diferenças notáveis. Neste artigo, construiremos um modelo de dados para um aplicativo de xadrez 3D que permite que os jogadores compitam uns contra os outros. Envie-nos para cima, Scotty!

O conceito de xadrez 3D

Embora o xadrez em si já seja um jogo complexo, combinar tabuleiros e vários conjuntos de peças pode aumentar significativamente a complexidade do jogo.

No xadrez 3D, os tabuleiros são empilhados em camadas paralelas e regras especiais de movimento se aplicam a certas peças, dependendo de onde elas estão localizadas. Por exemplo, peões no tabuleiro do meio podem imitar o comportamento de uma rainha. As peças também podem se mover de um tabuleiro para outro, com certas restrições aplicadas, e os próprios tabuleiros podem até se mover e girar. Não é de se admirar que Kirk e Spock gostassem tanto de xadrez 3D – requer bastante sutileza tática!

O xadrez tridimensional também se desvia do xadrez padrão em termos das propriedades de seus tabuleiros. No xadrez 3D, existem sete tabuleiros distintos com propriedades diferentes. Três dessas placas são 4x4, enquanto as quatro placas restantes são 2x2. Você pode mover essas placas menores.

Esperamos que nosso modelo de dados cubra tudo o que precisamos para jogar uma partida de xadrez 3D em um aplicativo da web. Vamos trabalhar com a suposição de que tudo pode se mover e que os tabuleiros podem impor diferentes restrições de movimento às mesmas peças. Isso deve ser suficiente para cobrir todas as variantes de xadrez 3D possíveis. Vamos pular direto para o modelo de dados!

O modelo de dados

Nosso modelo de dados consiste em três seções:

Jogadores e jogos
Configuração do jogo
Correspondências

Vamos agora discutir cada uma dessas áreas em mais detalhes.

Seção 1:Jogadores e Jogos

Tudo em nosso modelo está direta ou indiretamente relacionado a jogos. Claro, um jogo não pode prosseguir sem jogadores!

A lista de todos os jogadores é armazenada no player tabela. Em nosso modelo, os jogadores são todos os usuários registrados do nosso aplicativo. Para cada jogador, armazenaremos as seguintes informações:

first_name e last_name – o nome e sobrenome do jogador, respectivamente.
user_name – o nome de usuário que o jogador selecionou, que deve ser único.
password – um valor de hash da senha do jogador.
nickname – o nome de tela do jogador, que, assim como o nome de usuário, deve ser exclusivo.
email – o endereço de e-mail do jogador, que ele fornecerá durante o processo de registro. O código necessário para concluir o processo de registro será enviado para este e-mail.
confirmation_code – o código que foi enviado para o endereço de e-mail do jogador para concluir o processo de registro.
confirmation_date – o carimbo de data/hora de quando o jogador confirmou seu endereço de e-mail. Este atributo armazenará NULL até que o jogador confirme seu e-mail.
current_rating – a classificação atual do jogador, calculada com base em seu desempenho em relação a outros jogadores. Os jogadores começarão com algum valor inicial e suas classificações aumentarão ou diminuirão de acordo com as classificações de seus oponentes e os resultados do jogo.

O result table é um dicionário que armazena os valores de todos os resultados únicos possíveis do jogo, ou seja, “in_progress”, “draw”, “win” e “lose”.

Talvez a tabela mais importante em todo o modelo de dados seja game , que armazena informações sobre cada jogo de xadrez 3D. Neste modelo, vamos supor que dois jogadores humanos competirão entre si e que eles podem optar por salvar seu estado de jogo atual e retomar mais tarde (como se eles quisessem fazer um movimento por dia, em Nesse caso, os jogadores farão login no aplicativo, verão o movimento mais recente do oponente, pensarão em seu próprio movimento, executarão seu movimento e sairão). Armazenaremos os seguintes valores nesta tabela:

player_id_1 e player_id_2 – referências ao player tabela denotando ambos os participantes de um jogo. Como mencionado, estamos assumindo que um jogo ocorrerá estritamente entre dois jogadores humanos.

number_of_moves – denota o número de movimentos que foram executados até agora no jogo atual. Quando o jogo começa, esse número é definido como 0 e aumenta em 1 cada vez que um jogador faz um movimento.

player_id_next – uma referência ao jogador que deve fazer a próxima jogada no jogo atual.

result_id_1 e result_id_2 – referências ao result tabela que armazena o resultado do jogo para cada jogador.

player_1_points_won e player_2_points_won – denotar o número de pontos que os jogadores receberam, de acordo com o resultado do jogo.

Discutiremos como os jogadores podem acompanhar todos os movimentos na seção Partidas perto do final deste artigo. Por enquanto, vamos passar para a configuração do jogo.

Seção 2:Configuração do jogo

A seção Configuração do Jogo contém uma descrição de todos os tabuleiros e peças no xadrez 3D, bem como uma lista de todos os movimentos legais que os jogadores podem fazer.

Como mencionamos anteriormente, o xadrez 3D geralmente envolve mais de um tabuleiro. Essas placas podem aderir às dimensões padrão 8x8 com posições fixas, mas isso não precisa ser o caso. A lista de todos os quadros é armazenada no board tabela. Para cada quadro, armazenaremos um board_name exclusivo , a starting_position do tabuleiro em relação às nossas coordenadas 3D escolhidas e todos os details adicionais .

A seguir, definiremos todos os tipos possíveis de peças que podem aparecer em nossos tabuleiros de xadrez. Para fazer isso, usaremos o piece_type dicionário. Além de sua chave primária, esse dicionário contém apenas um valor exclusivo, type_name. Para um jogo de xadrez padrão, esperamos ver os valores “peão”, “torre”, “cavaleiro”, “bispo”, “rei” e “rainha” neste dicionário.

A lista de todas as peças individuais que são usadas em um jogo de xadrez 3D é armazenada na piece tabela. Para cada peça, armazenaremos as seguintes informações:

piece_name – um nome exclusivo que descreve o tipo de peça e sua posição inicial.

starting_position – um valor que denota o tabuleiro e a casa precisos em que a peça está inicialmente posicionada.

board_id – uma referência ao tabuleiro no qual a peça está originalmente posicionada.

piece_type_id – uma referência indicando o tipo da peça.

Por fim, usaremos o move_type table para armazenar a lista de todos os movimentos possíveis que as peças podem fazer em nossos tabuleiros (assim como todos os movimentos que os próprios tabuleiros podem fazer). Lembre-se da introdução que certos tabuleiros aplicam regras especiais de movimento às suas peças. Para cada movimento, definiremos o seguinte:

type_name – um nome que usaremos para denotar o movimento que foi feito, que não será um valor único (por exemplo, podemos ter “peão avançado 1 casa para frente” quantas vezes forem necessárias).

piece_type_id – uma referência ao tipo de peça que foi movida. Se esse valor for NULL, então o movimento diz respeito a um tabuleiro inteiro e não a uma peça em particular.

board_id – denota o tabuleiro no qual esse movimento ocorrerá (se uma peça de xadrez estiver se movendo). Se o próprio tabuleiro estiver se movendo, esse valor representará naturalmente o tabuleiro que está sendo movido. Juntamente com dois atributos anteriores, isso forma a chave exclusiva para esta tabela.

is_piece_move e is_board_move – denotam se um movimento diz respeito a uma peça de xadrez ou a um tabuleiro. Apenas um desses sinalizadores pode ser definido como verdadeiro para um movimento específico.

Como há muitos movimentos e rotações de peças a serem considerados, não armazenaremos todas essas possibilidades em nosso banco de dados. Em vez disso, apenas armazenaremos os nomes dos movimentos e implementaremos a lógica real no próprio aplicativo. Por exemplo, definiremos que os peões podem avançar uma única casa, avançar duas casas de sua posição inicial, reivindicar peças na diagonal, mover de um tabuleiro para outro e se mover como uma rainha no tabuleiro central. Assim, teremos cinco tipos de movimentos possíveis definidos para os peões, dependendo do tabuleiro em que estão colocados e de sua posição atual.

Seção 3:Correspondências

Estamos quase terminando! A última seção do nosso modelo se chama Partidas e contém três novas tabelas que usaremos para acompanhar o histórico de movimentos em uma partida de xadrez 3D. As tabelas restantes são apenas cópias de outras tabelas do nosso modelo de dados, o que ajuda a evitar relações sobrepostas. Também armazenaremos as posições atuais de todos os tabuleiros e suas peças nesta área. Vamos mergulhar direto.

O move table é, na verdade, a tabela mais complexa desta seção. Ele contém a lista de todos os movimentos executados durante um jogo. Esta tabela exibirá a lista de todos os lances para os jogadores, que podem ser usados posteriormente para revisar ou analisar a partida. Para cada movimento, armazenaremos o seguinte:

game_id – uma referência ao game em que a mudança foi feita.

player_id – uma referência ao player quem fez a mudança.

move_in_the_game – o número ordinal do movimento. Este número, combinado com a posição inicial de uma peça e todos os outros movimentos, pode ser usado para recriar todo o jogo. A ideia é permitir que os jogadores simulem o jogo depois de concluído para que possam analisar os resultados da partida.

piece_id – uma referência à piece que foi movido. Isso facilita o rastreamento do movimento de uma peça do início ao fim (principalmente para fins de análise).

piece_type_id – uma referência ao tipo de peça que foi movida. Embora a referência de uma peça sempre permaneça constante, seu tipo pode mudar ao longo do jogo (como se um peão for promovido). Se estivermos movendo o quadro, esse atributo conterá um valor NULL.

board_id – uma referência ao board em que a mudança ocorreu.

move_notation – uma notação acordada que usaremos para representar movimentos.

As duas tabelas restantes nos permitem armazenar um instantâneo do estado atual do jogo no banco de dados, o que é útil se os jogadores desejarem retomar o jogo mais tarde.

A current_board_position é usado para armazenar a posição de todas as placas em nosso sistema de coordenadas 3D. Isso é necessário para jogos de xadrez 3D em que pelo menos um tabuleiro pode mudar sua posição. Para cada registro nesta tabela, armazenaremos uma referência ao jogo e ao tabuleiro relacionados, bem como a notação da posição do tabuleiro. Dois pares de atributos específicos, game_id + board_id e game_id + position_notation , formam as chaves exclusivas para esta tabela.

Nossa última tabela é current_piece_position , que armazena referências ao jogo relacionado, uma peça em particular, o tipo de peça e uma notação de posição para a peça. Teremos novamente dois pares de atributos que servem como chaves exclusivas para esta tabela:o game_id e piece_id par e o game_id e position_notation par.

Conclusão

Isso é tudo para este modelo de dados - estamos orgulhosos de anunciar que o Capitão Kirk e o Sr. Spock agora podem jogar xadrez 3D em um computador!

Você tem alguma sugestão para melhorar nosso modelo de dados? Sinta-se à vontade para deixar seus comentários abaixo. Vida longa e próspera ??