Relatório de atividades (22/07 a 28/07)

Novamente, relatório um pouco atrasado devido à indisponibilidade do repositório. Aliás, este é o primeiro assunto do relatório.

Hospedagem de projeto

Estamos considerando a possibilidade de utilizar o serviço de hospedagem de projetos do Google, além do repositório da escola. O principal propósito é ter uma alternativa para quando problemas semelhantes ocorrerem no futuro, mas também há aspectos bem interessantes que podem ser úteis: wikis, possibilidade de maior visibilidade, gerenciamento de tarefas e problemas etc.

A questão foi proposta recentemente e ainda está em discussão, então vamos informar os resultados no próximo relatório.

Game Design Document

O GDD (Game Design Document), que descreve o roteiro, cartas, batalhas e outros itens referentes ao andamento do jogo, foi completo de acordo com as especificações iniciais. É possível que sofra alterações no futuro, mas pelo menos a "versão 1.0" foi concluída por mim hoje e descreve com detalhes o que acontece no jogo.

Implementação

O Hugo e o Felipe continuaram o trabalho da implementação da mecânica do jogo, cujo prazo foi adiado para este próximo mês de agosto (antes, havia sido estipulado que teríamos a mecânica do jogo feita em julho). A alteração no cronograma não deve afetar o andamento de forma significativa, uma vez que a mecânica de jogo é um dos principais requisitos do projeto, sendo os elementos como loja de itens e modo campanha secundários.

Adicionalmente, foi decidido que será utilizado o formato de arquivo JSON. A estrutura de acesso aos dados deverá ser a mais genérica possível, de modo que seja possível mudar de formato se assim for necessário no futuro.

Recursos gráficos

O Leon continuou a criação dos gráficos das cartas e o Victor ausentou-se nesta semana por questões de saúde.

Relatório de atividades (15/07 a 21/07)

O relatório demorou um pouco porque o repositório da escola ficou off por um tempo, então não conseguimos rastrear muito bem o que cada um fez nos últimos dias da semana. De qualquer forma, as seguintes atividades foram realizadas.

Reunião

As conclusões da reunião realizada em 18/07 podem ser encontradas neste post. A maior parte das atualizações se deve a ela, aliás.

Início da implementação

Conforme discutido, o Hugo deu início à implementação da camada visual do jogo, que deverá ser complementada com a camada lógica implementada pelo Felipe. Como eu fiquei de terminar tanto o diagrama de classes para guiar a implementação quanto o GDD (Game Design Document), optei por dar prioridade ao GDD por enquanto, mas descrevi em linhas gerais os componentes das camadas visual e lógica:

Camada lógica. Clique para ampliar.

Camada visual. Clique para ampliar.

OBS: Lembrando que já tinha feito o diagrama geral no post anterior.

Progresso nas cartas

Por enquanto temos 4 cartas feitas pelo Leon: DR-002, DR-003, Mineralogy e Reconnect Circuits.

Progresso nos mapas

O Victor estava tendo algumas dificuldades por conta das complicações na integração entre o libgdx e o Tiled Map Editor, mas agora acreditamos que a maior parte dos problemas está resolvida.

Progresso no GDD

A descrição das cartas está completa, restando agora a descrição das batalhas e a elaboração dos demais fluxogramas do roteiro. Devo terminar tudo nesta última semana de férias.

Conclusões da reunião de 18/07

A seguir estão as conclusões que tiramos da nossa última reunião. Como o post ficou meio grande, foi melhor separá-lo do resto das atualizações da semana, que serão registradas no próximo relatório.

Pauta da segunda reunião

A reunião que provavelmente ocorrerá no dia 17/07 ou 18/07 tem como objetivos principais coordenar esforços e fazer algumas decisões críticas referentes ao projeto. Os assuntos previstos são, nesta ordem:

Revisão do design de alto nível

O design de alto nível dos requisitos e plano de validação apresentado no post anterior será retrabalhado para contemplar quaisquer aspectos levantados pela equipe. Em particular, o plano de validação deverá ter um detalhamento maior.

Recursos gráficos

Parecem não estar ainda muito claras as tarefas referentes aos recursos gráficos, então precisamos estipular o que precisa ser feito e quem vai fazer o que. Também precisamos avaliar a viabilidade dessas tarefas e, dependendo da avaliação, fazer alterações no roteiro.

Arquitetura do projeto

A visão geral da arquitetura do projeto será mais detalhada, possivelmente entrando nas especificações do fluxo da partida através de diagramas de atividade. Assim como em relação aos recursos gráficos, a divisão das tarefas de implementação ainda precisa de uma definição formal. As decisões devem ser facilitadas com o estabelecimento de uma arquitetura inicial.

Suporte a mapas

