Em uma tarde, coloquei Pokémon Red e Blue 3D para rodar nativamente no Nintendo Switch — usando SDD e agentes de IA

Há algum tempo eu queria contribuir com alguma coisa relacionada ao Nintendo Switch. Não precisava ser um projeto enorme nem uma tentativa de criar “o próximo grande homebrew”. Eu só queria pegar algo real, colocar a mão na massa e aprender como funciona o desenvolvimento para o console.

Foi então que apareceu o Gen1Recomp.

Como grande fã de Pokémon, não precisei pensar muito. O projeto tinha acabado de surgir, a comunidade já estava experimentando e havia uma issue pedindo suporte ao Nintendo Switch. Parecia a oportunidade perfeita para brincar, aprender e, com sorte, devolver alguma coisa útil para o projeto.

Algumas horas depois, eu estava andando por Pallet Town em um Switch OLED.

Antes de tudo: o que é o Gen1Recomp?

Apesar do nome, o Gen1Recomp não é simplesmente um emulador de Game Boy com uma interface diferente. Também não distribui Pokémon nem inclui uma ROM dentro do projeto.

Ele é uma recriação nativa de Pokémon Red, Blue e Yellow, feita em Lua sobre o framework LÖVE2D. A engine e o comportamento dos mapas foram reescritos, enquanto os dados e gráficos do jogo são extraídos de uma ROM original fornecida pelo próprio jogador.

O projeto verifica o arquivo antes da importação e aceita apenas versões canônicas de Red, Blue e Yellow. Depois disso, cria um cache privado com os dados necessários. A ROM não vai para o repositório, não fica empacotada no aplicativo e não faz parte dos artefatos de distribuição.

Na prática, o jogo roda como uma aplicação nativa, sem um emulador de Game Boy no meio. Isso também abre espaço para recursos que seriam bem mais difíceis de encaixar no jogo original, como suporte a mods, diferentes paletas, zoom e até visualizações em 3D por voxels.

A ideia: levar essa base para o Switch

A issue #531 já mostrava que o arquivo .love conseguia iniciar por meio do love-nx, uma implementação do LÖVE para Nintendo Switch. Mas iniciar era só o primeiro passo: os botões não funcionavam corretamente, não havia um fluxo adequado para localizar e importar as ROMs e ainda faltava transformar aquilo em uma experiência minimamente utilizável no console.

Meu objetivo inicial ficou bem simples:

• detectar o ambiente NX sem fingir que o Switch era Android;
• fazer os Joy-Con funcionarem tanto no launcher quanto dentro do jogo;
• criar uma forma segura de importar Red, Blue e Yellow no armazenamento gravável do LÖVE;
• manter ROMs, saves, caches e mods fora do artefato gerado;
• chegar a um único arquivo .nro, que é o formato comum de homebrew no Switch;
• e, principalmente, comprovar tudo em hardware real.

Eu não tinha experiência profunda com homebrew de Switch. Então, antes de sair alterando código, preferi organizar a ideia.

Primeiro veio a arquitetura

Usei o GPT-5.6 Sol para me ajudar a construir um ADR, um registro de decisão arquitetural. A ideia era transformar “quero rodar Pokémon no Switch” em decisões concretas: qual runtime usar, onde guardar os arquivos importados, como tratar os controles, como empacotar o jogo e quais limites precisavam estar claros desde o começo.

Como referência, estudei o porte de Dusklight para Nintendo Switch, principalmente o documento LESSONS_AND_REUSE.md.

O Dusklight usa uma stack nativa diferente, então não fazia sentido copiar sua implementação de vídeo, áudio e input. O love-nx já resolve essas camadas para o Gen1Recomp. O que eu reaproveitei foi o método:

• testar cedo em um Switch real;
• validar primeiro a camada mais básica com um pequeno probe;
• executar em title override, com acesso à memória completa, em vez de Applet Mode;
• registrar exatamente qual build estava rodando;
• manter diagnósticos limitados para não transformar logs em outro problema;
• isolar o código específico da plataforma;
• e guardar o ELF correspondente ao NRO testado, algo importante para investigar crashes depois.

O ADR serviu como uma espécie de mapa. Ele não escreveu o porte, mas evitou que o desenvolvimento virasse uma sequência de tentativas desconectadas.

Do ADR para uma spec executável

Com as decisões principais definidas, usei a skill tlc-spec-driven para conduzir o trabalho como SDD (Spec-Driven Development).

Passei o ADR para o Grok 4.5 High, que criou a especificação e dividiu o porte em requisitos, design, tarefas menores e critérios de verificação. Em vez de pedir ao agente apenas “faça funcionar no Switch”, ele passou a trabalhar sobre contratos bem mais objetivos.

Alguns exemplos eram: o artefato não pode conter ROM; o mapeamento de controles deve ser compartilhado entre launcher e gameplay; o Switch precisa ter um diretório de importação gravável; o build deve existir tanto em modo solto, bom para iteração, quanto em um NRO fundido; e uma etapa de verificação precisa rejeitar conteúdo privado antes do empacotamento.

Essa parte foi importante porque agentes são muito rápidos para produzir código, inclusive código errado. A spec manteve o contexto estável durante várias alterações e deixou mais claro quando uma tarefa estava realmente pronta para ser testada.

A implementação foi tranquila. Os testes, nem tanto

