Descrevo aqui as etapas desse trabalho porque, juntas, elas formam um método que pode ser repetido com outro jogo e outro modelo. No fim, mostro um segundo projeto feito com o mesmo esquema, um port de Centurion: Defender of Rome do DOS para JavaScript. Os dois são projetos particulares, feitos para aprender: os jogos originais, seus gráficos e seu som continuam protegidos por direitos autorais, e eu não os distribuo.

A tela de título no Unity. A imagem é decodificada em tempo de execução a partir dos arquivos originais do jogo.

Da imagem de disquete ao código descompilado

O agente começou identificando os arquivos. Uma imagem de disquete do Amiga (ADF) é uma cópia bruta dos setores, então algumas dezenas de linhas de Python bastaram para extrair o conteúdo. O programa do jogo revelou-se um executável com overlays: um núcleo fica o tempo todo na memória, e outros três segmentos de código são lidos do disco conforme a necessidade. O Ghidra, um descompilador gratuito, não tem suporte nativo a esse formato. O agente escreveu um script que posiciona todos os segmentos em endereços fixos dentro de uma única imagem e transforma 45 saltos indiretos para os overlays em chamadas comuns. Com isso, o descompilador passou a enxergar cerca de 630 funções como um só programa.

Os dados do jogo trouxeram uma surpresa. Os arquivos com a extensão .rez têm a estrutura dos recursos dos computadores Macintosh, porque a versão para Amiga era um port da versão para Mac. Reconhecido o formato, o agente extraiu 210 textos, 82 listas de strings, os dados das cidades para seis épocas, imagens, animações, sprites e sons. Os textos se mostraram o melhor mapa do código: o número da string passada à rotina "mostrar texto" indica qual tela do jogo uma determinada função trata.

Treze agentes leem o código, nove o reescrevem

O código descompilado tinha quase 29 mil linhas, sem nomes de funções nem de variáveis. O agente principal o cortou em pedaços de cerca de 2 mil linhas e entregou cada um a um agente separado, com o mesmo briefing por escrito. Cada um devia gravar em um arquivo a descrição de todas as funções do seu trecho: fórmulas exatas, constantes, intervalos de sorteio, os números dos textos exibidos e as variáveis globais lidas e gravadas. O briefing continha uma frase que acabou sendo decisiva: uma fórmula errada é pior do que uma lacuna sinalizada. Assim, os agentes tinham de marcar o que não conseguiram determinar e conferir os pontos obscuros no assembly. O descompilador perdia aqui muitos argumentos de função, porque o compilador de 35 anos atrás usava um tipo int de 16 bits.

A segunda etapa teve a mesma divisão. Nove agentes reescreveram as regras do jogo em C#, cada um na sua faixa de endereços. Saíram daí cerca de 16 mil linhas de código, e o estado do jogo foi parar em um array de bytes endereçado exatamente como a memória do original. Não é elegante, mas elimina toda uma classe de erros. O código antigo sobrepõe estruturas umas às outras sem cerimônia e lê tabelas a partir do byte anterior ao seu início. Um port construído sobre a imagem da memória pode ser traduzido linha por linha e comparado com o assembly, e as tabelas de constantes ficam onde o código as procura. O desenho, o som e os controles foram substituídos pelos agentes por chamadas a uma interface que o motor implementa separadamente.

O oráculo: o código original em um emulador de processador

Ler código descompilado não prova que o port se comporta como o original. Por isso o agente construiu uma ferramenta de comparação. O código de máquina original do processador Motorola 68000 roda no emulador Unicorn. As rotinas de sistema, isto é, menus, caixas de texto, leitura dos controles e desenho, foram trocadas por funções em Python. Essas funções respondem a cada pergunta do jogo segundo um gerador de decisões simples e registram tudo o que o jogo mostrou. O port em C# recebe a mesma sequência de decisões por meio de um "jogador roteirizado", que roda fora do Unity. No fim, os dois registros são comparados linha por linha. Os textos contêm ouro, tamanho da tripulação, datas e nomes de cidades, de modo que a coincidência dos registros é um teste forte das regras.

