El mejor modelo de IA para crear videojuegos

No existe un único mejor modelo de IA para crear videojuegos, porque crear un juego no es una sola tarea. Son muchas: escribir la lógica del juego, corregir errores, diseñar niveles, generar arte, crear sonido y unirlo todo para que funcione. Cada modelo destaca en partes distintas, y las clasificaciones cambian cada pocos meses con cada nueva versión.

En lugar de perseguir un ganador que caduca enseguida, céntrate en lo que determina la calidad. Cuando lo veas, podrás juzgar cualquier herramienta o modelo por tu cuenta.

Un modelo por sí solo predice texto. Para convertir un prompt en un juego que funcione, el sistema que lo rodea tiene que planificar, editar archivos, validar código y reparar fallos. Ese sistema decide si obtienes algo jugable o un muro de código roto.

Ese sistema suele incluir:

• Un conjunto claro de reglas que le diga al modelo cómo estructurar un juego, no solo un prompt suelto.
• Plantillas y código base para que el modelo no tenga que recrear la infraestructura básica cada vez.
• Una forma de ejecutar el código generado, detectar errores y comunicarlos para que el modelo pueda corregir sus propios fallos.
• Generación de arte integrada y sonido de la biblioteca, para que los recursos se carguen en el juego.
• Comprobaciones de código más una prueba de juego en el navegador, con los resultados sin probar marcados como no verificados.

Dos productos pueden usar el mismo modelo y dar resultados muy distintos, porque uno tiene un sistema sólido a su alrededor y el otro no. Por eso la puntuación de un modelo aislado en una prueba comparativa no dice mucho sobre lo buena que será una herramienta para crear juegos.

Aquí tienes un mapa aproximado de dónde ayudan los modelos, general a propósito porque los detalles se quedan viejos rápido:

• Generación de código: los modelos más grandes y capaces suelen ser mejores produciendo lógica de juego que funciona y corrigiendo errores cuando algo se rompe. Aquí es donde pagar por un modelo más potente suele compensar.
• Iteración económica: un modelo de menor precio puede encajar en un cambio pequeño y bien acotado. Su tiempo de respuesta depende de la tarea, las herramientas, el razonamiento y la carga del proveedor, así que más pequeño no siempre significa más rápido.
• Arte e imágenes: los modelos de imagen forman una categoría distinta de los modelos de texto. El modelo que escribe la lógica del juego no tiene por qué ser el mismo que crea los sprites.
• Sonido y música: de nuevo, son modelos especializados separados, pero el sonido y la música provienen de una biblioteca de grabaciones reales.

La conclusión práctica es que ningún modelo hace todo esto bien, por lo que una herramienta de juegos seria combina varios en lugar de apostar todo a uno solo.

Cualquier artículo que nombre a un ganador permanente envejece pronto. Las nuevas versiones salen a menudo, y un modelo que lidera un trimestre puede quedarse atrás al siguiente. Perseguir la clasificación es una forma débil de elegir una herramienta para crear juegos.

Es más duradero hacer mejores preguntas. ¿La herramienta ejecuta y prueba el código que escribe? ¿Puede recuperarse de sus propios errores? ¿Produce algo que puedes jugar, y no un fragmento que tienes que montar por tu cuenta? Esas cualidades duran más que cualquier lanzamiento de un modelo.

OddShed está construido sobre esta idea. En lugar de pedirte que elijas el modelo de un proveedor, da a cada cuenta el mismo equipo de agentes: un constructor escribe el código, un artista dibuja el arte, un diseñador de sonido elige los efectos y la música, y un tester de QA prueba cada versión en un navegador cuando puede. OddShed elige por ti los modelos que hay detrás de cada uno.

OddShed crea juegos de navegador con Phaser para 2D y Three.js para 3D, y cada turno muestra exactamente cuánto costó cuando termina. Pone en el centro el sistema, no el nombre de un modelo.

• No hay un único mejor modelo. La respuesta depende de la tarea y cambia rápido.
• El sistema que rodea al modelo importa más que su nombre para conseguir un juego jugable.
• Los modelos más potentes ayudan más con la generación de código y la corrección de errores; los modelos más ligeros son suficientes para cambios pequeños.
• Juzga una herramienta por si ejecuta, prueba y repara lo que produce, no por el modelo que dice usar.