brunoabdon/domino

Jogo de Dominó programável 🁏

domino's Issues

O autor poderia disponibilizar um guia para a execução do projeto na maquina do usuario?

Estou com problemas para executar esse projeto em minha maquina.
Poderia me disponibilizar as ferramentas necessárias?

Jogador iterativo

Implementar um Jogador que simplesmente pergunta a um humano que Pedra jogar.

Seria a possibilidade de uma pessoa jogar contra as classes.

Esse jogador exibiria uma gui com as pedras na mão dele, e jogaria a que recebesse um click do mouse, etc.

Empatando a primeira rodada, quem começa a segunda?

Normalmente, a primeira rodada começa com quem tem o Dozão (a maior carroça, na verdade) e as próximas começam sempre pela dupla que bateu na rodada anterior.

Se a rodada anterior empatou, eu acho que começa a mesma dupla que começou a anterior.

Mas se a rodada anterior foi a primeira? Quem começa essa pós empate? Quem tiver o Dozão, ou a mesma dupla que começou a anterior (por ter tido o Dozão antes?)

Também acho que o código não tá preparado pra isso. Nunca pensei nesse caso.

Mesa não limpa cabeças quando a partida começa

Quando uma partida começa, mesa.getNumeroDireita() e mesa.getNumeroEsquerda() estão retornando os valores da última rodada da partida anterior. Isso é um bug em MesaImpl.

Quando o evento "partidaComeçou" for lançado, a mesa tem que estar consistentemente limpa.

Criar um enum pra "vontade de começar"

Fica mais simples de entender se o jogador expressar a "vontade de começar uma partida" com um enum do que com um inteiro que deve ser limitado entre 0 e 10.

Pode ter só uns cinco valores, tipo: QUERO_MUITO, QUERO, TANTO_FAZ, NAO_QUERO, QUERO_DE_JEITO_NENHUM.

Permitir adicionar listeners pelo domino-config.xml

O arquivo de configuração deve ter um elemento pra se configurar classes de listeners, que a aplicação vai instanciar e associar ao jogo.

Talvez precise criar um método de inicialização pros listeners, permitindo passar um mapa de parâmetros pelo xml....

Ou talvez deveria existir uma anotação @Listener ?

Atualizar o GroupId pra com.github.abdonia.domino

Segundo o manual, o groupId deve identificar o projeto enquanto o artifacId identifica o artefato (o jar).

O Logger deveria informar quando o jogo é abortado

O logger deveria suportar os novos eventos criados depois de #26.

Criar dtd pra o domino-config.xml

A dtd pro xml deve ser criada. Os xml exisentes devem declarar a dtd e a (inner) classe ConfigHandler deve chamar setValdidating(true) no SaxParserFactory

Incialização da lista `Jogadores` em `MesaImpl` está errada.

Incialização da lista Jogadores em MesaImpl está inclui jogador2dupla1 duas vezes e jogador1dupla2 nenhuma.

Jogar por rede

Permitir Jogadores jogarem remotamente, sem ter que copiar o código pra a maquina onde está rodando o jogo.

Implementar um visualizador de resultados em massa

Implementar um visualizador que roda zilhões de jogos de uma vez e fica mostrando um gráfico ao vivo (em barras?) quem está ganhando mais.

É possível fingir que tocou

Se um jogador disser que tocou tendo pedra jogável na mão, o jogo continua normalmente. Isso é roubo. Tem que verificar.

Fazer cache de Jogadas?

Será que não vale a pena criar previamente todas as instâncias possíveis de br.nom.abdon.domino.Jogada?

Existem 57 Jogadas possíveis:

• cada uma das 28 Pedras pra Esquerda; mais
• cada uma das 28 Pedras pra Direita; mais
• o toque

Uma Partida deve ter no mínimo umas 20 jogadas (chutando!). Um Jogo inteiro 4 vezes mais. Talvez, pra um único Jogo, não valha a pena. Mas, pra vários, deve começar a valer a pena rápido.

A classe br.nom.abdon.domino.Jogada esconderia seu construtor e exporia um método estático que retornaria uma Jogada, dado o Lado e a Pedra.

Toda Jogada seria imutável.

(A preocupação que a classe Partida tem em chamar getLado() e getPedra() só uma vez seria eliminada)

A classe em si deveria seria final...

...não seria então o caso de ser um enum também?

Melhorar o esquema de excecões

Jogo.jogar() deveria lançar uma exceção que, pelo seu tipo, poderia identificar se houve um erro de configuração, erro por parte de um dos jogadores ou algum outro erro inesperado.

