Blog · Game Developer

Minha palestra na Unite 2025 em Barcelona

Thu, 18 Dec 2025 00:00:00 +0000

No mês passado, participei do evento anual da Unity, o Unite, em Barcelona, onde apresentei a palestra Reusable technology: Saving development time with shared Unity plug-ins and SDKs. Durante a apresentação, compartilhei dicas e melhores práticas para desenvolver, compartilhar e manter SDKs e plugins para Unity.

Hoje, a Unite publicou a gravação da palestra em seu canal oficial, junto com as demais apresentações do evento. Você pode conferir o vídeo abaixo, assim como os slides da apresentação.

Apresentei a palestra em inglês, mas, caso seja mais fácil, no YouTube você pode selecionar uma dublagem gerada pelo Google em português nas configurações do vídeo ou adicionar legendas geradas em inglês.

Abaixo estão os slides da apresentação, que publiquei no Slideshare junto com minhas outras palestras. O PDF também está disponível neste link para download.

Comente abaixo se tiver alguma pergunta ou dúvida sobre a minha apresentação. Este é um assunto que faz parte do meu dia a dia trabalhando na Ubisoft, e tenho bastante coisa para compartilhar.

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.

Minha participação no Ludum Dare #58

Fri, 10 Oct 2025 00:00:00 +0000

Apesar de participar da game jam Ludum Dare há mais de uma década, ainda continuo aprendendo como finalizar um projeto em um tempo tão curto.

Lembro da primeira vez que participei de uma game jam, lá em 2015. Na época eu já trabalhava na indústria de jogos há cerca de cinco anos, com nomes como Glu e Electronic Arts no currículo, mas as game jams sempre me ensinaram algo novo sobre desenvolvimento de jogos.

Como mencionei no meu artigo anterior, decidi participar da última edição da game jam Ludum Dare. Desta vez, o tema escolhido pelos participantes foi Collector.

Conceito do jogo
#

Assim que o tema foi revelado, começou a contagem regressiva de 48 horas. Collector foi o tema mais votado de uma lista que os participantes geram e votam durante a semana anterior à game jam. Como essa lista é divulgada antes, costumo me preparar pensando no que poderia fazer com base nas 16 possibilidades.

Minha ideia original era criar um jogo roguelike em que o jogador coletaria cartas deixadas pelos inimigos e as usaria para melhorar seus poderes e habilidades. Antes de cada novo nível, o jogador escolheria algumas das cartas coletadas e usaria as habilidades dessas cartas para avançar e conquistar mais cartas ao final.

Como dá pra ver na imagem abaixo, rascunhei a ideia no papel, listando tudo o que veio à cabeça, sem pensar muito na viabilidade naquele momento. Esse processo ajuda bastante a tirar as ideias da cabeça e colocá-las no papel, deixando tudo mais claro e fácil de visualizar.

Do papel ao Unity
#

Assim que a ideia ficou um pouco mais concreta, comecei a desenvolver na minha game engine de escolha: Unity. Uso o Unity desde 2009, quando a versão 3.0 foi lançada, então é sempre minha escolha segura.

Meu conselho pra quem quer participar de uma game jam, seja iniciante ou profissional, é: use uma engine que você já conheça e tenha alguma experiência. Fazer um jogo em tão pouco tempo, com um tema que você só descobre na hora, já é difícil o bastante — então é importante eliminar qualquer complicação desnecessária do processo.

Costumo preferir fazer jogos 2D nas game jams, porque é mais fácil pra eu desenhar algo simples e colocar no jogo (até porque não tenho nenhuma habilidade artística). Porém, dessa vez decidi fazer um jogo 3D. Sabendo das minhas limitações, optei por usar apenas objetos geométricos básicos do Unity e criar materials diferentes pra mudar as cores. Também adicionei alguns spotlights nos objetos pra dar mais destaque.

Comecei criando uma cena de testes — algo que sempre faço pra experimentar ideias. Na imagem abaixo dá pra ver a cena: basicamente um plane servindo de chão e quatro cubos esticados formando as paredes. O jogador é um cilindro amarelo e os inimigos são cubos vermelhos e azuis — tudo bem simples, pra eu conseguir focar na jogabilidade.

Conforme comecei a programar, também fui ajustando a ideia e reduzindo bastante o escopo, pra garantir que conseguiria terminar algo dentro do prazo.

A jogabilidade mudou pra algo mais simples: inimigos surgem na cena e perseguem o jogador. Quando colidem, ambos causam dano ao longo do tempo até que um deles morra ou o jogador se afaste.

Mantive o conceito de coletar cartas, mas na nova versão do jogo os inimigos deixam cair cartas das suas respectivas cores (que chamei de cartas de Fogo e Gelo). Quando o jogador coleta uma carta, sua vida é restaurada para 5 pontos.

Esse é o core loop do jogo: o jogador precisa atacar os inimigos, mas também fugir quando mais de um começa a persegui-lo. Os inimigos vermelhos e azuis têm valores diferentes de ataque, vida e velocidade — assim como o jogador.

A imagem acima mostra a versão final que fiz upload no site do Ludum Dare dentro das 48 horas. Não tive muito tempo pra balancear o jogo, então as partidas acabaram ficando mais curtas do que eu esperava se acumular muitos inimigos na tela.

Apesar de o resultado final ser bem mais simples do que o conceito inicial, consegui desenvolver um jogo durante o fim de semana. Por causa dos inimigos e cartas vermelhas e azuis, o nome que escolhi foi Fire & Ice.

Lições de uma game jam
#

Depois de mais uma game jam, acho que meus conselhos e aprendizados continuam praticamente os mesmos das participações anteriores. Aqui vão algumas coisas que fiz e que funcionaram bem:

Pense em ideias de jogos com base na lista de possíveis temas antes da game jam começar.
Use uma game engine que você já conheça e tenha experiência.
Faça rascunhos da sua ideia pra ter uma visão mais clara do que vai criar.
É normal mudar o conceito do jogo depois que começar, mas tente fechar o core loop o quanto antes pra poder melhorar o jogo a partir daí.
Exporte o jogo para web (se possível), assim outras pessoas conseguem jogar sem precisar fazer download.

E aqui vão as coisas que fiz errado e quero evitar da próxima vez:

Ter que criar tudo do zero em 48 horas já é difícil o bastante, então fazer um jogo 3D não ajuda. Na próxima, vou ficar no 2D — é mais fácil deixar visualmente agradável e com menos problemas de colisão.
Falando em colisão, tive vários problemas que só percebi depois de enviar o jogo. Usando 2D, boa parte disso nem teria acontecido.

Como sempre, participar da game jam foi uma ótima experiência. Sou um grande fã do Ludum Dare e fico feliz de ter algo completo o suficiente pra compartilhar. Ainda estou aprendendo a fazer melhor a cada edição, e tenho certeza de que na próxima vai sair ainda melhor.

Você pode jogar Fire & Ice aqui. O código-fonte está disponível no meu GitHub (um dos requisitos do modo Compo).

Se você perdeu esta edição do Ludum Dare, recomendo ficar de olho na próxima, que vai acontecer em abril de 2026.

Esta semana começa o Ludum Dare #58

Wed, 01 Oct 2025 00:00:00 +0000

Nesta sexta começa a edição de número 58 da game jam Ludum Dare, o melhor game jam! Uma ótima oportunidade para criar um jogo para o seu portfólio, colocar em prática algo que está aprendendo, ou apenas se divertir fazendo um jogo durante o fim de semana.

Conseguir um primeiro emprego na indústria de jogos não requer apenas conhecimento - ter um portfólio para demonstrar suas habilidades ajuda bastante. Game jams são uma ótima maneira de conseguir fazer um jogo em um tempo e tema pré-determinados, o que também ajuda a focar e não perder muito tempo pensando no que fazer.

Existem muitas game jams online e presenciais, mas para mim a Ludum Dare é a melhor para quem está começando a fazer jogos, ou mesmo se está querendo participar de algo mais casual do conforto de casa, sozinho ou em grupo.

O tema da Ludum Dare é anunciado antes do seu início na sexta-feira, e é o resultado de uma votação aberta que acontece durante a semana que antecede o evento.

Você pode participar de dois formatos, e cada um tem suas características e audiência:

Compo: 24 horas para fazer um jogo do zero e sozinho - você não pode usar nada que já esteja pronto. Este é o modo mais hardcore que vai forçar a sua criatividade, e as pessoas não vão julgar sua arte se o gameplay for bem feito e divertido.
Jam: 72 horas para fazer um jogo sozinho ou em grupo, e você pode usar qualquer coisa que já esteja pronta para ajudar a criar o jogo. Este é um formato mais tranquilo, onde você tem menos pressão e mais ajuda para terminar seu jogo. É tão de boas que também permite submeter um jogo fora do tema, desde que você tenha feito ele durante o Ludum Dare.

Se esta é a primeira vez que você está participando de uma game jam, eu recomendo o formato Jam que é mais tranquilo, mesmo se você já tem alguma experiência desenvolvendo jogos. Mas, se você estiver confiante, participe do Compo e faça o seu melhor.

A minha primeira participação foi no Ludum Dare #32, dez anos atrás, e desde então participei de mais de 10 edições no formato Compo. Consegui terminar o jogo em algumas, em outras falhei, mas isso tudo é parte do aprendizado que uma game jam pode te dar.

Aqui estão algumas dicas que podem te ajudar:

Quando começar a rodada de votação final na sexta-feira, você vai ter uma lista dos possíveis temas - tente pensar qual jogo consegue fazer dentro do tema no final de semana.
Utilize uma game engine ou framework que você já conhece e se sente confortável em utilizar para poder focar em fazer o jogo.
Se você quiser participar do modo ultra hardcore (inventei isso), utilize uma game engine ou framework que você nunca utilizou antes - isso aumenta o desafio e também é uma oportunidade de experimentar algo novo.
Pegue leve e descanse - planeje o seu final de semana, quantas horas vai focar no seu jogo, e lembre-se de que você precisa sobreviver para enviar seu jogo no final.
Coloque uma roupa confortável e sua melhor playlist, tente focar especialmente no primeiro dia para conseguir um bom progresso.
Divirta-se! Lembre-se de que isso faz parte de um game jam.

Eu pretendo participar do formato Compo e espero que possa compartilhar meu jogo e minha experiência na próxima semana.

SDL3 com Visual Studio, git submodule, e GitHub Workflow

Sun, 13 Jul 2025 00:00:00 +0000

Após minha graduação em Ciência da Computação, iniciei uma pós-graduação em Produção e Programação de Jogos com o objetivo de mudar minha carreira e entrar na indústria de jogos. Isso foi em 2009, e uma das primeiras ferramentas de desenvolvimento de jogos que tive contato foi o SDL2, onde fiz o meu primeiro projeto de game com SDL e C++ em uma disciplina da pós-graduação. De lá pra cá utilizei o SDL em diversos projetos, principalmente game jams e para aprender a programar homebrew para Nintendo DS e PSP, e sempre foi um framework fácil de usar e bem completo para jogos 2D.

Criar um projeto novo utilizando Visual Studio e configurar o SDL2 era um pouco mais trabalhoso, e inclusive escrevi este tutorial pra mim mesmo por que eu sempre esquecia de algum passo. Alguns meses atrás, o SDL3 foi oficialmente lançado, e trouxe algumas mudanças para simplificar o desenvolvimento de jogos e sua configuração. Neste post vou mostrar como criar um projeto novo no Visual Studio, adicionar o SDL3 como uma dependência usando git submodule, configurar o projeto para compilar um Hello World, e como automatizar builds em cada commit utilizando GitHub Workflows.

SDL como dependência usando git submodule
#

A parte mais importante de todo este post é este primeiro passo, pois aqui vamos configurar o projeto como um repositório git e adicionar o SDL3 como um submodule. Existem diversos conteúdos muito bons sobre git, então não vou alongar muito com uma introdução, e vamos direto ao ponto. Caso não tenha git na sua máquina, você pode instalar aqui.

Primeiro, precisamos criar um repositório local. Os comandos abaixo são os mesmos em qualquer sistema operacional, mas como vamos utilizar o Visual Studio neste tutorial, pode assumir que estou utilizando Windows. Criei um novo diretório no seu computador com o nome HelloWorldSDL3. Após criar o diretório, abra o prompt de comandos do Windows (cmd ou power shell), nave até a nova pasta criada e, dentro dela, execute o comando abaixo:

git init

Este commando vai criar uma pasta invisível chamada .git. Caso algum erro aconteça, como comando não encontrado, certifique-se que o git foi instalado e está adicionado no path do Windows. Em seguida, vamos adicionar o repositório do SDL como um submodule usando os comandos abaixo:

git submodule add https://github.com/libsdl-org/SDL.git SDL

Este comando vai adicionar um arquivo .gitmodules com uma referência do SDL no repositório local, e baixar o projeto em uma pasta chamada SDL. Se tudo der certo, seu diretório deverá estar com esta estrutura abaixo:

HelloWorldSDL3/
├── .git/
├── SDL/
└── .gitmodules

Neste momento você pode criar um repositório no GitHub (necessário criar uma conta gratuita se não tiver). No meu exemplo abaixo, estou criando um repositório público com o nome hello-world-sdl, e não selecionei nenhuma opção para inicializar o repositório com algum arquivo.

Depois de criar o repositório, volte para o prompt de comandos e digite os seguintes comandos (substitua USERNAME pelo seu usuário no github):

git add .
git commit -m "SDL submodule"
git branch -M main
git remote add origin https://github.com/USERNAME/hello-world-sdl.git
git push -u origin main

E, após executar os comandos acima com sucesso, o seu repositório estará parecido com o meu na imagem abaixo:

Isso é tudo que precisamos por agora, mas vamos voltar ao github no final deste post para configurar a automação de compilação no GitHub Workflow.

Criação de um projeto no Visual Studio
#

O SDL3 tem uma documentação bem simples e fácil de seguir. A configuração do projeto no Visual Studio pode ser vista aqui, porém vou adicionar os passos em português abaixo com algumas modificações que fiz.

A principal diferença é que, ao invés de fazer o download do código fonte, nós vamos usar o submodule que configuramos no passo anterior em nosso repositório git.

Novo projeto no Visual Studio
#

O Visual Studio 2022 (ou mais novo) pode ser baixado aqui, e a versão Community é gratuita para desenvolvedores solo, uso acadêmico, ou projetos open source. Siga os passos do instalador e lembre de marcar as opções para adicionar Desktop Development with C++ (você também pode marcar as opções de Unity e game development mas não são necessárias para o SDL).

Depois de instalado, selecione a opção Create a new project e procure por Empty Project com C++, como na imagem abaixo. Se você não estiver vendo essa opção, volte no instalador e veja se as opções de suporte ao C++ foram instaladas no Visual Studio.

Após selecionar Empty Project com C++, na próxima janela digite HelloGame em Project name, e no campo Location selecione o caminho em que está o repositório que criamos no início deste post. As configurações do novo projeto devem estar iguais a imagem abaixo.

Depois de criar o novo projeto no Visual Studio, esta é a estrutura do nosso repositório atualizada:

HelloWorldSDL3/
├── .git/
├── HelloGame/
├── SDL/
└── .gitmodules

Adicionando código
#

Agora que temos um projeto em branco, vamos adicionar um arquivo de C++ e configurar o projeto para utilizar o SDL que está no mesmo diretório. É importante adicionar um arquivo de código fonte em C++ antes de continuar por que isso vai habilitar as opções que vamos configurar mais pra frente.

Clique com o botão direito no projeto HelloGame e, em seguida, selecione a opção Add | New Item... e digite main.cpp. No novo arquivo criado, copie e cole o código abaixo. Não se preocupe com os erros de compilação agora, nós ainda vamos configurar o projeto para localizar o SDL e poder compilar com sucesso.

#define SDL_MAIN_USE_CALLBACKS 1
#include <SDL3/SDL.h>
#include <SDL3/SDL_main.h>

static SDL_Window* window = NULL;
static SDL_Renderer* renderer = NULL;

SDL_AppResult SDL_AppInit(void** appstate, int argc, char* argv[])
{
 if (!SDL_CreateWindowAndRenderer("Hello World", 800, 600, SDL_WINDOW_MAXIMIZED, &window, &renderer)) {
 SDL_Log("Couldn't create window and renderer: %s", SDL_GetError());
 return SDL_APP_FAILURE;
 }
 return SDL_APP_CONTINUE;
}

SDL_AppResult SDL_AppEvent(void* appstate, SDL_Event* event)
{
 if (event->type == SDL_EVENT_KEY_DOWN ||
 event->type == SDL_EVENT_QUIT) {
 return SDL_APP_SUCCESS;
 }
 return SDL_APP_CONTINUE;
}

