DeepSeek V4: como otimizar a geração de jogos com IA gastando menos

Modelos acessíveis conseguem criar jogos de navegador que as pessoas realmente queiram jogar? Na última semana, testamos essa questão no OpenGame Studio. A novidade mais recente é o DeepSeek-V4.1-Flash-1017, lançado em 17 de outubro, da família DeepSeek V4.

Também testamos Grok 4.6, Xiaomi MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash e Claude Haiku 5.5. O objetivo era equilibrar melhor custo de geração, tempo de espera, comportamento jogável e qualidade visual. Um jogo que abre sem erros ainda pode se mover para a direita quando o jogador aperta esquerda, dar moedas antes da hora ou continuar caindo durante a pausa.

O runner mais recente do DeepSeek passou pelas verificações principais de jogabilidade que fizemos. Sua arte era modesta. Experimentos anteriores revelaram outros problemas, incluindo uma falha na nossa própria validação de entrega. Esses detalhes ajudam mais uma pessoa que cria jogos do que uma classificação de modelos sem explicação.

O runner original do DeepSeek-V4.1-Flash-1017. É possível distinguir o personagem, as pistas e as moedas; o ambiente continua sendo um protótipo básico.

Otimizando a geração acessível de jogos

Para quem cria jogos pequenos, repetir experimentos importa. Uma primeira versão pode precisar de mais uma tentativa na câmera, nos controles, nas regras de colisão ou na direção artística. A pergunta prática é quanto jogo útil e testável obtemos desse processo.

Um modelo topo de linha e potente como Claude Opus 5.5 é uma alternativa óbvia para tarefas exigentes de programação. A descrição oficial também aborda o uso de subagentes. Queríamos explorar uma lista menor e mais acessível antes de escolher um fluxo de trabalho maior. O nome do modelo, por si só, não garante um bom jogo; usar vários agentes é uma escolha de fluxo de trabalho que pode acrescentar trabalho e consumo.

Nossa seleção tinha funções variadas:

• Grok 4.6 serviu como referência de uso geral. Para nós, foi uma opção menos focada em economia, com acesso por assinatura entre seus atrativos. A página oficial de lançamento descreve acesso para programação pelo Grok Build e outras ferramentas.
• Xiaomi MiMo V2.6 Flash e Pro permitiram comparar duas opções da mesma família. A Xiaomi posiciona o Flash para uso eficiente e frequente e o Pro para raciocínio e projetos mais exigentes. Pro é o modelo topo de linha da própria família; ainda assim, foi um candidato na nossa exploração de opções econômicas.
• GLM 5.3 Flash ofereceu outra opção focada em eficiência. A apresentação oficial explica esse posicionamento. Queríamos observar como lidaria com o pedido completo do jogo.
• Claude Haiku 5.5 acrescentou uma opção internacional com custo em foco. A Anthropic descreve Haiku como adequado para trabalho rápido e em grande volume. Testamos seu uso para criar um jogo, com uma análise limitada detalhada abaixo.
• DeepSeek-V4.1-Flash-1017 foi o experimento mais recente. O anúncio de lançamento inclui demonstrações de projetos. Usamos nosso próprio pedido de runner para ver o que funcionaria no OpenGame Studio.

Há mais famílias de modelos chineses nesta seleção porque o custo acessível levou várias delas à nossa lista. Isso reflete nosso processo de escolha, não uma conclusão sobre a qualidade dos modelos por país.

Um runner, seis experimentos com modelos

Nosso jogo compartilhado foi Colossal Runner, um runner interminável original em terceira pessoa com três pistas. O personagem avança automaticamente. O jogador troca de pista, pula barreiras, desliza por baixo de obstáculos suspensos, coleta moedas e recomeça após uma colisão. Teclado e toque devem produzir o mesmo resultado visível.

O pedido original também incluía pausa, revives comprados com moedas coletadas e um obstáculo gigante que bloqueia duas pistas, deixando uma rota segura. Essa interação entre regras revela mais do que uma cena em movimento com um contador de pontos.

Reutilizamos o mesmo pedido original nestes experimentos, de 11 a 17 de outubro de 2026:

São experimentos individuais conduzidos por desenvolvedores. Eles permitem uma comparação prática, mas têm limites claros: cada modelo gerou seu próprio resumo e implementação, com escolhas visuais diferentes. Os testes ocorreram em datas diferentes e o ambiente do site não ficou congelado. O MiMo Flash precisou de outra conversa antes da geração. Os tempos não incluem conversa, elaboração da especificação nem teste de jogo; o número do GLM termina na rejeição.

Para o runner do DeepSeek, mantivemos as restrições de geração existentes e as mesmas instruções para o criador de jogos 3D usadas nos experimentos do MiMo. Nenhum reparo manual do código-fonte precedeu as verificações de aceitação. Esta série não estabelece uma classificação de velocidade ou qualidade com validade estatística.

O que MiMo, GLM e Haiku acrescentaram à análise

