Unity · Game Developer

Git no Unity: Como configurar um repositório do zero

Mon, 15 Dec 2025 00:00:00 +0000

Neste post você vai aprender como configurar um repositório Git em projetos Unity, seja antes de iniciar um novo projeto ou em um projeto já existente.

No vídeo, explico o passo a passo da configuração, compartilho boas práticas e dicas importantes para trabalhar com controle de versão e mostro como o mesmo processo funciona no GitHub, podendo ser adaptado facilmente para GitLab e Bitbucket.

Assista ao vídeo abaixo para acompanhar o tutorial completo.

Links mencionados no vídeo:

Mais conteúdo sobre git:

Minha participação na Unite 2025 em Barcelona

Mon, 24 Nov 2025 00:00:00 +0000

Unite é o evento anual da game engine Unity, que aconteceu este ano novamente em Barcelona, entre os dias 17 e 20 de Novembro. Foi minha primeira vez no evento, e tive a honra de participar não apenas como espectador, mas também como palestrante e Unity Insider.

O título da minha palestra foi Reusable technology: Saving development time with shared Unity plug-ins and SDKs, onde compartilhei como desenvolvemos SDKs para Android e iOS, plugins para Unity, e como testamos e publicamos. Este é parte do trabalho que minha equipe realiza na Ubisoft, e foi uma experiência incrível compartilhar isso no maior evento da Unity. Vou fazer outro post sobre a minha palestra quando a gravação for publicada no canal da Unity no YouTube, e comentar mais sobre o assunto.

Além de palestrar, também participei de um encontro com outros membros do programa Unity Insiders, do qual faço parte desde 2022. Também vou escrever outro post sobre este programa e os criadores de conteúdo que conheci pessoalmente no evento.

Neste post, quero destacar alguns anúncios do Keynote, a inesperada parceria entre Unity e Unreal, e o Roadmap da game engine para o próximo ano.

Keynote
#

O grande destaque do keynote deste ano foi a ausência de produtos e serviços baseados em Inteligência Artificial generativa, o que considero um ponto muito positivo. Tudo que foi apresentado no keynote, e depois detalhado no roadmap, mostra que a Unity está focada nos desenvolvedores de jogos e em tornar sua engine uma ferramenta sólida, ao invés de seguir o hype da I.A. para agradar acionistas.

Alguns jogos feitos com Unity lançados este ano foram apresentados, com destaque para Tiny Bookshop, Megabonk e Peak. Os desenvolvedores de Peak subiram ao palco para compartilhar como conseguiram criar um jogo em apenas 10 semanas, com 7 desenvolvedores, e que já vendeu mais de 10 milhões de cópias. Eles enfatizaram a facilidade de prototipar e iterar utilizando a engine.

Outro dado interessante apresentado foi que 70% dos jogos para dispositivos móveis são feitos utilizando Unity, o que demonstra a dominância desta game engine nesta plataforma. Além disso, 33% dos jogos no Steam são feitos com Unity, e na web o número é de aproximadamente 50%. Não foram mostrados dados para consoles, mas acredito que sejam inferiores aos do Steam, caso contrário teriam sido apresentados.

Durante o keynote, foi apresentado que a Unity consolidou seus esforços em três categorias que representam o ciclo de vida de um projeto: Develop (Desenvolver), Deploy (Lançar), e Grow (Crescer). Cada novo serviço, funcionalidade ou melhoria apresentada durante o evento está dentro destas categorias. Abaixo, fiz um resumo de algumas novidades que estão por vir.

Develop
#

Em parceria com a Konami, a Unity desenvolveu e lançou um jogo para Switch 2, o Survival Kids, o que permitiu observar de perto a utilização da engine para criar um jogo do início ao fim, além de adicionar suporte ao Switch 2 no lançamento.

Este jogo foi desenvolvido pela Unity Studios, e mais jogos serão lançados para ajudar a aprimorar a engine. Levou quase 20 anos para a Unity perceber que, ao utilizar sua própria engine, poderiam entender melhor as necessidades dos desenvolvedores. Isso também faz parte de outra iniciativa da Unity, chamada Production Verification, onde garantem que uma versão da Unity foi utilizada e verificada por eles mesmos em produção (ou seja, lançaram um jogo).

Ao que tudo indica, a Unity 7 (ou o que estava sendo chamado de Unity 7 até então) foi "cancelada". Em vez de uma nova versão, a Unity lançará versões incrementais da Unity 6 (semelhante ao ciclo de lançamento da Unreal). A Unity 6.3 LTS acabou de ser lançada, e no final de 2026 teremos a Unity 6.7 LTS, sendo que as versões lançadas entre estas duas (6.4, 6.5, 6.6) trarão melhorias, mas sem o Long Time Support (LTS).

Outras novidades incluem uma nova ferramenta para utilizar modelos 3D em jogos 2D (não é 2.5D), a validação de pacotes instalados pelo Package Manager com uma assinatura que garante a autenticidade deles, entre outras melhorias detalhadas no vídeo do roadmap.

Outro destaque é a migração do .Net para o Core CLR, que deve melhorar várias áreas da engine, como redução do tempo de compilação (projetos com mais de 50% de redução), suporte a versões mais novas do C#, e maior estabilidade para o editor. A migração está prevista para começar na versão 6.4 e ser concluída na versão 6.7.

Deploy
#

O principal destaque aqui foi o Platform Toolkit, um novo pacote da Unity que promete acelerar a publicação de jogos em diversas plataformas. Os desenvolvedores precisarão de apenas uma API para cada funcionalidade específica das plataformas, como conquistas, e a Unity garantirá que isso funcione em todas as plataformas suportadas, sem necessidade de alterações no código.

Outra promessa é que isso deve ajudar no processo de certificação dos jogos para lançamento em consoles, um processo complexo e exigente. Com este novo pacote, a Unity busca facilitar o lançamento de jogos em mais plataformas, reduzindo ou até eliminando complexidades específicas de cada uma.

Grow
#

A Unity apresentou uma nova ferramenta chamada Vector AI, que analisa o mercado e os dados do jogo para oferecer direções e sugestões para aumentar o engajamento dos jogadores. Esta foi provavelmente a única menção a uma ferramenta utilizando I.A., e parece ser uma ideia promissora, especialmente para pequenos estúdios e desenvolvedores independentes que não possuem equipes dedicadas para coleta e análise de dados.

Outra novidade é uma ferramenta para In-App Purchase (compras dentro do jogo), que permite a utilização de meios de pagamento de terceiros, como Stripe e Coda, além de uma ferramenta para gerenciar o inventário do jogador. Graças ao processo da Epic contra o monopólio da Apple e Google em suas lojas digitais, o suporte a meios de pagamento de terceiros está se tornando mais comum em jogos para dispositivos móveis.

Unity x Epic
#

O momento mais surpreendente do evento foi, sem dúvidas, o anúncio da inédita parceria entre Unity e Epic, com os CEOs de cada empresa no palco. A parceria permitirá que desenvolvedores na Unreal utilizem a nova ferramenta de In-App Purchase da Unity, provavelmente disponibilizando um plugin para Unreal e permitindo o acesso ao serviço.

Além disso, foi anunciado que jogos feitos com a Unity poderão ser lançados dentro do ecossistema do Fortnite. Detalhes ainda não foram anunciados, mas estou curioso para saber como isso funcionará. Sem dúvidas, isso abre um novo mercado para jogos feitos com Unity, beneficiando desenvolvedores e jogadores.

Roadmap
#

Além do keynote, por enquanto o único vídeo publicado do evento foi o roadmap abaixo, que mostra em detalhes tudo que foi mencionado no keynote.

Como o vídeo acima aborda basicamente o mesmo assunto do keynote, porém com muito mais detalhes, não vou escrever sobre a apresentação em si.

Conclusão
#

Fiquei feliz pela ausência de I.A. generativa e por ver que a Unity está levando a sério melhorias na engine com os desenvolvedores em mente. Após o fiasco do runtime fee (cancelado) e a troca de CEO, a Unity parece estar focada em tornar sua engine mais estável, com funcionalidades e serviços alinhados às necessidades dos desenvolvedores.

Esta foi minha primeira vez no Unite, e também a primeira vez apresentando uma palestra em Inglês. Fiquei feliz de participar do evento como palestrante, insider, e por reencontrar amigos e colegas de trabalho. Isso me faz lembrar que a indústria de jogos é "pequena" e sempre reencontramos pessoas ou conhecemos alguém com contatos em comum.

Como implementar o padrão Message Queue no Unity

Mon, 03 Feb 2025 00:00:00 +0000

O padrão Message Queue é uma maneira simples e eficiente de desacoplar o código no seu projeto de jogo. Uma das formas mais fáceis e eficazes de desacoplar o código em um jogo é implementando o padrão Message Queue, também conhecido como Event Queue.

Esse padrão consiste em enviar mensagens quando você deseja atualizar algo na interface do jogo, por exemplo, sem precisar manter uma referência direta ao objeto da interface ou utilizar um padrão Singleton para expor acesso a ele. Em vez disso, a interface escutará o tipo de mensagem necessário para atualizar a interface, e essa mensagem será enviada apenas quando um sistema do jogo precisar atualizar a interface.

Vamos dividir o padrão Message Queue em três partes: o gerenciador da fila, responsável pela fila em si; a mensagem, que contém o que queremos enviar; e os ouvintes, que ficam esperando a mensagem para executar alguma ação assim que a receberem.

O gerenciador Message Queue
#

O núcleo do padrão Message Queue é uma classe responsável por armazenar uma lista de ouvintes, além de adicionar e remover ouvintes e enviar mensagens para cada ouvinte que estiver escutando um tipo específico de mensagem.

No código abaixo, criamos nossa classe MessageQueue e definimos um Dictionary para armazenar nossos ouvintes, organizando-os por tipo. Cada Type possui uma List de Delegate, que são callbacks executados quando um tipo específico de mensagem é recebido.

using System;
using System.Collections.Generic;

public class MessageQueue
{
 private readonly Dictionary<Type, List<Delegate>> _listeners;

 private MessageQueue()
 {
 _listeners = new Dictionary<Type, List<Delegate>>();
 }
}