A primeira medição completa deu 800 execuções coincidentes em 802. As duas divergências tinham uma única causa: a aritmética de ponto flutuante. O jogo usa uma biblioteca em software que não arredonda como os processadores de hoje. A raiz quadrada de 81, nela, é 8,999999999999998, e o jogo trunca os resultados para inteiros, de modo que o moral da tripulação saía um ponto alto demais no port em certas proporções entre ouro e tripulação. A correção consistiu em reescrever as rotinas da biblioteca instrução por instrução: 1.572 instruções, 43 rotinas e 21.701 vetores de teste calculados pelo código original, sem nenhuma diferença. Depois dessa mudança, todas as 802 execuções coincidem, e em outras 120 o estado do jogo foi comparado quadro a quadro no duelo, na navegação e nas batalhas naval e terrestre.

A comparação também revelou dois bugs do próprio jogo de 1990: uma leitura do mapa por um ponteiro nulo ao atacar uma cidade na diagonal e uma divisão por zero quando a tripulação cai a zero. Nesses pontos o port precisa escolher um comportamento, e a ferramenta de comparação tem uma chave que obriga o original a seguir o mesmo caminho. O resultado também tem limites. A ferramenta não compara desenho nem som, e caminhos raros, como o casamento, o mapa do tesouro completo ou os postos mais altos, foram pouco exercitados.

A apresentação e os acréscimos que não existiam em 1990

A camada que o jogador vê foi construída pelos agentes no Unity a partir de código, sem cenas prontas. Imagens e animações são decodificadas dos recursos originais, os sprites recebem as cores da paleta da tela atual, e a música foi renderizada em arquivos de áudio por meio da emulação do sequenciador de quatro canais do jogo. O agente controlava o jogo em execução pela linha de comando, tirava capturas de tela e as examinava. Foi assim que apareceram alguns defeitos que nenhum teste de regras pega, como a falta de som na versão para navegador, porque a conversão de áudio exigia o programa ffmpeg, que não estava instalado no sistema.

Navegação pelo mapa. O fundo é montado a partir de uma grade de terreno de 160 por 200 células e dos tiles originais.

Depois das primeiras partidas, pedi três mudanças. A pergunta sobre a data de chegada da frota do tesouro era, no original, a proteção contra cópia e exigia o manual impresso; agora o quiz continua, mas a resposta certa aparece nas "anotações do capitão". A lista de cidades mostrava apenas os dados da cidade, porque o jogo pressupunha que o jogador tinha um mapa impresso; agora a cidade escolhida é marcada em um mapa do Caribe. A tela de duelo ganhou uma tabela com a força, o moral e a arma dos dois lados, disposta como no original. Os acréscimos podem ser desligados, e os testes de comparação rodam sem eles, para que os registros continuem batendo com o código de 1990.

O duelo no original. Fonte da captura de tela: OpenRetro Game Database.

A mesma tela no port. Os números da tabela são lidos em tempo real do estado do duelo.

Um acréscimo em relação ao original: a cidade escolhida em um mapa do Caribe.

Centurion: o mesmo esquema em JavaScript, com jogabilidade ampliada

O segundo projeto é Centurion: Defender of Rome, um jogo para DOS de 1990, levado para JavaScript e para o elemento Canvas, sem emulador. Os passos foram os mesmos, com outros nomes. Primeiro foi preciso descompactar o executável, porque ele estava comprimido com a ferramenta EXEPACK. Cinco módulos do jogo (batalha terrestre, arena de gladiadores, corrida de quadrigas, batalha naval e a introdução) ficavam em um arquivo de overlays e compartilhavam um único segmento de dados. O estado da campanha roda sobre uma cópia viva dos 64 quilobytes desse segmento, porque o motor do jogo depende de estouro de 16 bits, divisão inteira e bytes com sinal, que os números de ponto flutuante do JavaScript não reproduzem sozinhos. O jogo salvo coincide byte a byte com o formato original, o que os testes verificam.

A tela de título de Centurion no navegador, com os gráficos originais.

Aqui fui além de um port fiel. Acrescentei uma chave para regras ampliadas, desligada por padrão: fusão de legiões e várias legiões em uma mesma província, vélites de armamento leve, elefantes de guerra e desembarques pelo mar. O código desse port foi escrito por modelos diferentes dos de Pirates: principalmente o Gemini 3.8 Flash e, em parte, o gpt-6.1-sol da OpenAI, executado pelo Codex. A escolha veio das ferramentas que eu tinha à mão, e não de uma comparação entre modelos.

O menu de opções. O primeiro item ativa as regras ampliadas, que não existiam no original.

A tela da província com o menu de jogos.

Os problemas que o Gemini encontrou em Centurion

A maior parte do tempo foi gasta em pontos nos quais o código descompilado ou os nomes dos arquivos sugeriam algo diferente do que o jogo realmente faz. Cinco exemplos tirados das anotações do projeto:

• Overlays sem dados. Os cinco módulos do jogo ficam em um único arquivo, OVL0.OVL, e são carregados no mesmo endereço, mas todos usam um segmento de dados compartilhado. Por isso, o código de um overlay aberto sozinho no Ghidra não mostrava nenhuma string nem tabela. Um script juntou cada overlay ao segmento de dados em cinco executáveis sintéticos, e só então o descompilador ligou o código dos minijogos às estruturas da campanha.
• Fronteiras das províncias conquistadas. Contornar uma província a partir do mapa das regiões clicáveis com o mouse dava linhas serrilhadas, que não combinavam com o mapa desenhado à mão. O código mostrou outro mecanismo: na imagem do mapa, cada província tem um caminho oculto, com um pixel de largura e de cor escura, e uma tabela nos dados fornece um ponto de partida para cada uma das 27 províncias. O jogo repinta esse caminho com a cor do império, começando pelo ponto de partida, e o port faz o mesmo.
• Quadros que voltam atrás. O loop original do jogo rodava a 9–12 Hz, e um navegador desenha 60 vezes por segundo. Em três pontos, um sprite recuava um quadro por um instante. O globo da introdução gira pelo deslocamento de 14 cores da paleta em 10 passos, mas o primeiro passo da tabela tem valor zero; deslocar a paleta em todos os passos fazia os continentes darem um tranco a cada volta. Nas coortes em marcha e nas investidas dos gladiadores foi preciso reproduzir a ordem com exatidão: primeiro o quadro intermediário, depois a mudança de posição.
• Nomes de arquivo enganosos. Os bitmaps BB1.CBM e BB2.CBM pareciam faixas de batalha e, desenhados no alto da tela, cobriam o campo de batalha inteiro. O código só os carrega quando o computador não tem placa VGA: são fundos de tela cheia para as placas EGA e CGA, mais antigas. A mesma rotina revelou que o posicionamento antes da batalha tem duas etapas. A escolha da formação substitui a lista de táticas disponíveis, e a manobra de Canas só aparece depois que a cunha é escolhida.
• Música quase inaudível. Depois de decodificadas as 17 faixas e os 24 instrumentos do driver da placa de som AdLib, as melodias estavam certas, mas tocavam a cerca de −55 dB. A desmontagem do driver mostrou que, a cada nota, ele subtrai um quarto do volume da nota da atenuação gravada no instrumento. Uma linha de código devolveu cerca de 32 dB. Um segundo defeito estava do lado do navegador: em notas muito curtas, o cancelamento das mudanças de volume agendadas na Web Audio API apagava o ataque do som, que ainda estava em andamento, e silenciava a nota.

A segunda etapa do posicionamento antes da batalha: as táticas disponíveis para a formação em cunha.

