Matrix-Game 4.0 é insano: IA transforma caixas simples em um jogo jogável

Autoria: Prompt Engineer 48 · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Matrix-Game 4.0 Is CRAZY: AI Paints a Playable Game From Plain Boxes · Canal: Prompt Engineer 48 · 19:42 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Geração de conteúdo com IA, Inferência e otimização de modelos, Modelos de IA

Resumo

Matrix-Game 4.0, da Skywork AI, combina um game engine, um coding agent multimodal e um modelo de geração de vídeo para criar jogos interativos. O engine mantém as regras e o estado do mundo, enquanto o modelo de vídeo renderiza os visuais a partir de uma representação simplificada. Os autores relatam desempenho de até 83,4 FPS e latência de 112 ms em uma RTX 5090, mas os números dependem da configuração e não foram verificados independentemente pelo apresentador. O vídeo também examina os resultados, os limites do sistema, o repo e as condições necessárias para executá-lo.

Pontos-chave

A proposta separa as responsabilidades: o game engine controla regras e estado, o coding agent traduz e modifica a lógica, e o modelo de vídeo cuida da aparência.
O engine mantém uma representação simplificada do mundo, para que objetos e regras continuem consistentes mesmo fora da tela.
O treinamento usa pares de vídeos alinhados: uma versão low-poly e outra em alta fidelidade, capturadas no Unreal Engine 5.
Cada jogo tem seu próprio modelo de renderização, fine-tuned com dados específicos daquele mundo.
Legendas dinâmicas, geradas a partir dos dados do engine, descrevem objetos visíveis, estados e distâncias sem usar um VLM.
O sistema usa memória espacial e um cache de frames recentes para manter a continuidade entre segmentos e quando o jogador retorna a um local.
O relatório atribui os ganhos de velocidade a várias otimizações, incluindo kernels fused, CUDA graphs e cache de atenção.
O repo disponibiliza pesos e assets para Medieval Castle, Ancient Egypt e City Racing; Air Combat aparece nos dados e resultados, mas não entre os jogos com pesos liberados.
O apresentador não testou o sistema: sua RTX 4060 com 8 GB não atende aos cerca de 18,2 GB de memória de pico reportados.
Entre os limites estão a resolução de 480p, a necessidade de dados específicos por jogo e a ausência de testes independentes apresentados no vídeo.

Capítulos

Início	Capítulo	Resumo
00:00	A proposta e o problema dos modelos de mundo	O vídeo apresenta Matrix-Game 4.0 e explica por que modelos de vídeo que tratam os pixels como o próprio mundo podem perder estado, memória e consistência.
02:03	Engine, coding agent e modelo de vídeo	O sistema divide o trabalho entre o engine, que controla as regras, o coding agent, que descreve e altera o mundo, e o modelo de vídeo, que o renderiza.
04:08	Dados de treinamento e legendas dinâmicas	A equipe treinou modelos por jogo com vídeos pareados e usa informações do engine para atualizar as descrições da cena.
06:43	Arquitetura, memória e treinamento	O apresentador descreve as entradas do modelo, os mecanismos de memória e as etapas usadas para convertê-lo em um gerador causal rápido.
09:49	Otimizações de velocidade e resultados	O vídeo detalha as otimizações de inference, compara números reportados e examina os clipes de gameplay e as alterações de regras.
16:04	Repo, limitações e avaliação final	O apresentador revisa os arquivos e licenças do repo, explica por que não testou o sistema e resume seus limites e perspectivas.

Citações

Deixe que ele seja um renderizador, apenas um renderizador. — 02:03

O código controla as regras; o modelo de vídeo controla a aparência. — 04:08

Uma página selecionada continua sendo uma página selecionada. — 14:00

Código para as regras, engine para o estado, modelo de vídeo para os pixels. — 18:39

Conceitos e entidades

Matrix-Game 4.0 (modelo): Sistema da Skywork AI que combina um game engine, um coding agent e um modelo de vídeo para renderizar jogos interativos.
Skywork AI (empresa): Empresa responsável pelo Matrix-Game 4.0 e pelo repo apresentado no vídeo.
Unreal Engine 5 (ferramenta): Engine usado pela equipe para capturar as cenas de treinamento em versões low-poly e de alta fidelidade.
RunPod (empresa): Serviço mencionado pelo apresentador como opção para alugar uma GPU RTX 5090.
Matrix-Game (repo): Repo no GitHub que contém o código do projeto, opções de inference e uma demo no navegador.
RTX 5090 (ferramenta): GPU usada na configuração de desempenho reportada pelos autores.
Unreal Engine 5 (conceito): Ambiente de desenvolvimento de jogos cujos assets foram usados na captura dos dados do projeto.
dynamic captions (conceito): Descrições atualizadas a cada frame com informações de objetos, estados e distâncias fornecidas pelo engine.

Tradução completa (pt-BR)

00:00 Olhe para a metade esquerda deste quadro. Paredes de pedra de verdade, palmeiras, fumaça e um personagem com textura. Agora, olhe para a metade direita. Chão quadriculado cinza, caixas coloridas sem textura, um personagem feito de blocos. É o mesmo jogo, o mesmo quadro. E, segundo os autores, um modelo de vídeo pintou o lado esquerdo a partir do lado direito em tempo real. Este é o Matrix Game 4.0, da Skywork AI. A principal alegação é que se trata de um mundo de jogo jogável em 480p, a 60 quadros por segundo, em uma única RTX 5090, com 112 milissegundos entre o pressionamento da tecla

00:31 e o primeiro quadro que reage. Esse é o número apresentado no próprio artigo. Eu não reproduzi o resultado e vou explicar exatamente o porquê mais adiante no vídeo. O que posso fazer é percorrer com você, linha por linha, a página do projeto, o repo e o relatório técnico, e explicar o que há de realmente novo aqui, porque o interessante não é que um modelo de vídeo desenhe imagens bonitas. O interessante é o que eles não deixam o modelo de vídeo fazer. >> [música] >> Vamos começar pelo problema. Muitos dos modelos de mundo interativos recentes, os

01:02 no estilo do Genie, funcionam assim: você pressiona uma tecla, o modelo prevê o próximo trecho de pixels, e os pixels se tornam o mundo. Não há um jogo por baixo. O vídeo é o jogo. O relatório lista quatro problemas disso. Primeiro: nada corrige o modelo externamente, então o estado do mundo só existe implicitamente nos pixels gerados. Quando um baú sai da tela, ninguém acompanha onde ele está. Segundo: pequenos erros se acumulam. Cada novo trecho é condicionado pelo anterior, então uma parede um pouco errada acaba ficando muito errada um minuto

01:33 depois. Terceiro: a memória consiste apenas em quadros antigos, então o custo aumenta conforme você joga por mais tempo. E quarto: as mecânicas continuam limitadas. Você pode andar por aí, mas é difícil fazer cumprir regras como pontos de vida, munição, progresso de missões e um escudo que se quebra quando as regras precisam ser deduzidas a partir de imagens. Os autores dizem algo de que gosto. Eles argumentam que os geradores de vídeo atuais não são realmente modelos de mundo. Boa parte da inteligência aparente vem do codificador de texto ou do modelo de linguagem a montante, e a parte de difusão funciona mais como um renderizador. Então, a resposta deles é deixar que ele seja um renderizador, apenas um

02:03 renderizador. Então, aqui está o projeto: três partes — uma engine de jogo, um agent de programação multimodal e um modelo de geração de vídeo. O relatório dá a cada um um cargo e, sinceramente, os cargos são a maneira mais clara de lembrar o papel de cada um. A engine é a árbitra, o agent de programação é o roteirista e tradutor, e o modelo de vídeo é o pintor. Primeiro, a árbitra: a engine de jogo mantém os dados reais do mundo. Pontos de vida, inventário, gravidade, colisões, progresso de missões — tudo isso fica no código e é controlado pelo código. Ela não desenha nada sofisticado. Ela

02:34 desenha o que o artigo chama de representação proxy low-poly: caixas para edifícios, um cilindro com uma esfera para uma árvore, uma figura feita de blocos para um personagem, contornos pretos, sem textura, sem sombras, céu preto e chão quadriculado cinza. E é por isso que isso importa. Se um inimigo sai do campo de visão, a engine ainda sabe onde ele está. Se você atira em um barril de petróleo, a engine decide se o tiro acerta e se ele explode. O modelo de vídeo nunca precisa se lembrar de nada disso nem decidir nada disso. Ele simplesmente recebe uma imagem das consequências. Agora, o

03:04 roteirista: o agent de programação trabalha em duas direções. No sentido descendente, ele traduz o que a engine diz: “Há uma caixa aqui com este ID de objeto”. E o agent transforma isso em palavras, como “uma velha cabana de palha, desgastada pelos ventos do mar, com uma porta de madeira vermelha-escura”. No sentido ascendente, você diz: “Faça monstros atacarem em bando, vindo de todas as direções”. E ele edita a configuração da cena e o código do jogo, incluindo onde eles surgem, como se movem e atacam e o que conta como vitória. Se você deixar detalhes em aberto, ele improvisa. No exemplo do artigo, um jogador abre uma porta que ainda não dá para lugar nenhum.

03:35 O agent imagina uma sala de armazenamento com um baú de ferro trancado no canto, registra isso na engine e, a partir desse momento, a engine passa a controlar aquele baú. Ele pode ser aberto ou não, de acordo com as regras, não com a intuição. Depois, o pintor: o modelo de vídeo recebe o quadro proxy, a descrição de texto atual, alguns quadros de referência e um primeiro quadro, e os transforma em materiais, iluminação e atmosfera. O ciclo completo é: o jogador envia uma entrada, a engine atualiza o mundo, saem a imagem proxy e os sinais de controle, o modelo de vídeo renderiza e o jogador vê o resultado.

04:08 O código controla as regras; o modelo de vídeo controla a aparência. Como ensinar um modelo a fazer isso? Com dados pareados. A equipe capturou tudo na Unreal Engine 5, e cada clipe é gravado duas vezes, da mesma câmera e no mesmo índice de quadro: uma vez como renderização da estrutura low-poly e outra como imagem de alta fidelidade. Assim, os dois vídeos se alinham pixel por pixel. A tabela um do relatório lista estas cenas: castelo medieval, um jogo de tiro em terceira pessoa, 17.848 clipes de treinamento. Deserto do Antigo Egito, também um jogo de tiro, 40.296.

04:41 Combate aéreo em cânion desértico, 28.720. E uma amostra urbana, megacidade para dirigir, 27.470. No total, 114.334 clipes, 1.712 horas. Eles também reservam sessões inteiras de captura que nunca são usadas no treinamento: três sessões cada para o castelo, o deserto e a cidade, e lotes inteiros de captura para o combate aéreo. Portanto, os clipes que você vê nos resultados não foram vistos durante o treinamento. Vale dizer isso claramente, porque é a primeira coisa que eu verificaria. Mais uma escolha de projeto: eles

