Funcionalidades
Em termos de funcionalidades efetivas, isso é, coisas que o usuário percebe, temos o seguinte:
- Barra de vida: Agora a barra de vida realmente funciona, mas estamos discutindo uma forma melhor de implementá-la. Provavelmente o ideal é deixar um "fundo" preto que se mantenha fixo, mesmo quando a quantidade de vida for abaixando. Isso serve para facilitar a visualização do jogador.
- Inserção de carta: O jogador já pode clicar em uma carta e colocá-la em campo, mas sem escolher o slot específico.
- Movimentação de personagem: Sim, as coisas se movem!
- Resize: Antes, os elementos da tela eram todos destruídos e refeitos quando um evento de redimensionamento acontecia, o que foi concertado.
Comunicação com arquivos
Eu (Gabriel) fiquei responsável pela camada de acesso aos dados, enquanto o Hugo e o Felipe se focam na lógica e na camada visual. Após reestruturar um pouco as classes através da separação de conceitos (antes, o modelo lógico tratava tanto da lógica quanto dados e exibição do objeto na tela), implementei a recuperação de cartas em arquivos. De forma idêntica, pode-se facilmente implementar o save/load de perfis. Fora isso, agora faltam:
- Animação por spritesheet: Atualmente, toda a movimentação dos personagens está dividida em arquivos, com uma imagem por frame. Para otimizar as animações, todas as posições devem ser inclusas em uma imagem só (é o chamado spritesheet).
- Leitura de texto: Falta elaborar uma estrutura que facilite a exibição de texto na tela e permita que um jogador retome o mesmo bloco de texto ao salvar o jogo e carregá-lo novamente.
- Internacionalização: Apesar de termos acoplado um módulo de internacionalização ao projeto, ainda não o estamos usando. É bem possível que ele passe por algumas mudanças radicais para se adequar às nossas necessidades, mas a princípio não parece complicado implementá-lo.
A previsão para o término dessas tarefas é até o final deste mês. Com elas e a mecânica prontas, daí em diante é só construir o jogo em cima do que temos.
Outras atualizações
Uma das principais dúvidas durante a implementação sempre foi como a aplicação saberia o que cada carta deveria fazer. Optamos por utilizar uma interface (que posteriormente teve que ser transformada em classe para ser gravada junto com a carta) CardAction, com um único método doAction. No momento de instância de uma carta, é criada uma inner class anônima que estende CardAction e implementa doAction, assim acoplando a lógica ao objeto. A ideia é criar algumas classes para ações muito comuns (como é o caso da maioria dos lutadores, que apenas se movimentam e atacam), mas o resto é feito na hora.
0 comentários:
Postar um comentário