5ª Reunião – Definições a respeito da parte gráfica, alterações nos
módulos e planejamentos do projeto, problemas com divisão do grupo
Durante a
semana que antecedeu a 5ª reunião algumas coisas importantes aconteceram e
demandaram que, durante essa reunião, algumas definições fossem refeitas e
alguns pontos fossem acertados.
Escolha pela utilização da libGDX
Em primeiro
lugar, desde o início do projeto houve uma grande manifestação por parte da
maioria do grupo para utilização da multi-plataforma gráfica para
desenvolvimento de jogos libGDX, da badlogic. Após definirmos durante a semana
via skype que iríamos realmente tomar como caminho a utilização da libGDX, colocou-se
como prioridade para o grupo a coleta de informações a respeito da mesma, bem
como alguns exemplos de códigos, referências e ideias de como poderíamos
introduzí-la ao nosso projeto da melhor forma possível. O deadline dessa tarefa
foi estipulado para essa reunião (29/10). Percebemos que, com a utilização da
libGDX, muitas coisas definidas e previamente pensadas antes dessa decisão se
tornariam consideravelmente mais simples de serem realizadas, o que levou a uma
reestruturação dos nossos módulos e, consequentemente, do nosso calendário.
A grande
facilidade encontrada com a utilização da libGDX é que a portabilidade havia
sido prevista do nosso engine principal do jogo (nossas funcionalidades básicas
como as classes e módulos principais, esquemas de batalhas e outros), que já estavam prontas em java para plataforma PC,
para a plataforma Android não era mais necessária. A libGDX possui uma gama de
recursos que possibilita utilizar o nosso engine da forma como foi estruturado
para plataforma PC sem exigir grandes mudanças visando a interação com a parte
gráfica, o que foi um ganho considerável de tempo e eliminou a necessidade do
módulo 2, definido justamente como o módulo de transição entre as plataformas
intermediária (PC) e final (celular Android).
Outra
facilidade relevante da libGDX é o fato de ser uma boa biblioteca para se
trabalhar com a parte gráfica, completa, repleta de funções que facilitam o
desenvolvimento, além da utilização de um conceito de telas (screens) e
submódulos internos que tornam o desenvolvimento mais claro e auxiliam na
legibilidade do código. Além disso, permite controle e acompanhamento do tempo
de frame a partir de uma variável interna chamada delta, que representa a
fração de tempo de um frame, abrindo um leque aplicações gráficas
interessantes.
Alterações do escopo e do planejamento do
projeto
Na 2ª reunião ficou
decidido que teríamos 4 módulos, três módulos principais e um módulo extra opcional
com funcionalidades que extrapolam o escopo fundamental do projeto que só seria
produzido caso o projeto tivesse bom andamento e houvesse uma produtividade
constante e satisfatória. Os três módulos principais foram definidos como:
-
Produção do nosso módulo motor (engine), aquele responsável pelas
funcionalidades principais e sobre o qual o jogo giraria em torno, em java para
plataforma PC padrão. Essa escolha foi feita pela maior familiaridade do grupo
com o desenvolvimento java para PC, o que facilitaria a estruturação do nosso
motor, testes e produtividade da equipe.
-
Transferência do nosso engine principal feito para plataforma PC para a
plataforma android. Era esperado um trabalho relativamente alto da equipe em
transformar nosso engine feito para PC em um engine para android já estruturado
para receber as interações com a parte gráfica no terceiro módulo.
-
Elaboração da parte gráfica e finalização das ligações e ajustes necessários
entre nosso motor e a interação gráfica com o usuário.
Como já
explicado, a adoção da libGDX ao nosso projeto eliminou a necessidade do
segundo módulo o que fez com que o escopo do nosso projeto fosse reduzido
significativamente levando-nos ao replanejamento das datas e dos módulos.
Decidimos por
manter o esquemático de três módulos principais. A elaboração da parte gráfica
e finalização das ligações e ajustes necessários entre o motor e a interação
gráfica com o usuário, que era nosso terceiro módulo, passou a ser o nosso
segundo módulo e, o que era um módulo extra com funcionalidades a mais, passou
a fazer parte do escopo principal do nosso projeto como nosso terceiro módulo.
Nossa divisão
em módulos ficou assim, então:
-
Produção do nosso módulo motor (engine), aquele responsável pelas
funcionalidades principais e sobre o qual o jogo giraria em torno, em java para
plataforma PC padrão. Essa escolha foi feita pela maior familiaridade do grupo
com o desenvolvimento java para PC, o que facilitaria a estruturação do nosso
motor, testes e produtividade da equipe.
-
Elaboração da parte gráfica e finalização das ligações e ajustes necessários
entre nosso motor e a interação gráfica com o usuário.
-
Incrementação da versão completa que envolve o nosso engine básico e a parte
gráfica com funcionalidades extras, as quais já temos alguma idéia e rascunhos
mas ainda não há a definição completa das mesmas.
Em termos de datas
de entregas não houveram grandes mudanças, nosso cronograma ficou:
23/10/2015 – Testes Primeiro Módulo – Concluído
26/10/2015 – Entrega Primeiro Módulo – Concluído
16/11/2015 – Testes Segundo Módulo – em andamento
19/11/2015 – Entrega Segundo Módulo – em andamento
27/11/2015 – Testes Terceiro Módulo – a fazer
01/12/2015 – Entrega Terceiro Módulo – a fazer
Nossos
encontros e reuniões também estão previamente planejados como semanais com
ajustes e definições básicas via meios de comunicação. Graças à boa comunicação
estabelecida entre o nosso grupo – via skype, whatsapp, hangouts, email e
facebook – as datas das reuniões não são fixas, depende do andamento do projeto
e da quantidade de decisões em conjunto demandadas para aquele momento.
Problemas na divisão
Tivemos um início
de projeto muito produtivo e fluente. Os testes e as entregas do primeiro
módulo foram realizados sem grandes dificuldades ao longo do percurso, o grupo
dividido em duplas conseguiu realizar bem as tarefas propostas, inclusive
realizando o entregável para testes bem antes do previsto no planejamento e,
ainda, a liberação do primeiro módulo só não ocorreu antes do planejado pois
acabamos tendo uma semana com pouco trabalho devido a outras obrigações e pendências
dos integrantes, mas ainda sim foi entregue dentro do planejado.
No entanto,
acabamos passando por um período menos produtivo. Um de nossos integrantes, que
era até então quem estava coordenando as ações e o planejamento, teve que fazer
uma cirurgia, que já havia sido previamente comunicada e já era esperada, o que
acabou levando a uma reestruturação do nosso formato de produção. A troca das
quatro duplas por duas duplas e um trio não manteve a produção do módulo
anterior, o que se agravou após o abandono de um dos membros do projeto. Com
três duplas, o segundo módulo demorou a ter avanços e se tornar produtivo,
principalmente pela falta da coordenação e planejamento exercida no primeiro
módulo pelo integrante que teve de operar. Somente após outro membro tomar a
frente e começar a realizar o papel de coordenar, planejar e direcionar as
ações e estabelecer metas de evolução na produção é que conseguimos uma melhora
considerável na produtividade do segundo módulo.
A familiaridade
por parte do grupo com a biblioteca gráfica adotada e a implementação gráfica
do nosso motor já foi realizada. Na próxima reunião vamos definir os requisitos
desse segundo módulo, referentes às telas do jogo e às formas de interação com
o usuário final.
Nenhum comentário:
Postar um comentário