DeepSeek V4: cómo optimizar la generación de juegos con IA a bajo coste

¿Pueden los modelos asequibles crear juegos de navegador que la gente de verdad quiera jugar? Durante la última semana hemos estado probando esa pregunta en OpenGame Studio. La incorporación más reciente es DeepSeek-V4.1-Flash-1017, el lanzamiento del 17 de octubre de la familia DeepSeek V4.

También probamos Grok 4.6, Xiaomi MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash y Claude Haiku 5.5. El objetivo era mejorar el equilibrio entre el coste de generación, el tiempo de espera, el comportamiento jugable y la calidad visual. Un juego puede abrirse correctamente y aun así moverse a la derecha cuando el jugador pulsa izquierda, conceder monedas antes de tiempo o seguir cayendo mientras está en pausa.

El runner más reciente de DeepSeek superó las comprobaciones básicas de juego que realizamos. Su arte era sencillo. Experimentos anteriores revelaron otros problemas, incluido un fallo en nuestro propio proceso de validación de la entrega. Estos detalles son más útiles para quien crea juegos que una clasificación de modelos sin explicación.

Runner original de DeepSeek-V4.1-Flash-1017. El personaje, los carriles y las monedas se distinguen; el entorno sigue siendo el de un prototipo básico.

Cómo optimizar la generación asequible de juegos

Para quien crea juegos pequeños, poder repetir experimentos es importante. Puede que una primera versión necesite otro intento para ajustar la cámara, los controles, las reglas de colisión o la dirección artística. La pregunta práctica es cuánto contenido jugable y comprobable obtenemos con ese proceso.

Un modelo puntero y potente como Claude Opus 5.5 es una alternativa evidente para tareas de programación exigentes. Su descripción oficial también trata el trabajo con subagentes. Queríamos explorar una lista más asequible antes de elegir un flujo de trabajo más amplio. El nombre de un modelo no garantiza por sí solo un buen juego, y usar varios agentes es una decisión de flujo de trabajo que puede añadir trabajo y consumo.

Nuestra lista tenía distintas funciones:

• Grok 4.6 sirvió como referencia de propósito general. Para nosotros fue una opción menos centrada en el presupuesto, cuyo atractivo incluía el acceso por suscripción. La página oficial del lanzamiento describe el acceso a programación mediante Grok Build y otras herramientas.
• Xiaomi MiMo V2.6 Flash y Pro nos permitieron comparar dos opciones de la misma familia. Xiaomi presenta Flash como una opción para uso frecuente y eficiente y Pro como una opción para razonamiento y trabajo de proyectos más exigentes. Pro es un modelo insignia de su propia familia; aun así, lo incluimos en nuestra exploración de opciones económicas.
• GLM 5.3 Flash aportó otra opción centrada en la eficiencia. Su presentación oficial explica ese posicionamiento. Queríamos ver cómo abordaba la solicitud completa de un juego.
• Claude Haiku 5.5 añadió una opción internacional sensible al coste. Anthropic describe Haiku como modelo para tareas rápidas y de gran volumen. Lo probamos como creador de juegos con la revisión limitada que describimos más abajo.
• DeepSeek-V4.1-Flash-1017 fue el experimento más reciente. El anuncio del lanzamiento incluye demostraciones de proyectos. Usamos nuestra propia solicitud de runner para ver qué podía trasladarse a OpenGame Studio.

En esta lista hay más familias de modelos de China porque su precio asequible hizo que varias entraran en nuestra selección. Esto refleja nuestro proceso de selección, no una conclusión sobre la calidad de los modelos según su país.

Un runner, seis experimentos con modelos

El juego común fue Colossal Runner, un runner infinito original en tercera persona con tres carriles. El personaje avanza automáticamente. Los jugadores cambian de carril, saltan barreras, se deslizan bajo obstáculos elevados, recogen monedas y reinician tras una colisión. El teclado y los controles táctiles deberían producir el mismo resultado visible.