Em seguida, adicionamos métodos à nossa classe MessageQueue. O primeiro é o AddListener, que tem o tipo genérico T para o parâmetro listener.

public void AddListener<T>(Action<T> listener)
{
 if (_listeners.TryGetValue(typeof(T), out List<Delegate> listeners))
 {
 listeners.Add(listener);
 }
 else
 {
 listeners = new List<Delegate> { listener };
 _listeners.Add(typeof(T), listeners);
 }
}

O próximo método é o RemoveListener, que remove um ouvinte da lista e, caso a lista fique vazia, a remove do Dictionary.

public void RemoveListener<T>(Action<T> listener)
{
 if (_listeners.TryGetValue(typeof(T), out List<Delegate> listeners))
 {
 listeners.Remove(listener);
 if (listeners.Count == 0)
 {
 _listeners.Remove(typeof(T));
 }
 }
}

Por fim, o método SendMessage encontra uma lista de ouvintes aguardando um tipo de mensagem e chama cada um como callback, passando a mensagem como parâmetro.

public void SendMessage(object message)
{
 if (_listeners.TryGetValue(message.GetType(), out List<Delegate> listeners))
 {
 for (int i = 0; i < listeners.Count; i++)
 {
 listeners[i].DynamicInvoke(message);
 }
 }
}

O objeto Message
#

O objeto mensagem pode ser qualquer classe. No exemplo abaixo, criamos uma classe que representa uma mensagem contendo uma propriedade NewColor.

using UnityEngine;

public class UpdateColorMessage
{
 public Color NewColor;
}

O uso dos ouvintes
#

A classe MessageQueueExample é um MonoBehaviour que pode ser adicionado a qualquer GameObject no Unity. Ela usa o MessageQueue para adicionar e remover um callback.

using UnityEngine;

public class MessageQueueExample : MonoBehaviour
{
 private readonly MessageQueue _messageQueue = new MessageQueue();

 private void OnEnable()
 {
 _messageQueue.AddListener<UpdateColorMessage>(UpdateColor);
 }

 private void OnDisable()
 {
 _messageQueue.RemoveListener<UpdateColorMessage>(UpdateColor);
 }

 private void UpdateColor(UpdateColorMessage message)
 {
 // Use o message.NewColor para atualizar a cor
 }
}

Os métodos OnEnable e OnDisable são executados uma vez pelo Unity, garantindo que os ouvintes sejam sempre adicionados e removidos corretamente.

Enviando mensagens
#

Abaixo estão três métodos que enviam mensagens para mudar a cor para vermelho, verde e azul.

public void ChangeColorToRed()
{
 var message = new UpdateColorMessage { NewColor = Color.red };
 _messageQueue.SendMessage(message);
}

public void ChangeColorToGreen()
{
 var message = new UpdateColorMessage { NewColor = Color.green };
 _messageQueue.SendMessage(message);
}

public void ChangeColorToBlue()
{
 var message = new UpdateColorMessage { NewColor = Color.blue };
 _messageQueue.SendMessage(message);
}

Cada método cria uma instância de UpdateColorMessage e define a propriedade NewColor antes de enviar a mensagem aos ouvintes.

Conclusão
#

O padrão Message Queue é muito poderoso para desacoplar o código e facilitar a comunicação entre sistemas usando mensagens. Espero que este artigo tenha ajudado você a entender como implementá-lo usando C# no Unity.

O código deste artigo, assim como um exemplo completo implementado no Unity, pode ser encontrado no meu repositório do GitHub.

Você já utilizou esse padrão em algum projeto? Compartilhe sua experiência nos comentários e me avise se tiver alguma dúvida!

Meu primeiro livro: Criando um Jogo RTS na Unity 2023

Sun, 01 Oct 2023 00:00:00 +0000

Fiquei sem atualizar o blog nos últimos meses, e hoje posso compartilhar o motivo: escrevi meu primeiro livro!

Da concepção à publição foram meses dedicando meu tempo livre para escrever um livro que combinasse minha experiência profissional de quase 14 anos desenvolvendo jogos, sendo 10 anos utilizando Unity como minha principal engine. Foi uma oportunidade incrível e que não seria possível sem a editora Packt para me apoiar e fornecer o suporter necessário para revisão de textos, código, e muito mais.

Com pouco mais de 550 páginas, em Inglês, o livro vai te ensinar a fazer um jogo RTS na Unity 2023 utilizando C#. O foco do livro é criar um jogo RTS do início ao fim, porém, todo conteúdo do livro é facilmente aplicável a praticamente qualquer outro tipo jogo, já que muitos conceitos e algoritmos são os mesmos. Apesar de ter sido um desafio ainda maior pra mim, escrever o livro em Inglês possibilita que mais pessoas tenham acesso ao seu conteúdo.

O livro já está em pré-venda, e será lançado no próximo dia 13 de Outubro na Amazon Brasil em todas as outras, inclindo algumas livrarias nos EUA e Reino Unido, e no próprio side da editora. O livro estará disponível em formato digital (Kindle) e físico.

Abaixo está uma descrição do livro sobre o conteúdo. Ficarei feliz de responder qualquer pergunta sobre o livro e seu conteúdo, e agradesço desde já se você puder adquirir o livro.

Descrição do Livro
#

Construir um jogo de estratégia em tempo real de sucesso é desafiador, devido às mecânicas complexas e à necessidade de equilibrar diferentes elementos, garantindo que os jogadores desfrutem de criar e executar estratégias contra a inteligência artificial do jogo. "Creating an RTS game in Unity 2023" irá ensinar você a instalar e configurar o motor de jogo Unity, criar um novo projeto 3D e construir um editor de níveis para facilitar a modificação e adição de mapas ao jogo.

Ao longo do livro, o seu RTS começará a ganhar forma à medida que você aprender a implementar sistemas centrais, como batalhas corpo a corpo e à distância, geradores de unidades, controles de câmera, geração dinâmica de mapas, IA básica de inimigos e o algoritmo de pathfinding. Você também dominará a implementação de unidades de comando para executar ações, produção e gestão de recursos, física básica e detecção de colisões, tudo isso enquanto constrói um jogo de estratégia em tempo real do zero, utilizando C# e as últimas funcionalidades da Unity.

O Que Você Irá Aprender
#

Configuração do Unity e criação de projetos 3D.
Desenvolvimento de um editor de níveis personalizado.
Implementação de mecânicas de combate e unidades.
Controles de câmera envolventes para o jogador.
Geração dinâmica de mapas e IA de inimigos.
Algoritmo de pathfinding para movimentação eficiente das unidades.
Comandos de unidades para execução de ações estratégicas.
Gestão de recursos e produção de unidades.
Física e detecção de colisões para um gameplay realista.
Construção completa de um RTS usando C# e Unity.
Ao final deste livro, você estará apto a criar jogos de estratégia em tempo real profissionais e de alta qualidade, utilizando as melhores práticas e técnicas da indústria de jogos.

PS: Comenta se você reconheceu a imagem da capa do livro, e se inscreva no meu canal no YouTube por que muito contéudo novo está por vir!

Desenvolvimento de jogos em Unity com TDD

Sat, 04 Mar 2023 00:00:00 +0000

Desenvolver jogos é um processo complexo e desafiador, mas o uso de técnicas de desenvolvimento de software pode ajudar a tornar esse processo mais eficiente e eficaz. Um desses métodos é o Test-Driven Development (TDD), que pode ser aplicado ao desenvolvimento de jogos com Unity.

O TDD é um processo iterativo de desenvolvimento de software que consiste em escrever testes automatizados antes de escrever o código final. O processo começa com a escrita de um teste automatizado que falha e, em seguida, a escrita de código que faça o teste passar. Isso ajuda a garantir que o código escrito atenda aos requisitos definidos pelos testes e reduz o risco de erros e defeitos.

Ao usar o TDD no desenvolvimento de jogos com o Unity, é importante seguir algumas boas práticas recomendadas para garantir que o processo seja eficaz e eficiente.

Escreva testes para cada nova funcionalidade
#

Cada nova funcionalidade que você adiciona ao seu jogo deve ter seus próprios testes automatizados. Isso ajudará a garantir que o código funcione como esperado e que não há efeitos colaterais indesejados em outras partes do jogo.

Escreva testes para cada cenário de uso
#

Além de testar cada nova funcionalidade, é importante testar cada cenário de uso do jogo. Por exemplo, se o jogo tiver uma fase em que o personagem precisa coletar moedas, é importante testar se todas as moedas são coletadas corretamente. Isso ajuda a garantir que o jogo seja jogável e livre de bugs.

Escreva testes para detectar erros comuns
#

Alguns erros são comuns no desenvolvimento de jogos com Unity, como erros de colisão e de controle de personagens. Escreva testes para detectar esses erros comuns e corrigi-los antes que eles se tornem problemas maiores.

Escreva testes antes de implementar o código final
#

O TDD requer que os testes sejam escritos antes do código final ser implementado. Isso ajuda a garantir que o código final atenda aos requisitos definidos pelos testes e ajuda a evitar a introdução de erros no código.

Execute testes automaticamente durante o processo de construção
#

Os testes automatizados devem ser executados automaticamente durante o processo de construção do jogo. Isso ajuda a garantir que todas as alterações no código sejam testadas e que nenhum erro seja introduzido no código existente.

Refatore o código à medida que novos testes são adicionados
#

À medida que novos testes são adicionados, pode ser necessário refatorar o código existente para que ele atenda aos requisitos dos novos testes. Isso ajuda a garantir que o código seja fácil de manter e que não haja erros ou problemas de desempenho.

O uso do TDD no desenvolvimento de jogos com Unity pode ajudar a garantir que o jogo seja jogável, livre de erros e fácil de manter. Ao seguir as práticas recomendadas acima, você pode maximizar os benefícios do TDD e tornar o processo de desenvolvimento de jogos mais eficiente e eficaz.

Devo admitir que TDD é algo que está na minha lista para me aperfeiçoar a anos, e ainda não saí do básico que é criar os testes na Unity e tentar lembrar de rodar eles. Por isso automatizar os testes com Integração Contínua (CI) ou adicionar um script que obrigue rodar os testes antes de um git push pode ajudar a introduzir o uso do TDD cada vez mais ao dia-a-dia.