Erros no arquivo xml em DominoApp deveria gerar mensagens de erro no System.err, e não stack traces.

LoggerDominoEventListener deveria dar flush

LoggerDominoEventListener deveria dar flush no printWriter pelo menos nos eventos de fim de jogo ("jogoAcabou" e os eventos de bug de jogador).

Contagem de pontos da empate sem ser

Na contagem de pontos quando a partida trava (todos os jogadores tocam), existe pelo menos um senário onde o jogo erra na contagem:

Se o primeiro e o segundo jogador tiver o mesmo número de pontos na mão, o terceiro tiver mais que eles e o quarto menos, o quarto deveria ganhar. O resultado tá saindo empate.

Implementar um Gravador / Reprodutor de jogos

Implementar um Gravador de Jogos que, ouvindo os eventos de um jogo, vá gravando o jogo e persista ele em algum arquivo.

Esse arquivo poderia então ser lido depois pelo Reprodutor de Jogos, que iria vendo o que aconteceu e disparando os eventos correspondentes. Se conectado à interface gráfica, seria possível reassistir o jogo.

Jogos salvos também seriam bons pra se estudar estatistificas do que acontece.

A Pedra LIMPO_DUQUE (🁥) deve aparecer antes da CARROCA_DE_PIO (🁫)

De acordo com o critério de ordenação do enum Pedra, 🁥 < 🁫.

Jogador deveria receber pedras soltas, e não um array

O método Jogador.recebeMao() deveria receber 6 Pedras, e não um array. Cabe ao jogador decidir que estrutura de dados usar pra armazenar as pedras. Também isso daria a garantia que são 6 pedras.

Tornar o gerador de aleatoriedade configurável no `DominoConfig`/ `domino-config.xml`

O bean DominoConfig deve ter um atributo do tipo com.github.abdonia.domino.motor.RandomGoddess, para ser configurável como será a geração de aleatoriedade do jogo. Esse parâmetro deve poder ser lido do domino-config.xml.