MiMo Flash produziu um jogo que pudemos inspecionar, com controles úteis, inclusive verificações limitadas de teclado, toque e pausa. O problema estava nas moedas: elas podiam ser coletadas antes de o runner alcançá-las. O código lia o campo de posição errado durante a verificação de coleta. Uma cena convincente e um contador crescente haviam escondido uma interação quebrada.

Resultado original do MiMo Flash, antes de reparos posteriores selecionados. O defeito no tempo de coleta veio de verificações da jogabilidade e do código; este quadro, sozinho, não o comprova.

MiMo Pro também entregou um protótipo jogável, e as verificações de direção e contato com moedas foram promissoras. Pausar no meio do salto revelou outro defeito. A distância e as moedas pararam, mas o personagem continuou caindo. Uma pausa completa precisa congelar a simulação relevante, incluindo o movimento vertical.

Cena urbana original do MiMo Pro. O defeito na pausa exigia um teste durante um salto, algo que uma imagem estática atraente não revelaria.

O GLM exige duas constatações separadas. A execução no Studio falhou na entrega porque nosso validador interpretou código de jogo em linha como marcação de recurso proibida. Foi um erro da plataforma. Seria enganoso contar isso como evidência de que o GLM não conseguiu gerar o jogo.

Recuperamos o original inalterado e o inspecionamos separadamente. Naquela inspeção, as verificações limitadas de direção, toque e pausa funcionaram, mas reiniciar podia manter um contador de moedas desatualizado. Essa inspeção nos informa sobre o comportamento do artefato; não transforma o fluxo de Studio que falhou numa entrega bem-sucedida.

Original recuperado do GLM sob inspeção separada. Esta imagem não é prova de uma entrega bem-sucedida pelo Studio.

Haiku 5.5 entregou a prévia relativamente rápido nesta amostra. A tela inicial apareceu, e encerramos o teste depois de uma primeira análise visual. Não concluímos a aceitação de teclado, toque, colisão, revive ou reinício. A primeira impressão não mudou nossa preferência pelos experimentos do MiMo, mas não temos evidências de jogabilidade para dar um veredito firme sobre Haiku.

Essa distinção importa ao manter um diário de testes: entregue, analisado visualmente e verificado em comportamento são etapas diferentes.

Por que esquerda pode virar direita?

O runner do Grok revelou a falha de controle mais evidente. Partindo da pista central, a seta para a esquerda movia o personagem para o lado direito da tela. Gestos para a esquerda faziam o mesmo.

Antes: o runner está no centro.

Depois de ArrowLeft: o runner está visivelmente à direita. Ambas as capturas mostram a versão gerada sem modificações.

O código explicava o problema: o manipulador movia o personagem em direção ao X negativo do mundo para indicar “esquerda”, mas a direção da câmera fazia o movimento parecer para a direita na tela. Teclado e toque usavam o mesmo controlador de pistas; portanto, ambos herdaram o erro.

Para o jogador, a referência é a pista visível. Diminuir uma coordenada não demonstra que o movimento foi para a esquerda na tela. Uma câmera que acompanha o personagem também precisa ser verificada em relação às pistas, já que o personagem pode permanecer centralizado na tela enquanto a pista se move.

Um experimento separado de corrida também revelou uma fraqueza na nossa avaliação. Um controlador automatizado conseguia compensar a direção invertida e terminar uma volta. Agora verificamos cada direção separadamente, a partir de uma nova partida. Concluir o percurso não havia validado os rótulos dos controles.

Como o DeepSeek V4 se saiu no teste do runner

O runner levou cerca de sete minutos para ser gerado após uma confirmação breve. Testamos o resultado original pela prévia no site:

• Direções: ArrowLeft, ArrowRight, A e D moveram o personagem para a pista visível correta. Comandos repetidos paravam na pista mais externa.
• Toque: gestos para a esquerda e para a direita funcionaram em emulação de tela vertical e horizontal. Para cima fazia o personagem pular; para baixo o fazia descer e deslizar.
• Obstáculos: o teste com teclado passou por uma barreira no chão, deslizou por baixo de uma barra suspensa e seguiu pela pista segura ao passar pelo bloqueador gigante.
• Moedas e revives: a coleta começava ao alcançar as moedas. Um revive gastava moedas acumuladas e retomava a partida com segurança; um revive sem saldo suficiente não gastava moedas nem uma tentativa.
• Pausa e reinício: pausar no meio do salto manteve estáveis a altura e a distância, bloqueando comandos da pista. Reiniciar restaurou a pista central, a distância e as moedas visíveis.

Uma sessão entre obstáculos continuou além de 216 metros com 51 moedas coletadas. A automação do navegador enviou comandos normais de jogo. Não alteramos coordenadas, pontuação nem estado de colisão para obter esse resultado.

Um gesto para a esquerda alcança a pista esquerda visível na emulação de navegador vertical. A compatibilidade com celulares físicos ainda não foi testada.

Não esgotamos todas as sequências aleatórias de obstáculos, rotas pelos tetos dos trens, limite de revives nem estados mais avançados. Dentro do escopo testado, o resultado foi um protótipo funcional, com tratamento promissor das regras.