Mas cuidado, o TDD não pode ser visto como uma barreira que atrasa o desenvolvimento - apenas entendendo e usando o TDD pensando sempre na qualidade do código pode fazer ver seu uso mais como uma garantia bem-vinda do que um empecílio.

Como exibir um README na Unity ao abrir o projeto

Sat, 16 Apr 2022 00:00:00 +0000

Uma forma interessante de exibir uma mensagem de boas vindas ou informações sobre o projeto ao ser carregado é exibir um conteúdo similar à um arquivo README que pode ser customizado e exibido na janela do inspector dentro do editor da Unity. Neste vídeo eu mostro como criar um ScriptableObject, alterar sua visualização utilizando um CustomEditor e, por fim, colocar o foco do projeto e do inspector neste arquivo ao carregar o projeto na Unity.

Abaixo estão os códigos das duas classes criadas no vídeo como referência, Readme e ReadEditor, respectivamente.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

[CreateAssetMenu(fileName = "Readme", menuName = "Create Readme")]
public class Readme : ScriptableObject
{
 public string Title;
 public List<string> Sections = new List<string>();
}

using UnityEngine;
using UnityEditor;

[CustomEditor(typeof(Readme))]
[InitializeOnLoad]
public class ReadmeEditor : Editor
{
 static ReadmeEditor()
 {
 EditorApplication.delayCall += SelectReadme;
 }

 static void SelectReadme()
 {
 EditorApplication.delayCall -= SelectReadme;

 var readmeObject = Resources.Load<Readme>("Readme");
 if (readmeObject != null)
 {
 EditorUtility.FocusProjectWindow();
 Selection.activeObject = readmeObject;
 }
 }

 protected override void OnHeaderGUI()
 {
 Readme readme = (Readme)target;

 GUILayout.BeginHorizontal();

 var style = GUI.skin.GetStyle("label");
 style.fontSize = 32;
 GUILayout.Label(readme.Title, style);

 GUILayout.EndHorizontal();
 }

 public override void OnInspectorGUI()
 {
 Readme readme = (Readme)target;

 foreach(string section in readme.Sections)
 {
 var style = GUI.skin.GetStyle("label");
 style.fontSize = 18;
 style.wordWrap = true;
 GUILayout.Label(section, style);

 GUILayout.Space(18);
 }
 }
}

Veja a playlist do canal com mais vídeos sobre Unity clicando aqui.

Dúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.

Como adicionar e utilizar botões na Unity

Sat, 15 Jan 2022 00:00:00 +0000

Neste vídeo demonstro como criar um botão na interaface da Unity, algumas customizações que podem ser aplicadas nele, e como executar um script a partir do evento OnClick. Além de um script, também mostro como executar métodos de outros objetos da Unity no OnClick.

Veja a playlist do canal com mais vídeos sobre Unity clicando aqui.

Dúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.

Utilizando Object Pool pattern na Unity

Fri, 24 Dec 2021 00:00:00 +0000

Neste vídeo mostro um exemplo de como utilizar o design patter Object Pool para reutilizar game objects em situações onde várias cópias são necessárias, como tiros ou inimigos, porém utilizando este design pattern para garantir um bom uso de memória.

A ideia do Object Pool é ter um conjunto de objetos na memória que podem ser reutilizados. Na sua inicialização, um número pré-determinado de objetos são instanciados e ficam disponíveis porém não habilitados. Quando um objeto é requisitado, ele é habilitado e fica indisponível neste conjunto. E, quando não é mais necessário, ele fica desabilitado ao invés de ser destruído para que possa ser utilizado novamente.

O projeto do vídeo está disponível neste repositório no meu GitHub. Dúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.

Como fazer um sistema de build na Unity

Sat, 18 Dec 2021 00:00:00 +0000

A Unity possui um sistema de build onde você pode exportar seu projeto para diferentes plataformas e otimizaçoes. Este sistema é um pouco limitado quando utilizado através da interface do Editor, porém ele possui uma excelente API que pode ser utilizada para criar sistemas de build bem flexíveis e robustos.

Neste vídeo eu demonstro como utilizar a API BuildPipeline da Unity e como gerar uma build através da linha de comando sem precisar abrir o projeto - o que pode ser utilizado em conjunto com sistemas de integraçao contínua, como o Jenkins. Apesar de não mostrar detalhes de como configurar, ao final do vídeo mostro como o Jenkins pode ser utilizado para gerar a build do exemplo do vídeo.

Alguns links mencionados no vídeo:

Abaixo está a linha de comando executada para gerar as builds no vídeo. Os caminhos nesta linha de comando são do meu computador e podem não funcionar no seu, modifique de acordo com o seu ambiente de desenvolvimento.

"C:\Program Files\Unity\Hub\Editor\2020.3.23f1\Editor\Unity.exe" \
 -quit \
 -batchmode \
 -projectPath "C:\Projects\unity-build-system-sample" \
 -executeMethod BuildSystem.BuildAll \
 -logFile "C:\Projects\unity-build-system-sample\BuildLog.txt"

O projeto do vídeo está disponível neste repositório no meu GitHub. Dúvidas, comentários ou sugestões para futuros vídeos deixem aqui no post ou lá no vídeo no YouTube.

Como fazer um plugin para Android em Java na Unity

Mon, 01 Mar 2021 00:00:00 +0000

Existem algumas estruturas possíveis para implementar um plugin Android na Unity. Quando utilizamos um plugin desenvolvido por terceiros é comum que a sua distribuição seja através de um arquivo AAR, que é uma biblioteca java para Android, junto com alguns scripts em C# para sua utilização. Esta é a opção mais simples, pois a Unity já reconhece o arquivo AAR como uma biblioteca Android e cuida do resto na compilação. Também é possível utilizar um arquivo JAR, mas não é um formato muito utilizado hoje em dia para desenvolvimento com Android, e até exige um pouco mais de configuração para ser utilizado na Unity.

Outra maneira de desenvolver um plugin dentro da Unity é mantendo o código java dentro do próprio projeto e, com ajuda de alguns outros arquivos, a Unity consegue configurar e compilar seu código Java como uma biblioteca para Android. Neste post não vou explicar como criar um arquivo AAR, mas é tão simples quanto criar um projeto de library no Android Studio e compilar para exportar o AAR, e a partir daí pode pular para a integração em C# na Unity.

Estrutura
#

Para usar o código java dentro da Unity precisamos montar a estrutura abaixo, assim a engine vai compilar o código corretamente como uma biblioteca Android. Qualquer plugin com código nativo deve sempre ser colocado dentro de uma pasta Plugins, e em uma sub-pasta com o nome da plataforma, no caso Android. Na pasta Android é onde fica a biblioteca Android, onde no exemplo abaixo é chamada native-test-lib. Agora precisamos de pelo menos mais 3 arquivos, que eu irei descrever em seguida.

├───Plugins
│ │
│ └───Android
│ │
│ └───native-test-lib
│ │ AndroidManifest.xml
│ │ build.gradle
│ │ project.properties
│ │
│ └───src
│ │
│ └───com
│ │
│ └───cicanci
│ │
│ └───unity
│ NativeTest.java

Arquivo de configuração
#

No arquivo project.properties é necessário colocar apenas dois parâmetros para que o projeto seja reconhecido como uma biblioteca Android, a versão da API do Android que será a target (não é a versão mínima e não necessariamente a versão que será utilizada na compilação), e o parâmetro que habilita o projeto como library.

target=android-21
android.library=true

Android Manifest
#

O AndroidManifest.xml utilizado na library tem a o mínimo necessário para a definição deste arquivo: package e versão. O package é o mesmo que será utilizado no arquivo Java, e neste exemplo é com.cicanci.unity.

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
 package="com.cicanci.unity" android:versionCode="1" android:versionName="1.0" >
 <application></application>
</manifest>

Compilação com gradle
#

Por fim, precisaremos apenas do arquivo build.gradle que também define o projeto como library e mostra para o compilador onde está o AndroidManifest.xml e o código Java (na pasta src). Aqui também temos definidas algumas versões para o SDK do Android utilizado para compilação e o mesmo target definido no arquivo project.properties. Este arquivo será compilado pela Unity junto com o gradle do projeto.

apply plugin: 'android-library'
android {
 sourceSets {
 main {
 manifest.srcFile 'AndroidManifest.xml'
 java.srcDirs = ['src']
 }
 }
 compileSdkVersion 30
 buildToolsVersion '30.0.3'
 defaultConfig {
 targetSdkVersion 21
 }
}

Com todos os arquivos acima definidos e utilizando a estrutura mostrada no início do post, a Unity irá reconhecer o projeto como um plugin para Android, como podemos ver na imagem abaixo.

Código java
#

Eu quis manter este exemplo bem simples por que meu objetivo é demonstrar como criar um plugin e utilizá-lo na Unity, por isso o código abaixo faz algo bem simples: recebe e retorna strings e inteiros. O package aqui deve ser o mesmo definido no AndroidManifest.xml. Este é um exemplo simples, porém não existem limites para uma library Android aqui quando comparada com um aplicativo para Android feito fora da Unity.

package com.cicanci.unity;

public class NativeTest {
 private int counter = 0;
 private String message = "Hello from Android";

 public int getCounter() {
 return ++this.counter;
 }
 public String getMessage() {
 return this.message;
 }
 public void setCounter(int counter) {
 this.counter = counter;
 }
 public void setMessage(String message) {
 this.message = message;
 }
}

A localização do arquivo Java dentro do plugin deve ter ser em uma estrutura de pastas que reflitam o package. Como neste exemplo o package é com.cicanci.unity, o arquivo NativeTest.java deve ficar dentro de Plugins/Android/native-test-lib/src/com/cicanci/unity/ - a localização do plugin Android na Unity + a pasta que o arquivo build.gradle vai procurar o código Java que é src + estrutura que reflete o package no AndroidManifest.xml.

Implementação no C#
#