A classe Jogo não precisa mais ter um construtor recebendo RandomGoddess (se #19 for implementado).

O atributo deve ser considerado opcional. A implementação com.github.abdonia.domino.motor.DefaultRandomGoddess deve continua a ser usada quando nenhuma é especificada.

Criar eventos pra situações que abortam o jogo

Criar eventos (na OmniscientDominoEventListener) pra quando ocorre um bug de um jogador e o jogo é cancelado. Tipo:

   public void jogadorJogouPedraInvalida(int jogador, Lado lado, Pedra pedra);

   public void jogadorTentouRemoverPedraDaMesa(int jogador);

   public void jogadorErrouVontadeDeComeçar(int jogador);

   public void jogadorFaleceu(int jogador); //lançou uma RuntimeException....

Talvez criar também um evento pra dizer que o Jogo foi cancelado. Ou não, fica explicitado na documentação que esses eventos indicam o cancelamento da partida.

Uma UI pode querer reportar esses acontecimentos. E isso evita que Jogo.jogar(conf) precise silenciar completamente exceçães de jogadores ou de lançar elas.

Fazer um manual pra iniciantes

Fazer um manual pra iniciantes, que a pessoa leia e saiba implementar um Jogador e botar pra rodar uma partida, pelo menos.

Usar Maven

Usar Maven pra fazer build do sistema todo.

DepShield Deprecation Notice

Depshield will be deprecated on Monday December 12th

Please install our new product, Sonatype Lift with advanced features

Padronizar nome dos métodos

Alguns métodos booleanos estão usado is (como Pedra.isCarroca()) enquanto outros estão usando eh ou ta (Mesa.taVazia()). O ideal seria padronizar.

O método Jogador.vontadeDeComecar() deveria ser um verbo (ver "Naming a Method" em Defining Methods ou "Methods" em 9 - Naming Conventions)

Um evento deveria avisar qual foi o dorme

Mesmo sendo possível prever quais pedras foram pro dorme baseado nas pedras que foram distribuídas pros jogadores, deveria haver um evento específico anunciando quais pedras que foram pro dorme.

[DepShield] (CVSS 7.5) Vulnerability due to usage of org.yaml:snakeyaml:1.24

Vulnerabilities

DepShield reports that this application's usage of org.yaml:snakeyaml:1.24 results in the following vulnerability(s):

• (CVSS 7.5) [CVE-2017-18640] The Alias feature in SnakeYAML 1.18 allows entity expansion during a load operat...

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Saber como foi escolhido quem começou a partida

Quando uma dupla começa a partida (por ter vencido a anterior), os jogadores não têm atualmente como saber se o Jogador da dupla que começou foi escolhido por ter querido começar mais que o outro, ou se quis tanto quanto e foi escolhido aleatoriamente.

Num jogo real, essa informação é acessível a todos os jogadores. Deveria haver um evento anunciando o desfecho das decisões de "quer começar".

Essa informação é útil por exemplo, pra saber se a mão do parceiro tá boa ou não, e decidir adotar a uma estratégia de jogar se sacrificando pelo parceiro.

Esconder JogadorWrapper, expor DominoConfig

O construtor da classe Jogo deve receber um DominoConfig, ao invés de receber 4 JogadorWrapper.

A classe 'JogadorWrapper` não deve mais ser pública (só é usada internamente pelo motor).

A classe DominoConfig deve ser movida pra o pacote com.github.abdonia.domino.motor (continuando pública), por "outros mains" vão utilizar ela pra criar Jogos.

A criação de 'JogadorWrappers que acontece em DominoAppdeve acontecer agora emJogo(ou em alguma classe utilitária interna do pacote) (ou num método de visibilidadedefaultdentro doDominoConfig`!).

Deve ser possível saber quantas pedras os outros Jogadores têm

Na vida real, quando um jogador vai jogar, ele tem acesso a informação de quantas pedras cada um dos outros tem na mão. Se ele perguntar, a galera tem que dizer. Não pode ficar escondendo não.

Como está implementado, o cara só sabe de quantas pedras os outros têm se for contando.

DominoConfig deveria aceitar instâncias e literais de classes

DominoConfig não deveria aceitar apensas Strings dos nomes das classes. Deveria aceitar também instâncias e literais de classes, dando mais de uma opção pra as classes que usam.

Deve ser possível setar o Jogador 3 com: getClasseJogador2Dupla1(String) ou getClasseJogador2Dupla1(Class). Chamando as duas versões pra o mesmo jogador, a posterior sobrescreve a anterior.

Deve existir também o setJogador2Dupla1(Jogador j).

O mesmo deve valer pra EventListeners e pra a RandomGodess.

Applicação morre se um eventlistener lança uma RuntimeException

A aplicação deveria ser um pouco mais robusta e tentar lidar melhor com erros nos eventListeners, inclusive, em jogadores.

Primeiro Jogador com mais chances de ter 6 carroças

Num teste que rodou 323.385 jogos, de um total de 2.336.737 partidas, 49 tiveram morte súbita por 6 carroças na mão. Estranhamente, em todos os casos, foi o primeiro jogador que teve as 6 carroças.

Analisando o log, não parece ter sido um erro do logger (escrevendo sempre o nome do primeiro jogador). De fato, o primeiro jogador sempre recebia 6 carroças.

5 carroças volta. 6 ganha um ponto

O jogo ainda não implementa a regra de que, quando um jogador começa com 5 carroças, a partida é anulada (volta as pedras, embaralha e começa de novo), e quando um começa com 6, a partida termina como vitória da dupla desse jogador, valendo 1 ponto.

Pedra.carrocas pode ser modificado por qualquer um

O Pedra exibe um atributo carrocas publico, teoricamente pra ajudar. Mas assim qualquer classe pode alterar seu conteúdo. Ele não é confiável.

Implementar uma interface gráfica

Implementar uma interface gráfica, onde dê pra assistir o jogo.

Configurações avançadas: Usar cache

A classe DominoEventBroadcaster atualmente faz um cache de "jogadas de jogadores" que só é útil caso vários jogos forem ser jogados em seqüência. Pra rodar só um Jogo, esse cache até atrapalha (pq nunca, num mesmo jogo, vai se repetir do mesmo jogador jogar a mesma pedra do mesmo lado).

Esse cache deveria ser usado só quando solicitado. Seria uma configuração opcional em DominoConfig, que diria pra o Jogo usar ou não um broacaster com cache (default seria não usar).

Mover a UI pra outro projeto

Mover as classes de (tentativa de) UI com Java Fx pra um outro projeto.

DepShield encountered errors while building your project

The project could not be analyzed because of build errors. Please review the error messages here. Another build will be scheduled when a change to a manifest file^* occurs. If the build is successful this issue will be closed, otherwise the error message will be updated.

_{This is an automated GitHub Issue created by Sonatype DepShield. GitHub Apps, including DepShield, can be managed from the Developer settings of the repository administrators.}

_{* Supported manifest files are: pom.xml, package.json, package-lock.json, npm-shrinkwrap.json, Cargo.lock, Cargo.toml, main.rs, lib.rs, build.gradle, build.gradle.kts, settings.gradle, settings.gradle.kts, gradle.properties, gradle-wrapper.properties, go.mod, go.sum}