Fórum Unificado de Romhacking e Tradução

Devido à limitação de caracteres esse artigo foi divido em duas partes.

CitarA IA não substitui o romhacker. Ela se torna realmente útil quando recebe memória persistente, fontes verificáveis, regras técnicas, ferramentas e critérios objetivos para saber quando deve parar.

Objetivo e finalidade do artigo

O objetivo deste artigo é apresentar uma estrutura prática para usar IA em projetos longos de romhacking e localização: um cérebro persistente no Obsidian, recuperação de conhecimento, agentes especializados, ferramentas determinísticas, revisão humana e QA reproduzível.

Sua finalidade é ajudar cada romhacker a decidir se essa arquitetura serve para o próprio projeto, quais partes adotar e o que pode ser simplificado. Para isso, serão usados dois projetos independentes como exemplos: o cérebro especializado da tradução de Wild Arms e o Romhack_Brain, criado para acumular conhecimento técnico de múltiplos jogos e plataformas.

Ao final, você deverá entender o que o método resolve, o que ele não resolve, como começar com uma versão mínima e quando RAG, LLM Wiki, múltiplos agentes ou automação tradicional fazem sentido.

Não é uma promessa de tradução automática perfeita nem um argumento de que programação deixou de ser necessária. É um relato sobre como transformar uma IA que apenas conversa em uma operadora assistida por conhecimento, evidências e validações reproduzíveis.

---

1. O problema: o chat não é memória de projeto

Uma conversa com uma IA pode produzir uma boa análise hoje e contradizê-la amanhã. O contexto acaba, a sessão muda e decisões importantes ficam soterradas no histórico. Em romhacking isso é especialmente perigoso: um endereço errado, uma suposição sobre ponteiros, uma tag alterada ou uma paleta recomposta incorretamente pode inutilizar horas de trabalho.

Por isso adotei uma regra simples:


Termos aprovados, descobertas técnicas, evidências de diversos idiomas, formatos de gráficos, decisões de tom, resultados de QA e falhas encontradas no emulador precisam sair da conversa e entrar em arquivos versionados.

---

2. O que eu chamdo de "cérebro"

Nos projetos atuais, o cérebro é um Vault no meu caso uso o Obsidian formado principalmente por arquivos Markdown. O Obsidian é a interface para navegar, pesquisar e visualizar as relações; a inteligência não está presa ao aplicativo. Os arquivos continuam legíveis por qualquer editor, script, Git ou agente com acesso ao sistema de arquivos.

A adaptação usa três camadas:

• Raw: fontes brutas e evidências preservadas. Dumps, logs, screenshots, referências, saídas de ferramentas e decisões ainda não consolidadas.
• Wiki: conhecimento compilado. Glossários, regras, perfis de personagens, formatos técnicos, relatórios, páginas por projeto e decisões já validadas.
• Schema: o contrato operacional. Um [tt]AGENTS.md[/tt] e notas de agentes/regras dizem o que deve ser lido, o que pode ser alterado, como validar e quando pedir aprovação humana.

O ponto importante é o retorno: uma descoberta confirmada durante a execução volta para a wiki. Assim, o projeto acumula conhecimento em vez de reconstruí-lo a cada pergunta, ou seja vira um conhecimento orgânico.

---

3. Dois projetos independentes, dois tipos de cérebro

O Romhack_Brain e o cérebro do Wild Arms não formam uma hierarquia e um não depende do outro. São dois projetos independentes que aplicam princípios parecidos de memória persistente, fontes, schema e validação, mas foram criados para finalidades diferentes.

Romhack_Brain: projeto abrangente e multiplataforma

O Romhack_Brain foi criado para reunir conhecimento reutilizável entre vários jogos e plataformas. Ele documenta ponteiros, gráficos, paletas, atlas, compressões, assembly, ferramentas, checklists, decisões e páginas próprias de projetos para NES, Mega Drive, Dreamcast e outras plataformas conforme forem incorporadas.