A parte final do plugin é sua utilização na Unity através do C#, e nisso a engine ajuda bastante com a classe AndroidJavaObject. Com esta class iremos criar nosso objeto com o nome completo da classe (package + nome da classe). Após criar o objeto podemos executar métodos da classe Java utilizando o método Call(), que também possui parâmetro para retornar um tipo quando o método Java não é void.

#if UNITY_ANDROID
using UnityEngine;

public class NativeTestAndroid {
 private readonly AndroidJavaObject _nativeTestClass;

 public NativeTestAndroid() {
 _nativeTestClass = new AndroidJavaObject("com.cicanci.unity.NativeTest");
 }
 public int GetCounter() {
 return _nativeTestClass.Call<int>("getCounter");
 }
 public string GetMessage() {
 return _nativeTestClass.Call<string>("getMessage");
 }
 public void SetCounter(int counter) {
 _nativeTestClass.Call("setCounter", counter);
 }
 public void SetMessage(string message) {
 _nativeTestClass.Call("setMessage", message);
 }
}
#endif

Não existe muito segredo, é realmente bem simples executar um código de uma library Android em Java no C# da Unity. Basta prestar atenção no tipo do retorno do método e no seu nome na hora de definir os métodos no C#. Outra dica é colocar seu código C# dentro de um #if UNITY_ANDROID para evitar erros de compilação em outras plataformas já que a classe AndroidJavaObject existe apenas quando a plataforma é Android na Unity.

Conclusão
#

Neste post quis mostrar como é criar um plugin para Android na Unity e, a partir deste template é possível fazer muitas coisas. Na época da Unity 5 era mais comum criar plugins para Android, já que a engine tinha um suporte bem limitado para esta plataforma, isso mudou bastante nas versões posteriores. Hoje muito do que você precisa já tem suporte para Android na Unity, porém pode ser que seja limitado ou que você queira ter controle sobre o código - nestes casos é bom fazer seu próprio plugin.

Quando preciso desenvolver um plugin para Android na Unity eu geralmente crio um projeto novo no Android Studio e faço tudo por lá, inclusive com um aplicativo de testes. Desta forma é possível utilizar todas as ferramentas de desenvolvimento presentes na IDE antes de ir para a Unity, onde seria mais difícil e nada prático desenvolver uma library Android mais complexa. Eu prefiro exportar o projeto como um arquivo AAR, porém para algo simples e pequeno eu acabo deixando o código dentro da Unity e evito manter um projeto Android apenas para esta finalidade.

Todo o código deste post e um exemplo de uso está disponível neste repositório no GitHub. Pretendo escrever outro post mostrando como fazer o mesmo plugin para iOS e sua utilização na Unity.

Relatório da Unity sobre jogos e tendências

Thu, 25 Feb 2021 00:00:00 +0000

A Unity publicou esta semana o 2021 Game Report contendo informações e muitos dados sobre a indústria de jogos em 2020, apontando tendências para 2021. Os dados analisados no relatório são de desenvolvedores que utilizam a engine e, apesar de representar apenas quem publicou jogos utilizando a Unity, ainda assim é bem relevante como mostram os dados.

Os números impressionantes demonstram um crescimento da engine e da indústria de jogos. De acordo com a Unity, jogos desenvolvidos com a engine foram baixados cerca de 5 bilhões de vezes por mês em 2020, sendo que o número de jogadores ativos mensal foi em média 2.8 bilhões. A rede de publicidade Unity Ads teve 23 bilhões de impressões de anúncios por mês.

O relatório também mostra que a pandemia do COVID-19 contribuiu para o aumento da quantidade de jogadores que buscaram jogos mid/hardcore ao invés de casuais, que eram mais populares principalmente por quem utilizava com frequencia o transporte público. O gráfico abaixo faz um comparativo entre 2019 e 2020 e mostra que os jogadores estão dando preferência por jogos com mais contéudo já que possuem mais tempo disponível sem interrupções para jogar.

O revenue, que é a receita que o jogo faz, também cresceu em comparação com o ano anterior. O gráfico abaixo mostra que no D1, ou seja, no dia seguinte após a primeira vez que o jogo foi aberto (D0), a receita gerada por compras dentro do jogo (IAP) aumentou bastante. Este aumento de revenue também foi bem expressivo em jogos que possuem ads (publicidade) como fonte de receita.

Estes dados e muito mais estão disponíveis gratuitamente no relatório da Unity, disponível aqui em Inglês. Recomendo a leitura e análise dos dados, principalmente se você tem algum projeto em desenvolvimento para ser lançado em breve - muitos dados ainda são válidos e podem ser considerados indicadores para um produto.

Por fim, a Unity fez algumas previsões baseadas nas tendências observadas durante 2020:

Mudanças em privacidade terão um grande impacto em jogos mobile (exemplo disso é o AppTrackingTransparency da Apple que vai ser habilitado em breve no iOS 14.5).
Cross-platform entre mobile e HD (desktop/consoles) é o futuro.
Mesmo após o COVID-19 o número de jogadores vai continuar alto.

Eu pessoalmente concordo e acredito nas previsões da Unity, principalmente na questão do cross-platform entre mobile e desktop/consoles. Além disso, acredito que a geração anterior de consoles, PS4 e Xbox One, vão continuar com novos lançamentos por um tempo maior do que na geração do PS3 e Xbox 360. A base de jogadores é bem grande e acho que vai demorar para a maioria migrar para a geração atual do PS5 e Xbox Series X/S. E você, leitor, tem alguma outra previsão para a indústria de jogos em 2021?

Exemplo do Design Pattern Command na Unity com C#

Tue, 29 Dec 2020 00:00:00 +0000

Sempre recomendo o livro Game Programming Patterns, que possui versões física e digital à venda, além de uma online gratuita disponibilizada pelo autor, Robert Nystrom. Este livro revisita os design patterns definidos na década de 1990 pela "Gangue dos Quatro", focando no seu uso para o desenvolvimento de jogos.

O livro conta com excelentes exemplos e com pseudocódigo baseado em C/C++, além de descreve situações em que cada programming pattern pode ser utilizado. Já realizei algumas palestras sobre este assunto e utilizei este livro como base, sendo a mais recente na TDC Porto Alegre 2019. Meu objetivo com este post e, com os próximos que virão, é criar exemplos do uso de cada programming pattern na game engine Unity e com a linguagem de programação C#.

Seguindo a ordem do livro, este primeiro post será sobre o Design Pattern Command. O código deste exemplo, assim como de todos os próximos, pode ser acessado neste repositório do GitHub.

Design Pattern Command
#

O Command é um design pattern que tem como objetivo encapsular um método ou ação. Em uma definição muito simples pode-se dizer que é um padrão para callbacks. Um exemplo bem prático do Command é o input de um jogo. Imagine que seu jogo possui uma opção para que o jogador modifique as ações de cada botão, seja por preferencia pessoal ou acessibilidade. Com a Implementação do Command fica simples modificar o comando que um botão executa, como demonstrado no exemplo a seguir.

Implementação na Unity com C#
#

Neste exemplo de implementação existem duas ações possíveis para o jogador: Pular e Atirar. Para simplificar o exemplo, cada ação será apenas uma mensagem de log. O código abaixo define exatamente isso, dois comandos que podem ser executados. É importante ter uma interface neste caso, ou pelo menos uma classe base, para que o código que executar estas ações não precise necessariamente saber o tipo de cada classe derivada.

public interface ICommand
{
 void Execute();
}

public class JumpCommand : ICommand
{
 public void Execute()
 {
 Debug.Log("Execute command: Jump");
 }
}

public class FireCommand : ICommand
{
 public void Execute()
 {
 Debug.Log("Execute command: Fire");
 }
}

E é basicamente isso, uma interface com o método que executará uma ação e duas implementações desta interface. Agora ambas ações podem ser utilizadas em outra classe, como será demonstrado no MonoBehaviour abaixo. A classe abaixo possui dois métodos públicos executados por botões na Unity, o ButtonA() e o ButtonB(). Estes métodos executam qualquer comando associado com as respectivas variáveis, as quais possuem o tipo da interface ICommand.

public class DesignPatternCommand : MonoBehaviour
{
 private ICommand _buttonA;
 private ICommand _buttonB;

 private void Start()
 {
 _buttonA = new JumpCommand();
 _buttonB = new FireCommand();
 }

 public void ButtonA()
 {
 _buttonA.Execute();
 }

 public void ButtonB()
 {
 _buttonB.Execute();
 }
}

Quando executado, o código acima irá atribuir a ação de pular para o botão A e a ação de atirar para o botão B. Agora imagine que, neste exemplo, teremos uma opção que permite o jogador inverter os comandos dos botões. Para isso, um método como este abaixo irá alterar o comando dos botões sem a necessidade de qualquer outra modificação no código.

private void ChangeButtons()
{
 _buttonA = new FireCommand();
 _buttonB = new JumpCommand();
}

Este é um exemplo bem simples para explicar o conceito por trás deste programming pattern. A partir disso pode-se ver como o Command é um poderoso recurso para todo programador, pois permite alterar ações sem criar dependências no código. Existem outros exemplos interessantes para o seu uso, como um sistema de avançar e voltar no tempo onde todas as ações do jogador podem ser uma lista de comandos executados. Isso pode ser utilizado até mesmo em um editor para desfazer e refazer uma determinada ação.

Exemplo
#

Neste repositório do GitHub existe um exemplo utilizando o código acima, porém com 4 botões de ações do jogador e um outro botão que permite embaralhar as ações.

O Command é um padrão simples, mas que é muito poderoso quando entendido e utilizado corretamente na arquitetura de um jogo. Imagine ter que adicionar novos botões no exemplo acima, ou um hardware diferente para o input. Tudo isso pode ser feito de forma prática com o Command. Este programming pattern é um bom aliado para tornar um jogo mais acessível, permitindo a customização do controle do jogo pelo jogador.

Boas práticas para uso de logs na Unity

Mon, 26 Oct 2020 00:00:00 +0000

Neste post quero compartilhar algumas dicas e boas práticas para uso do Debug.Log() na Unity. Pode parecer intuitivo utilizar a API da Unity para registrar todo tipo de ação que o jogador fizer, mas existem algumas maneiras de fazer isso que podem tornar o processo de debug e teste mais fácil, além de registrar logs apenas do que realmente é necessário.

