ChessBook

Projeto para a cadeira de Construção de Sistemas de Software (CSS) (2021/2022)

Instruções:

• Dentro de um jogo, a interface suporta as seguintes interações:
  • Escrever duas coordernadas válidas no formato xy xy em que x é a letra correspondente à file/coluna (de "a" a "h") e y é o número inteiro correspondente à rank/linha (de 1 a 8).
  • Escrever castle long para queen-side castling, e castle short para king-side castling, quando possível e válido.
  • Escrever resign para desistir e facultar a vitória ao adversário.

Funcionalidades 1ª fase:

• Construído em Maven
• Integração com JPA
• Verificação da validade de jogada para cada peça
• Verificação de cheque
• Test Coverage de 78%
• Versão human-readable de cada classe (toString())

Funcionalidades 2ª fase:

• Verificação de validade de jogadas para todo o tipo de peças (capturas + pushes)
• Verificação de check:
  • A verificação de check é sempre correta, sendo que emula uma jogada e verifica se esta causará ainda check, permitindo-nos avaliar até as possições mais teoricamente complicadas, como absolute e relative pins.
• Castling (completamente suportado!):
  • A nossa implementação de castling funciona para os dois lados, apenas nas condições corretas segundo as regras FIDE. Invocável através de castle long (para queen-side castling) e castle short (para king-side castling)
• Desenvolvemos um gerador de jogadas legais e pseudo-legais, que nos permite determinar com toda a certeza se uma posição é checkmate (check e sem jogadas legais para uma equipa) ou stalemate (sem jogadas legais, mas sem estar em check).
• Deteção de vários finais de jogo, são atualmente suportados:
  • Vitória por checkmate
  • Vitória por desistência
  • Vitória por timeout
  • Empate por stalemate
  • Empate por material insuficiente (rei vs. rei)
  • Empate por limite de _moves (segundo regras FIDE)
• Gestão de tempo:
  • A nossa implementação de gestão de tempo é flexível de forma a suportar vários tipos de duração de jogo, sendo que toda a lógica do programa relativa à gestão de tempo utiliza o atributo ChessGame.timeControl, e funcionaria corretamente para qualquer valor que este tivesse (em minutos). No entanto, no âmbito do projeto, decidimos apenas que cada jogo fosse de 15 minutos, por questões de simplicidade.
  • Ao iniciar um jogo, o tempo começará a contar apenas quando a pessoa com as peças brancas estiver pronta para fazer a primeira jogada (estiver na página de jogo sendo a sua vez).
  • O tempo para de contar após a jogada de um jogador, retomando quando o jogador oposto vê a jogada pela primeira vez (primeira vez que entrar no jogo após uma jogada ser feita).
    • Portanto, a seguinte situação de exemplo é possível:
      • O jogador A faz uma jogada
      • Até o jogador B ver a nova jogada de A, nenhum dos tempos será decrementado
      • O tempo utilizado pelo jogador B entre o momento em que este vê a jogada de A e faz a sua própria jogada será decrementado no seu tempo total
      • O jogador B faz uma jogada
      • Até o jogador A ver a nova jogada de B, nenhum dos tempos será decrementado
      • (e por aí em diante)
  • Através da página de perfil (My Games) é possível ver, em tempo real (atualizando) quanto tempo um jogador têm no respetivo jogo.
  • Um total de uso de tempo para lá do time control resultará em vitória do adversário por timeout.
    • Se for necessário alterar o time control (duração de um jogo) por razões de teste, este poderá facilmente ser editado no atributo ChessGame.timeControl, em minutos (default 15)
• Replay:
  • Esta funcionalidade permite rever um jogo, jogada a jogada, após este terminar.
• Promoção de peão:
  • De acordo com as regras FIDE, o jogador tem a possibilidade de escolher uma nova peça conforme um dos seus peões chega ao fim do tabuleiro. A suporta a promoção de peões, e é flexível de forma a que se pudesse escolher qualquer tipo de nova peça, no entanto, por falta de uma boa maneira de interface de escolha, decidímos implementar (à semelhança de alguns sites de xadrez) o que se chama de auto-queening, em que o peão é automaticamente promovido para uma rainha.
• Estética melhorada:
  • Graças ao tempo extra fornecido pelo professor, foi-nos possível não só implementar praticamente todas as funcionalidades que previamente descrevemos como shortcomings, mas também melhorar a interface do programa de modo a que a utilização seja mais fácil, prática, e bonita. (e.g. uso de bootstrap, board personalizado para além do toString, aviso de rei em check, uso de Font Awesome Icons)
• Estrutura:
  • A nossa implementação conta com uma estrutura que divide a camada de apresentação das outras camadas de forma muito clara e explícita, o que torna o código organizado e fácil de manter/alterar.

Shortcomings (funcionalidades não suportadas ou em progresso, por ordem de importância):

• Gestão de tempo (praticamente funcional, será a próxima funcionalidade a ser implementada)
• Promoção de peão
• Replay
• Estética melhorada
• Finalização de jogo por repetição de posição (simples de implementar, passado à frente por questões de tempo)
• En passant

Modelo de Domínio: