Esta entrada fue escrita originalmente en italiano por Paolo Gambardella. Ha sido traducida por un agente de inteligencia artificial y puede contener imprecisiones.
Da lo que entiendo, Miyamoto nunca escribió una sola línea de código en sus juegos. En un antiguo Iwata Asks, Toshihiko Nakago, el programador principal, cuenta cómo funcionaba todo. Miyamoto y Takashi Tezuka dibujaban los niveles a lápiz en enormes hojas de papel cuadriculado. El equipo de Nakago introducía los datos a mano, bloque a bloque. Por la noche grababan todo en una ROM y los dos diseñadores jugaban el nivel. Las correcciones volvían en forma de anotaciones a lápiz sobre el papel. “A duras penas conseguíamos hacer un ciclo de modificaciones al día”, dice Nakago.
Una vuelta al día. Hoy, con un modelo de lenguaje abierto junto al editor, puedo hacer una cada dos minutos.
Ya escribí que el genio solitario es un mito y sigo pensándolo: sin Nakago no habría existido Super Mario. Hoy, parte de ese diálogo entre diseñador y programador lo lleva un modelo. El diálogo, sin embargo, sigue ahí, y la manera en que Miyamoto se manejaba dentro de él dice mucho sobre en qué se está convirtiendo nuestro oficio.
El diseñador como director
Me gusta imaginar a Miyamoto como alguien que sabía lo que quería y sabía comunicarlo. Su trabajo era describir: dónde está el bloque, hasta qué altura llega el salto, qué hace el Goomba cuando choca contra una tubería. La traducción a ensamblador le tocaba a otros.
Con la IA pasa algo parecido. Puedo describir una mecánica, los estados de un personaje, los casos límite, y obtener un script para Godot o Unity que los ejecuta. La calidad del resultado depende de lo claras que tenga las ideas; gastaré más o menos tokens según lo preciso que sea.
El diseñador decide qué tiene que pasar, por qué, y qué sensación debe transmitir. Escribir el código se convierte en una parte del proceso que se puede delegar. Lo comentaba ayer a propósito de los juniors: la tarea siempre ha sido instruir a una máquina para que se convierta en un juego.
Los límites de hoy
La NES tenía 2 KB de RAM de trabajo. Nakago cuenta que iban a la caza de memoria libre: con veinte bytes disponibles podías añadir diez bloques a un nivel. De esos límites nacieron soluciones que han pasado a la historia, como las nubes y los arbustos de Super Mario Bros., que son el mismo dibujo con un color diferente.
Miyamoto no programaba, pero esos límites los conocía a la perfección. Por eso pedía cosas que se podían hacer.
La IA también tiene sus límites, y quien la usa tiene que conocerlos del mismo modo. El modelo olvida lo que queda fuera de su ventana de contexto. Da respuestas distintas a la misma pregunta. Si corre en tiempo real dentro de un juego, cada llamada tiene un tiempo de respuesta y un coste. Quien los conoce puede diseñar a su alrededor, y a veces convertirlos en mecánicas: un personaje que recuerda mal, un oráculo impredecible, un mundo que cambia cada vez que lo visitas.
Diez vueltas al día, luego cien
En la misma entrevista, Nakago dice que, con las herramientas que llegaron después, podían modificar un nivel diez o veinte veces al día. Hoy el ciclo entre idea, implementación y prueba se acorta casi a cero. Cambio la gravedad, vuelvo a jugar, la cambio otra vez.
Esto desplaza el cuello de botella. Antes el límite era la velocidad a la que alguien podía implementar un cambio. Ahora el límite es la velocidad a la que yo puedo entender si ese cambio funciona. Y para entenderlo tengo que jugar, sentir, comparar. El feel de un salto solo se encuentra con el mando en la mano.
Lo que la IA no sabe
La IA escribe código, esboza diálogos, genera assets en pocos segundos. Pero no sabe cuándo un nivel es demasiado largo, cuándo un enemigo aparece en el momento equivocado, cuándo un salto se vuelve frustrante. No siente alegría, aburrimiento ni tensión. Imita bien las soluciones que otros ya han encontrado; elegir cuál quedarse le corresponde a quien juega.
Por eso creo que el valor del game designer se está desplazando todavía más hacia el gusto, el ritmo y la psicología del jugador. Son las cualidades que hicieron atemporal el trabajo de Miyamoto, y él las ejercitaba con un lápiz y un papel cuadriculado.
Tres cosas que entrenar a partir de mañana
- Escribe especificaciones que otra persona pueda ejecutar. Coge una mecánica que conozcas bien, por ejemplo el salto de Mario, y descríbela en diez líneas. Luego dásela a un modelo y observa qué sale. Cada diferencia entre lo que tenías en la cabeza y lo que ves es un punto en el que tu descripción era vaga.
- Estudia los límites de tu herramienta. Miyamoto conocía la memoria de la NES; tú aprende qué hace mal el modelo: dónde se confunde, qué olvida, cuándo se inventa cosas. Son información de diseño.
- Juega más de lo que generas. Si una iteración cuesta dos minutos, es fácil producir cincuenta sin haber jugado de verdad ninguna. Reserva momentos en los que coges el mando y juzgas, y escribe lo que has sentido antes de pedir el siguiente cambio.