As corridas de quadrigas no Circus Maximus foram um trabalho à parte. Ali, a quadriga não é uma imagem única. Bitmaps separados para cada combinação de três classes de quadriga, quatro cores de condutor, quatro ações, dezesseis inclinações na curva e três quadros de galope dariam mais de 2.300 quadros, então os autores do jogo montaram na memória uma árvore de nós de 16 bytes. Cada nó aponta para o próximo elemento do mesmo nível e para o seu primeiro filho, e guarda um índice de quadro, uma tabela de deslocamentos para os sucessivos quadros da animação e uma flag de visibilidade. A raiz são os quatro cavalos. A caixa do carro tem um deslocamento horizontal adicional, no qual a física da curva grava uma inclinação de 0 a 15 pixels, e o condutor é seu filho e herda essa posição. É por isso que, na curva, o condutor se inclina junto com a caixa, enquanto os cavalos continuam correndo no eixo da pista. Os ramos com o eixo que se parte e com os destroços capotando existem o tempo todo; apenas estão com a flag de visibilidade desligada.

A árvore de sprites da quadriga reconstruída a partir dos dados do jogo. O diagrama foi feito no projeto com os recursos originais decodificados.

A pista também não é montada com tiles. O jogo expande 72 pares de coordenadas gravados em 368 pontos de controle e divide a posição transversal na pista em 16 faixas. Da faixa depende a velocidade segura na curva, calculada como (número da faixa + 15) × 4: junto à parede interna ela é 60, junto à barreira externa, 116–120. A faixa interna é o caminho mais curto, mas entrar no grampo acima desse limite inclina a caixa, empurra a quadriga para fora e dispara um sorteio de acidente, tanto mais provável quanto maior o excesso. O marcador vermelho na barra de velocidade mostra esse limite ao jogador.

Os 368 pontos da pista e a velocidade segura na curva conforme a faixa.

O que fica desse trabalho além dos jogos

Registrei o método como uma skill, isto é, um conjunto de instruções que o agente carrega quando recebe uma tarefa parecida. Ela contém três princípios tirados dos dois projetos. As regras do jogo são portadas com fidelidade, e a apresentação é substituída por uma interface. O port mantém o layout de memória do original. Não se confia no resultado enquanto ele não passar por uma comparação com o código original. A skill inclui ainda os briefings para os agentes de análise e de portabilidade e os scripts do projeto Pirates.

A conclusão mais interessante diz respeito aos fãs, não aos agentes. Quem tem um jogo de que gosta e sente falta de alguma coisa nele há anos pode hoje refazê-lo do seu jeito, de forma rápida e barata, sem o código-fonte. Em Pirates, o quiz que exigia o manual impresso agora dá a resposta, e apareceu um mapa que o jogo nunca teve. Em Centurion, acrescentei regras que o original não tinha: fusão de legiões, elefantes de guerra e desembarques pelo mar. Depois que as regras do jogo viram código comum em C# ou JavaScript, a próxima mudança é uma alteração de código comum, e não um patch no binário. Do mesmo modo dá para levar um jogo para um motor mais rápido ou para outra plataforma: Centurion roda no navegador, e Pirates é compilado para Linux e para o navegador. O método também não está preso a jogos antigos. Um descompilador, um emulador de processador e a comparação dos registros funcionam do mesmo jeito para um programa mais recente; mais código significa mais trabalho, não outra abordagem.

Fontes

• Materiais próprios dos dois projetos: anotações da análise do código, briefings para os agentes, o relatório da ferramenta de comparação (802 execuções, a lista das diferenças encontradas) e a descrição do port de Centurion com suas especificações. Não estão publicados.
• National Security Agency, Ghidra, o pacote de engenharia reversa usado para descompilar os dois jogos.
• Unicorn Engine, o emulador de processadores usado para executar o código 68000 original.
• OpenRetro Game Database, a página de Pirates! para Amiga, fonte da captura de tela do jogo original.

