Relatório de atividades (05/08 a 11/08)

Breve síntese do que foi feito na semana, de 05/08/2012 a 11/08/2012.

Implementação

O Felipe conseguiu resolver alguns problemas de manipulação de câmera que estávamos enfrentando e o Hugo concertou a incompatibilidade com o Android devido a arquivos corrompidos e implementou uma lógica inicial de manipulação de dados em arquivos. Quanto à implementação efetiva da mecânica do jogo, enfrentamos alguns problemas na camada lógica. Basicamente, ficamos quebrando um pouco a cabeça porque não entendíamos e/ou não concordávamos com a visão um do outro à respeito da arquitetura, que não ficou clara só com os diagramas.

Conseguimos chegar a pelo menos um consenso: ao invés de criar uma classe para cada carta, que era a intenção inicial, vamos reunir todas as informações das cartas em arquivos e estabelecer uma única classe responsável por implementar os efeitos possíveis. Por exemplo, uma carta teria informações em arquivo como algo do tipo:

nome: nome_carta

tipo: armadilha

custo: 20

duração (em segundos): 5

efeitos: {drenar_vida_lutador, drenar_vida_base_inimiga}

Assim, quando essa carta for ativada durante a partida, a aplicação vai chamar os métodos correspondentes aos efeitos drenar_vida_lutador e drenar_vida_base_inimiga. Isso inclusive deve permitir que os programadores principais, Hugo e Felipe, possam se concentrar mais na engine em si, enquanto outra pessoa pode editar os arquivos e adicionar funcionalidades extras.

Mesmo assim, ficou claro que não podemos começar direto pela lógica. Decidimos adotar uma abordagem mais top-down, ou seja, primeiro determinar como o sistema é apresentado ao jogador e só depois especificar o que ele deve fazer. Vamos dar uma atenção extra à interface gráfica, preocupando-nos em exibir as informações na tela, para apenas depois implementar a lógica e manipulação de dados.

Essa abordagem é vantajosa por cinco motivos:

1. Temos uma visão geral do que a aplicação realmente é, então evitamos problemas de módulos que deveriam ter sido implementados, mas acabaram passando batido, e módulos que alguém pensou que o jogo precisaria, mas ficaram inutilizados.
2. Podemos verificar desde o início as questões referentes ao design. No final das contas, o design é uma das coisas mais relevantes em um game e é o que o jogador realmente vê, apesar de ser o mais trivial em termos de programação.
3. Com a camada visual pronta, teremos mais facilidade em divulgar o projeto e apresentar nosso progresso nele.
4. É o modo mais natural e "concreto" de começar a implementação, sem que precisemos entrar em detalhes abstratos de lógica e organização.
5. Torna mais flexível a alteração do design em qualquer momento, pois a lógica ainda não estará completamente pronta e poderá ser adaptada.

Recursos gráficos

Em contraste à implementação, não houve muitos problemas em relação aos gráficos. O Leon terminou mais uma carta e iniciou a interface dos menus, enquanto eu comecei a parte de animações e fiz ilustrações adicionais. Eventualmente pretendo refazer algumas coisas, principalmente animações, mas ficam aí como recursos provisórios. Como dito anteriormente, sou inexperiente e o nível dos meus trabalhos ainda está abaixo do esperado, mas isso é algo que só melhora com o tempo mesmo.

Divulgação

Um dos principais objetivos do projeto é ter um bom alcance global, então eu dei mais alguns passos em direção a isso. Apliquei algumas técnicas de SEO (Search Engine Optimization) ao blog, a fim de melhor posicioná-lo em buscas, e encontrei bons espaços destinados a desenvolvedores indies pela web:

Indie Game Maker Brasil
GameDev
Indie DB

Também cadastrei o blog no diHITT, serviço que agrega diversos blogs.

Metas para as próximas semanas

O Felipe tinha sugerido no mês passado que utilizássemos a seguinte ordem de implementação:

1. Carregar um mapa (já feito).
2. Inserir um personagem no mapa que saiba se locomover à base inimiga.
3. Inserir vários personagens.
4. Fazer o lutador reconhecer se existe algo dentro de seu alcance e realizar a ação respectiva.
5. Carregar o baralho do jogador.
6. Implementar a I.A. do inimigo.

Proponho alguns passos intermediários visando principalmente o design e a interação com o usuário, além de detalhar um pouco mais:

1. Exibir a interface de batalha (cartas, indicadores de energia e vitalidade, baralho, menu lateral).
2. Implementar a inserção de uma carta.
3. Implementar as ações de uma carta.
4. Implementar o baralho do jogador e o saque (não regido pelo timer).
5. Implementar o indicador de energia dos jogadores.
6. Implementar a vitalidade das bases.
7. Implementar o timer, a recuperação de energia e o saque regido pelo timer.
8. Implementar a I.A. do inimigo.
9. Implementar as regras de jogo (condições de vitória/derrota).
10. Implementar a visualização de uma carta.
11. Implementar as opções do menu lateral.