05:11 treinam um modelo de renderização por jogo, em vez de um único modelo gigante para todos os mundos. Um modelo de jogo de tiro em castelo, um de jogo de tiro no deserto e um de direção na cidade, cada um com fine-tuning nos próprios dados. Tenha isso em mente ao pensar em quão generalizável é o sistema. O segundo ingrediente é o que eles chamam de legendas dinâmicas. Em um jogo, a imagem muda a cada ação: você gira a câmera e objetos diferentes ficam visíveis. Você aciona algo e um objeto muda de estado. Um único prompt fixo não consegue acompanhar isso. Então, cada objeto da cena tem um ID vinculado a uma descrição. A cada quadro, o sistema

05:42 lê da engine quais objetos estão visíveis, seus estados e suas distâncias, e preenche o modelo de texto. Não há nenhum modelo de visão e linguagem envolvido. O artigo enfatiza esta regra: sem VLM. Veja o exemplo do clipe de direção na cidade. O quadro quatro lista minivans estacionadas a 4 e 10 m de distância e um pedestre parado a 30 m. No quadro 53, os pedestres estão andando e se aproximando. E um edifício cinza-escuro aparece. No quadro 155, entram em cena um saco de lixo e um poste de iluminação. O texto muda junto com o mundo. A imagem proxy e a

06:12 legenda dividem o trabalho. A imagem proxy fornece a estrutura: onde as coisas estão e como se movem. A legenda fornece o significado: o que cada coisa é e o que está fazendo. Juntas, elas restringem o modelo pelos dois lados. E você pode ver isso na página do projeto. Há um painel de prompt para uma sequência de 40 segundos nas pirâmides, com 12 segmentos, um a cada 80 quadros. Ele mostra um resumo da cena com o estado do jogador, inimigos e pontos de referência ao redor, além dos eventos daquele segmento, escritos pelo harness. Ação do jogador, ação do inimigo, acerto, explosão, inimigo derrotado, coisas entrando e saindo do campo de

06:43 visão. Tudo identificado por cores. Agora, o próprio pintor. Ele parte do 12.2, o modelo de 5 bilhões de parâmetros em sua variante de controle divertido, e o transforma em um modelo de vídeo para vídeo. Quatro coisas condicionam cada segmento. A imagem proxy low-poly concatenada com o latente que está sendo gerado, a legenda dinâmica, quadros de referência da memória espacial e o primeiro quadro, que conecta o novo vídeo ao que já está na tela. Os números, para quem gosta de arquitetura: 30 blocos transformer com dimensão de 3.072, 24 cabeças de atenção,

07:14 um quadro latente corresponde a quatro quadros de vídeo e, em 480 por 864, isso equivale a 405 tokens por quadro latente. O codificador de texto é o UMT5XXL, e as legendas, as chaves e os valores ficam em cache e só são recalculados quando a legenda muda. O que faz isso ser um jogo, e não um filme, é o cache. Cada novo segmento consulta três tipos de memória: até três quadros de memória espacial recuperados pela pose da câmera, os quadros de referência e uma janela deslizante dos 20 segmentos mais recentes. Depois que um segmento é gerado, o modelo executa mais uma vez

07:45 no resultado final, com uma entrada de controle removida, e grava essa versão limpa no cache. Assim, os trechos posteriores consultam o histórico limpo, não os próprios rascunhos ruidosos. Essa memória especial é como ele consegue voltar a um lugar. Os candidatos são escolhidos entre os quadros que estão pelo menos 40 quadros atrás; são mantidos aqueles cuja visão se sobrepõe, e escolhe-se o mais próximo pela pose da câmera. Não é uma memória perfeita, e é o mecanismo do jogo que realmente mantém o layout, mas ela conserva a consistência visual quando você volta. O treinamento acontece em duas grandes fases.

08:15 Primeiro, fine-tuning supervisionado. O modelo aprende como um modelo de vídeo para vídeo bidirecional, em janelas de 81 quadros a 704 por 1280, usando 64 GPUs, uma taxa de aprendizado de 10 elevado a menos cinco e 4.000 etapas. Para permitir orientação e geração sem um primeiro quadro, eles descartam aleatoriamente o primeiro quadro em 30% das vezes, o prompt em 20% e o controle proxy em 20%. Depois vem a parte que torna o tempo real possível. Um modelo bidirecional vê o clipe inteiro de uma vez. Um jogo não pode fazer isso porque o futuro ainda não aconteceu, então eles o destilam em um gerador causal

08:47 que segue um método chamado causal forcing plus plus, em três etapas. Etapa um: difusão autorregressiva com teacher forcing. Cada quadro latente recebe seu próprio nível de ruído e só pode consultar os quadros limpos anteriores a ele. 20.000 etapas. Isso produz um teacher causal. Etapa dois: destilação de consistência causal. Um teacher congelado, um student online e uma cópia média do student trabalham em uma grade de 48 níveis de ruído. Depois de 5.000 etapas, o student consegue gerar um trecho em quatro etapas.

09:18 Etapa três: correspondência de distribuição, da família DMD. Agora, o student aprende com as próprias sequências geradas e acaba removendo o ruído de cada trecho em duas etapas, e do primeiro quadro gerado em quatro. Um detalhe prático de que gostei: o sistema implantado usa um decoder minúsculo. Então, durante essa etapa, o student vê a versão do controle do decoder minúsculo em 80% das vezes. Eles treinam para a configuração que realmente vão implantar. Mesmo um modelo de duas etapas não é automaticamente rápido. Trechos curtos significam que o modelo é chamado com muita frequência e, com apenas uma etapa de remoção de ruído, cada chamada faz