Lógica, arte e legibilidade exigem avaliações separadas

O runner do DeepSeek deixou distinguíveis objetos importantes: personagem azul-esverdeado, bordas de pista brilhantes, moedas douradas e perigos contrastantes. O ambiente escuro e esparso, com prédios simples, ainda oferece bastante espaço para melhorias visuais. Esse resultado isolado não demonstra uma afirmação geral de que DeepSeek é melhor em lógica do que em arte.

Nosso experimento separado de Neon Harbor Sprint tinha um estilo neon forte, mas a silhueta do carro e a pista eram mais difíceis de ler. Uma revisão de desempenho reduziu a resolução de renderização, melhorando a resposta dos comandos e perdendo definição.

Um protótipo de corrida separado do DeepSeek. Usou um pedido diferente e está fora da comparação do runner compartilhado.

Voltamos ao runner porque outro jogo atrapalharia a comparação. O jogo de corrida ainda ofereceu uma lição útil: avalie personagem, perigos e limites das pistas no tamanho real de jogo e com a ação em andamento. Efeitos e decoração da interface podem coexistir com baixa legibilidade.

Os prompts e as habilidades são restritivos demais?

Nosso pedido do runner foi deliberadamente detalhado para que pudéssemos reutilizá-lo. Um criador comum deveria poder começar com uma ideia bem mais curta. Ajudar a transformar essa ideia num resumo útil faz parte do trabalho do produto.

Não fizemos uma comparação controlada entre prompts curtos e detalhados. Portanto, o tamanho do prompt não explica sozinho os controles invertidos. O código com falha oferece uma explicação direta ligada à câmera e à entrada; outras versões geradas a partir do mesmo pedido acertaram as direções.

Algumas restrições protegem a experiência: controles consistentes, coleta de moedas por contato, uma pausa completa e um reinício limpo. Outras escolhas podem continuar abertas, como tema, paleta, apresentação da câmera e construção da cena pelo modelo. Um processo de geração rígido também pode deixar pouco espaço para inspecionar e melhorar a primeira implementação. Vale testar se mais oportunidades de revisão ajudam; neste caso, isso permanece uma hipótese.

As tentativas anteriores mostraram por que o fluxo de trabalho merece atenção. Uma tentativa do MiMo esgotou o limite de resposta antes de entregar um jogo. Outra escreveu código, mas perdeu a entrega final quando o fluxo do provedor falhou. Essas falhas tiveram causas diferentes e devem ser registradas separadamente dos defeitos de jogabilidade. Também impedem que tratemos toda tentativa histórica como um teste A/B exclusivamente de modelos.

Um criador poderia começar com:

Crie um runner 3D rápido com três pistas. Deixe-me desviar para a esquerda e para a direita, pular barreiras e deslizar por baixo de vigas, usando teclado ou toque. Quero um personagem fácil de ver, coletas de moedas satisfatórias e uma maneira rápida de recomeçar quando eu bater. Escolha o cenário e o estilo visual.

Esta é uma sugestão para começar, não o prompt original da comparação. O Studio pode esclarecer regras que faltam, confirmar o resumo e preservar espaço para escolhas criativas. Depois, um teste de jogo breve pode apontar a revisão mais útil.

O que esses testes mudam no nosso próximo experimento

Para nós, otimizar agora também inclui confiabilidade da entrega, tempo de inspeção e volume de reparos necessários em um resultado jogável. Uma geração barata é útil quando o resultado resiste a comandos comuns e pode melhorar por meio de um ciclo de revisão administrável.

Manteremos os resultados originais, registraremos a etapa alcançada por cada tentativa e compararemos teclado e toque com o comportamento visível. Uma comparação futura poderá manter o jogo fixo e mudar uma variável do fluxo de trabalho, como o tamanho do resumo ou as oportunidades de revisão. Essas observações, por si sós, não indicam qual modelo vencerá esse experimento.

Para ver um exemplo jogável, visite Colossal Runner. Suas versões públicas revisadas incluem correções posteriores e são separadas dos experimentos originais mostrados aqui. Você também pode explorar outros jogos de navegador para ter ideias da experiência que deseja criar.

Tem uma ideia pequena para um jogo? Comece um resumo no OpenGame Studio, combine o ciclo principal e teste a primeira versão com comandos reais.

Nota sobre as fontes

As fontes oficiais estabelecem os nomes dos modelos, o contexto de lançamento e o posicionamento dos fornecedores: lançamento do DeepSeek em 17 de outubro, Grok 4.6, MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5 e o exemplo de contexto não testado do modelo topo de linha Claude Opus 5.5.

As observações de jogabilidade e os tempos de geração vêm de nossos próprios experimentos no OpenGame Studio e dos originais mantidos. As oito imagens são capturas inalteradas dessas inspeções, com arte procedural original ou recursos de personagem M0 do OpenGame licenciados sob CC0-1.0. Nenhuma imagem é demonstração de provedor nem reconstrução aprimorada.