Ele não traduz um único jogo. Seu papel é evitar que uma descoberta feita em um projeto desapareça ou precise ser redescoberta no próximo. Uma técnica de tilemap, um formato de ponteiro ou um cuidado de round-trip pode virar conhecimento reaproveitável, sempre mantendo separadas as particularidades de cada ROM. E com isso os agentes vão pegando padrões de cada console e entendendo o que fazer e como fazer.


No Romhack_Brain: três estruturas independentes de edição da ROM

Nos projetos documentados pelo Romhack_Brain, procuro oferecer três rotas diferentes para editar e reconstruir a ROM. Elas compartilham o conhecimento técnico já mapeado, mas não são a mesma ferramenta e nenhuma deve ser tratada como uma pasta da outra.

1. BASS — projeto ASM montável

BASS é a rota de baixo nível. O projeto mantém módulos ASM para constantes, macros, ponteiros, hooks, patches e rotinas novas, além de textos, tabelas de caracteres, gráficos e um processo de build. O BASS monta essas definições sobre a ROM-base e produz uma nova ROM reproduzível.

É a rota mais transparente para quem quer estudar ou modificar profundamente a engine: o romhacker enxerga endereços, desvios, repointing e alterações binárias de forma explícita. Também exige maior domínio técnico e não depende de interface gráfica.

2. Python — extract, insert e validate

Python é a rota de automação standalone. Os scripts leem a ROM, extraem textos e gráficos para formatos editáveis, geram metadata técnica, aplicam traduções, recalculam ponteiros, recomprimem dados, validam round-trip e criam uma ROM de saída.

O fluxo Python mantém sua própria estrutura, normalmente com JSON, PNG, BIN e [tt]metadata/[/tt]. Ele pode funcionar sem BASS e sem RomNexus. É também onde o mapeamento técnico pode ser convertido em dados estruturados: offsets, encoding, ponteiros, tilemaps, paletas, limites e regras de rebuild.

3. RomNexus — edição visual por interface gráfica

RomNexus é o aplicativo GUI do ecossistema. Ele usa um plugin Python por jogo e dados estruturados em JSON/metadata. Ao abrir uma ROM compatível, o aplicativo identifica o jogo, consulta o mapeamento já criado pelo fluxo técnico e apresenta textos, gráficos e demais recursos de forma organizada para edição.

Assim, o usuário não precisa operar diretamente o ASM ou executar scripts manualmente. Ele edita pela interface e o handler/plugin aplica as regras de extração e reconstrução da ROM.


Por que manter as três rotas? Porque elas atendem perfis diferentes. O romhacker avançado pode usar BASS; quem prefere linha de comando pode usar Python; e quem deseja uma experiência visual pode usar RomNexus. O conhecimento de uma investigação é mapeado uma vez e reaproveitado nas três entregas, poupando tempo sem misturar suas estruturas.

Wild_Arms_PSX: projeto especializado em um único jogo

O cérebro do Wild Arms foi criado especificamente para a retradução e localização desse jogo. Seu conteúdo não tenta servir como manual geral de romhacking: ele conhece o contexto de Filgaia, a fonte japonesa, glossário, tons e vozes, regras técnicas dos scripts, gráficos, arquivos processados e relatórios de QA.

Essa especialização permite que os agentes saibam não apenas como preservar um cabeçalho ou uma tag, mas também como Cecilia deve soar em determinada fase da história, quando a localização inglesa diverge do japonês e quais decisões já foram aprovadas para aquele jogo.

Exemplos reais registrados nele:

• [tt]Earth Golem[/tt] foi restaurado para Asgard após confirmação no arquivo japonês local [tt]101.txt[/tt], bloco 45.
• Nos mapas [tt]048.txt[/tt] e [tt]124.txt[/tt], a estrutura foi adaptada para preservar Rudy como protagonista silencioso, conforme a fonte japonesa, em vez de repetir automaticamente uma fala atribuída a ele pela versão ocidental.
• Os mapas 031–033 receberam variações próprias para Adlehyde em reconstrução. Igreja, cura, save e lojas deixaram de usar falas genéricas e passaram a refletir uma cidade ferida, mas resiliente.
• O glossário diferencia restaurações, naturalizações PT-BR, limites do executável e decisões que ainda exigem aprovação.

---