09:49 tão poucas operações que a GPU passa boa parte do tempo esperando a CPU iniciar os kernels. Assim, a segunda metade deste artigo é basicamente uma história sobre velocidade. A Tabela 2 é minha parte favorita. Ela é cumulativa. Cada linha acrescenta uma coisa. Começamos com o modelo causal 1D, com quatro etapas e o decoder completo. 4,5 quadros por segundo, 1.110 ms de latência. Trocar pelo decoder minúsculo TAEHV: 6,5 FPS, 867 ms. Adicionar um kernel de posição rotatória personalizado e armazenar em cache as chaves de texto: 15,4 FPS e 551 ms.

10:23 Em seguida, pesos de 8 bits mais um CUDA graph, que registra o transformer inteiro uma vez e o reproduz em um único lançamento: 24,2 FPS, 466 ms. Depois, destilação em uma etapa: 51,2 FPS, 376 ms. Depois, entrada e saída assíncronas: 57,7 FPS, 367 ms. Então vem o grande salto na latência: kernels Triton fundidos elevam o resultado para 65,8 FPS, e a latência cai de 367 para 121 ms. Um buffer circular para o cache key-value, de modo que o quadro mais recente

10:55 sobrescreva a posição mais antiga em vez de copiar a janela inteira, resulta em 73,7 FPS; e a atenção key-value dividida, que separa a janela em sete intervalos e combina os resultados parciais, chega a 83,4 FPS e 112 ms. No total, 19 vezes mais rápido e latência 9,9 vezes menor, de 1.110 ms para 112. Em uma etapa, remove o ruído de um trecho de quatro quadros em 48 ms, com cerca de 18,2 GB de memória de pico, com o codificador de texto, o transformer e o decoder todos na

11:27 mesma placa. Duas etapas dão cerca de 57 FPS. E há números para placas menores, com prompts fixos e uma etapa: cerca de 67 FPS em uma RTX 5080 e 58 em uma 5070 Ti, usando cerca de 12,8 e 10,9 GB. As novidades do repo dizem que essas otimizações foram incorporadas em 16 de outubro. Repare, porém, na condição dos prompts fixos: o caminho de legendas dinâmicas tem um custo. Como isso se compara aos outros? A Tabela 3 compara quatro sistemas recentes que também renderizam mundos definidos por código com modelos de vídeo.

11:58 O Code World Model: streaming em 10,2 segundos em uma H200, com memória de pico acima de 100 GB; o Stream Render H3: 517 milissegundos, mas em 8 GPUs H200. Agent Garden: 878 milissegundos em uma H100; Magpie: 1,55 segundo em uma H100; e Matrix game 4.0: 112 milissegundos em uma RTX 5090. Uma única GPU de consumo com 32 GB; o artigo diz que isso é cerca de um quinto do tempo do próximo sistema e que é o único que roda

12:28 em uma placa de consumo. Duas ressalvas da minha parte. Primeiro, esses números foram compilados pelos autores a partir dos relatórios de cada projeto, e a própria legenda da tabela explica como cada latência é calculada; portanto, não são uma comparação direta controlada. Segundo, as resoluções diferem. Matrix game está em 480p, e alguns dos outros ainda estão em 768p. A diferença de uma ordem de grandeza é suficientemente real para merecer atenção. Agora, a parte pela qual você veio: os resultados. A página do projeto tem uma galeria, com um clipe não usado no treinamento por jogo, de 15 segundos cada: castelo,

12:58 pirâmide, corrida e combate aéreo. À esquerda do divisor está o quadro gerado; à direita, o proxy low poly do mecanismo do jogo. Veja o que o modelo acrescenta que não está no proxy. No castelo, blocos planos viram muralhas de pedra desgastadas; faíscas e fumaça aparecem quando algo é atingido. No deserto, as caixas viram edifícios de arenito, telhados de palha e palmeiras. Na corrida, uma cidade de prismas cinza vira fachadas, reflexos de vidro na estrada, e o personagem mantém a mesma aparência do primeiro trecho ao último. O relatório mostra sequências de 40 segundos, 961

13:30 quadros a 24 FPS, que começam com o primeiro quadro real e depois seguem totalmente de forma autorregressiva. A Figura 7 os mostra em 1, 11, 21 e 31 segundos. O layout do proxy se mantém, a câmera segue o mesmo caminho e a aparência permanece estável. Essa é a alegação, e os quadros da figura dão respaldo a ela. A página também tem sessões longas de jogo, sessões contínuas de 54 segundos a um minuto e 39 segundos, mostradas com a interface do jogo e as teclas pressionadas, além do áudio do jogo. Aqui está a do castelo, depois a da pirâmide. Enquanto assiste, preste

14:00 atenção às bordas. O que acontece quando a câmera vira rapidamente, e o que acontece quando muitas coisas explodem? Vou ser honesto sobre o que vejo. São clipes selecionados na própria página dos autores, dos jogos com que treinaram. Impressionam, a estrutura acompanha o proxy, e não vejo o derretimento típico das sequências longas sem condicionamento. Mas uma página selecionada é uma página selecionada. O teste real é jogar com teclado, e eu não fiz isso. Aqui está a de corrida. Repare como a estrada, os edifícios e o trânsito

14:30 permanecem no lugar enquanto o carro se move rápido. É o proxy do mecanismo do jogo fazendo seu trabalho. Um modelo de vídeo puro teria que inventar uma rua consistente em tempo real, sem nada mantendo a rua no lugar. E o combate aéreo, a quarta cena, está na galeria e na tabela de dados do relatório, mas repare que não está entre os três jogos cujos pesos foram disponibilizados. O lançamento inclui castelo, Egito e corrida urbana. Voltarei a isso. Agora, o recurso que, na minha opinião, vende a ideia toda. Como as regras ficam no código, o agent de programação pode alterá-las, e

