ETruco Code

Trabalhei nas imagens das telas e nas cartas

Tirei uma regra q nao existe, q eh no caso da segunda mao empatar, pelas regras q nos colocamos, se alguem ganha a primeira e empatar a segunda o jogo ja esta ganho, isso eh mto injusto.

Antes o metodo execute da regra tinha de definir oq/pra qm mandar a mensagem, agora foi criado um metodo separado dentro da classe regra, chamado send_my_message, onde o execute trata toda a parte de logica da regra, e o send_my_message trata a parte de rede da regra.
Vale lembrar q os dois ultimos parametros q o send_my_message recebe sao fixos, no caso do servidor o ultimo eh o servidor e o penultimo eh o cliente q mandou a msg, e no caso do cliente soh o ultimo eh usado, sendo este o propio cliente.

Criei um metodo chamado handle_message, esse metodo eh chamado toda vez que o servidor ou cliente recebe uma mensagem, eh um metodo "abstrato", as classes derivadas q tem q dizer como essas mensagens serao tratadas.

Soh consertando alguns problemas de mal funcionamento, ao testar libs percebi q estava com problemas de envio e recebimento de msgs =X. Mas agora jah esta tudo ok.
A classe Action_Handler foi removida, antes um dealer ou um player executava uma acao, q essa implicava em execucao de uma ou mais regras, mas isso iria prejudicar e mto no carregamento de regras dinamico escolhido pelo usuario, entao decidi q um dealer ou um player executara uma regra direto.

Novamente a biblioteca mudou de nome. Mas dessa vez nao foi soh o nome q mudou.
Foi criado um framework chamdo DIS.CAR.GA (Distributed Card Game), onde uniu todas as coisas q eu fiz, tratamento de regras com tratamento de mensagens.
Agora toda a lógica de jogo fica por conta das regras, antes ainda se armazenava na classe principal jogadores, baralho, etc. Agora tudo isso vai ser armazenado nas regras, as regras serao completamente toda a logica de jogo.
Com a nova tematica de carregamento de regras ficou mais facil de manter a logica de jogo somente nas regras. Existe uma classe principal de onde todas as regras herdam, a partir dai fica a criterio do desenvolvedor trabalhar as classes de regras, desde que elas implementem o metodo execute(vector<void*>&), q eh nele q a magica acontece.

A ipcpp agora eh somente um wrapper do Ecore-IPC.
Antes ela registrava mensagens de uma arquivo xml onde cada msg tinha uma funcao pra ser executada.
Agora isso fica por conta de uma classe q a herde.

Coloquei todos os membros da classe como static.
Jah q essa classe nao possui atributos nao faz sentido criar objetos.
Nao foi criado um namespce ao inves de uma classe estatica pq existem metodos privados.

Agora pode ser registrada uma mensagem sem uma funcao callback. Os dados sao enviados sem nenhum tratamento.

Todos os using namespace dos .Hs foram tirados. O motivo foi por conta da criacao dos namespaces proprios, usar outros namespaces com criacao do seu namespace o torna sujo e dependente.

Novamente foi mudada a estrutura de como a libcardgame funciona. Agora nao se carrega uma funcao, e sim um objeto. Desse novo jeito ficou bem mais no estilo de orientacao a objetos. Mas para isso ocorrer vao precisar de mudancas fundamentais nas implementacoes das regras. Agora TODA regra eh uma classe derivada da classe Rule, onde ela tem um metodo chamado execute, q sempre sera chamado pela classe libcardgame. Sim, sera necessario criar uma classe diferente para cada regra. O carregamento do objeto vai ocorrer da seguinte forma: existira uma biblioca com todas as regras instanciadas, objetos. O nome deste objeto eh o nome da regra q sera carregada, no xml vc diz esse nome, e ao carregar a biblioteca sera procurados objetos pelo nome da regra no xml.