SDL_AppResult SDL_AppIterate(void* appstate)
{
 const char* message = "Hello World!";
 int w = 0, h = 0;
 float x, y;
 const float scale = 4.0f;

 SDL_GetRenderOutputSize(renderer, &w, &h);
 SDL_SetRenderScale(renderer, scale, scale);
 x = ((w / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE * SDL_strlen(message)) / 2;
 y = ((h / scale) - SDL_DEBUG_TEXT_FONT_CHARACTER_SIZE) / 2;

 SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
 SDL_RenderClear(renderer);
 SDL_SetRenderDrawColor(renderer, 255, 255, 255, 255);
 SDL_RenderDebugText(renderer, x, y, message);
 SDL_RenderPresent(renderer);

 return SDL_APP_CONTINUE;
}

void SDL_AppQuit(void* appstate, SDL_AppResult result)
{
}

O código acima é uma variação do hello.c disponibilizado no repositório do SDL. As mudanças que fiz foram mudar a extensão para .cpp, remover os comentários para não ficar tão longo aqui, e configurar a janela usando SDL_WINDOW_MAXIMIZED (modo janela) ao invés do original que criava a janela em modo tela cheia.

Adicionando SDL como dependência
#

Agora vamos adicionar o SDL no Visual Studio junto com o nosso projeto. Para isso, clique com o botão direito na Solution 'HelloGame', selecione Add | Existing Project e, na nova janela navegue até SDL/VisualC/SDL (dentro do nosso repositório), e selecione o arquivo SDL.vcxproj. Depois de adicionar o projeto SDL junto ao nosso projeto HelloGame, você deve ter a estrutura abaixo no Visual Studio:

O próximo passo agora é adicionar o SDL como uma referência no projeto HelloGame. Cliquei com o botão direito no projeto HelloGame, selecione Add | Reference... e, na nova janela, selecione o projeto SDL e clique em OK. Isso vai garantir que o nosso projeto use o SDL como uma dependência para compilar o código.

Por fim, vamos adicionar os headers do SDL na configuração do nosso projeto. Para isso, clique com o botão direto no projeto HelloGame e selecione a opção Properties. Na nova janela, mude o filtro acima para All Configurations e All Platforms (se já não estiver assim). Em seguida, expanda a opção C/C++ no menu da esquerda, selecione General, e no primeiro campo Additional Include Directories, selecione Edit e adicione o caminho SDL/includes (dentro do nosso repositório).

A imagem baixo mostra como a configuração deste janela deve estar depois dos passos acima:

Rodando o projeto
#

Se tudo deu certo, agora basta rodar o projeto no Visual Studio utilizando o botão play verde ou pressionando F5, e você deverá ver a tela abaixo:

Caso encontre algum erro, dê uma revisada nos passos anteriores e compare as imagens que adicionei no post para ajudar. Se mesmo assim tiver dúvidas ou problemas, deixe um comentário que tentarei ajudar assim que possível.

Nós temos um repositório configurado no GitHub com o SDL adicionado como uma dependência e também o nosso projeto configurado para rodar no Visual Studio. O próximo passo agora é um extra, mas que com certeza vai ajudar o desenvolvimento ao médio e longo prazo.

Automação com GitHub Workflow
#

Automação é algo muito comum e essencial em empresas, não só em jogos. A automação pode ser desde rodar alguns testes unitários, compilar o projeto, e até rodar o jogo em um teste pré-definido. Para isso, muitas vezes precisamos de outras máquinas ou até servidores dedicados a rodar nosso projeto sempre que precisar de um teste, ou até mesmo a cada alteração.

É ai que entra o GitHub Workflow, onde podemos automatizar muita coisa no nosso repositório utilizando servidores Windows, Linux e macOS do GitHub. Existem alguns limites, mas mesmo uma conta gratuita tem o suficiente para bastante coisa em projetos pequenos e até médios. Você também pode registrar uma máquina sua como servidor e não se preocupar com limites (já fiz isso com um raspberry pi e funcionou bem para projetos pequenos!).

Não vou entrar em muitos detalhes sobre o GitHub Workflow em si, por que é algo muito grande e complexo de explicar tudo, mas recomendo dar uma olhada na documentação e pesquisar sobre também.

Para adicionar suporte a automação em nosso projeto, precisamos apenas adicionar um arquivo no repositório. No repositório, cria uma nova pasta .github e outra pasta dentro dela chamada workflows. Dentro da pasta workflows, adicione um novo arquivo chamado msbuild.yml. Seu repositório deve estar assim:

HelloWorldSDL3/
├── .git/
├── .github/workflows/msbuild.yml
├── HelloGame/
├── SDL/
└── .gitmodules

Por fim, abra o arquivo msbuild.yml em qualquer editor e copie e cole o conteúdo abaixo:

name: MSBuild

on:
 push:
 branches: [ "main" ]
 pull_request:
 branches: [ "main" ]

env:
 SOLUTION_FILE_PATH: ./HelloGame
 BUILD_CONFIGURATION: Release

permissions:
 contents: read

jobs:
 build:
 runs-on: windows-latest

 steps:
 - uses: actions/checkout@v4
 with:
 submodules: recursive

 - name: Add MSBuild to PATH
 uses: microsoft/setup-msbuild@v1.0.2

 - name: Restore NuGet packages
 working-directory: ${{env.GITHUB_WORKSPACE}}
 run: nuget restore ${{env.SOLUTION_FILE_PATH}}

 - name: Build
 working-directory: ${{env.GITHUB_WORKSPACE}}
 run: msbuild /m /p:Configuration=${{env.BUILD_CONFIGURATION}} ${{env.SOLUTION_FILE_PATH}}

 - name: Upload a Build Artifact
 uses: actions/upload-artifact@v4.6.2
 with:
 name: hellogame-x64-release
 path: ./HelloGame/x64/Release/

O arquivo acima parece um pouco confuso, mas se você ler cada linha vai começar a fazer sentido:

Este workflow roda quando commits forem adicionados no branch main ou quando tiver um pull request para ele.
O nosso env está configurado com o caminho do projeto HelloGame e a build Release.
O job vai rodar em máquinas windows.
Estamos utilizando msbuild para compilar o projeto pela linha de comando (já que é um servidor sem interface).
Depois de compilar, a build do jogo vai ficar arquivada como um artefato deste workflow.

Assim que adicionarmos esse arquivo no repositório e fizermos um commit para o branch main, este workflow vai rodar em gerar uma build que podemos baixar e testar, e vai estar no menu Actions do repositório no GitHub.

Além disso, é possível ver todo o processo de compilação e os logs do servidor. Caso algum erro aconteça, é lá que você vai entender o por que.

Conclusão
#

Este post demorou um pouco mais do que planejei para escrever, e ficou mais longo do que imaginei, mas acho que no fim é uma boa introdução de como criar um projeto novo usando SDL3, configurar o Visual Studio, e ainda como usar git submodule e GitHub Workflows para automação.

Tudo que fiz neste post pode ser visto no meu repositório público hello-worlds-sdl3. Fique a vontade para usar este repositório como um template ou base para o seu projeto, este é um dos motivos que fiz para mim mesmo.

Muito obrigado se você leu até o final, e espero que tenha sido útil. Qualquer dúvida, problemas no passo-a-passo, ou sugestões deixe um comentário abaixo.

Adeus Jekyll, olá Docusaurus

Sun, 04 May 2025 00:00:00 +0000

Mês passado foi o aniversário de 16 anos deste blog que, desde 2009, já passou por diferentes tecnologias e servidores para publicar o conteúdo. Chegou a hora de mais uma mudança, e desta vez escolhi migrar o blog do Jekyll para o Docusaurus.

Evolução do blog
#

Em 2009 eu comecei o meu blog utilizando o bom e velho Wordpress, que ainda é uma das maneiras mais rápidas e fáceis de se criar um blog que pode ser totalmente customizado. Depois de um tempo utilizando Wordpress, eu decidi levar o blog para um próximo nível que me daria mais flexibilidade, e decidi ter o meu próprio servidor para hospedar o blog.

Passei por diversos servidores de hospedagem, sempre procurando um melhor custo benefício já que pagava um valor mensal para manter o blog no ar. Em 2016, comecei a procurar por alternativas para reduzir meu custo e aumentar a performance do blog, já que um dos gargalos era a constante conexão do PHP com o bando de dados MySQL usado pelo Wordpress. Foi então que eu fiz uma primeira migração de framework do blog, dando adeus ao Wordpress, e olá ao Ghost.

O Ghost é um pouco parecido com Wordpress - você pode ter um blog hospedado por eles ou sua própria hospedagem. Porém, uma vantagem, que também foi uma gambiarra, era que eu podia rodar o servidor local, e "compilar" o site em páginas estáticas, e ai então publicar essas páginas no GitHub Pages. Consegui eliminar o meu custo mensal e ainda fazer o site ficar incrivelmente rápido já que conteúdo estático não precisa de conexão com banco de dados.

Depois que me acostumei com o blog em formato estático, comecei a ficar incomodado em ter que rodar um servidor local toda vez que ia publicar algo no blog. A interface do Ghost era bem legal, porém não uma necessidade. Foi então que, em 2017, dei adeus ao Ghost, e olá ao Jekyll. Diferente to Ghost (e do Wordpress), o Jekyll não tem uma interface por padrão, apenas arquivos em um repositório que são "compilado" para gerar um site estático. Isso reduziu a necessidade de rodar um servidor local, pois para publicar posts eu não precisava disso - apenas escrever e fazer um commit no git, e então o site era atualizado já que o GitHub pages consegue fazer essa "compilação".

Minha última mudança foi em 2018, quando decidi dar adeus ao GitHub Pages, e olá ao Netlify. Na época o GitHub Pages era um pouco limitado, e além disso era possível ter apenas um site estático por conta no GitHub, e eu queria publicar um novo site para o meu portfólio, também utilizando Jekyll. Foi então que migrei de plataforma, indo para o Netlify, que além de ter muito mais do que preciso, também é gratuito e suporta diversos sites ao mesmo tempo.

Foram 8 anos utilizando Jekyll no blog, e aos poucos comecei a encontrar alguns problemas que me fizeram pensar em outras opções, inclusive voltar para o Ghost, porém encontrei a solução perfeita pra mim: Docusaurus.

Mudança para Docusaurus
#

Jekyll é um framework incrível para criar sites estáticos, desde um simples blog ou documentação de um sistema, até sites completos com E-commerce. Existem muitos layouts (themes) gratuitos e pagos, a flexibilidade nele é imensa. Porém, é um framework um pouco velho que já está mostrando sinais de que precisa se modernizar. Um dos maiores problemas que eu tinha era depender de versões específicas de Ruby para compilar o blog, e sempre tinha problemas de incompatibilidade entre as dependências em diferentes computadores. Além disso, a maioria das dependências não eram atualizadas e eu ficava cada vez mais preso em coisas antigas.

Eu descobri o Jekyll no trabalho, pois era como a documentação era feita na época, e a mesma coisa aconteceu quando descobri o Docusaurus. Muitos dos meus problemas estão listados na comparação do Jekyll com Docusaurus, o que foi mais um incentivo para mudar. Docusaurus é uma plataforma open source desenvolvida pela Meta, e é feita com React, também mantido pela mesma empresa.

Por utilizar frameworks mais modernos, como React, o Docusaurus não possui problemas de dependências e tem uma melhor consistência entre diferentes sistemas operacionais. Configurar um site nele é bem rápido e fácil, e publicar ele no Netlify foi ainda mais fácil e rápido do que o Jekyll.

Porém, nem tudo é perfeito, e existem algumas limitações no Docusaurus que podem ser um problema. A customização nele é bem menos flexível do que o Jekyll, e não existe tantos layouts disponíveis para ele. Além disso, o foco do Docusaurus é documentação, e o blog é um sistema secundário nele e bem limitado. A customização nele é mais fechada, e requer o uso de swizzling, onde você pode expandir ou "ejetar" um componente dele para customizar. Nem todo componente é customizável, e os que são possuem um alerta dizendo que podem deixar de funcionar em atualizações futuras.

Eu tive que desativar a parte de documentação, fazer algumas mudanças no blog e customizar alguns componentes, e apesar das limitações estou bem feliz com o resultador. Vai demorar um pouco para me acostumar com o Docusaurus, mas por enquanto ele está cumprindo todos meus requisitos para um blog:

Simples, rápido e fácil de usar
Boa performance, moderno e fácil de manter
Me permite focar em escrever
Sem custo adicional

Apesar da limitação em customização e layouts disponíveis (comparando com o Jekyll), acho que o Docusaurus é o que eu estava procurando para este momento do blog. Provavelmente irei atrás de um layout melhor no futuro, mas por enquanto este layout básico e comum já está muito bom.

Novas funcionalidades
#

Uma das coisas que sempre tentei adicionar no blog, e sempre sem sucesso, foi uma ferramenta de busca. É uma limitação para sites estáticos, e é necessário algo externo para poder funcionar. Felizmente, o Docusaurus tem suporte nativo para uma ferramenta de busca chamada Algolia, e como você pode ver ali no canto superior direito, funciona muito bem. Tive que ajustar algumas configurações e aprender como funcionar a indexação, mas valeu o trabalho e fiquei feliz com o resultado.

Um pouco menos importante, mas também uma novidade, é poder mudar o tema do blog entre dark e light (botão à esquerda da busca ali no topo). Isso também era algo que queria adicionar ao blog, mas ficava preso os layouts do Jekyll que não tinham esse suporte porém eram gratuitos.

Outra mudança significativa pra mim foi abandonar o Google Analytics em favor do Cloudflare Analytics, que é bem mais leve e menos intrusivo, com foco em privacidade ao invés de capturar dados para publicidade. Eu utilizava o Google Analytics desde ~2010, quando movi meu blog do Wordpress para um servidor próprio, e por mais que tenho anos de dados lá, não vai fazer falta. Costumo utilizar esse tipo de ferramenta para ver quais posts são mais acessados e como leitores chegam no blog.

O Docusaurus também tem uma ferramenta que valida links quebrados e impede a publicação do site (esse comportamento é configurável). Isso ajuda demais a não deixar passar links que não funcionam, mas também foi um dos maiores trabalhos que tive quando migrei - corrigir todos links quebrados ao longo dos últimos 16 anos.

Por fim, por ser moderno e utilizar React, isso também me possibilita estudar algo novo, como o irmão React Native, muito utilizado para aplicativos.

Conclusão
#

Já estava na hora de uma atualização na tecnologia por trás do blog, e apesar do Docusaurus parecer menos flexível do que o Jekyll, ele é mais moderno e fácil de manter. Agora é arrumar detalhes que possam estar quebrados e focar em publicar mais conteúdo por aqui, e também migrar meu portfólio para Docusaurus.

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 criar atalhos com git alias

Wed, 17 Aug 2022 00:00:00 +0000

O comando git alias é um recurso muito poderoso do git que permite customizar comandos e ganhar tempo combinando uma sequencia de operações. Desde que aprendi a usar o git alias há alguns anos não consigo trabalhar sem algumas combinações de comandos que uso diáriamente.

Todos alias criados ficam na configuração local do git na sua máquina. Para criar um alias, basta usar o comando abaixo substituindo o NAME pelo nome do seu alias (sem espaços ou acentos) e substituindo o COMMAND pelo comando que quer executar.

$ git config --global alias.NAME COMMAND

No exemplo abaixo estamos criando um alias com nome s para o comando status. Então, ao invés de usar git status podemos usar git s para o mesmo comando, como um atalho.

$ git config --global alias.s status

Caso você não queira mais o alias criado, basta utilisar o comando abaixo com o nome criado para que ele seja removido das configurações:

$ git config --global --unset alias.s

Agora que já sabemos criar um alias vamos ver o poder real dele: a combinação de comandos. Para poder combinar os comandos precisamos:

Iniciar a sequencia de comandos com exclamação !
Separar os comandos por e comercial duplo &&
Por fim, todos os comandos deve ficar dentre de aspas simples

No exemplo abaixo estamos criar um alias com o nome s que irá executar, em sequencia, os comandos git status e git pull.

$ git config --global alias.s '!git status && git pull'

Incrível, não? Confesso que uso e abuso deste recurso, e isso me ajuda demais no dia-a-dia. Abaixo vou deixar meus alias preferidos: o git pizza que limpa e atualiza o repositório; e o git nuke que faz a mesma coisa porém descarta tudo que está no gitignore, como se o repositório tivesse sido clonado sem nada além do que está no remote.

$ git config --global alias.pizza '!git clean -fd && git reset --hard && git fetch -fp && git pull'
$ git config --global alias.nuke '!git clean -fdx && git reset --hard && git fetch -fp && git pull'

Um dos motivos de escrever este post foi ter estes comandos fáceis de achar quando eu precisar, além de compartilhar algo que acho bem interessante e produtivo no uso do git. Se você tem alguma dica legal para usar o git deixe aqui nos comentários.

O Futuro do Game Design: Palestra de Mark Venturelli

Mon, 08 Aug 2022 00:00:00 +0000

O game designer e fundador da Rogue Snail, Mark Venturelli, apresentou uma brilhante palestra no Big Festival 2022 sobre sua visão para o futuro do game design e da indústria de games.

Apesar da qualidade baixa, é possível assistir a palestra na íntegra no vídeo abaixo. Esta é a primeira vez que não quero comentar o conteúdo da palestra para não dar spoilers, pois recomendo assistir para entender onde Mark leva o espectador com sua apresentação. Posso adiantar que concordo com ele.

O vídeo acima foi publicado no canal do Mark, e ele também disponibilizou os slides da apresentação neste link.

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.

Unreal Engine 5 está disponível em Early Access

Mon, 31 May 2021 00:00:00 +0000

Quase um ano após seu anúncio a Unreal Engine 5 já está disponível para testes através do programa de Early Access da Epic Games. Na prática isso quer dizer que desenvolvedores podem começar a utilizar a nova versão da engine para estudar e desenvolver protótipos, porém ela não está pronta para ser utilizada em um jogo comercial no momento.

Para ter acesso ao Early Access da UE5 basta relizar o download ou atualizar o launcher da Epic Games, ir na sessão Unreal Engine do menu esquerdo e selecionar UE5 no menu superior. O download tem cerca de 10GB e a após a instalação o espaço ocupado é de aproximadamente 31GB (praticamente o mesmo espaço ocupado pela UE4).

Assim como na versão anteriore da engine, o seu código-fonta também está disponível no GitHub. A Epic Games também disponibilizou dois cursos em sua plataforma online para quem quiser começar a estudar a UE5. UE5 Early Access Quickstart é um curso de 2 horas que serve como uma introdução a nova versão da engine, enquando que o curso Upgrading to UE5 Early Acess possui apenas 20 minutos e tem como objetivo mostrar como importar um projeto feito na UE4.

O vídeo abaixo é uma pequena introdução do que está presente na Unreal Engine 5 Early Access.

Download de modelos 3D para jogos

Fri, 09 Apr 2021 00:00:00 +0000

Há um tempo atrás escrevi este post sobre sites para baixar sprites e modelos de jogos. Por mais que seja legal utilizar artes dos nossos jogos favoritos, existem leis de copyright que não permitem que um jogo seja feito e comercializado com propriedade intelectual de outras empresas.

Pensando nisso montei a lista de links abaixo, que são de sites onde artistas e animadores disponibilizam seu trabalho. Existe muito conteúdo gratuito mas lembre de sempre creditar o autor em seu jogo. Mesmo que não seja necessário para alguns casos, é um tipo de reconhecimento e divulgação muito bem vinda para alguem que dedicou horas (e até dias) criando uma arte ou animação, e depois disponibilizando gratuitamente.

Existem artes e animações que são pagas, muitas com preço bem acessível. Se você está fazendo um prótipo ou apenas testando algo, o conteúdo gratuito deve ser o suficiente para te ajudar em seu projeto. Porém, se você está desenvolvendo um jogo para ser lançado, recomendo dar uma olhada nas artes pagas pois existem muitas tão incríveis que vão deixar seu jogo ainda mais profissional, além de ajudar um artista talentoso.

Sketchfab
#

Conteúdo: Modelos 3D e animações (pagos e gratuitos). Possui plugins para Unity, Unreal e Godot.

Site: https://sketchfab.com

Turbo Squid
#

Conteúdo: Modelos 3D e animações (pagos e gratuitos).

Site: https://turbosquid.com

Unity Asset Store
#

Conteúdo: Modelos 3D e animações (pagos e gratuitos).

Site: https://assetstore.unity.com

Unreal Marketplace
#

Conteúdo: Modelos 3D e animações (pagos e gratuitos).

Site: https://unrealengine.com/marketplace

Kenny
#

Conteúdo: Modelos 3D (pagos e gratuitos).

Site: https://kenney.nl

Open Game Art
#

Conteúdo: Modelos 3D (gratuitos).

Site: https://opengameart.org

Conhece algum que não está a lista? Deixe um comentário abaixo pra eu poder incluir na lista.

Modelo 3D da capa: The Lighthouse.

Hello World usando SDL no Visual Studio

Sun, 21 Mar 2021 00:00:00 +0000

A SDL é uma biblioteca para desenvolvimento de jogos cross-platform com código aberto que existe desde 1998. Diversos jogos foram publicados utilizando SDL, como por exemplo, Half-Life 2, Left 4 Dead 2, Dying Light, Factorio, FTL, entre muitos outros. Sua linguagem de programação principal é C e C++, porém existem alguns bindings que permitem programar em outras linguagens como C#, Go, Lua, Rust e Python. Por ser "apenas" uma biblioteca, não possui uma interface gráfica como a Unity ou Unreal. Neste post vou demonstrar o passo a passo para criar um projeto utilizando o Visual Studio no Windows.

Para começar faça o download do runtime binaries da sua plataforma. Se você está utilizando Windows 10, pode fazer download da versão 64-bit Windows. Também é possível utilizar o código fonte, mas o runtime binaries é o suficiente para iniciar um projeto. Para referência, a versão da SDL utilizada é 2.0.14.

Configuração no Visual Studio
#

Estou utilizando o Visual Studio 2019 Community Edition que pode ser baixado aqui. Apesar das imagens abaixo serem da versão 2019 a configuração é a mesma em outras versões do Visual Studio.

Após realizar o download da SDL faça a extração em algum local do seu computador sem espaços no nome dos diretórios. Eu gosto de colocar meus projetos em C:\Projects e qualquer biblioteca ou dependência (como os arquivos da SDL) em C:\Dev.

Vamos criar um projeto novo do tipo Console App. Este projeto vai ter apenas um arquivo cpp, onde vamos adicionar o código do Hello World. O nome deste arquivo não importa, mas gosto de renomeá-lo para main.cpp.

Com o projeto criado basta clicar com o botão direito no Project (dentro da Solution) e selecionar a última opção chamada Properties. A seguir iremos adicionar o caminho para as pastas include e lib\x64 em VC++ Directories, e as libs SDL2.lib e SDL2main.lib em Linker/Input, conforme as imagens abaixo. Lembre-se de selecionar All Platforms antes de iniciar a configuração.

Por fim, precisamos copiar o arquivo SDL2.dll que está em lib\x64 para dentro do projeto, junto com o nosso arquivo cpp. Esta é a última etapa para configurar o Visual Studio e compilar o projeto com a SDL.

Como realizamos toda a configuração utilizando a lib\x64 lembre de selecionar x64 na Visual Studio antes de compilar e executar o projeto.

Hello World
#

Um projeto com SDL segue uma sequência bem definida de métodos, os quais devem ser executados para que tudo funcione corretamente. O código abaixo é a base que iremos utilizar, contendo a importação do SDL, o tamanho da tela e da imagem que vamos exibir e o método principal da aplicação. Este código não faz nada, mas pode ser executado para testar se a SDL está configurada corretamente no projeto do Visual Studio.

#include <SDL.h>

#define WINDOW_WIDTH 640
#define WINDOW_HEIGHT 480

#define IMAGE_WIDTH 256
#define IMAGE_HEIGHT 256

int main(int argc, char* args[])
{
 return 0;
}

Os trechos de código a seguir estão dentro do método main(). Em primeiro lugamos vamos inicializar a SDL e verificar se foi inicializada com sucesso. Caso algum erro seja retornado, iremos exibir a mensagem de erro no console utilizando SDL_Log() e finalizar a aplicação. Mais detalhes do método de inicialização aqui.

if (SDL_Init(SDL_INIT_EVERYTHING) != 0)
{
 SDL_Log("SDL_Init Error: %s\n", SDL_GetError());
 return -1;
}

A seguir criaremos nossa Window onde o jogo será exibido. No código abaixo, a janela será criada no centro da tela com o tamanho definido anteriormente, e o título Hello World SDL2. Você pode ver aqui todos os parâmetro em detalhes.

SDL_Window* window = SDL_CreateWindow("Hello World SDL2", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, WINDOW_WIDTH, WINDOW_HEIGHT, SDL_WINDOW_SHOWN);
if (window == nullptr)
{
 SDL_Log("SDL_CreateWindow Error: %s\n", SDL_GetError());
 return -1;
}

O último item necessário para terminarmos a inicialização da SDL é o Renderer, responsável por "desenhar" na tela criada anteriormente. Os detalhes da criação do renderer podem ser vistos aqui.

SDL_Renderer* renderer = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED);
if (renderer == nullptr)
{
 SDL_Log("SDL_CreateRenderer Error: %s\n", SDL_GetError());
 return -1;
}