15:01 o modelo de vídeo simplesmente continua renderizando o que quer que o mecanismo do jogo produza. A Figura 8 mostra três modos criados dessa forma. No jogo de tiro, o pedido foi adicionar um escudo que se quebra ao atingir seu limite de durabilidade. O agent adicionou controle de saúde e munição, durabilidade do escudo, uma espingarda com maior cadência de tiro, uma condição de fim de jogo quando a saúde chega a zero e efeitos sonoros simples. No jogo de direção, adicionar pontos de controle na estrada e penalidades por colisão. Criar uma corrida contra o relógio com pontos de controle, penalidades e derrapagens. No mesmo jogo de direção, transformar o modo em uma perseguição: o jogador precisa

15:32 interceptar um veículo-alvo e ficar perto dele por 5 segundos. O relatório diz que o mecanismo do jogo avalia cada regra e o modelo de vídeo renderiza cada quadro a partir da saída do mecanismo. Um jogo de tiro em que todos lutam sozinhos poderia virar uma batalha em equipe; uma corrida contra o relógio poderia virar polícia e ladrão. Gosto disso porque muda quem pode criar protótipos: descrever uma regra em uma frase é muito mais barato do que criar manualmente um novo conjunto de recursos visuais para ela. Os autores também dizem claramente que este é um mecanismo leve e que os jogos são leves. É uma prévia de um workflow, não um substituto para um grande estúdio.

16:04 pipeline. Você consegue executá-lo? Vamos dar uma olhada no repo de verdade: Matrix game no GitHub, da Skywork AI, com a pasta V4 contendo inference, uma demonstração no navegador e o código-fonte do jogo. Os weights e os assets dos jogos Medieval Castle, Ancient Egypt e City Racing estão no Hugging Face. Quando olhei, o repo tinha cerca de 2.700 stars e 286 forks. Uma observação sobre a licença, porque o repo é um pouco confuso: o readme do V4 diz Apache 2.0 e aponta para o arquivo de licença do V4. As versões mais antigas

16:34 1, 2 e 3 continuam sob a licença MIT na raiz do repo. Componentes e assets de terceiros mantêm suas próprias licenças, então confira antes de lançar qualquer coisa. O readme lista opções de inference com uma única GPU para uma A100, RTX 5090, RTX 5080 e RTX 5070 TI. A opção para a 5090 inclui camadas lineares FP8, kernels fundidos, CUDA graphs e um back end Sage attention opcional. Há tanto renderização offline quanto uma demonstração online no navegador. Então, eu testei? Não. Meu laptop aqui tem uma RTX 4060 com 8 GB de

17:05 memória, e o relatório aponta um pico de uso de 18,2 GB, sem contar mais nada. Não vai caber. Eu poderia ter alugado uma 5090 na RunPod, mas um teste justo exige que a opção otimizada, os weights e os assets do jogo estejam configurados corretamente, e não queria apresentar um resultado malfeito. Tudo o que vocês viram hoje é material do autor, e deixei isso claro. Se quiser experimentar a opção otimizada, você precisa do hardware indicado no readme. Caso contrário, encare a tabela de velocidade do relatório pelo que ela é: uma medição do fornecedor, cuidadosamente descrita, feita em uma única 5090 com uma

17:37 configuração que consigo ler e que você pode conferir. Quais são as limitações? Os próprios autores as listam, então vamos começar por aí. No curto prazo, eles querem reduzir o custo de inference e os requisitos de hardware, com o objetivo de lançar uma prévia técnica no Steam. Dizem que ainda querem melhorar a fidelidade visual, adicionar uma etapa de refinamento para resolução mais alta, incluir multiplayer com visões consistentes entre os jogadores e oferecer um controle mais preciso sobre os visuais gerados. Pelo que entendi, estas são as limitações reais. A saída é em 480p. Há um modelo por jogo, então um mundo novo exige novos pares de dados e um novo fine-tune.

18:08 Os dados vieram de assets do Unreal Engine 5, então criar novas cenas exige trabalho real de captura. Os jogos lançados são três, e combate aéreo não está entre eles. E os números de velocidade vêm com condições. 83 FPS correspondem a uma etapa de denoising em uma 5090, em regime estável. A configuração avaliada por eles é de gameplay a 60 FPS com 112 milissegundos. Os resultados de 67 e 58 nas placas menores usam prompts fixos. Nada disso está escondido. Está tudo no relatório, mas vale a pena ler as notas de rodapé antes de repetir uma manchete. Então, qual é a minha opinião? Acho que a última

18:39 coisa que fiz aqui não é o recorde de velocidade. É a divisão do trabalho: código para as regras, engine para o estado, modelo de vídeo para os pixels. Cada parte faz aquilo em que realmente é boa, e não se pede ao modelo de vídeo que seja um engine de física. Se isso funcionar na prática, também diz algo sobre o rumo que os jogos generativos podem tomar primeiro. Não como um único modelo que imagina um jogo inteiro, mas como um renderizador neural sobre um engine barato, com um coding agent que reescreve as regras quando você pede. Esse é um caminho muito mais plausível para chegar a algo que as pessoas possam desenvolver. Está

19:10 pronto? Obviamente, não. É um relatório técnico com código aberto, weights para três jogos e algumas imagens muito bonitas. O que eu gostaria de ver agora são testes independentes, cenas de outras pessoas e o que acontece quando o proxy é rudimentar ou está errado. Se você procura GPUs baratas e confiáveis, eu uso a RunPod, e o link está na descrição. Se quiser que eu alugue uma 5090 e teste isso direito, conte nos comentários e diga qual dos três jogos gostaria de ver primeiro: Castle, Egypt ou Racing. Os links para a página do projeto, o relatório, o repo,