Enfrentamos algumas complicações na integração do Tiled Map Editor com o libgdx, então esperamos chegar a um consenso sobre como resolver os conflitos. Uma boa alternativa seria a construção e implementação de um mapa de teste.

Linguagem de script

Provavelmente não utilizaremos scripts devido aos entraves com o Android, mas se algum dos integrantes oferecer uma solução viável, seria um recurso interessante ao projeto. Alguma pesquisa adicional também poderá ser realizada.

Bibliografia

Nada melhor do que aproveitar as férias para estudar, certo? A intenção é pesquisar e trocar experiências sobre algum conhecimento que nos auxilie durante a construção do projeto, seja em relação aos gráficos, sons, game design, programação ou qualquer outro aspecto.

Atualização

Bem, não é exatamente um relatório semanal, mas achamos útil registrar aqui como anda o desenvolvimento do projeto Shadow Struggles. Entretanto, como dito no post anterior, o fato é que não havia sido feito um avanço significativo para ser registrado.

Documento de game design

Foi iniciado um documento de game design (GDD) para documentar aspectos mais específicos do jogo, como roteiro e descrição dos mapas e cartas. O roteiro em inglês está finalizado, bem como a descrição dos mapas, restando agora terminar de detalhar as cartas, partidas do modo campanha, IA dos oponentes e quaisquer outros pontos adicionais que venham a surgir.

O documento pode ser acessado aqui:

Design de alto nível

Seguindo as orientações do livro Engenharia de Sistemas para Leigos, leitura para a disciplina de Teoria e Desenvolvimento de Sistemas, iniciamos um design de alto nível contemplando o conjunto inicial de requisitos e planos de teste. Para os requisitos funcionais:

• Vermelho indica que o requisito é obrigatório para a avaliação do sistema como funcional;
• Amarelo indica que o requisito é desejável, mas não afeta a funcionalidade plena do sistema;
• Já os requisitos em verde podem ser removidos sem comprometerem a qualidade ou funcionalidade do sistema.
• Retas tracejadas mostram uma relação entre um requisito e seu plano de verificação ou refinamento.

Requisitos funcionais de design e jogabilidade. Clique para expandir.

Requisitos funcionais de modalidade e configurabilidade. Clique para expandir.

Requisitos não funcionais. Clique para expandir.

Arquitetura do projeto

Foi elaborada uma estrutura geral de organização que deve guiar a implementação do jogo. Por enquanto é apenas uma visão geral em alto nível das camadas, mas a intenção é refiná-la cada vez mais e complementar com diagramas adicionais.

Clique para expandir.

A camada de visualização é dividida em interface de navegação, basicamente a estrutura de navegação através de menus, e interface de batalha, que exibirá os gráficos e receberá os inputs do usuário durante uma partida.

Logo abaixo vem a camada lógica, responsável por interpretar as jogadas, aplicar as regras e retornar as respectivas consequências. A plataforma genérica é responsável pelas tarefas básicas de todas as partidas: carregar mapas, inicializar valores etc. Isso busca separar a lógica da partida em si da manipulação dos dados, que podem vir de um banco de dados, arquivo XML, script ou qualquer outro meio de armazenamento, além de proporcionar um grau de customização individual para cada partida.

Nos níveis mais baixos estão os dados, recursos e a camada interpretadora, responsável pela comunicação com esse meio externo. No lado esquerdo estão listados os testes previstos.

Linguagem de script

Pensamos em utilizar scripts para auxiliar na construção das entidades do jogo. Isso facilitaria bastante a customização de diversos aspectos sem ser necessário fazer alterações profundas no código da aplicação, permitindo também que mesmo os que não estiverem envolvidos diretamente com a implementação possam ajudar na programação dos scripts. A principal utilização seria programar a IA dos oponentes.

No momento, o principal entrave é a compatibilidade com Android. Em primeiro momento cogitamos a possibilidade de usar Groovy, mas este ainda não encontra suporte pleno na plataforma. Uma boa alternativa parece ser BeanShell. Enfim, o tópico ainda está sendo pesquisado e esperamos trazer uma conclusão no próximo relatório.

Reunião

Pretendemos realizar uma reunião com todos os membros da equipe para coordenar os esforços, trocar experiências e tomar algumas decisões importantes à respeito do projeto. A pauta será decidida em breve e publicada aqui no blog.

Subversion e Subversive - Guia rápido

Não tivemos muitas atualizações desde a última postagem, mas o ritmo de relatórios deve aumentar bastante durante este mês de julho, quando damos início ao desenvolvimento do projeto. E é por isso que hoje vamos falar um pouco de Subversion, tanto para tirar dúvidas dos integrantes da equipe quanto ajudar qualquer outra equipe de desenvolvimento que use ou queira usar o Subversion como ferramenta colaborativa.