Melhores práticas na Unity #1

Conheço a Unity desde 2009, quando estava no meu primeiro ano da pós-graduação, mas só fui trabalhar com ela profissionalmente em 2014 na 2Mundos. Já utilizei Unity em freelas, game jams, projetos pessoais e para trabalhos na faculdade, participei de todos eventos da Unity que foram realizados em São Paulo nos últimos anos, o Unite, assisto com frequência videos de palestras no YouTube e já li alguns livros e artigos sobre desenvolvimento de jogos com Unity. Hoje trabalho na Aquiris, uma das maiores referências em Unity no mundo, inclusive fizeram a demo para a Unity 3 que foi a versão que usei em 2009. E depois de tantos anos e experiências, ainda não sei nada de Unity.

Trabalhar na Aquiris me dá a oportunidade de aprender cada vez mais sobre desenvolvimento de jogos e Unity com pessoas que tem muita experiência no assunto. Toda semana estou aprendendo algo novo, simples ou não, e isso me motivou a escrever mais sobre o assunto aqui no blog. A Unity é uma ótima game engine, e costumo recomendar para todo iniciante começar por ela.

Nesta série de posts sobre Unity não vou falar da engine em si ou por que usar ela, mas sim focar em algumas coisas simples que fazem diferença no seu uso, seja você iniciante ou não. Tudo que vou escrever aqui é baseado nas minhas experiências, e pode ser um pouco diferente do que você viu por ai.

O método Awake

O Awake está em todo MonoBehaviour, faz parte do lifecycle da Unity e é executado apenas uma vez enquanto o script ou seu GameObject não for destruído. Diferente do Start que é executado quando um objeto é habilitado, o Awake é um método de inicialização e sua execução acontece um frame antes da interface ser exibida. Por este motivo, o Awake, quando utilizado, deve ser breve e sem chamadas que podem demorar e fazer o seu jogo ficar esperando por uma resposta para continuar.

Muitas coisas inicializadas no Awake geralmente não precisam estar lá, podem ser movidas para o Start ou até mesmo para dentro de um método específico para a situação. Inicializar código no Awake não é ruim, e não vai melhorar absurdamente a performance do jogo, mas é uma boa prática que pode fazer seu jogo ter menos travadas em inicializações de cenas ou objetos. Isto também ajuda a você repensar se todas variáveis inicializadas no Awake realmente precisam ser globais pra classe ou se podem ser locais no método que são utilizadas. Quando é necessário fazer o cache da variável, sempre verifique se ela já foi inicializada, e caso contrário faça isso onde é necessário (se for possível tirar do Awake).

Primeira scene do jogo

Já vi muitos jogos (muitos mesmo) que tem tudo em uma única scene. Um dos pontos negativos disso em projetos com equipes grandes é que a chance de dar conflitos quando duas pessoas alteram a scene é muito grande, mas uma vantagem é que depois do loading da scene todo jogo flui sem precisa carregar nada (considerando que todos prefabs estão na scene). A decisão de qual abordagem utilizar depende muito do jogo, mas o que eu quero compartilhar aqui é que a mesmo com uma única scene, uma boa prática é ter uma scene vazia com apenas um script que vai chamar a scene principal do jogo.

Quando seu jogo é carregado, parte do load é a Unity inicializando a engine antes de chamar sua scene. Por este motivo, se a sua primeira scene for muito grande (e ainda tiver muita coisa no método Awake), o load do seu jogo vai demorar mais do que deveria. Por este motivo, é uma boa prática criar uma scene vazia com apenas um script, que sua única função é chamar outra scene. Assim como no tópico anterior, isto não vai solucionar todos seus problemas, mas é uma boa prática que vai ajudar a fazer seu jogo inicializar melhor. É importante que este script e a scene não inicie nada, seu único objetivo é realmente ser carregado rápido o suficiente pra apenas chamar a próxima scene, que pode ser uma tela de loading ou seu jogo inteiro.

Guias de melhores práticas da Unity

A Unity tem um serviço premium que, quando uma empresa solicita, ela envia um engenheiro para analisar o jogo e ajudar a solucionar problemas que a equipe de desenvolvimento está enfrentando, e até a mostrar problemas que eles nem perceberam. Após uma visita dessas, a Unity envia um relatório para a empresa com informações sobre o que podem melhorar. E, em muitos casos, parte desses relatórios viram guias de melhores práticas e são publicados no site da Unity em Best practice guides.

Como estes guias são gerados a partir de revisões de projetos de empresas grandes, eles podem ter conteúdo muito técnico e avançado. Atualmente existem conteúdos publicados para melhores práticas em otimização, física, loading de assets e otimizações de UI. Eu recomendo que leiam estes guias, porém não comecem a implementar tudo que está lá por que muitas vezes não se aplicam a sua situação atual, mas são técnicas úteis de conhecer quando você estiver em uma situação parecida.

Estude, mas não coloque tudo em prática

Os guias de melhores práticas possuem muita informação útil, mas não caia na armadilha de querer fazer tudo que está lá. Parte do processo de aprendizagem é parar e pensar se você realmente precisa daquilo no seu jogo antes de escrever código sem parar. Além dos guias, a Unity também tem uma ótima área no site com tutoriais para iniciantes, que também podem ser usadas ou não em seu jogo. Também recomendo os vídeos do canal da Unity e do canal Brackeys.

Melhores práticas para jogos 2D

Escrevi estes três posts há muito tempo sobre melhores práticas para jogos 2D na Unity. Na época eu estava na 2Mundos, a Unity não tinha sua UI nativa, então utilizei o plugin NGUI. Apesar de datados, estes posts possuem informações relevantes e que ainda podem ser aplicadas hoje em dia:

• Melhores práticas para 2D na Unity - Parte 1
• Melhores práticas para 2D na Unity - Parte 2
• Melhores práticas para 2D na Unity - Parte 3

Meu objetivo com esta nova série de posts sobre Unity é compartilhar minha experiência profissional na engine. Não vou prometer uma frequência regular, mas vou postar sempre que possível. Tenho uma lista de assuntos que quero discutir aqui, e vou sempre postar poucos para que eu possa escrever mais sobre eles. Qualquer dúvida, crítica ou sugestão fique a vontade para deixar um comentário aqui.