La solicitud original también incluía pausa, reanimaciones con monedas ganadas y un obstáculo gigante que bloquea dos carriles y deja una ruta segura. Estas reglas interactúan entre sí y permiten evaluar mejor el resultado que una escena en movimiento con un contador de puntos.

Reutilizamos la misma solicitud original en estos experimentos realizados entre el 11 y el 17 de octubre de 2026:

Son experimentos individuales realizados por el desarrollador. Ofrecen un caso práctico para comparar, con límites claros: cada modelo generó su propio documento de especificaciones y su implementación, incluidas decisiones visuales distintas. Las pruebas se hicieron en fechas diferentes y el entorno del sitio web no se mantuvo congelado. MiMo Flash necesitó otra conversación antes de generar el juego. Los tiempos excluyen la conversación, el trabajo de especificación y las pruebas de juego; la cifra de GLM termina con el rechazo.

Para el runner de DeepSeek, mantuvimos las restricciones de generación existentes y las mismas instrucciones del generador 3D que usamos en los experimentos con MiMo. No reparamos manualmente el código fuente antes de las comprobaciones de aceptación. Esta serie no establece una clasificación de velocidad o calidad con fiabilidad estadística.

Qué aportaron MiMo, GLM y Haiku a la comparación

MiMo Flash produjo un juego que pudimos inspeccionar y con controles útiles, incluidas comprobaciones acotadas del teclado, la pantalla táctil y la pausa. El problema estaba en las monedas: se podían conceder antes de que el runner llegara a ellas. El código consultaba el campo de posición equivocado al comprobar la recogida. Una escena convincente y un contador que aumentaba habían ocultado una interacción defectuosa.

Resultado original de MiMo Flash, antes de las reparaciones seleccionadas posteriores. El defecto del momento de recogida se detectó al comprobar el juego y su código; este fotograma por sí solo no lo demuestra.

MiMo Pro también entregó un prototipo jugable, y las comprobaciones de dirección y contacto con las monedas dieron buenos resultados. Poner el juego en pausa a mitad de un salto reveló otro defecto. La distancia y las monedas se detenían, pero el personaje seguía cayendo. Una pausa completa debe congelar la simulación pertinente, incluido el movimiento vertical.

Escena urbana original de MiMo Pro. El defecto de la pausa requirió probar el juego durante un salto, algo que una imagen estática atractiva no revelaría.

GLM requiere dos conclusiones separadas. La ejecución en Studio no pudo entregar el juego porque nuestro validador interpretó mal el código integrado del juego y lo identificó como marcado de recursos prohibido. Fue un error de la plataforma. Sería engañoso contar esto como prueba de que GLM no pudo generar el juego.

Recuperamos el original sin modificarlo y lo inspeccionamos por separado. Las comprobaciones acotadas de dirección, controles táctiles y pausa funcionaron; al reiniciar, el contador de monedas podía quedar desactualizado. Esa inspección nos informa sobre el comportamiento del artefacto, pero no convierte el flujo fallido de Studio en una entrega exitosa.

Original recuperado de GLM bajo una inspección separada. Esta imagen no demuestra que la entrega mediante Studio tuviera éxito.

Haiku 5.5 entregó su vista previa con relativa rapidez en esta muestra. Apareció la pantalla inicial y después terminamos la prueba tras una revisión visual inicial. No completamos las pruebas de aceptación del teclado, la pantalla táctil, las colisiones, la reanimación ni el reinicio. La impresión inicial no cambió nuestra preferencia por los experimentos con MiMo, pero nos faltan pruebas de juego para emitir un veredicto firme sobre la calidad de Haiku.

Esta distinción importa al llevar un registro de pruebas: entregar, revisar visualmente y verificar el comportamiento son hitos diferentes.

¿Por qué la izquierda puede convertirse en derecha?

El runner de Grok mostró el fallo de control más claro. Desde el carril central, la flecha izquierda movía al personaje al lado derecho de la pantalla. Los deslizamientos hacia la izquierda hacían lo mismo.

Antes: el runner está en el centro.

Después de pulsar ArrowLeft: el runner está claramente a la derecha. Ambas capturas muestran la versión generada sin modificar.

El código lo explicaba: al pulsar «izquierda», el controlador se movía hacia la coordenada X negativa del mundo, pero la orientación de la cámara hacía que ese movimiento pareciera hacia la derecha en pantalla. El teclado y la pantalla táctil compartían el controlador de carriles, así que ambos heredaban el error.

El punto de referencia del jugador es la pista visible. Que una coordenada disminuya no demuestra que el movimiento sea hacia la izquierda. También hay que comprobar al personaje con relación a los carriles cuando la cámara lo sigue, ya que puede mantenerse centrado en pantalla mientras la pista se desplaza.

Otro experimento de carreras mostró un punto débil de nuestra evaluación. Un controlador automatizado podía compensar la dirección invertida y terminar una vuelta. Ahora comprobamos cada dirección por separado desde un inicio nuevo. Terminar el circuito no había verificado las indicaciones de control.

Qué hizo DeepSeek V4 en nuestra prueba del runner

El runner más reciente tardó unos siete minutos en generarse después de una breve confirmación. Probamos el resultado original en la vista previa del sitio web:

• Direcciones: ArrowLeft, ArrowRight, A y D movieron al personaje hacia el carril visible correcto. Las pulsaciones repetidas se detenían al llegar al carril exterior.
• Controles táctiles: los deslizamientos a izquierda y derecha funcionaron en la emulación vertical y horizontal. Deslizar hacia arriba hizo saltar al personaje; deslizar hacia abajo lo hizo bajar y deslizarse.
• Obstáculos: durante el juego con teclado, se superó una barrera a ras de suelo, se pasó por debajo de una barra elevada y se tomó el carril seguro junto al gran obstáculo.
• Monedas y reanimaciones: la recogida comenzó al llegar a las monedas. Una reanimación gastó las monedas ganadas y permitió reanudar la partida de forma segura; una reanimación que no se podía pagar no gastó monedas ni un uso.
• Pausa y reinicio: al poner en pausa el juego a mitad de un salto, la altura y la distancia se mantuvieron estables y se bloquearon los controles de la pista. Al reiniciar, se restablecieron el carril central, la distancia y las monedas visibles.

Una partida con obstáculos continuó más allá de 216 metros y recogió 51 monedas. La automatización del navegador envió controles normales del juego. No alteramos las coordenadas, la puntuación ni el estado de colisión para obtener ese resultado.

Un deslizamiento a la izquierda lleva al carril izquierdo visible en la emulación vertical del navegador. Aún no se ha comprobado la compatibilidad con teléfonos físicos.

No agotamos todas las secuencias aleatorias de obstáculos, rutas por los techos de trenes, límites de reanimación ni estados de las fases avanzadas. Dentro del alcance probado, era un prototipo funcional que gestionaba bien las reglas.

La lógica, el arte y la legibilidad requieren evaluaciones separadas

El runner de DeepSeek hacía reconocibles los elementos importantes: un personaje turquesa, bordes de carril brillantes, monedas doradas y peligros con colores contrastantes. Su entorno oscuro y escaso y sus edificios sencillos dejaban bastante margen para mejorar el aspecto visual. Ese único resultado no demuestra que DeepSeek sea mejor en lógica que en arte en general.

Nuestro experimento independiente Neon Harbor Sprint tenía un estilo de neón llamativo, pero costaba más distinguir la silueta del coche y la carretera. Una revisión de rendimiento redujo la resolución de renderizado, lo que mejoró la respuesta a los controles, pero redujo la definición.

Otro prototipo de carreras de DeepSeek. Usó una solicitud diferente y no forma parte de la comparación del runner compartido.

Volvimos al runner porque otro juego habría dificultado la comparación. El juego de carreras aun así dejó una lección útil: evalúa al personaje, los peligros y los límites de los carriles al tamaño real de juego y con el juego en movimiento. Los efectos y la decoración de la interfaz pueden convivir con una mala legibilidad.

