Final Frontier: Refactoring e GitHub

Desde o último post sobre o andamento do Final Frontier, há quase 4 meses atrás, comecei a descartar código e assets que eram temporários para o protótipo, e assim começar a desenvolver o projeto como um jogo. Naquele post falei sobre o início do GDD do projeto, que foi o primeiro passo para organizar as ideias que tenho para o jogo e comparar com o que eu testei através do protótipo.

Após aquele post comecei um branch novo do projeto para limpar tudo que era temporário, e até acabei adicionando um novo modelo de nave e refazendo o controle dela. Todo o resto, interface do menu e asteroides, foram removidos por que não tinham sido desenvolvidos pensando em fazer parte do jogo final. Mas, devido ao meu bloqueio criativo deixei esse projeto de lado nos últimos meses. O curioso é que logo depois de escrever este post, deu vontade de retomar o projeto, e aqui estamos.

Refactoring preguiçoso

Como mencionei acima, a ideia do refactoring era primeiramente limpar o projeto de assets e código que eu não iria utilizar. Consegui remover quase tudo, deixei apenas algumas coisas para serem usadas como referência daqui pra frente. A estrutura do projeto foi reorganizada e escrevi um código novo para o controle da nave, que está melhor mas não com o feel que eu quero.

Uma das mudanças visuais foi remover o modelo de nave que estava usando por um novo, que é modular e vai permitir que eu mude as partes da nave de acordo com cada upgrade que o jogador selecionar no inventário. O novo asset pack, Modular Spaceship 1: StarSparrow, também é gratuito e permite mudar partes e cores das naves. A mesma empresa que fez esse asset pack gratuito tem um outro bem maior e com mais conteúdo que é pago, o Modular Spaceships Collection. Como o projeto fica em um repositótio público, não posso colocar assets pagos, mas quem sabe um dia eu não faço um repositório privado para poder colocar essas naves e lançar o jogo.

Outra mudança é que o jogo agora tem 4 scenes, sendo duas antes do jogo e duas para o jogo em si. Hoje elas são apenas uma estrutura, mas que no futuro será expandida.

• scene_init: Possui scripts de sistemas que precisam ser iniciados com o jogo (ainda não está em uso)
• scene_loading: Scene para carregamento dos assets (hoje ta com um timer fake de 3 segundos)
• scene_ui: UI do jogo onde vão ficar elementos de interface e menu (hoje tem só o contador de FPS)
• scene_game: Scene principal do jogo carregada junto com a UI usando LoadSceneMode.Additive

Por fim, implementei um contador de frames por segundo que vi neste tutorial. Achei algumas coisas bem legais nesse tutorial, como ter a separação de valor máximo, médio e mínimo da contagem de frames por segundo, e o uso de um array de strings para não fazer conversão de o valor do FPS para string em cada frame. Recomendo dar uma lida no artigo e até implementar eu um projeto, é bem útil e simples ter um contador de FPS desde o início.

Features do GitHub

Outra novidade, que vai deixar o desenvolvimento do jogo mais organizado e fácil de acompanhar é o uso de duas features do GitHub: Pull Request (PR) e Issues. Ante seu estava trabalhando direto no branch principal do projeto, mas agora vou criar um branch separado para cada feature nova. Antes de criar o branch, vou criar um Issue no projeto, que vai servir para listar o que eu quero fazer naquela feature. Quando terminar a feature, eu abro um PR mencionando a Issue, e no PR é possível ver todos os commits e arquivos que foram modificados no branch que será/foi mergeado no branch principal. Além disso, o status da Issue pode ser acompanhado no board do projeto no GitHub também.

Se tudo o que eu disse no parágrafo acima não faz sentido, recomendo dar uma lida no livro Introdução ao GitHub: um guia que não é técnico e conhecer as features que o GitHub oferece para os desenvolvedores. O GitHub é muito mais do que apenas um lugar para manter o repositório dos seus projetos, ele também possui ótimas features para ajudar na organização e desenvolvimento. O BitBucket, outro serviço para manter repositórios git, também possui algumas features similares.

Próximo passo

Atualmente estou trabalhando na próxima feature, que é implementar controle da nave através de touch e testar o jogo em um Android. É uma feature simples que não deve tomar muito tempo, e a ideia daqui pra frente é justamente esta: manter tudo simples para o que projeto não fique muito tempo parado por ter uma feature longa em desenvolvimento. Diferente dos posts anteriores, onde eu adicionei o link do último commit do projeto até a data da publicação do post, a partir de agora vou sempre adicionar o link da Issue que eu criei, e nela é possível ver seu status e se já foi integrada ao branch principal. A Issue atual é Touch controls and Android test.

O andamento do projeto pode ser conferido no repositório do GitHub e no board do projeto. Todos os posts desta série sobre meu projeto podem ser vistos na tag Final Frontier, e como sempre qualquer sugestão ou opinião é bem vinda!