4. Os agentes: especialização sem teatro

Na arquitetura atual, o Strands Agents coordena Aurora, Sentinela e Artífice como agentes especializados. Cada agente recebe função, ferramentas, regras e contexto compatíveis com sua responsabilidade, enquanto o Vault funciona como memória persistente compartilhada.

A separação impede que a mesma etapa produza, aprove e encerre o próprio trabalho sem critérios diferentes. O orquestrador encaminha a tarefa, os especialistas executam suas partes e a decisão humana continua obrigatória nos pontos sensíveis.

Aurora | Tradutora

Consulta o arquivo alvo, a versão EU/US, o japonês local, o glossário e os perfis de voz. Identifica o momento narrativo, propõe termos e tradução e devolve ao usuário tudo que exige decisão humana.

Ela não traduz apenas palavras. Uma fala de Cecilia no início da jornada não deve soar igual à carta íntima do epílogo; Jack precisa continuar direto e provocador; Hanpan permanece analítico; Emma é acelerada, vaidosa e mandona; os Guardiões soam antigos e julgadores, e por ai vai.

Artífice | GFX

Analisa dimensão, formato, paleta, transparência, tiles, atlas, compressão e estilo dos glifos. Não gera livremente uma nova arte "parecida". Trabalha sobre a estrutura real do jogo e entrega comparação, preview e riscos técnicos.

Sentinela | QA

Não pergunta apenas se a frase "parece boa". Compara linhas, cabeçalhos, tags, encoding, idioma residual, limites visuais e, quando necessário, bytes, offsets, ponteiros, dimensões, paletas e round-trip.

Em [tt]101.txt[/tt], por exemplo, foram preservadas 173 linhas, 46 cabeçalhos e as tags por linha, além da decisão [tt]Earth Golem -> Asgard[/tt]. Em uma varredura posterior, 131 arquivos foram escaneados para localizar resíduos e divergências de glossário.

Humano | Direção e aprovação

O humano continua responsável por termos sensíveis, nomes, voz de personagens, naturalização, prioridades e aceite final. A IA reduz o custo de procurar, cruzar, documentar e verificar; não recebe autoridade ilimitada.

---

5. RAG de qualidade não é "jogar PDFs na IA"

RAG significa Retrieval-Augmented Generation: antes de responder, o modelo recupera informação externa relevante e usa esse contexto para gerar a resposta. Isso reduz a dependência da memória interna do modelo, mas não garante qualidade sozinho.

Um RAG ruim recupera o trecho errado com muita confiança. Um RAG de qualidade precisa cuidar de quatro coisas:

• Corpus: as fontes são confiáveis, identificadas e atuais?
• Recuperação: o sistema trouxe o trecho realmente necessário, com contexto suficiente?
• Fidelidade: a resposta está apoiada nas evidências recuperadas ou inventou conexões?
• Avaliação: existe teste capaz de separar erro de busca, erro de raciocínio e erro de execução?

O sistema não é apenas um RAG vetorial clássico. Ele é um híbrido de LLM Wiki, busca textual, links, hierarquia de fontes e ferramentas determinísticas. Em vez de reler toda a documentação bruta para cada pergunta, o agente consulta primeiro conhecimento já compilado. Só volta ao [tt]raw/[/tt], à ROM limpa, ao japonês local ou à internet quando precisa confirmar uma evidência.

A hierarquia do Wild Arms, por exemplo, prioriza:

• script japonês local do mesmo arquivo/bloco;
• dump, manual ou screenshot original verificável;
• referência japonesa confiável;
• script inglês e contexto de gameplay;
• inferência baseada no glossário aprovado.

Além disso, a evidência recebe um status visível: "JP local confirmado", "JP local divergente", "referência JP online", "JP pendente" ou "inferência de lore". Isso impede que uma suposição ganhe o mesmo peso de um dump original.

O RAG fornece contexto. Scripts, comparações binárias, ROM limpa e teste no emulador fornecem prova.

---

6. O método LLM Wiki de Karpathy