¿Son demasiado restrictivos los prompts y las skills?

La solicitud del runner tenía muchos detalles a propósito para poder reutilizarla. Quien crea un juego debería poder empezar con una idea mucho más breve. Ayudar a convertir esa idea en una descripción útil forma parte del trabajo del producto.

No hemos realizado una comparación controlada entre una solicitud breve y una detallada. Por eso, la longitud del prompt no basta para explicar los controles invertidos. El código defectuoso ofrece una explicación directa relacionada con la cámara y los controles, y otros resultados de la misma solicitud acertaron las direcciones.

Algunas restricciones protegen la experiencia: controles coherentes, contacto real con las monedas, una pausa completa y un reinicio limpio. Otras decisiones pueden quedar abiertas, como el tema, la paleta, la presentación de la cámara y la forma en que el modelo construye la escena. Un proceso de construcción rígido también puede dejar demasiado poco margen para inspeccionar y mejorar la primera implementación. Vale la pena probar si más oportunidades de revisión ayudan; aquí ese beneficio sigue siendo una hipótesis.

Los intentos anteriores mostraron por qué hay que prestar atención al flujo de trabajo. En un intento de MiMo se agotó el límite de respuestas antes de entregar un juego. Otro generó código, pero se perdió la entrega final porque falló el flujo de datos del proveedor. Fueron fallos con causas distintas y deben registrarse por separado de los defectos del juego. También impiden tratar todos los intentos históricos como una prueba A/B exclusiva de modelos.

Quien crea un juego podría empezar con algo así:

Crea un runner 3D breve con tres carriles. Permite esquivar a izquierda y derecha, saltar barreras y deslizarse bajo vigas con teclado o controles táctiles. Quiero un personaje claro, una recogida satisfactoria de monedas y un reinicio rápido cuando choque. Elige el escenario y el estilo visual.

Este texto es una sugerencia para empezar, no el prompt original de la comparación. Studio puede aclarar las reglas que falten, confirmar la descripción y dejar espacio para decisiones creativas. Después, una prueba de juego breve puede revelar cuál sería la siguiente revisión útil.

Qué cambia en nuestro próximo experimento

Para nosotros, optimizar ahora también incluye la fiabilidad de entrega, el tiempo de inspección y la cantidad de reparaciones que necesita un resultado jugable. La generación barata es útil cuando el resultado resiste los controles habituales y se puede mejorar mediante un ciclo de revisión manejable.

Conservaremos los resultados originales, anotaremos a qué etapa llegó cada intento y comprobaremos el comportamiento visible con teclado y pantalla táctil. En una comparación futura podremos mantener estable el juego y cambiar una sola variable del flujo de trabajo, como la longitud de la descripción o las oportunidades de revisión. Estas observaciones por sí solas no indican qué modelo ganará ese experimento.

Para ver un ejemplo jugable, visita Colossal Runner. Sus versiones públicas revisadas incluyen reparaciones posteriores y son independientes de los experimentos originales que se muestran aquí. También puedes explorar otros juegos de navegador para inspirarte en la experiencia que quieras crear.

¿Tienes una idea pequeña para un juego? Empieza una descripción en OpenGame Studio, acuerda el ciclo principal y prueba la primera versión con controles reales.

Nota sobre las fuentes

Las fuentes oficiales respaldan los nombres de los modelos, el contexto de los lanzamientos y el posicionamiento de los proveedores: lanzamiento de DeepSeek del 17 de octubre, Grok 4.6, MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5 y el ejemplo de modelo insignia de referencia no probado, Claude Opus 5.5.

Las observaciones de juego y los tiempos de generación proceden de nuestros experimentos en OpenGame Studio y de los originales conservados. Las ocho imágenes son capturas sin modificar de esas inspecciones, con arte procedural original o recursos de personajes OpenGame M0 con licencia CC0-1.0. Ninguna imagen es una demostración de un proveedor ni una reconstrucción mejorada.