O desenvolvimento em si fluiu melhor do que eu esperava. A maior dificuldade não foi escrever Lua ou montar os scripts de build. Foi o ciclo extremamente manual de testar cada mudança no console.

Meu fluxo era basicamente este:

1. o agente implementava uma etapa e rodava os testes locais;
2. quando precisava de comprovação no hardware, ele parava;
3. eu gerava a nova build no macOS;
4. no Switch, abria o DBI e ativava Run MTP responder;
5. no Mac, usava o OpenMTP para copiar os arquivos para o cartão SD;
6. saía do DBI e iniciava o homebrew por title override;
7. executava o roteiro no Switch e voltava com o resultado;
8. só então o agente continuava.

Isso se repetiu praticamente até o fim.

Era demorado, mas também foi a parte mais valiosa do experimento. Um teste headless consegue dizer se o código reconhece NX, se o importador encontra um arquivo ou se um mapeamento produz a ação esperada. Ele não consegue me dizer se o botão que o jogador enxerga como A realmente confirma a opção no Joy-Con, se o jogo volta corretamente depois de suspender o console ou se o NRO fundido abre sozinho no hardware.

O que já funciona

O PR #574 ainda está como draft, mas a primeira trilha jogável já existe. Entre as coisas implementadas estão:

• detecção própria da plataforma Nintendo Switch;
• configuração em tela cheia a 1280 × 720;
• importação de ROMs por uma pasta imports/, com opção de procurar novamente;
• correções para Red e Blue em builds fundidas;
• mapeamento compartilhado de controles, incluindo a experiência A/B do padrão Nintendo;
• recuperação após perda de foco ou reconexão do controle;
• build solta, com gen1recomp.nro e game.love, para iteração rápida;
• build fundida em um único gen1recomp.nro;
• identificação da build que está rodando;
• verificação automática para impedir que ROMs, saves e caches entrem no pacote;
• importação de mods em .zip por uma pasta própria;
• atalhos com Select + botões frontais para opções de exibição;
• testes headless específicos para plataforma, importação, input, mods e empacotamento.

No meu Switch OLED, validei o probe inicial, a importação e execução de Red e Blue, entrada de nomes usando A/B, persistência do save depois de fechar e abrir, dez ciclos de suspensão, reinicialização do console, execução do NRO fundido sozinho e atualização trocando apenas o NRO.

Também consegui instalar o Dramatic Shape Voxel Mod e ver o mundo do jogo ganhar profundidade diretamente no Switch:

É uma sensação curiosa ver um jogo de 1996, que eu conheço desde criança, rodando dessa forma no hardware da Nintendo. Mesmo sabendo o que estava por trás, ainda houve aquele pequeno momento de “caramba, funcionou”.

O que ainda falta

Quero deixar essa parte bem clara: o porte não está finalizado.

Até agora, toda a validação foi feita no meu Nintendo Switch OLED. Isso não significa que o código seja exclusivo do OLED; significa apenas que foi o único hardware em que eu realmente testei. Switch V1, V2, Lite, modo dock e outros controles ainda precisam de cobertura.

O deploy continua totalmente manual. Não existe, por enquanto, um pacote oficial pronto para instalar, uma etapa de CI para Switch ou um fluxo de atualização automatizado. O objetivo final é distribuir um único .nro, parecido com outros homebrews, mas o PR atual ainda é uma implementação experimental para revisão.

Também faltam testes mais longos, uma matriz maior de controles e documentação de transferência para Linux e Windows. O macOS com OpenMTP e o DBI foi o meu fluxo de desenvolvimento, não uma dependência que o produto final deveria impor aos usuários.

Em resumo: já roda, já dá para jogar e existe evidência em hardware real, mas ainda não é uma release.

Quanto tempo levou?

Entre entender o projeto, escrever o ADR, gerar a spec, implementar, montar o build e repetir os testes no console, levei aproximadamente quatro a cinco horas.

É pouco tempo para a quantidade de coisas que saíram, mas não vejo isso como “a IA fez um porte completo em cinco horas”. O que aconteceu foi mais interessante: os agentes aceleraram muito a leitura, o planejamento, a geração de código e a criação de testes, enquanto eu fiquei responsável pelas decisões, pelos limites e por toda a validação física que eles não podiam executar.

O gargalo deixou de ser digitar código e passou a ser provar que o código fazia o que prometia.

E talvez essa tenha sido a principal lição dessa brincadeira. SDD e agentes ajudam bastante quando existe uma especificação clara, critérios verificáveis e um humano disposto a interromper o fluxo para testar de verdade. Sem isso, eu provavelmente teria produzido uma build “teoricamente compatível”. Com isso, terminei a tarde jogando Pokémon Red no Switch.

Quer acompanhar ou ajudar?

O trabalho está aberto e qualquer ajuda de quem conhece HOS, love-nx ou homebrew de Switch será muito bem-vinda, principalmente para testar em outros modelos e melhorar o empacotamento.

• Projeto Gen1Recomp
• Issue #531 — suporte ao Nintendo Switch
• PR #574 — implementação experimental com love-nx
• Fotos dos testes no Switch OLED
• Documentação do porte de Dusklight usada como referência

Se você tiver um Switch V1, V2, Lite ou costuma desenvolver homebrew para o console, seu teste pode ser justamente o próximo passo que falta para esse porte sair do meu OLED e virar algo realmente confiável para mais gente.