Essa interpretação exige, porém, verificar se um trabalho humano mais longo significa de fato uma tarefa proporcionalmente mais difícil para a IA. Se, em certa faixa, as tarefas têm dificuldade parecida para o agente, uma pequena melhora na taxa de sucesso pode deslocar o resultado por uma grande faixa de minutos.

Na escolha de um agente, precisamos então de uma informação adicional: como mudou a chance de concluir as mesmas tarefas. O multiplicador de tempo, sozinho, pode superestimar a diferença entre versões, se estivermos comparando justamente um trecho do benchmark em que o tempo distingue mal a dificuldade.

A METR chama essa medida de time horizon. Na variante com limiar de 50%, é o tempo de trabalho humano no qual a curva ajustada prevê que metade das tentativas do agente dá certo. É uma média para as tarefas com aquele tempo, não uma garantia para cada uma delas. Não medimos aqui o tempo de funcionamento da própria IA.

No preprint On the estimation and validity of AI time horizons—a statistical look at the METR plot, Drew T. Nguyen e William Fithian analisam justamente a conversão do tempo em dificuldade. O trabalho, da área de avaliação de IA e estatística, publicado pela primeira vez em 8 de outubro de 2026, aponta nos dados da METR um trecho quase plano entre 2 e 30 minutos de trabalho humano. As tarefas dessa faixa tinham, em média, dificuldade parecida para os agentes estudados.

Uma pequena mudança nas chances pode deslocar muito o limiar

O exemplo a seguir é uma simplificação didática própria, não o resultado de um estudo. Temos três tarefas, A, B e C, que tomam de uma pessoa 3, 10 e 30 minutos, respectivamente. Cada um de dois agentes executa cada tarefa 100 vezes no mesmo ambiente. Registramos sucesso ou fracasso.

Para simplificar, tratemos essas frequências como chances conhecidas com exatidão e liguemos os pontos com curvas decrescentes. O agente mais antigo cruza os 50% aos 3 minutos; o mais novo, aos 30. O horizonte cresce dez vezes, embora em cada tarefa a taxa de sucesso tenha subido apenas 2 pontos percentuais. Em 300 tentativas por agente, o número de sucessos passou de 147 para 153.

As três tarefas e todos os fracassos continuam na medição. Escolhemos apenas o ponto em que a curva cruza o limiar; não filtramos nem premiamos nada. O custo desse teste hipotético são 600 tentativas completas de agente. Em um experimento real, amostras desse tamanho não permitem tratar uma diferença de 2 pontos percentuais como certa. É preciso ajustar uma curva e estimar a incerteza.

O exemplo mostra a operação de ler o horizonte em uma curva quase plana. Em um estudo, a forma dela ainda precisa ser estabelecida a partir de muitas tarefas e sistemas. Se, em outra faixa, a curva cai muito mais depressa, o mesmo multiplicador de horizonte exige um aumento maior das chances de sucesso. Por isso, as passagens de 3 para 30 minutos e de 30 minutos para 5 horas não são, por definição, porções iguais de progresso.

O tempo humano precisa ser ajustado à dificuldade para a IA

O ponto de partida é a tabela de resultados: que tarefa cada agente executou, quantas vezes e com que desfecho. Conhecemos também o tempo humano e a família da tarefa. Não conhecemos um número objetivo único que descreva a dificuldade dela para a IA.

O baseline dos autores pressupõe que cada nova duplicação do tempo humano aumenta a dificuldade no mesmo passo. Ele usa uma inclinação comum das curvas para todos os agentes; elas diferem no nível de capacidade. É uma referência mais forte do que a regressão separada para cada sistema, usada originalmente.

A primeira proposta substitui o passo constante por uma curva monotônica aprendida, do tipo spline: trechos ligados suavemente, que podem crescer mais depressa ou mais devagar. Um tempo maior continua sem reduzir a dificuldade prevista, mas o crescimento não precisa ser uniforme.

