Guia prático para rodar o blinky na floresta
O projeto blinky na floresta é uma simulação interativa escrita em Python que reinventa um clássico arcades com cenários procedurais de floresta. Ele nasceu como exercício acadêmico e acabou sendo puxado para uso independente por quem quer treinar lógica de pathfinding sem depender de framework pesado. O repositório oficial tá no GitHub, link abaixo. Se você só quer rodar e testar, pule direto para a seção de instalação.
blinky na floresta — instalação rápida
A dependência principal é o PyGame 2.5 ou superior, porque a versão mais nova traz melhorias no loop de renderização que o projeto usa. No Ubuntu eu costumo usar o apt mesmo, mas no Debian às vezes entra uma versão desatualizada e o compilador do C++ trava na compilação dos efeitos de partícula. Aí o workaround foi simples: instale o python3-pygame via pip dentro de um venv, nunca pelo apt, e desative o modo acelerado pelo hardware setando SDL_VIDEODRIVER=virtualbox antes de executar. Parece bobeira, mas já vi gente passar meia hora sem entender por que a tela ficava preta em VMs com VirtualBox. Depois de instalar, o comando padrão é:
python3 main.py --mode forest --difficulty medium O arquivo de configuração padrão fica em config/default.yaml. Ele já vem com valores razoáveis, mas se você deixar o FPS fixo em 60 e o caminho de busca em A* com heurística Manhattan, o processo gasta cerca de 40% de CPU a mais do que o necessário em mapas grandes. Mudar para Chebyshev ou usar uma lista de prioridade com heap reduz pra algo em torno de 18% no meu teste com mapa 64x64.
Entendendo a estrutura do projeto
A árvore de pastas segue o padrão MVC básico, mas com uma camada extra chamada navmesh_generator.py que cria malhas de navegação a partir do mapa em pixels. Isso é importante porque o código não roda varredura pixel a pixel durante o jogo — o navmesh é gerado uma vez no carregamento e reutilizado a cada frame. O problema é que o gerador não lida bem com diagonais em terreno com altura variável, então se você carregar um mapa com elevação (o parâmetro --terrain=elevation), alguns paths ficam truncados e o personagem pode parecer travado em colinas. O workaround que eu uso é rodar um pós-processamento com simplificação de polígonos antes de salvar o navmesh. No próprio repositório tem um script chamado postprocess_navmesh.py que você executa após a geração inicial. Leva uns 3 segundos num i5 e resolve 95% dos casos de path truncado. O resto é caso de mapa malfeito mesmo, não bug do motor.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Como modificar o comportamento do Blinky
O arquivo AI/blinky_controller.py controla as decisões de perseguição. O código padrão usa uma combinação de target_prediction + pathfinding, mas tem uma armadilha comum: se você aumentar o lookahead_time para mais de 2 segundos, o Blinky começa a superestimar a posição futura do jogador em mapas com muitas curvas e acaba indo para canto morto. No meu teste com mapa procedural hard, colocar lookahead em 0.8 segundos e adicionar um fator de correção baseado na curvatura do segmento atual deixou o comportamento muito mais realista. Eu modifiquei assim: dentro do método predict_position(), adicionei um check de ângulo entre o vetor velocidade atual do jogador e o vetor direção do caminho. Se o ângulo for maior que 60 graus, reduz o lookahead pela metade. O resultado é um Blinky que persegue de forma agressiva em reta, mas ajusta o curso antes de curvas fechadas.
Limitações que o projeto tem
Não espere multiplayer ou suporte a rede. O código foi feito para single player mesmo, e a arquitetura de estados não prevejo serialização. Se você tentar hackear uma sessão multiplayer, vai gastar mais tempo do que vale a pena e provavelmente quebrar o pathfinding em algum momento. Para algo com multiplayer, o próprio autor recomenda o fork blinky-net que tá num repositório separado, mas esse não tem suporte ativo desde 2023. O outro ponto fraco é a renderização em telas com taxa de atualização variável, como G-Sync ou FreeSync. O game loop usa delta time fixo de 1/60s, então em monitores 120Hz a animação fica com aparência de travado. A solução temporária é forçar vsync pelo driver da placa de vídeo ou patchear o loop principal para aceitar refresh rate dinâmico. Eu fiz o patch num branch separado, mas não submeter ao repositório principal porque o autor disse que quer manter o comportamento original por questões de compatibilidade com gravações de speedrun.
Download e recursos
Repositório principal: https://github.com/exemplo/blinky-na-floresta Documentação técnica: docs/TECHNICAL.md (leia antes de abrir issues, tem FAQ sobre pathfinding e navmesh)
Fork com patch de refresh rate dinâmico: https://github.com/exemplo/blinky-na-floresta-dynamic-refresh O projeto é licenciado sob MIT, então você pode modificar e distribuir sem burocracia. Se tiver dúvida técnica, abre issue com o mapa e o log de erro em vez de mandar print de tela — o log gera informações muito mais úteis pra quem tá tentando ajudar.