Com a SDL inicializada e a window e o renderer criados, podemos desenhar uma imagem na tela. O código abaixo carrega uma imagem no formato BMP e a exibe no centro da tela. Primeiro criamos uma surface para então criar a texture. Com a textura criada, podemos remover a surface da memória (a texture será removida só no final da aplicação). O SDL_Rect possui as coordenadas onde a imagem será desenhada e seu tamanho, considerando que o ponto de origem da imagem é no seu centro. Por fim, desenhamos a texture na tela utilizando o SDL_Render.

SDL_Surface* image = SDL_LoadBMP("image.bmp");
if (image == nullptr)
{
 SDL_Log("SDL_LoadBMP Error: %s\n", SDL_GetError());
 return -1;
}

SDL_Texture* texture = SDL_CreateTextureFromSurface(renderer, image);
if (texture == nullptr)
{
 SDL_Log("SDL_CreateTextureFromSurface Error: %s\n", SDL_GetError());
 return -1;
}

SDL_FreeSurface(image);

SDL_Rect rect;
rect.x = (int)(WINDOW_WIDTH * 0.5f - IMAGE_WIDTH * 0.5f);
rect.y = (int)(WINDOW_HEIGHT * 0.5f - IMAGE_HEIGHT * 0.5f);
rect.w = IMAGE_WIDTH;
rect.h = IMAGE_HEIGHT;