A estrutura foi inspirada no padrão LLM Wiki publicado por Andrej Karpathy (https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f). A diferença central em relação ao RAG tradicional é a acumulação: a IA não apenas recupera pedaços brutos em cada pergunta; ela mantém uma wiki persistente, interligada e progressivamente refinada.

As três operações principais são:

• Ingest: uma nova fonte entra em [tt]raw/[/tt], é lida e integrada às páginas afetadas.
• Query: a IA consulta primeiro o índice e a wiki compilada; se surgir conhecimento reutilizável, ele volta para a wiki.
• Lint: o cérebro procura contradições, páginas órfãs, decisões não consolidadas, links quebrados e informações superadas.

O [tt]index.md[/tt] funciona como mapa de conteúdo; o [tt]log.md[/tt] registra a evolução cronológica; o [tt]AGENTS.md[/tt] define o comportamento. Para centenas de páginas moderadamente organizadas, isso pode funcionar sem banco vetorial. Se o volume crescer, busca BM25, embeddings, reranking ou GraphRAG podem ser adicionados sem abandonar o Markdown.

---

7. Strands Agents: a camada de orquestração

O Strands Agents SDK (https://strandsagents.com/) é o framework usado para transformar as funções documentadas de Aurora, Artífice e Sentinela em uma arquitetura multiagente. Em termos simples, cada agente combina modelo, prompt e ferramentas; o orquestrador decide qual especialista deve atuar e acompanha a passagem de contexto entre as etapas.

O cérebro continua sendo a fonte comum; o schema delimita permissões; ferramentas determinísticas produzem evidências; e nenhum agente recebe autoridade para aprovar sozinho decisões sensíveis de lore, tom, formato ou alteração binária.

Na estrutura usada:

• Agents as Tools: o orquestrador chama Aurora, Artífice ou Sentinela como especialistas de domínio.
• Workflow: organiza o fluxo repetível "analisar -> aprovar -> aplicar -> QA -> registrar", preservando dependências e resultados intermediários.
• Graph: controla ciclos de correção, permitindo que uma reprovação da Sentinela retorne ao agente responsável até satisfazer os critérios de saída.
• Swarm: fica reservado para pesquisa exploratória ou problemas em que especialistas precisam colaborar de forma menos previsível. Alterações de ROM continuam preferindo fluxos controlados e auditáveis.

O Strands resolve a orquestração, mas não substitui a qualidade do conhecimento. Sem Vault, fontes, permissões restritas, ferramentas seguras e testes, múltiplos agentes apenas multiplicariam erros.

---

8. Exemplo real de QA gráfico: DAILY BUGLE -> CLARIM DIARIO

No projeto Spider-Man vs The Kingpin (Mega Drive), o letreiro [tt]DAILY BUGLE[/tt] parecia inicialmente uma troca simples de tiles. O agente de QA mostrou algo bem mais interessante:

• o endereço observado era uma referência de tilemap, não o gráfico bruto;
• o gráfico vinha de um bloco comprimido em HuffSloane;
• o atlas correto tinha 24 colunas por 3 linhas, totalizando 192x24 pixels;
• o jogo reutilizava tiles e aplicava espelhamento horizontal;
• algumas posições que pareciam independentes no PNG apontavam para o mesmo tile na ROM;
• a arte precisava continuar indexada e usar a paleta real do jogo.

O agente não apenas sugeriu "arrumar o M". Ele relacionou o defeito visual ao tilemap, identificou aliases, paleta e espelhamento e produziu regras verificáveis. Quando os tiles compartilhados impediram desenhos independentes, cinco tiles livres foram usados no atlas editável e o runtime recebeu um remapeamento específico para a fase. Nesse caso o agente devolveu a tarefa para o Artífice, com os dados necessários para a correção.


Depois vieram as validações: modo indexado, índices permitidos, round-trip HuffSloane, equivalência entre builds Python e BASS e, por fim, teste visual no emulador.


Esse caso resume bem o método: imagem para observar, disassembly e dados para explicar, script para reproduzir e emulador para confirmar.

Página 2>> (https://www.romhacking.net.br/index.php?topic=3417.0)

Sensacional!!!   :supermacaco2:

Gratidão por nos disponibilizar seu conhecimento!!