Práticas recomendadas para o desenvolvimento de jogos estáveis com menos bugs

Mantenha uma build de jogo limpa e estável para colher os benefícios a longo prazo:

• Lance jogos mais estáveis com menos bugs.
• Economize tempo de produção devido à quantidade inferior de bugs e uma base de código mais limpa.
• Diminua a chance de "quebrar a build".
• Crie versões de demonstração e builds especiais com mais facilidade.

Nem todas as práticas de build AAA são adequadas para equipes independentes. Mas há muitas coisas que podem ser feitas para garantir que a sua build permaneça limpa e estável que são gratuitas (ou acessíveis) e podem ser implementadas por equipes de qualquer tamanho.

Mesmo que você esteja sozinho no projeto, essas dicas ajudarão você a manter uma build de jogo melhor e mais íntegra. 

Atualmente, mesmo com a disponibilidade de sistemas de controle de versão (VCS) gratuitos, ainda há equipes que trabalham com pastas e repositórios compartilhados para colaborar. Desenvolver sem o controle de versão é igual a dirigir sem cinto de segurança. Usar o cinto de segurança nem sempre é confortável e causará certa limitação, mas se você sofrer um acidente em alta velocidade, salvará sua vida.

Não se pode dar ao luxo de perder trabalho, independentemente do tamanho da equipe. Uma conta do Dropbox hackeada ou um disco rígido quebrado não deve fazer com que você perca dias ou semanas de trabalho.

Há diversas soluções gratuitas disponíveis. Perforce, Git e SVN oferecem versões gratuitas. E com o Unity Teams integrado diretamente ao Unity, tudo fica ainda mais fácil.

Além da segurança que um VCS oferece, outro benefício é a obtenção de listas de alterações, que ajudarão você a manter uma visão geral das alterações feitas. A imagem acima é de um histórico de pastas do Perforce que mostra todas as alterações.

Embora a maioria dos sistemas não force você a enviar uma descrição para uma alteração feita, descrever as alterações com clareza é uma prática recomendada.

Além disso, criar "anotações de patch" e documentos semelhantes tornam-se fáceis ao começar a usar prefixos para as alterações, como os seguintes: 

• !B: uma correção de bug.
• !V: uma alteração ou melhoria visual.
• !G: uma alteração na jogabilidade.
• !X: uma alteração que deve ser ignorada nas anotações de patch.

Enviando as alterações para o VCS e descrevendo-as com prefixos, mais tarde você poderá executar um script em todas as entradas e organizar tudo em documento de anotações de patch elegante e organizado.
Um envio limpo para o VCS teria a seguinte aparência:

"!V Aumento do efeito da partícula de explosão"

"!B Correção de travamento ao pegar uma arma"

"!G Aumento da quantidade de vida em kits médicos"

Se você manter todas as entradas sucintas, porém bem descritas, será fácil compilar documentos de anotações de patch quando houver a necessidade. É uma abordagem mais eficiente do que revisar manualmente as alterações recentes para identificar o que deve ser listado nas anotações de patch.

É importante que toda a sua equipe esteja familiarizada com os princípios da boa higiene de build. Aqui estão as cinco práticas recomendadas para manter a organização.

1. Sem código de quebra de build
   Não inclua nada que você sabe que não funciona. Se o recurso em que está trabalhando não estiver concluído, mas precisar incluí-lo, desative-o ou arquive as alterações para que não gerem interrupções para o restante da equipe. O restante da equipe não deve ser bloqueado por uma build quebrada simplesmente porque você incluiu código não funcional.
    
2. Sem atalhos do teclado codificados
   É conveniente adicionar atalhos personalizados para algumas funcionalidades de trapaça ou depuração. "Vamos definir a tecla F12 como trapaça de dinheiro, ninguém vai apertar ela, não é mesmo?"
   Mas programar esse tipo de funcionalidade em uma tecla é perigoso pois é fácil de esquecer. Você pode acabar lançando com ela acidentalmente ou os testadores podem ativá-la involuntariamente e poluir os relatórios de bugs.
    
3. Assinale código ruim e ausente
   Às vezes, é preciso hackear. Não importa quanto você queira evitar, em algum momento seu código terá hacks temporários. Ao adicionar um hack ou alternativa, sinalize no código com palavras-chave fáceis de encontrar. Assinale um hack com //HACK ou código ausente com //TODO. Mais tarde, a busca para encontrar e substituir essas tags no código será mais fácil.
    
4. Spam do log
   Registrar coisas no código é útil e pode ajudar a rastrear problemas. No entanto, é importante limpar o spam do log de vez em quando para que avisos e erros importantes não fiquem para trás. A menos que esteja trabalhando ativamente em um recurso, o console deve estar o mais limpo e vazio possível para que, quando algo aparecer, você veja imediatamente.
    