SDL_RenderClear(renderer);
SDL_RenderCopy(renderer, texture, nullptr, &rect);
SDL_RenderPresent(renderer);

Todo esse código acontece antes do main loop, ou seja, será executado apenas uma vez. A imagem do exemplo será desenhada apenas uma vez na tela e, como no loop abaixo não tem outra chamada para o SDL_Render, ela continuará desenhada até o fim. Este loop é usado apenas para ler o input do jogador e sair do loop se a janela for fechada.

while (true) {
 SDL_Event e;
 if (SDL_PollEvent(&e)) {
 if (e.type == SDL_QUIT) {
 break;
 }
 }
}

Quando o jogador fechar a tela e o jogo sair do loop vamos finalizar a SDL. Para isso tiramos tudo que foi alocado da memória, como texture, renderer e window. E por fim finalizamos a SDL.

SDL_DestroyTexture(texture);
SDL_DestroyRenderer(renderer);
SDL_DestroyWindow(window);
SDL_Quit();

Assim temos nosso Hello World com uma imagem desenhada na tela. A class completa pode ser vista neste gist. Se tiver alguma dúvida sobre os métodos e objetos da SDL acesse a documentação da biblioteca, a qual contem bastante informação e exemplos práticos.

Cuidados
#

Pelo tamanho do post é possível ver que desenhar uma simples imagem na tela exige uma boa quantidade de código. Enquanto na Unity, isso pode ser feito praticamente arrastando uma imagem para dentro da engine, com a SDL tudo é mais "manual". Isso pode dar mais trabalho, mas também da mais controle ao programador. Por isso, é preciso prestar atenção para não fazer algo errado sem perceber.