A segunda proposta, chamada no trabalho de Modelo 2, recorre à item response theory, IRT. A partir do padrão de sucessos e fracassos, ela estima em conjunto a capacidade dos agentes e a dificuldade das tarefas. Leva em conta também a semelhança entre tarefas de uma mesma família e uma variação adicional nos resultados das tentativas. Com isso, muitas repetições do mesmo par agente–tarefa não são tratadas como outras tantas informações novas e independentes sobre o benchmark inteiro.

O primeiro passo em que o baseline e os novos métodos diferem é a conversão do tempo humano em dificuldade. Os resultados dos agentes usados como entrada continuam os mesmos. O novo ajuste pode, portanto, mudar o horizonte sem que mude uma única resposta da IA.

Os mesmos resultados do GPT-4o deram outro horizonte

Os autores reanalisam os resultados registrados do METR Time Horizon 1.1: 228 tarefas e 26 sistemas de IA. Na figura 1, o horizonte do GPT-4o é de 7,2 minutos segundo o baseline com inclinação comum e de 4,4 minutos segundo o Modelo 2. São duas estimativas feitas com as mesmas tentativas, não uma piora no funcionamento do GPT-4o nem uma comparação do custo da sua inferência.

Uma curva mais flexível poderia simplesmente se ajustar melhor ao ruído. Por isso os autores verificam a previsão dos resultados em famílias inteiras de tarefas não utilizadas no ajuste. Em uma validação em cinco partes, dividem as 79 famílias, e não tentativas isoladas de uma mesma tarefa. Os dois novos métodos têm estimativas pontuais melhores em todas as 12 combinações de métrica e forma de ponderação dos resultados. Isso significa um erro menor na previsão do sucesso, não um aumento da taxa de sucesso dos próprios agentes. §2.4–2.5 e figura 2

A vantagem não se distribui por igual. O ajuste melhora mais para os sistemas da era do GPT-4, cujos horizontes atravessam a faixa plana apontada. Para os sistemas mais fortes, as curvas comparadas quase coincidem. As estimativas para sistemas individuais também são muito menos conclusivas do que o resultado agregado. Apêndice A

Tarefas mais longas exigem verificar a escala de novo

O trabalho não estabelece a causa do trecho plano nem mostra que ele aparecerá em todo benchmark. Tampouco prova que as tarefas da METR representam todo o trabalho de um programador. Os autores não contestam a tendência exponencial de progresso observada; eles investigam o que significam os intervalos no eixo do tempo de trabalho humano.

A aplicação prática é complementar o horizonte com um gráfico das chances de sucesso para faixas fixas de tarefas. Isso permite ver se um salto do horizonte corresponde a uma mudança nítida de confiabilidade. Ao acrescentar tarefas mais longas ao próprio benchmark, vale verificar, em famílias reservadas, se o tempo delas continua prevendo a dificuldade para o agente, antes de prolongar a curva usada até então.

Fontes

• Drew T. Nguyen, William Fithian, On the estimation and validity of AI time horizons—a statistical look at the METR plot, preprint, 2026, v1. arXiv:2610.12466; DOI: 10.48550/arXiv.2610.12466. Texto completo.
• METR, Task-Completion Time Horizons of Frontier AI Models, definição da medida, procedimento de avaliação e limitações. A página informa que o gráfico não é mais atualizado ativamente.

Segundo as medições deles, com as proporções de tokens adotadas para o trabalho de agentes, o Claude com o Opus 5.5 oferece cerca de cinco vezes mais valor, pelas tabelas de preços da API, do que as assinaturas da OpenAI com o GPT-6.1 Sol incluídas na comparação. Essa é uma medida do uso disponível; a eficácia dos modelos na execução de tarefas não foi comparada aqui.

O artigo mostra também os efeitos do corte pela metade da cota de tokens no novo Pro 200 da OpenAI e descreve um teste A/B detectado pelos autores, no qual uma das contas tinha limites cerca de 20% menores. O valor de uma assinatura depende, portanto, também das regras de contabilização do uso, que mudam com o tempo.

A comparação final dos serviços de intermediários está disponível para assinantes pagos.