Em um jogo publicado não faz sentido ter chamadas para o Debug.Log(), pois que utilidade existe em registar uma mensagem do tipo "Item found!" se isso não é relevante para o jogador e você não poderá ver esta mensagem no aparelho dele? O uso do Debug.Log() pode ser muito útil enquanto está desenvolvendo e testando um jogo. Mas, mesmo assim, as mensagens precisam ser úteis e ter um contexto que ajude a entender o que está acontecendo.

Mensagens relevantes
#

Vamos analisar a seguinte sequencia de mensagens:

Button pressed!
Button pressed!
Player killed monster
Monster drops: 2

Apesar de ser possível entender o que aconteceu, estas mensagens são bem pobres em informações. Nas mensagens acima não é possível saber qual botão foi pressionado, qual monstro foi derrotado, e qual item o monstro largou. Perceba que nem é possível ver se o jogador pegou o item a partir destes logs, e se algum erro acontecer será bem difícil de reproduzir e corrigir. Por isso, é importante registrar mensagens relevantes e com contexto suficiente para entender o que aconteceu. Vamos analisar agora a mesma sequencia, porém com mais detalhes:

State changed: EXPLORING -> START_BATTLE
Player attacked monster blue and caused 10 damage (critical). Monster blue has 5HP
Player attacked monster blue and caused 7 damage. Monster blue has 0HP
Monster blue was defeated. Drops: {"potion": "potion_red","gold": 10}. Experience: +2XP
State changed: START_BATTLE -> END_BATTLE
Player picked up items: {"potion": "potion_red","gold": 10}
Player received 2XP. Now has 32/50
State changed: END_BATTLE -> EXPLORING

Ao invés de registrar um botão foi pressionado, é registrada a ação desencadeada pelo botão, o ataque e qual a consequência da ação, que foi causar dano no monstro blue. Na mesma linha do log é possível ver quanto dano foi causado, se foi um ataque crítico e quanta vida resta para o monstro. Após ser derrotado, é possível ver quais itens o monstro derrubou e quanta experiência deu ao jogador.

Podemos ver também que o jogador pegou os itens, recebeu a experiência, quanta experiência tem no momento (32), e quanto precisará para o próximo nível (50). Um detalhe a mais são os registros de mudança de estado: a batalha inicia e tem um fim. Assim, fica fácil ver que todas aquelas ações aconteceram em uma batalha, o que torna mais simples de entender e reproduzir um determinado comportamento para corrigir um erro ou até ajustar o balanceamento do jogo.

Mensagens seletivas
#

Apesar das mensagens acima terem contexto e serem relevantes, ainda assim, podem criar uma quantidade desnecessária de logs em uma sessão de jogo. Em alguns momentos vamos querer ver os logs da batalha em detalhes, porém em outros, vamos querer ver apenas os logs de mudança de estados. E em outros nenhum log, apenas erros (quando acontecerem).

Uma das maneiras de escolher quais logs devem ser exibidos no jogo é utilizar Scripting Define Symbols no código e habilitá-los no Player Settings da Unity para a plataforma desejada. Assim, é possível habilitar determinados logs para determinadas situações. Uma solução bem prática é criar uma classe estática responsável por chamar a API de logs da Unity, e fazer o jogo utilizá-la ao invés de chamar Debug.Log() diretamente.

public static class Logger
{
 [System.Diagnostics.Conditional("ENABLE_LOG_BATTLE")]
 public static void LogBattle(string message)
 {
 UnityEngine.Debug.Log(message);
 }

 [System.Diagnostics.Conditional("ENABLE_LOG_STATE")]
 public static void LogChangeState(string message)
 {
 UnityEngine.Debug.Log(message);
 }

 public static void LogWarn(string message)
 {
 UnityEngine.Debug.LogWarning(message);
 }

 public static void LogError(string message)
 {
 UnityEngine.Debug.LogError(message);
 }
}

Os métodos LogBattle() e LogChangeState() possuem o atributo Conditional com os define symbols "ENABLE_LOG_BATTLE" e "ENABLE_LOG_STATE", respectivamente. Desta maneira, é possível chamar ambos os métodos a qualquer momento no jogo, mas eles só serão executados se os respectivos define symbols estiverem habilitados no Player Settings, conforme imagem abaixo. Adicionei também métodos para Warnings e Errors, assim todos os logs podem ser concentrados nesta classe. Outra vantagem de centralizar tudo em uma classe é poder customizar as mensagens adicionando qualquer tipo de informação ou formatação.

Vale lembrar que os define symbols são por plataforma, ou seja, é necessário defini-los para cada plataforma que será utilizada. Uma maneira bem prática de adicionar e remover os define symbols é criando um script que faça isso. Este script pode ser usado a partir de um menu, ou até em um sistema de build. Isso é muito útil para gerar builds em um CI como o Jenkins, por exemplo, parametrizando a build para ter ou não determinados logs.

Utilizar uma classe como a Logger causa um efeito colateral e pode ser visto no Editor: ao clicar duas vezes em uma mensagem de log será aberto o script do Logger ao invés do script que executou o método, como acontece quando usamos diretamente o Debug.Log(). Isto pode ser corrigido modificando o código e adicionando um delegate.

public static class Logger
{
 public static class Logger
 {
 public delegate void LogHandler(string message);

 #if ENABLE_LOG_BATTLE
 public static LogHandler LogBattle = UnityEngine.Debug.Log;
 #else
 public static LogHandler LogBattle = (message) => { };
 #endif

 #if ENABLE_LOG_STATE
 public static LogHandler LogChangeState = UnityEngine.Debug.Log;
 #else
 public static LogHandler LogChangeState = (message) => { };
 #endif

 public static LogHandler LogWarn = UnityEngine.Debug.LogWarning;
 public static LogHandler LogError = UnityEngine.Debug.LogError;
 }
}

O código fica um pouco mais complexo, porém agora ao clicar duas vezes em uma mensagem de log no Editor o script que executou o Logger será aberto. Infelizmente, não é possível utilizar o atributo Conditional, pois estamos usando uma propriedade ao invés de um método, por isso é necessário utilizar o #if ... #else ... #endif. Quando o define symbol não estiver no Player Settings, nada acontece.

Existem outras coisas que podemos fazer para melhorar os logs em um jogo, desde cores e formatação até um sistema mais robusto para ligar e desligar mensagens em determinado tipo de build. Meu objetivo neste post foi mostrar algumas coisas que considero boas práticas e muito úteis para um projeto. Logs são muito importantes para um jogo, e devem ser tratados como tal. Gaste um minuto a mais para escrever uma mensagem útil, com informações que vão realmente te ajudar a entender o que está acontecendo.

Minha sugestão de centralizar os logs em uma classe e combinar com define symbols ajudam, porém muitas mensagens podem poluir e esconder informações úteis e até causar problemas de performance no jogo sem perceber. Seja bem crítico para não deixar seu projeto se tornar um mar de mensagens inúteis e planeje um tempo para revisar as mensagens de tempos em tempos.

Compressão de Asset Bundles na Unity

Mon, 24 Aug 2020 00:00:00 +0000

A utilização de Asset Bundles na Unity é uma boa solução da própria engine para download de recursos. É comum utilizar esta forma de distribuição de assets para poder atualizar ou adicionar conteúdo ao jogo após o lançamento, não sendo necessário publicar um novo binário do jogo. Desta forma, jogos podem adicionar personagens, níveis, ou fazer correções em modelos e imagens sem precisar de uma versão nova do jogo. A única limitação é não poder adicionar novos scripts ou utilizar scripts em versões diferentes dos que estão no binário, o que faz os desenvolvedores pensarem em formas de tornar seus jogos mais flexíveis e extrair o máximo dos asset bundles.

Porém, existem mais vantagens em utilizar asset bundles do que apenas atualizar o conteúdo do jogo: é possível reduzir o tamanho do jogo, o uso de memória, uso de CPU e até tempo de loading ajustando algumas opções de compressão na Unity. O objetivo deste post é explorar algumas combinações de compressão, utilizando a plataforma Android como exemplo, e comparar os resultados. Se você quiser saber mais sobre asset bundles, recomendo este curso gratuito da Unity.

Configuração
#

Escolhi a plataforma Android para o teste por ser mais simples de compilar e testar em um aparelho. Utilizei um Samsung Galaxy S9 com Android 8.0.0 nos testes e instalei um total de 27 builds nele, cada uma contendo uma combinação de compressão no APK e nos asset bundles. Para deixar o teste mais simples, todos asset bundles foram carregados a partir da pasta StreamingAssets. A versão da Unity utilizada foi a 2019.4.7f1 e todas as builds foram geradas em modo release.

A primeira variação foi a configuração do APK gerado pela Unity no Player Settings. Realizei testes com o Scripting Backend Mono e IL2CPP, além de testar com as arquiteturas ARMv7 e AMR64, já que o aparelho utilizado no teste suporta ambas.

No Build Settings testei os métodos de compressão do APK: Default (ZIP), LZ4 (recomendado para development) e LZ4HC (melhor compressão, porém processo de build mais lento). Esta configuração, assim como as anteriores, não afetam os asset bundles, porém são algumas mudanças no APK que quis testar para ver a influência na build.

As últimas configurações foram feitas na geração dos asset bundles, utilizando o Unity package Asset Bundle Browser versão 1.0.7. Para o teste foram gerados 3 conjuntos de asset bundles, cada um com opção de compressão:

No compression: sem compressão, carregamento rápido.
LZMA: menor tamanho de arquivo, porém mais lento para carregar por causa da descompressão.
LZ4: compressão com tamanho maior, porém, descompressão mais rápida.

Teste
#

Para realizar o teste escrevi um script bem simples para gerar todas as builds Android, as quais iriam utilizar no teste, considerando as seguintes variações e resultado em um total de 27 APKs:

Scripting backend: Mono, IL2CPP
Architecture: ARMv7, ARM64
Build compression: Default, LZ4, LZ4HC
Asset bundles compression: No compression, LZMA, LZ4