Quando estava criando este exemplo para o post, percebi que o simples fato de desenhar uma imagem na tela estava utilizando 97% da minha GPU (o que é um absurdo). Notei que meu erro foi executar os métodos SDL_RenderClear(), SDL_RenderCopy() e SDL_RenderPresent() a cada loop (é um exagero para uma imagem estática).

Movendo as chamadas destes métodos para fora do loop, a utilização da GPU caiu para 1%. Existem algumas técnicas para controlar melhor o main loop e o frame rate, assim como desenhar apenas quando a imagem mudar de posição, entre outras possibilidades. O que me pegou de surpresa foi a própria documentação ter este exemplo, de uma imagem estática sendo desenhada todo frame.

Conclusão
#

Trabalhar com a SDL é um pouco lento no início até ter a base do jogo pronta, depois disso é a programação do jogo em si. É mais complicado do que utilizar a Unity e C#, por exemplo, com uma curva de aprendizado bem maior. Porém, é bem recompensador e importante aprender a programar (e programar jogos) em um "nível mais baixo" do que em uma engine que já te dá tudo pronto e você não vê muito bem o que acontece por trás do seu script.

O código completo está disponível neste link. Caso queira se aprofundar, recomendo olhar a documentação oficial. Este site também possui bons exemplos de programação de jogos com SDL.

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.

