Por que todo mundo precisa de um playground de teste no Funkin'
Vocês sabem como é. Você acaba de fazer uma mod nova com dois personagens, duas músicas e agora quer testar se a chart não quebra quando o oponente fica acelerando nos trechos rápidos. Aí você tenta rodar normal e leva um crash porque o FPS cai pra metade só de ter dois sprites na tela. Eu já passei por isso centenas de vezes. O fnf test playground remake é basicamente isso: uma versão limpa do jogo que remove tudo que não é necessário pro teste e te deixa brincar com as funções de debugging sem depender de build completa. Tem tela cheia de atalhos que o jogo original não expõe, como pular directly pros frames de animação, travar o BPM, e ativar um modo onde cada nota quebra de forma independente pro profiling.
fnf test playground remake — onde baixar e o que esperar
A versão mais usada no momento circula pelo fórum do Kevin Iglesias e também tá no GitHub do usuário thathanman. O repositório oficial deles tem build pré-compilada tanto pros binários Windows quanto Linux, e o README atualizado em março de 2025 já indica compatibilidade com a v0.3 do engine. Se você for compilar do source, precisa ter LÖVE 11.4 instalado antes, senão o linker reclama da lib math do Lua 5.4. O download em si é simples. Entra no repo, vai na aba Releases, baixa o zip do último tag. Descompacta na mesma pasta onde tá seu projeto de mod ou num diretório separado. O executável chama testplayground.exe no Windows e testplayground.x86_64 no Linux. Não tem instalador, roda direto.
Como configurar pra não perder tempo
A primeira coisa que eu sempre faço é copiar a pasta assets da sua mod pro diretório assets_test do playground. O engine original lê assets_test primeiro, então qualquer recurso duplicado ali sobrescreve o padrão. Isso resolve o problema clássico de textura duplicada quando você testa uma mod que renomeia arquivos de sprite sem avisar. Depois, abre o arquivo settings.json na raiz. Tem uma chave chamada debug_overlay que eu deixo sempre ligada. Mostra frame time, FPS real, count de draw calls, e uma barra que pisca vermelho quando o delta time passa de 33ms. Isso já te avisa cedo se algum sprite ou shader tá pesado demais antes de você ir pras métricas avançadas.
Outro detalhe que ninguém menciona: o playground tem um arquivo de configuração separado chamado testconfig.lua que carrega AFTER o main.lua da sua mod. Isso quer dizer que se sua mod redefine alguma função global, o testconfig pode sobrescrever isso se você não tomar cuidado. Achei isso sozinho depois de passar uma tarde inteira debugando um comportamento que sumia quando mudava a ordem dos includes.
Atalhos que salvam horas de trabalho
O mapa de teclas padrão do playground não é intuitivo de cara. Segue o que eu uso no dia a dia: F8 pausa e abre o painel de debugging. Dali você consegue navegar frame a frame tanto da animação do personagem quanto da chart. Útil quando quer saber exatamente em qual beat a animação do BF travou sem precisar rodar a música inteira de novo.
F9 abre o profiler de áudio. Mostra o buffer de latência atual e o desvio em milissegundos entre o sample que o jogo tá tocando e o sample que a entrada do microfone captou. Eu usei isso pra detectar que meu setup de gravação tava com 47ms de delay, algo que nunca aparecia no modo normal porque o jogo simplesmente ignorava o input nessa faixa. F10 reinicia o stage completo sem reload da engine. Importante quando você tá testando várias variações de um mesmo verso e não quer matar o processo pra recomeçar. Economiza uns 20 segundos a cada tentativa, o que numa sessão de testes longa vira tempo considerável.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Ctrl+Shift+F9 mostra o hitwindow visual. Uma linha horizontal aparece no screen mostrando o perfeito, bom, ruim e miss em tempo real. Essencial quando você tá ajustando a chart pro modo hard e precisa ver se as notas rápidas não estão ficando impossíveis por causa de um hitwindow mal configurado.
Um problema real que eu encontrei e como resolvi
No meu último projeto, eu tava testando uma mod com um personagem que tinha uma animação especial ativada só no meio da terceira música. O playground travava consistentemente nesse exato momento, mas o crash report era genérico — nada sobre qual resource ou function quebrou. Fiquei duas horas sem saber o que era. O problema era que o motor carregava todos os sprites de todos os personagens num único atlas, e a animação especial do personagem novo tinha um frame com dimensões diferentes dos demais. O atlas não comportava e o LÖVE simplesmente morria sem aviso.
A solução foi simples mas demorou pra achar: no painel de debugging, tem uma aba Resources onde dá pra ver o tamanho de cada sprite carregado. Localizei o frame suspeito com 64x96 quando todos os outros eram 64x64. Redimensionei pros 64x64 e o playground rodou sem problema. A lição prática aqui é que inconsistência de tamanho de sprite é uma das causas mais silenciosas de crash no Funkin' engine, e o playground te mostra isso visualmente se você souber onde olhar.
Limitações que ninguém conta
O playground não roda mods que fazem hook direto em classes nativas via DLL. Se sua mod usa uma biblioteca como hscript ou carrega extensões em C, o playground simplesmente ignora e segue em frente. Isso é útil pra muitos casos, mas irritante quando você precisa testar exatamente esse comportamento. Também não tem suporte nativo pra multiplayer local. Se você quer testar uma chart contra o modo versus com dois jogadores no mesmo teclado, precisa usar o jogo normal. O playground só roda single-player com AI bot. Pra isso mesmo, existe uma option no settings que ativa o bot com dificuldade configurável, mas é só isso.
O terceiro ponto importante: performance profiling no playground não é confiável pra builds Android. Os números que aparecem na tela são válidos pros seus dispositivos Windows/Linux locais, mas quando você exporta pro mobile, o comportamento muda bastante por causa do renderer OpenGL ES. Se o foco principal do seu projeto for mobile, considere usar o profiler nativo do LÖVE com o build exportado, não depender do playground.
Alternativa quando o playground não resolve
Se o que você precisa é testar chart em condições reais de hardware mobile, o melhor caminho é exportar a build pra Android via LÖVE diretamente e usar o ADB logcat pra ler os dumps de FPS e memória em tempo real. Não é tão confortável quanto o painel visual do playground, mas os números são mais precisos pro target final. pra quem quer só testar chart rápido sem se preocupar com performance, o playground continua sendo a ferramenta mais prática. Leva cerca de 3 minutos pra deixar tudo configurado e pronto pra testar, contra uns 20 minutos se você fosse configurar um build completo do engine com todas as dependências.