19:42 e o Hugging Face estão na descrição. Obrigado por assistir e até a próxima.

Transcrição original

[00:00] Look at the left half of this frame. Real stone walls, palm trees, smoke, and textured character. Now, look at the right half. Gray checkerboard floor, flat colored boxes, a character made of blocks. It is the same game, the same frame. And according to the authors, a video model painted the left side from the right side in real time. This is Matrix Game 4.0 from Skywork AI. The headline claim is a playable game world at 480p, 60 frames per second on one RTX 5090 with 112 milliseconds from key

[00:31] press to the first frame that reacts. That is the paper’s own number. I have not reproduced it, and I will tell you exactly why later in the video. What I can do is go through the project page, the repo, and the technical report with you line by line and explain what is actually new here because the interesting part is not that a video model draws pretty pictures. The interesting part is what they refuse to let the video model do. >> [music] >> Let’s start with the problem. A lot of the recent interactive world models, the

[01:02] Genie style ones, work like this. You press a key, the model predicts the next chunk of pixels, and the pixels become the world. There is no game underneath. The video is the game. The report lists four things that go wrong with that. One, nothing corrects the model from outside, so the world state only exists implicitly inside generated pixels. Once a chest leaves the screen, nobody is keeping track of it. Two, small errors pile up. Each new chunk is conditioned on the last one, so a slightly wrong wall becomes a very wrong wall a minute

[01:33] later. Three, memory is just old frames, so the cost grows with how long you play. And four, the mechanics stay thin. You can walk around, but health, ammunition, quest progress, a shield that breaks, those are hard to enforce when the rules have to be guessed from pictures. The authors say something I like here. They argue that today’s video generators are not really world models. Much of the apparent intelligence comes from the text encoder or the language model upstream and the diffusion part acts more like a renderer. So, their answer is let it be a renderer, only a

[02:03] renderer. So, here’s the design, three parts, a game engine, a multimodal coding agent, and a video generation model. The report gives each one a job title and honestly the titles are the clearest way to remember it. The engine is the referee, the coding agent is the script writer and translator, the video model is the painter. The referee first, the game engine keeps the real estate of the world. Health, inventory, gravity, collisions, quest progress, all of it lives in code and is enforced in code. It does not draw anything fancy. It

[02:34] draws what the paper calls a low-poly proxy boxes for buildings, a cylinder with a sphere for a tree, a figure made of blocks for a character, black outlines, no texture, no shadow, black sky, gray checkerboard ground. And here’s why that matters. If an enemy walks out of view, the engine still knows where it is. If you shoot an oil barrel, the engine decides whether the shot hits and whether it explodes. The video model never has to remember or decide any of that. It just gets handed a picture of the consequences. Now, the

[03:04] script writer, the coding agent works in two directions. Downstream it translates the engine says, “There is a box here with this object ID.” And the agent turns that into words, like an old thatched cottage weathered by sea winds with a dark red wooden door. Upstream it writes, “You tell it make monster swarm in from all directions.” And it edits the scene configuration and the game code including where they spawn, how they move and attack, and what counts as winning. If you leave details open, it improvises. The paper’s example, a player opens a door that has nothing

[03:35] behind it yet. The agent imagines a storage room with a locked iron chest in the corner, registers it in the engine, and from that moment the engine owns that chest. It can be opened or not, by the rules, not by the vibes. Then the painter, the video model takes the proxy frame, the current text description, a few reference frames, and a first frame, and turns them into materials, lighting, and atmosphere. The whole loop is player input, engine updates the world, proxy and control signals come out, the video model renders, and the player sees the result.

[04:08] Code owns the rules, the video model owns the look. How do you teach a model to do that? With paired data. The team captured everything in Unreal Engine 5, and every clip is recorded twice from the same camera at the same frame index. As the low poly structure render, once as the full high fidelity picture. So, the two videos line up pixel by pixel. Table one in the report lists these scenes: Medieval Castle, a third-person shooter, 17,848 training clips. Ancient Egypt desert, also a shooter, 40,296.

[04:41] Desert canyon air combat, 28,720. And a city sample, megacity for driving, 27,470. Total, 100 14,334 clips, 1,712 hours. They also hold out whole capture sessions that never touch training, three sessions each for castle, desert, and city, and entire capture batches for air combat. So, the clips you see in the results were not seen in training. Worth saying clearly, because it is the first thing I would check. One more design choice, they

[05:11] train one rendering model per game, not one giant model for every world. A castle shooter model, a desert shooter model, a city driving model, each fine-tuned on its own data. Keep that in mind when you think about how general this is. The second ingredient is what they call dynamic captions. In a game, the picture changes with every action you turn the camera and different objects are visible. You trigger something and an object changes state. A single fixed prompt cannot follow that. So, every object in the scene has an ID linked to a description. Each frame, the system

[05:42] reads which objects are visible, their states, and their distances from the engine, and fills the template. No vision language model involved. The paper stresses this rule-based no VLM. Look at the example from the city driving clip. Frame four lists parked minivans four and 10 m away, pedestrian standing 30 m off. By frame 53, the pedestrians are walking and getting closer. And a dark gray building comes into view. By frame 155, a trash bag and a street lamp enter. The text changes with the world. The proxy and the

[06:12] caption split the work. The proxy supplies structure, where things are, how they move. The caption supplies meaning, what each thing is and what it is doing. Together, they pin the model down from both sides. And you can watch this on the project page. There’s a prompt panel for a 40-second pyramid run, 12 segments, one every 80 frames. It shows a scene summary with the player’s state, enemies, and landmarks around, and the events in that segment written by the harness. Player action, enemy action, hit, explosion, enemy defeated, things entering and leaving