Com os 27 APKs gerados, instalei cada um no aparelho, sempre desinstalando o anterior. Cada APK foi iniciado apenas uma vez, com os seguintes dados coletados:

Tamanho da builds
Tempo até executar o método Awake() no único MonoBehaviour em um Game Object na Scene
Tamanho do asset bundle
Média do tempo para carregar um asset bundle usando a API AssetBundle.LoadFromFileAsync()

O projeto de teste contém 5 asset bundles, todos são cubos padrões da Unity com um material diferente em cada para modificar a cor (green, orange, purple, red, yellow). Cada asset bundle foi carregado sequencialmente, e o tempo considerado foi a média do tempo para carregar cada um deles.

private IEnumerator Start()
{
 yield return CreateCube("green", "cube_green", new Vector3(0, 0, 0));
 yield return CreateCube("orange", "cube_orange", new Vector3(0, 1.5f, 0));
 yield return CreateCube("purple", "cube_purple", new Vector3(0, -1.5f, 0));
 yield return CreateCube("red", "cube_red", new Vector3(1.5f, 0, 0));
 yield return CreateCube("yellow", "cube_yellow", new Vector3(-1.5f, 0, 0));
}

private IEnumerator CreateCube(string bundleName, string assetName, Vector3 position)
{
 string path = Path.Combine(Application.streamingAssetsPath, bundleName);

 AssetBundleCreateRequest assetBundleRequest = AssetBundle.LoadFromFileAsync(path);
 yield return assetBundleRequest;

 GameObject sphere = assetBundleRequest.assetBundle.LoadAsset<GameObject>(assetName);
 Instantiate(sphere, position, sphere.transform.rotation, transform);
}

O script acima é uma versão simplificada do que utilizei para o teste. Omiti os logs e medições para mostrar como carreguei cada asset bundle e instanciei o game object.

Resultado
#

O resultado das 27 execuções de cada build está na tabela abaixo, ordenada pelo menor tempo médio para carregar um asset bundle.

Build	Backend	Arch.	APK	Startup	Bundle	Size	Avg. ^
LZ4HC	IL2CPP	ARM64	84.5MB	2.04s	No	15.4MB	46.4ms
LZ4HC	Mono	ARMv7	94.5MB	2.14s	No	15.4MB	49.4ms
LZ4HC	IL2CPP	ARM64	46.2MB	2.03s	LZ4	7.7MB	50ms
LZ4	IL2CPP	ARM64	84.6MB	2.04s	No	15.4MB	52.4ms
Default	IL2CPP	ARM64	84.5MB	2.04s	No	15.4MB	54.8ms
LZ4	IL2CPP	ARM64	46.2MB	2.04s	LZ4	7.7MB	55.4ms
LZ4	IL2CPP	ARMv7	45.6MB	2.03s	LZ4	7.7MB	55.8ms
LZ4HC	IL2CPP	ARMv7	84.0MB	2.03s	No	15.4MB	56ms
LZ4	IL2CPP	ARMv7	84.0MB	2.04s	No	15.4MB	56.8ms
Default	IL2CPP	ARM64	46.1MB	2.04s	LZ4	7.7MB	57.6ms
LZ4HC	IL2CPP	ARMv7	45.6MB	2.03s	LZ4	7.7MB	57.8ms
LZ4	Mono	ARMv7	94.6MB	2.14s	No	15.4MB	58.2ms
Default	Mono	ARMv7	56.1MB	2.14s	LZ4	7.7MB	59.8ms
Default	IL2CPP	ARMv7	83.9MB	2.04s	No	15.4MB	61.2ms
Default	IL2CPP	ARMv7	45.5MB	2.03s	LZ4	7.7MB	61.4ms
Default	Mono	ARMv7	94.5MB	2.13s	No	15.4MB	62.4ms
LZ4	Mono	ARMv7	56.2MB	2.13s	LZ4	7.7MB	62.8ms
LZ4HC	Mono	ARMv7	56.2MB	2.13s	LZ4	7.7MB	67.8ms
LZ4HC	IL2CPP	ARM64	39.4MB	2.03s	LZMA	6.4MB	1331.6ms
Default	IL2CPP	ARM64	39.3MB	2.03s	LZMA	6.4MB	1343ms
LZ4	Mono	ARMv7	49.4MB	2.13s	LZMA	6.4MB	1355.8ms
LZ4	IL2CPP	ARM64	39.4MB	2.03s	LZMA	6.4MB	1358.6ms
LZ4HC	Mono	ARMv7	49.4MB	2.13s	LZMA	6.4MB	1369.2ms
LZ4	IL2CPP	ARMv7	38.8MB	2.04s	LZMA	6.4MB	1376.4ms
LZ4HC	IL2CPP	ARMv7	38.8MB	2.03s	LZMA	6.4MB	1378.8ms
Default	IL2CPP	ARMv7	38.7MB	2.04s	LZMA	6.4MB	1394ms
Default	Mono	ARMv7	49.3MB	2.13s	LZMA	6.4MB	1414.8ms

Legenda da tabela:

Build: compression method do Build Settings
Backend: scripting backend do Player Settings
Arch.: architecture do Player Settings
APK: tamanho do APK
Startup: tempo até carregar o MonoBehaviour
Bundle: compression do Asset Bundle Build
Size: tamanho do asset bundle
Avg.: tempo médio para carregar um asset bundle

Conclusão
#

O projeto utilizado no teste era bem pequeno e, apesar do foco ser a compressão de asset bundles, foi interessante ver como as demais configurações influenciam no todo. Qual a melhor configuração para o seu projeto? Depende.

Não comprimir asset bundles faz o carregamento ser muito rápido, porém, isso aumenta tanto o tamanho dos arquivos baixados e da build (quando possuem asset bundles), o que é bem raro um jogo grande utilizar. A compressão LZMA deixa um tamanho menor para download, reduzindo o tempo para o jogador poder jogar e até diminuindo o custo do CDN, porém, aumenta bastante o tempo de loading por causa da descompressão. O LZ4 pode ser o melhor dos dois mundos, sendo relativamente rápido para carregar e não tão pesado, mas ainda assim depende muito do projeto.

Já nas configurações específicas do Android, LZ4HC mostrou um bom desempenho para carregar o jogo, assim como o IL2CPP. Sempre que possível inclua as duas arquiteturas, ARMv7 e ARM64, no APK ou no Android App Bundle (AAB) - o Android vai fazer o resto e decidir qual é a melhor arquitetura presente no app para ser utilizada. No caso do teste, eu forcei builds apenas com ARMv7 e ARM64 para poder comparar os resultados, já que se incluísse ambas apenas a ARM64 seria utilizada.

Lembrando novamente que, este teste foi realizado em um projeto pequeno e simples, mas que serviu para mostrar qual seria a melhor combinação para este jogo. Mais do que isso, este teste mostra que existem muitas variáveis nas configurações do projeto na Unity, as quais podem influenciar bastante a performance do jogo, e conhecê-las te ajudará a escolher qual é a melhor para seu projeto. Lembre-se de não decidir sem testar, algumas horas do seu dia podem melhorar muito o desempenho do seu jogo.

Um ótimo tutorial feito pela Unity para criar um Flappy Bird

Sat, 18 Apr 2020 00:00:00 +0000

Este tutorial chamado Making A Flappy Bird Style Game feito pela Unity esta disponível no site Unity Learn e é dividido em 10 partes. Não é um tutorial novo, foi publicado em 2006, porém existem muitas coisas interessantes nestes vídeos que ainda são bem atuais para desenvolvimento de jogos 2D na Unity, além de muitas dicas de como ser mais produtivo no editor.

Esta série de vídeos, que tem menos de 2 horas no total, é um conteúdo rápido e muito bom para aprender algumas coisas básicas na Unity, além de exemplos de design patterns na prática. Eu recomendo pra quem tem experiência com Unity também, pois sempre temos algo a aprender. Eu assiti todo o curso e realmente aprendi e relembrei algumas coisas.

Os vídeos estão disponíveis no site Unity Learn e também no canal da Unity no Youtube. Listei todos abaixo, mas recomendo fortemente acompanhar pelo site da Unity Learn por que em cada vídeo tem o código em seguida pra você ver em detalhes.

Vale lembrar que todo conteúdo premium da Unity Learn está disponível de graça por um tempo. O conteúdo criado pela Unity é muito bom, e tem vídeos para todas as áreas - de arte a programação. Aproveita que você está em casa e assiste alguns dos vídeos, e depois comenta aqui os que você mais gostou de ver lá.

Como criar e utilizar um Unity Package

Sun, 01 Mar 2020 00:00:00 +0000

Uma forma comum de compartilhar código, modulos e até plugins nativos sempre foi criar um package - exportar um arquivo .unitypackage para ser importado em outro projeto. É uma forma prática de distribuir conteúdo para Unity, porém tem problemas como falta de versionamento, não ter um canal de distribuição centralizado, não avisar de atualizações, permitir que seu conteúdo seja modificado ou removido, entre outros. Isso tudo, quando existia, dependia do desenvolvedor criar uma ferramenta para controlar a integridade e o versionamento do pacote.

Felizmente, a Unity criou uma ferramenta que ajuda em todos os pontos acima e mais alguns, chamada Unity Package Manager. Para utilizá-lo, é necessário criar um projeto seguindo o padrão de package, que pode depois ser importado como um projeto local, um tarball, um repositório git, e até distribuído por npm.

Neste post vou falar mostrar como eu fiz para criar o meu package chamado Cicanci Utils e como configurei para ele ser distribuído em um repositório público no GitHub. O conteúdo do package em si é bem básico no momento - apenas um script para enviar e receber mensagens que criei neste post. Minha ideia é adicionar mais scripts úteis neste package, sempre com algum post explicando seu funcionamento.

Criando um package
#

Criar um package é bem simples, e começa com um projeto novo na Unity. Depois de criar um projeto novo, você precisa criar os seguintes arquivos, sendo que alguns são obrigatórios como o package.json e a estrutura abaixo para código e teste.