Blog · Game Developer

Minha palestra na Unite 2025 em Barcelona

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 #

Minha participação no Ludum Dare #58

Conceito do jogo #

Do papel ao Unity #

Lições de uma game jam #

Esta semana começa o Ludum Dare #58

SDL3 com Visual Studio, git submodule, e GitHub Workflow

SDL como dependência usando git submodule #

Criação de um projeto no Visual Studio #

Novo projeto no Visual Studio #

Adicionando código #

Adicionando SDL como dependência #

Rodando o projeto #

Automação com GitHub Workflow #

Conclusão #

Adeus Jekyll, olá Docusaurus

Evolução do blog #

Mudança para Docusaurus #

Novas funcionalidades #

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 criar atalhos com git alias

O Futuro do Game Design: Palestra de Mark Venturelli

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

Unreal Engine 5 está disponível em Early Access

Download de modelos 3D para jogos

Sketchfab #

Turbo Squid #

Unity Asset Store #

Unreal Marketplace #

Kenny #

Open Game Art #

Hello World usando SDL no Visual Studio

Configuração no Visual Studio #

Hello World #

Cuidados #

Conclusão #

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 #

Keynote
#

Develop
#

Deploy
#

Grow
#

Unity x Epic
#

Roadmap
#

Conclusão
#

Conceito do jogo
#

Do papel ao Unity
#

Lições de uma game jam
#

SDL como dependência usando git submodule
#

Criação de um projeto no Visual Studio
#

Novo projeto no Visual Studio
#

Adicionando código
#

Adicionando SDL como dependência
#

Rodando o projeto
#

Automação com GitHub Workflow
#

Conclusão
#

Evolução do blog
#

Mudança para Docusaurus
#

Novas funcionalidades
#

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
#

Sketchfab
#

Turbo Squid
#

Unity Asset Store
#

Unreal Marketplace
#

Kenny
#

Open Game Art
#

Configuração no Visual Studio
#

Hello World
#

Cuidados
#

Conclusão
#

Estrutura
#

Arquivo de configuração
#

Android Manifest
#

Compilação com gradle
#

Código java
#

Implementação no C#
#

Conclusão
#