Desarrollador y diseñador de videojuegos — tareas, una a una

Diseñar mecánicas, misiones y puzles

Los modelos de lenguaje pueden enumerar ideas de mecánicas y puzles cuando se les pide, pero esas ideas salen de recombinar juegos que ya existen, y lo difícil no es producir una idea: es saber si es divertida, algo que solo se ve cuando la gente juega. Un diseño también tiene que encajar con el presupuesto del equipo, el motor y la identidad del juego, y alguien tiene que responder por él ante el director creativo y la editora. Los estudios tienen pocos motivos para ceder ese juicio a una herramienta, así que la herramienta alimenta la lluvia de ideas y el diseñador sigue eligiendo.

Esto dice quién decide, no cuántos diseñadores necesita un estudio: si las herramientas permiten a cada diseñador explorar ideas más rápido, un equipo puede mantener su tamaño y hacer más, o reducirse. Evidencia que lo movería: un juego comercial publicado cuyas mecánicas centrales eligió un sistema generativo, con los diseñadores limitándose a revisar, o estudios que recortan puestos de diseño y nombran esas herramientas como motivo.

Equilibrado y pruebas de juego

Partes de esto se automatizaron mucho antes de los modelos de lenguaje: los paneles de telemetría muestran dónde abandonan los jugadores y hay scripts que simulan combates y economías. Los agentes entrenados para jugar a un juego pueden ahora disputar muchas partidas y explorar niveles más rápido que los probadores humanos, lo que saca a la luz pronto los desequilibrios y los exploits. Lo que no pueden contar es cómo se siente el juego —si un pico de dificultad frustra o satisface—, así que el diseñador sigue observando a jugadores reales, decide qué cambiar y responde por ello cuando el juego sale.

Ajustar más rápido acorta el trabajo sin decir quién pierde las horas: es más probable que lo noten los grupos de prueba externos y los puestos júnior de ajuste que el diseñador principal. El juicio cambiaría si los estudios publicaran cambios de equilibrio decididos por agentes automáticos sin la aprobación de un diseñador, o sustituyeran las sesiones con jugadores reales por sesiones simuladas.

Prototipos y maquetas

Aquí es donde la tecnología llega con más fuerza al trabajo diario. Los asistentes de código escriben scripts del motor, código de enlace de la interfaz y lógica de juego habitual a partir de una descripción, y los generadores de imágenes y 3D producen deprisa arte provisional y entornos aproximados, así que un prototipo que antes necesitaba un equipo pequeño a menudo puede construirlo una sola persona. Un prototipo todavía tiene que funcionar en tiempo real en el hardware de destino, el código generado falla de formas que solo encuentra quien entiende el motor, y lo que el prototipo debe demostrar lo sigue decidiendo quien lo construye.

Aumentar aún puede significar menos personas: si un desarrollador puede prototipar lo que antes requería a varios, los primeros puestos en menguar son los de programación de nivel inicial y greyboxing. Los recursos generados aquí son sobre todo provisionales; esto no dice que lleguen a un juego terminado. Un caso fechado de un estudio que publique un juego cuyo código o niveles se generaron en su mayor parte, o que recorte personal de prototipado por estas herramientas, movería esto hacia la automatización.

Documentos de diseño y especificaciones de prueba

Una vez tomadas las decisiones, convertirlas en un documento estructurado es el tipo de escritura que los modelos de lenguaje ya hacen bien: redactan especificaciones a partir de notas, mantienen la coherencia entre secciones, convierten un diseño en casos de prueba y generan diagramas de flujo a partir de una descripción. Los estudios pueden adoptarlo a bajo coste dentro de herramientas que ya usan, y un documento erróneo se detecta en la revisión y no por los jugadores. Lo que la herramienta asume es la redacción, no las decisiones que el documento recoge, y alguien todavía tiene que comprobar que el documento coincide con lo que se construyó.

Esto quita horas, no un puesto: pocas personas se contratan solo para escribir documentos de diseño, así que el efecto aparece como diseñadores que dedican menos tiempo al papeleo, o como menos diseñadores júnior cuyo primer trabajo era mantener los documentos al día. Volvería atrás si los estudios vieran que los documentos generados se apartan de lo que realmente se construyó con tanta frecuencia que dejaran de usarlos.

Historia, personajes y texto del juego

Los modelos de lenguaje escriben texto fluido en cualquier registro, lo que abarata la redacción del grueso del texto de un juego: descripciones de objetos, frases incidentales, variantes de un mismo comentario. La historia y los personajes son otra cosa: llevan la identidad del juego, los jugadores notan una frase floja y muchos jugadores reaccionan mal ante el texto que creen generado. Los contratos de los guionistas y las normas sobre si el texto generado por máquina puede tener dueño también frenan su uso en los juegos publicados, así que el guionista edita borradores en lugar de ceder la voz.

Dentro de esta tarea hay una división: el texto en volumen puede pasar a la automatización mientras la historia principal se queda con las personas, y este juicio cubre ambas partes. No dice cuántos puestos de escritura quedan. Una publicación fechada en la que la mayor parte del texto se generó a escala y los jugadores lo aceptaron, o un cambio en las normas sobre la propiedad del texto generado, movería esto.

Revisiones de diseño y dirección del equipo

Este trabajo es persuasión y arbitraje entre personas que quieren cosas distintas: artistas, programadores, productores y la editora. Las herramientas resumen reuniones y siguen tareas, pero el valor está en decidir qué función se recorta, mantener a un equipo en una sola visión y contar con la confianza para tomar esa decisión, y eso nace de la posición de una persona dentro del equipo. Nada en la tecnología actual da a un estudio motivo para dejar que una máquina zanje esas discusiones.

Dirigido por personas dice que el papel de coordinación sobrevive, no cuántos coordinadores: si los equipos encogen porque construir es más rápido, hacen falta menos personas para dirigirlos. Cambiaría si los estudios empezaran a llevar la producción con herramientas de planificación automática que tomen las decisiones de calendario y de recorte y que los responsables solo aprueben.

Fijar las reglas del contenido generado

Cuando los recursos y personajes generados entran en un flujo de producción, alguien tiene que decidir qué está permitido: qué arte es provisional y cuál puede publicarse, qué no debe decir nunca un personaje que improvisa diálogos, y cómo llevar un registro de la procedencia de cada recurso para los propietarios de plataformas y las editoras. Es trabajo de diseño con aristas legales y de reputación, y recae en los diseñadores y los responsables técnicos porque conocen los sistemas.

Una tarea nueva no es un puesto nuevo: en la mayoría de los estudios forma parte de la semana de un diseñador o responsable que ya existe, y solo crece en la medida en que el contenido generado se publica de verdad. Crecería hasta convertirse en puestos propios si los propietarios de plataformas o las normas empezaran a exigir que los juegos declaren el contenido generado y lleven registros de procedencia.