O package.json é um arquivo com toda informação necessária sobre o pacote, e é o que vai ser exibido na janela do Package Manager. Este arquivo contém campos importantes como nome, versão do pacote, versão mínima suportada, e dependencias de outros packages. Abaixo está o exemplo do meu, que contém também dados de autor, palavras-chave e o tipo do pacote.

{
 "name": "com.cicanci.unity-utils",
 "version": "1.0.0",
 "displayName": "Cicanci Utils",
 "description": "Useful pieces of code for Unity projects.",
 "unity": "2017.4",
 "keyworks": [
 "library",
 "utility",
 "utils"
 ],
 "author": {
 "name": "Bruno Cicanci",
 "email": "bruno@cicanci.com",
 "url": "https://cicanci.com"
 },
 "type": "library"
}

Adicionando conteúdo
#

No meu caso, eu criei um package do tipo library e adicionei o código do pacote em uma pasta chamada Runtime e os testes unitários em uma outra pasta chamada Test\Runtime. Além dos scripts, é necessário criar um arquivo asmdef para cada um desses dois diretórios. Dentro destas pastas pode ter a estrutura de namespace que você quiser.

Para funcionar os testes eu tive que adicionar no asmdef dele uma referência para o pacote da Unity chamado Test Runner (engine e editor). Caso contrário, um erro de compilação acontece por que uma pasta com asmdef não consegue importar e usar namespaces de pacotes que não estão adicionados como referência, além da API padrão da Unity.

Publicando no GitHub
#

Eu tive alguns problemas para publicar o package no GitHub e fazer ele ser reconhecido pela Unity. O primeiro problema é a estrutura, pois a Unity não reconhece como um package um projeto na raiz do repositório. Para funcionar é necessário adicionar o conteúdo do package direto na raiz do repositório, como mostrado na image abaixo.

O segundo problema que tive, depois que resolvi a estrutura do repositório, foi com os arquivos .meta. Eu acho que não eram necessários, já que no repositório não é mais um projeto Unity. Porém, eu estava enganado e é necessário sim adicionar estes arquivos.

Esta estrutura é bem simples, porém dificulta um pouco na hora de atualizar o pacote e publicar. A melhor maneira que encontrei foi criar um projeto na Unity e clonar o repositório dentro dele. Provavelmente existe alguma maneira melhor de manter um package publicado no GitHub, se você souber por favor comenta a baixo.

Eu publiquei como um repositório público por ser mais simples e poder realmente divulgar o package, porém também é possível configurar um repositório privado para ser usado na sua empresa ou em seus projetos, por exemplo. Não li sobre como fazer, mas li que é possível sim com alguma configuração a mais.

Importando em seu projeto
#

Por fim, vamos a parte da utilização do package. É bem simples, basta abrir o Package Manager e adicionar um novo package como git URL. Você pode adicionar o link SSH ou HTTPS, ambos funcionam. No meu pacote o link é https://github.com/cicanci/cicanci-utils.git.

Depois de importado, basta usar como normalmente é feito. Importe o namespace na sua classe e está pronto para utilizar todo conteúdo do package. Abaixo está um exemplo de uso, que também está disponível no README do repositório.

using Cicanci.Utils;
using UnityEngine;

public class MessageBehaviour : MonoBehaviour
{
 private void Start()
 {
 MessageManager.Instance.AddListener<MyMessage>(OnMessageReceived);
 }

 private void OnDestroy()
 {
 MessageManager.Instance.RemoveListener<MyMessage>(OnMessageReceived);
 }

 private void OnMessageReceived(MyMessage message)
 {
 Debug.Log(message.Greetings);
 }

 public void SendMessage()
 {
 MyMessage message = new MyMessage { Greetings = "Hello, World!" };
 MessageManager.Instance.SendMessage(message);
 }
}

public class MyMessage
{
 public string Greetings;
}

Conclusão
#

Apesar de dar um pouco mais de trabalho para configurar do que apenas exportar seu projeto como um .unitypackage, as vantagens de utilizar o novo sistema de package é bem grande. É bem simples para outros desenvolvedores usarem seu código e conteúdo, e mais fácil para manter atualizado e organizado seguindo um padrão pré-definido pela engine.

Meu package Cicanci Utils é bem simples e pequeno, eu criei apenas para estudar como criar e distribuir um pacote, e poder postar o resultado aqui no blog. Minha idea é adicionar mais scripts úteis neste package, junto com posts explicando o que tem de novo nele. É bom ter um lugar organizado e centralizado onde posso jogar meus scripts que uso com frequência ao invés de copiar e colar de outros projetos.

Vou deixar uma referência muito boa que é este vídeo do canal Infallible Code explicando praticamente tudo que escrevi neste post, com exceção da parte de publicá-lo no GitHub. Recomendo assistir os demais vídeos deste canal, o conteúdo é muito bom.

O que você achou do Package Manager? Usaria em seu projeto? Se já usou e tem dicas para compartilhar, deixe um comentário abaixo.

Dicas para teste técnico com Unity #2

Mon, 14 Oct 2019 00:00:00 +0000

Este é o segundo post da série com dicas para teste técnico utilizando Unity e C#. No primeiro post, o foco foi como organizar o projeto para facilitar seu desenvolvimento, e como enviar após o término. Agora, vamos falar um pouco de código, cobrindo um dos erros comuns que vejo em testes técnicos, especialmente relacionado a API da Unity.

Nesta série de posts sobre dicas para teste técnico, o assunto código vai ser bem recorrente, mas não vamos deixar de lado tópicos relacionados a configuração da engine, e features que podemos usar sem necessariamente escrever código pra isso. A Unity possui diversas ferramentas, e meu objetivo aqui vai ser sempre ajudar a evitar alguns erros comuns e mostrar o que é interessante demonstrar em um teste técnico nesta engine.

Uso do GetComponent na Unity
#

Meu objetivo não é falar para usar ou não usar uma determinada chamada da API da Unity, mas sim mostrar o lugar ideal para colocá-la quando utilizada. Vamos começar por uma das mais comuns: GetComponent, utilizado para buscar um componente, de um tipo específico, no gameObject. O GetComponent possui algumas variações, como: GetComponents, para retornar uma lista de um tipo; o GetComponentInParent, que busca no pai do gameObject; e o GetComponentInChildren, que busca no filho do gameObject. Estes dois últimos também possuem uma variação para retornar uma lista do tipo desejado.

Vamos para alguns exemplos e, nos códigos a seguir, imagine que o script está em um gameObject na scene. No código abaixo, você consegue identificar qual é o problema?

public class MyGame : MonoBehaviour
{
 private void Awake()
 {
 GetComponent<SpriteRenderer>().enabled = false;
 }
}

Neste exemplo, estamos buscando o componente SpriteRenderer e assumindo que ele existe para, logo em seguida, mudar o valor de uma propriedade sua. Se o componente não existir, vamos gerar um NullReferenceException logo no Awake() do MonoBehaviour. Vamos modificar um pouco o código para corrigir isso.

public class MyGame : MonoBehaviour
{
 private void Awake()
 {
 if(GetComponent<SpriteRenderer>() != null)
 {
 GetComponent<SpriteRenderer>().enabled = false;
 }
 }
}

Parece mais seguro agora, não? Evitamos o uso do NullReferenceException, mas ainda tem algo que não é o ideal ali. Estamos usando duas vezes a chamada do GetComponent(), podemos reduzir para uma chamada com a modificação abaixo.

public class MyGame : MonoBehaviour
{
 private void Awake()
 {
 var spriteRenderer = GetComponent<SpriteRenderer>();
 if(spriteRenderer != null)
 {
 spriteRenderer.enabled = false;
 }
 }
}

Podemos, também, garantir que o objeto vai ter um determinado script anexado usando o RequireComponent, assim não precisamos verificar se o componente existe.

[RequireComponent(typeof(SpriteRenderer))]
public class MyGame : MonoBehaviour
{
 private void Awake()
 {
 var spriteRenderer = GetComponent<SpriteRenderer>();
 spriteRenderer.enabled = false;
 }
}

Voltando um pouco, vamos falar agora o que o GetComponent faz por trás da chamada. O código C# da Unity está no seu GitHub para ser usado como referência, assim fica fácil de ver o que alguma determinada API faz. Não é o código inteiro da engine, apenas a parte C#, mas já ajuda muito a aprender o que cada API faz. No caso, o GetComponent faz isso:

public unsafe T GetComponent<T>()
{
 var h = new CastHelper<T>();
 GetComponentFastPath(typeof(T), new System.IntPtr(&h.onePointerFurtherThanT));
 return h.t;
}

Não precisa ser muito experiente em C# para ver que existem duas alocações ali, um CastHelper e um System.IntPtr, além do que o GetComponentFastPath() deve executar no código C++ da Unity (essa parte não está disponível para consulta). Não é muita coisa, e não é algo que vai fazer muita diferença de performance, mas podemos evitar o uso do GetComponent em alguns casos, como o exemplo abaixo, onde a variável é recebida pelo Inspector, e podemos até usar o GetComponent caso ela não seja referenciada no gameObject.

public class MyGame : MonoBehaviour
{
 [SerializeField]
 private SpriteRenderer _spriteRenderer = null;
 private void Awake()
 {
 if(_spriteRenderer == null)
 {
 _spriteRenderer = GetComponent<SpriteRenderer>();
 }
 _spriteRenderer.enabled = false;
 }
}

A modificação acima não vai fazer muita diferença, o GetComponent é rápido o suficiente pra não causar problemas de performance. Porém, com base em tudo que escrevi neste post, o código abaixo não é recomendado. É um caso exagerado onde queremos garantir que o SpriteRenderer esteja desabilitado por qualquer motivo, usando um Update() para a validação.

public class MyGame : MonoBehaviour
{
 private void Update()
 {
 if(!GetComponent<SpriteRenderer>().enable)
 {
 GetComponent<SpriteRenderer>().enable = true;
 }
 }
}

O código acima, em um projeto médio/grande, pode causar alguns problemas de performance, especialmente se esse padrão estiver espalhado pelo projeto e a plataforma algo for Android ou iOS. Aparelhos mais antigos podem ter uma redução no FPS ou apresentar algumas travadas rápidas em transições. Então, sempre que possível, faça cache do GetComponent.