[06:43] view. All color-coded. Now, the painter itself. It starts from 12.2, the 5 billion parameter model in its fun control variant, and turns it into a video-to-video model. Four things condition each chunk. The low-poly proxy concatenated with the latent being generated, the dynamic caption, spatial memory reference frames, and the first frame which connects the new video to what is already on screen. The numbers, if you like architecture, 30 transformer blocks with 3,072, 24 attention heads,

[07:14] one latent frame is four video frames and at 480 by 864, that is 405 tokens per latent frame. The text encoder is UMT5XXL, and the captions, keys, and values are cached and only recomputed when the caption changes. The part that makes it a game rather than a movie is the cache. Each new chunk attends to three kinds of memory, up to three spatial memory frames retrieved by camera pose, the reference frames, and a sliding window of the latest 20 chunks. After a chunk is generated, the model runs once more

[07:45] on the finished result with a control input removed and writes that clean version into the cache. So, later chunks look back at clean history, not at their own noisy drafts. That special memory is how it copes with going back to a place. Candidates are picked from frames at least 40 frames earlier, keeping ones whose view overlaps, and choosing the closest by camera pose. It is not a perfect memory, and the engine is what really holds the layout, but it keeps the look consistent when you return. Training happens in two big phases.

[08:15] First, supervised fine-tuning. The model learns as a bidirectional video-to-video model on 81-frame windows at 704 by 1280, using 64 GPUs, a learning rate of 10 to the minus five, 4,000 steps. To support guidance and generation without a first frame, they randomly drop the first frame 30% of the time, the prompt 20%, and the proxy control 20%. Then comes the part that makes real-time possible. A bidirectional model sees the whole clip at once. A game cannot do that because the future has not happened yet, so they distill it into a causal

[08:47] generator following a method called causal forcing plus plus in three stages. Stage one, teacher-forced autoregressive diffusion. Each latent frame gets its own noise level and can only look at clean frames before it. 20,000 steps. That gives a causal teacher. Stage two, causal consistency distillation. A frozen teacher, an online student, and an average copy of the student working on a grid of 48 noise levels. After 5,000 steps, the student can make a chunk in four steps.

[09:18] Stage three, distribution matching, the DMD family. Now, the student learns from its own rollouts and ends up denoising each chunk in two steps, and the very first generated frame in four. One practical detail I liked, the deployed system uses a tiny decoder. So, during this stage, the student sees the tiny decoder version of the control 80% of the time. They train for the setting they will actually deploy. Even a two-step model is not automatically fast. Short chunks mean the model is called very often, and with only one denoising step, each call does

[09:49] so little arithmetic that the GPU spends much of its time waiting for the CPU to launch kernels. So, the second half of this paper is basically a speed story. Table two is my favorite part. It is cumulative. Every row adds one thing. Start the causal 1D it with four steps and the full 1 decoder. 4.5 frames per second, 1,110 ms of latency. Swap in the tiny decoder TAEHV 6.5 FPS, 867 ms. Add a custom rotary position kernel and cache text keys, 15.4 FPS and 551 ms.

[10:23] Next, 8-bit weights plus a CUDA graph which records the whole transformer once and replays it in a single launch, 24.2 FPS, 466 ms. Then one-step distillation, 51.2 FPS, 376 ms. Then asynchronous input and output, 57.7 FPS, 367. Then the big latency cliff, fused Triton kernels take it to 65.8 FPS, and latency drops from 367 to 121 ms. A ring buffer for the key value cache, so the newest

[10:55] frame overwrites the oldest slot instead of copying the whole window, gives 73.7 FPS, and split key value attention, which cuts the window into seven ranges and merges the partial results, lands at 83.4 FPS and 112 ms. Overall, 19 times faster and 9.9 times lower latency from 1,110 ms down to 112. At one step, it denoises a four-frame chunk in 48 ms with about 18.2 GB of peak memory, text encoder, transformer, and decoder all on

[11:27] the same card. Two steps gives roughly 57 FPS. And there are smaller card numbers with fixed prompts and one step about 67 FPS on an RTX 5080 and 58 on a 5070 Ti using around 12.8 and 10.9 GB. The repo news says those optimizations landed on October 16th. Notice that fixed prompts condition though, the dynamic caption path costs something. How does it stack up? Table three compares four recent systems that also render code defined worlds with video

[11:58] models, code world model streaming 10.2 seconds on 1 H 200 with peak memory above 100 GB stream render H3 517 milliseconds, but on 8 GB 200 GPUs. Agent Garden 878 milliseconds on 1 H 100, Magpie 1.55 seconds on 1 H 100, and Matrix game 4.0 112 milliseconds on 1 RTX 5090. A single consumer GPU with 32 GB, the paper calls that about 1/5 of the next system and the only one running

[12:28] on a consumer card. Two cautions from me. First, these are numbers the authors compiled from each project’s own reports and the table’s own caption explains the way each latency is computed, so they are not a controlled head-to-head. Second, resolutions differ. Matrix game is at 480p, some of the others are at 768p still. The order of magnitude gap is real enough to be worth noticing. Now, the part you came for, results. The project page has a gallery, one held out clip per game, 15 seconds each. Castle,

[12:58] pyramid, racing, and air combat. Left of the divider is the generated frame, right as the engine’s low poly proxy. Watch what the model adds that the proxy does not contain. In the castle, flat blocks become stone walls with weathering, sparks and smoke show up when something is hit. In the desert, the boxes become sandstone buildings, thatched roofs, and palm trees. In racing, a city of gray prisms becomes facades, glass reflections on the road, and the character keeps the same look from the first chunk to the last. The report runs 40-second rollouts, 961