5. Nomes de arquivos e convenções de nomenclatura
   O tamanho da sua build alcançará centenas, possivelmente milhares de arquivos. Portanto, é importante manter uma convenção de nomenclatura limpa.

Ao iniciar um novo projeto, dedique um tempo para definir convenções de nomenclatura que façam sentido para você e limite-se ao uso delas. Quando começam a aparecer nomes como texturetestFinal01.png ou backup22.fbx na build, perde-se rapidamente o controle.

Realize verificações rotineiras e elimine nomes de arquivo ruins que entraram no projeto.
Aqui estão algumas dicas:

• Use nomes descritivos
  AttackButtonBehavior.cs em vez de atkBtn.cs
• Use camelCase ou PascalCase
  notsocleanfilename.cs não é tão legível quanto MyCleanFilename.cs
• Use sublinhados para deixar os nomes de arquivos mais claros.
  WoodenHouse_Blue, WoodenHouse_Green, etc.

Você precisará depurar e trapacear constantemente durante o desenvolvimento de um jogo. Talvez você queira avançar para um nível diferente, obter mais dinheiro, tornar-se invulnerável, gerar inimigos adicionais, etc.

Você poderia adicionar essas trapaças sempre que necessárias e desativá-las depois de usar, mas é preferível ter um método limpos para ligar/desligar esse tipo de funcionalidade.

Até mesmo em projetos menores, vale a pena investir um tempo extra para criar um menu de depuração/trapaça fácil de usar. Algo que possa ser facilmente ligado/desligado pelos desenvolvedores e que forneça acesso a todas as opções comuns de trapaça e depuração.

Optar por essa maneira minimiza o risco de entregar trapaças acidentalmente com o jogo. Além disso, ter o "código de trapaças" em um local central também garante que tudo funcione e facilita a ampliação.

Outro benefício dessa abordagem é que o uso de trapaças de desenvolvedor se torna muito mais rápido, economizando tempo na produção diária. Simplesmente pressionar um botão na elegante e confortável janela de depuração é muito mais ágil do que programar valores nos scripts.

O seu jogo terá bugs. Todo jogo tem bugs e o seu não será exceção. A pergunta é: como lidar com bugs?

O fluxo de trabalho para lidar com bugs de maneira eficiente é bem direto: o departamento de QA encontra e registra os bugs no sistema de acompanhamento de bugs. Depois, os problemas são designados aos desenvolvedores que, por sua vez, corrigem os problemas e os marcam como tal. Por fim, a equipe de QA verifica os problemas e os marca como encerrados. Um processo fácil de três etapas, certo? 

Espera, o quê? Você não tem um departamento de QA dedicado? Os testadores também são os desenvolvedores?

Não se preocupe, você não precisa de muito para ficar a par dos bugs. 

Antes de mais nada, acompanhe os bugs. Isso é fácil mesmo que você esteja sozinho.

Escolha um software de acompanhamento de bugs (há uma infinidade de opções gratuitas e acessíveis por aí) e configure-o. Se isso soar como excesso para você, sem problemas, use o Excel ou até mesmo o bloco de notas, não importa. O importante é ter um local central para coletar e acompanhar os problemas. Depois que tiver um sistema implantado para acompanhar os problemas, é tudo uma questão de disciplina. Uma build com bugs desacelera a produção e pode até criar mais problemas.

Aqui estão algumas dicas rápidas para ficar a par dos bugs:

Sextas-feiras de correção de bugs

As Sextas-feiras de correção de bugs são uma ótima forma de manter a build sem bugs. Toda sexta-feira, em vez de trabalhar em novos recursos, todos trabalham somente em itens da lista de bugs. Essa abordagem garante que você comece a nova semana com uma build estável e sem bugs.

Não adie por muito tempo

Se você sabe que está perdendo o controle sobre os bugs, pode ser uma boa ideia parar de trabalhar em novos recursos e concentrar na estabilização da build até que as coisas voltem para os trilhos. 

Não tente apagar incêndios o tempo todo

Se você sofre com vários bugs que reaparecem, investigue a causa raiz. Há alguma parte do pipeline de criação de níveis que sempre faz com que os níveis não funcionem? A forma como você analisa os valores de jogo dos arquivos .xml está gerando problemas dia sim, dia não?

Se você identificar um sistema que esteja causando problemas frequentemente, poderá valer a pena recriá-lo em vez de corrigir os problemas causados repetidamente.

Com todas essas práticas recomendadas e dicas em mente, vira tudo uma questão de disciplina e de quanta atenção você dá ao estado da build. Você pode misturar e combinar essas sugestões e aplicá-las à sua produção independente. O tempo usado para manter a build íntegra sempre vale a pena.