Final Frontier: Refactoring e GitHub

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.

Modular Spaceship 1: StarSparrow

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!

Bruno Cicanci

Bruno Cicanci
Desenvolvendo jogos desde 2009.

Falta de foco

Você planeja uma tarefa ou atividade, reserva um bom tempo pra isso, escolhe aquela playlist perfeita, coloca seu fone e se isola em um c...… Continue lendo

Comparando deletages e Unity Events

Published on September 09, 2018