[13:30] frames at 24 FPS that start from the real first frame and then go fully auto aggressive. Figure 7 shows them at 1:11, 21, and 31 seconds. The layout of the proxy holds, the camera follows the same path, and the look stays stable. That is the claim, and the frames in the figure do support it. The page also has long play sessions, continuous sessions from 54 seconds to a minute 39, shown with the game HUD and the key presses, and with game audio. Here is the castle one, then the pyramid. As you watch, pay

[14:00] attention to the edges. What happens when the camera turns quickly, and what happens when a lot of things explode. I will be honest about what I see. These are curated clips on the author’s own page from the games they trained on. They look impressive, the structure follows the proxy, and I do not see the usual melting you get from long unconditional rollouts. But a curated page is a curated page. The real test is hands-on a keyboard, and I have not done that. Here is the racing one. Notice how the road, the buildings, and the traffic

[14:30] stay put while the car moves fast. That is the engine’s proxy doing its job. A pure video model would have to invent a consistent street in real time with nothing holding the street in place. And air combat, the fourth scene, it is in the gallery and in the report’s data table, but notice it is not among the three games that have released weights. The release has castle, Egypt, and city racing. I will come back to that. Now, the feature that I think sells the whole idea. Because the rules live in code, the coding agent can change them, and

[15:01] the video model just keeps rendering whatever the engine outputs. Figure 8 shows three modes built that way. In the shooter, the request was add a shield that breaks at its durability limit. The agent added health and ammunition control, shield durability, a shotgun with a higher fire rate, a game over condition at zero health, and simple sound effects. In the driving game, add road checkpoints and collision penalties. Give a time trial with checkpoints, penalties, and drifting. In the same driving game, turn into a pursuit mode, the player has to

[15:32] intercept a target vehicle and stay close for 5 seconds. The report says the engine evaluates every rule and the video model renders each frame from the engine output. A shooter where everyone fights alone could become a team battle, a time trial could become cops and robbers. I like this because it changes who can prototype describing a rule in a sentence is much cheaper than hand-building a new art pass for it. The authors also say plainly that this is a lightweight engine and lightweight games. It is a preview of a workflow, not a replacement for a big studio

[16:04] pipeline. Can you run it? Let’s look at the actual repo, Matrix game on GitHub from Skywork AI with the V4 folder holding inference, a browser demo, and the game source code. Weights and game assets for Medieval Castle, Ancient Egypt, and City Racing are on Hugging Face. At the time I looked, the repo had about 2,700 stars and 286 forks. One licensing note, because the repo is slightly confusing, the V4 readme says Apache 2.0 and points to the V4 license file. The older

[16:34] versions 1, 2, and 3 stay under the MIT license in the repo root. Third-party components and assets keep their own licenses, so check before you ship anything. The readme lists single GPU inference paths for a 100, RTX 5090, RTX 5080, and RTX 5070 TI. The 5090 path includes FP8 linear layers, fused kernels, CUDA graphs, and an optional Sage attention back end. Offline rendering and an online browser demo are both there. So, did I test it? No. My laptop here has an RTX 4060 with 8 GB of

[17:05] memory, and the report puts peak usage at 18.2 GB before you count anything else. It will not fit. I could have rented a 5090 on RunPod, but a fair test needs the optimized path, the weights, and the game assets configured properly, and I did not want to hand you a half-baked result. Everything you saw today is the author’s footage, and I have labeled it that way. If you do want to try the optimized path, you need the hardware the readme names. Otherwise, treat the report’s speed table as what it is, a vendor measurement carefully described on a single 5090 with a

[17:37] setting I can read and you can check. What are the limits? The authors list them themselves, so let’s start there. In the near-term, they want to reduce inference cost and hardware requirements with the goal of a technical preview on Steam. They say they still want better visual fidelity, a refinement stage for higher resolution, multiplayer with consistent views across players, and more precise control over generated visuals. From my reading, here are the real constraints. The output is 480p. It is one model per game, so a new world means new pair data and a new fine-tune.

[18:08] The data came from Unreal Engine 5 assets, so new scenes cost real capture work. The released games are three, and air combat is not among them. And the speed numbers come with conditions. 83 FPS is one denoising step on a 5090 steady state. 60 FPS gameplay with 112 milliseconds is their evaluated configuration. The 67 and 58 on smaller cards use fixed prompts. None of that is hidden. It is all in the report, but it is worth reading the footnotes before you repeat a headline. So, what is my take? I think the last

[18:39] thing I did here is not the speed record. It is the division of labor, code for rules, engine for state, video model for pixels. Each part does the thing it is actually good at, and the video model is never asked to be a physics engine. If that holds up in the wild, it also says something about where generative games might go first. Not as a single model dreaming an entire game, but as a neural renderer sitting on top of a cheap engine with a coding agent that rewrites the rules when you ask. That is a much more believable path to something people can build on. Is it

[19:10] finished? Obviously not. It is a technical report with open code weights for three games and some very nice footage. What I would want to see next is independent testing, other people’s scenes, and what happens when the proxy is rough or wrong. If you’re looking for cheap and reliable GPUs, I use RunPod, and the link is in the description. If you want me to rent a 5090 and try this properly, tell me in the comments, and tell me which of the three games you would want to see first: Castle, Egypt, or Racing. The links to the project page, the report, the repo,

[19:42] and Hugging Face are in the description. Thanks for watching, and I will see you in the next one.