O post ficou um pouco longo, mas espero que eu tenha conseguido mostrar algumas maneiras de usar o GetComponent e, principalmente, recomendações do que deve ser evitado. Tudo isso é analisado em um teste técnico, independente do tamanho do projeto, pois ajuda a entender como o programador pensar e o quanto conhece da Unity, a game engine em questão. Deixei passar algo no post? Usa o GetComponent de alguma mandeira diferente? Comenta abaixo, sempre temos muito o que aprender, por isso compartilhar sempre acrescenta.

Canal no Youtube com tutorials em Unity

Fri, 04 Oct 2019 00:00:00 +0000

O canal no YouTube Code Monkey tem diversos vídeos muito bons sobre desenvolvimento de jogos, com uma ótima didática e bem resumidos. O autor do canal é um programador, que já publicou alguns dos seus jogos no Steam e, através do seu canal, compartilha tudo que já usou para fazer seus jogos utilizando Unity e C#.

No site do Code Monkey estão todos os seus vídeos, como no YouTube, e algum conteúdo extra, como seu pacote Code Monkey Utilities, com diversos scripts muito úteis para acelearar o desenvolvimento de jogos na Unity, e também é usado em seus vídeos.

Vou listar alguns vídeos que gostei abaixo, não deixei de conferir o seu canal no YouTube para ver mais conteúdo. Outro canal muito bom, que já indiquei aqui no blog, é o Brackeys.

Humble Bundle Unity com cursos, ferramentas e assets

Mon, 30 Sep 2019 00:00:00 +0000

O Humble Bundle é um site que vende bundles (pacotes) com jogos ou livros digitais pelo preço que você quiser pagar, e ainda permite escolher dividir seu pagamento entre caridade e/ou para o desenvolvedor. Este mês ele fez uma parceria com a Unity e lançou um bundle contendo recursos e ferramentas da Asset Store, um curso do GameDevHQ, e 1 ano de acesso aos cursos do Unity Learn Premium.

A soma total de todo conteúdo do bundle é de mais de $1000 dólares, e você pode pagar apenas $15 dólares por tudo isso (valor mínimo para pegar tudo). Só os cursos do Unity Learn Premium já valem o preço e, além disso, alguns assets e ferramentas do pacote são essenciais para agilizar o desenvolvimento de um projeto ou até fazer um protótipo para testar uma ideia.

Vou colocar abaixo alguns vídeos de assets e ferramentas contidos nesse bundle, como: Eazy Mobile Pro, praticamente tudo que você precisa para um jogo mobile (IAP, Ads, Login, etc); DoozyUI, para fluxos de UI; Aura 2, que possui efeitos incríveis de luz; e o famoso PlayMaker, uma ferramenta de visual scripting para Unity.

O Humble Bundle Unity vai até o dia 14 de Outubro. Se você está começando a estudar Unity, recomendo pegar pelos cursos. Se você já tem experiência, recomendo pelos cursos e assets. Considerando a cotação do dólar de hoje esse bundle me custou R$70, um valor muito baixo pela quantidade de conhecimento e assets de qualidade incluídos no pacote. No lugar de comprar aquele jogo em promoção no Steam, aproveite para aprimorar seu conhecimento em Unity.

Dicas para teste técnico com Unity #1

Wed, 25 Sep 2019 00:00:00 +0000

Parte do meu trabalho na Aquiris é avaliar testes e realizar entrevistas técnicas com candidatos. Nos últimos anos aplicando testes, percebi que existe um padrão de erros básicos que, infelizmente, são comuns até para Senior Programmers. Este será o primeiro de uma série com dicas e sugestões do que fazer e não fazer em um teste técnico, focando Unity e C#.

Quando uma empresa de jogos pede para um candidato realizar um teste técnico utilizando Unity, pode ser algo desde criar um jogo do zero, corrigir ou expandir um projeto existente. A qualidade do código também é avaliada, mas parte do teste consiste em ver o conhecimento do candidato em desenvolvimento de jogos, boas práticas, organização e conhecimento na própria engine em questão. Antes de falar de assuntos mais técnicos, vamos começar com um bem simples: como enviar o teste.

Melhores práticas para enviar o resultado de um teste técnico
#

Submeter o teste técnico feito na Unity não é simplesmente zipar toda a pasta do projeto e enviar. Isso requer não enviar algumas pastas e arquivos, o que também é avaliado por demonstrar conhecimento da estrutura básica da Unity e boas práticas de organização do projeto. Um projeto Unity, basicamente, é composto pelas seguinte pastas:

Assets: Onde fica o projeto em si
Packages: JSON com as dependências do projeto
ProjectSettings: Configuração do projeto

Qualquer outra pasta além destas não é necessário adicionar, isso é o mínimo para rodar qualquer projeto Unity. Nunca inclua a pasta Library, ela não é necessária para rodar o jogo e aumenta muito o tamanho do projeto. Se um zip contém mais de 1MB, eu ja suspeito que esta pasta, desnecessária para o projeto, foi incluída.

Se você utilizar um repositório git em um servíco como o GitHub (recomendo), na criação do repositório é possível escolher iniciar o repositório com um arquivo .gitignore com a configuração da Unity para ignorar qualquer arquivo e pasta desnecessária.

Outras recomendações são sempre criar o repositório como privado, já que é um teste técnico para uma vaga, e marcar a opção de adicionar o arquivo README. Neste arquivo inclua toda e qualquer informação relevante sobre o projeto, como rodar o jogo e detalhes que sejam relevantes para o teste técnico. Use este arquivo para documentar o que for necessério, assim todas informações ficarão junto ao projeto/repositório, e não perdidas em um arquivo externo ou em um e-mail.

Configurando o repositório corretamente, além de facilitar o seu desenvolvimento, vai simplificar a submissão, pois você precisa apenas baixá-lo como zip e enviar. Isso é importante, envie como zip. Quem vai revisar o teste técnico pode estar usando um macOS e não precisa ser obrigado a baixar um app pra descompactar rar ou outro formato diferente.

Por fim, após ter o seu arquivo zip enxuto, envie por e-mail e compartilhe através do Google Drive ou similares, assim a pessoa que receber o seu teste técnico vai ter mais de uma maneira de baixá-lo caso tenha algum problema. Enviar o resultado é uma tarefa simples, mas você ganhará pontos em se preocupar com estes detalhes.

Por mais que o tempo para fazer o teste técnico seja curto, você não levará mais do que alguns minutos para configurar o projeto e deixar tudo pronto para uma submissão tranquila, então falta de tempo não é desculpa para enviar o resultado do teste de qualquer jeito.

Gostou dessa dica? Comente abaixo compartilhando sua experiência realizando testes técnicos para vagas em desenvolvmento de jogos. No próximo post vou abortar um erro comum relacionado a programação e uso das APIs da Unity.

Unity · Game Developer

Git no Unity: Como configurar um repositório do zero

Minha participação na Unite 2025 em Barcelona

Keynote #

Develop #

Deploy #

Grow #

Unity x Epic #

Roadmap #

Conclusão #

Como implementar o padrão Message Queue no Unity

O gerenciador Message Queue #

O objeto Message #

O uso dos ouvintes #

Enviando mensagens #

Conclusão #

Meu primeiro livro: Criando um Jogo RTS na Unity 2023

Descrição do Livro #

O Que Você Irá Aprender #

Desenvolvimento de jogos em Unity com TDD

Escreva testes para cada nova funcionalidade #

Escreva testes para cada cenário de uso #

Escreva testes para detectar erros comuns #

Escreva testes antes de implementar o código final #

Execute testes automaticamente durante o processo de construção #

Refatore o código à medida que novos testes são adicionados #

Como exibir um README na Unity ao abrir o projeto

Como adicionar e utilizar botões na Unity

Utilizando Object Pool pattern na Unity

Como fazer um sistema de build na Unity

Como fazer um plugin para Android em Java na Unity

Estrutura #

Arquivo de configuração #

Android Manifest #

Compilação com gradle #

Código java #

Implementação no C# #

Conclusão #

Relatório da Unity sobre jogos e tendências

Exemplo do Design Pattern Command na Unity com C#

Design Pattern Command #

Implementação na Unity com C# #

Exemplo #

Boas práticas para uso de logs na Unity

Mensagens relevantes #

Mensagens seletivas #

Compressão de Asset Bundles na Unity

Configuração #

Teste #

Resultado #

Conclusão #

Um ótimo tutorial feito pela Unity para criar um Flappy Bird

Como criar e utilizar um Unity Package

Criando um package #

Adicionando conteúdo #

Publicando no GitHub #

Importando em seu projeto #

Conclusão #

Dicas para teste técnico com Unity #2

Uso do GetComponent na Unity #

Canal no Youtube com tutorials em Unity

Humble Bundle Unity com cursos, ferramentas e assets

Dicas para teste técnico com Unity #1

Melhores práticas para enviar o resultado de um teste técnico #

Keynote
#

Develop
#

Deploy
#

Grow
#

Unity x Epic
#

Roadmap
#

Conclusão
#

O gerenciador Message Queue
#

O objeto Message
#

O uso dos ouvintes
#

Enviando mensagens
#

Conclusão
#

Descrição do Livro
#

O Que Você Irá Aprender
#

Escreva testes para cada nova funcionalidade
#

Escreva testes para cada cenário de uso
#

Escreva testes para detectar erros comuns
#

Escreva testes antes de implementar o código final
#

Execute testes automaticamente durante o processo de construção
#

Refatore o código à medida que novos testes são adicionados
#

Estrutura
#

Arquivo de configuração
#

Android Manifest
#

Compilação com gradle
#

Código java
#

Implementação no C#
#

Conclusão
#

Design Pattern Command
#

Implementação na Unity com C#
#

Exemplo
#

Mensagens relevantes
#

Mensagens seletivas
#

Configuração
#

Teste
#

Resultado
#

Conclusão
#

Criando um package
#

Adicionando conteúdo
#

Publicando no GitHub
#

Importando em seu projeto
#

Conclusão
#

Uso do GetComponent na Unity
#

Melhores práticas para enviar o resultado de um teste técnico
#