Ir al contenido

Diseño de directores de juego con IA

¿Salidas estructuradas o prosa para un director de juego con IA?

Descubre cuándo usar salidas estructuradas o prosa en un RPG con IA y por qué el motor debe validar tiradas, permisos y estado guardado.

Por Playworlds · Elser.AI ·

De un diario abierto parten caminos dorados hacia un castillo, montañas y ruinas iluminadas por la luna.

Asigna tareas distintas a la estructura y a la historia

Un director de juego con IA debe entender qué intentó un jugador y contar una historia atractiva sobre lo que ocurrió. Son tareas relacionadas, pero el mismo párrafo no debería ser la única fuente de reglas y estado guardado. Una salida estructurada puede hacer que una decisión propuesta por el modelo sea más fácil de inspeccionar para un programa. La prosa le da al jugador atmósfera, diálogo y una próxima decisión clara. Ningún formato hace verdadera por sí solo una afirmación generada.

Imagina una escena ilustrativa: un pícaro llega a una bóveda sellada y dice: «Uso un espejo pequeño para inspeccionar los glifos antes de tocar la cerradura». El juego podría identificar un intento de investigación, decidir si se requiere una tirada, resolver la tirada y describir lo que el pícaro descubre. Si un modelo escribe «Encuentras la marca de liberación y abres la bóveda» antes de la resolución, la ficción se ha adelantado a las mecánicas. Este es un ejemplo de diseño, no un registro del comportamiento en producción de Playworlds.

Usa un esquema sencillo para decisiones propuestas

Una propuesta estructurada podría contener la acción intentada, el objeto objetivo, una posible prueba, una referencia de regla relevante y una incertidumbre que requiera decisión. Para la bóveda, podría identificar la inspección con un espejo como acción intentada y sugerir una prueba de percepción o investigación. No debería afirmar un valor de dado, otorgar un objeto, mover al personaje ni marcar la bóveda como abierta.

OpenAI distingue las llamadas a funciones, que conectan un modelo con herramientas de la aplicación, del formato de respuesta estructurada, que da forma a lo que devuelve el modelo. Su guía de Structured Outputs indica que un esquema estricto admitido hace que la respuesta se ajuste al esquema, pero también advierte que los resultados estructurados pueden contener errores. Para el diseño de juegos, eso significa que un campo válido como «check_required: false» sigue siendo una afirmación que debe revisarse contra las reglas y el estado. Que un analizador lo acepte es solo la primera barrera.

Mantén los dados y el estado bajo control del juego

El motor debe controlar los hechos que determinan un resultado: habilidades del personaje, inventario, acciones disponibles, dados, valores objetivo y el cambio aceptado al estado del mundo. En un flujo de trabajo propuesto, el modelo puede solicitar una prueba o describir por qué podría importar. La aplicación verifica esa solicitud, realiza o registra la tirada y devuelve el resultado resuelto. Solo entonces la narración describe la consecuencia. Un personaje compañero puede reaccionar a una prueba completada sin crear otra tirada ni reescribirla.

Supongamos que el resultado aceptado es 11 en el dado más 2, por debajo de un objetivo de 16. El narrador puede decir que las marcas se difuminan en el espejo, que la cerradura sigue sellada y que el pícaro puede consultar un boceto, preguntar a un compañero o intentar otra herramienta. No debe convertir silenciosamente 13 en éxito. Si la regla permite un resultado parcial, el motor debe autorizarlo antes de que la prosa lo presente como hecho.

Escribe la prosa después de conocer el resultado

La salida narrativa tiene un criterio de aceptación distinto al de la propuesta estructurada. Debe reconocer el método intentado, respetar el resultado resuelto, preservar el conocimiento de los PNJ y terminar en un punto de decisión útil. Puede describir el frío del latón cerca de la mano del pícaro sin afirmar que se ha añadido una herida, una condición o un objeto a menos que la actualización de estado lo permita. La escena puede mantenerse vívida mientras el motor sigue siendo la autoridad sobre las mecánicas.

Esta separación facilita las correcciones. Si la prueba propuesta fue incorrecta, cambia la interpretación o la correspondencia con las reglas. Si la prueba y el estado son correctos pero la escena es aburrida, mejora las instrucciones de narración. Si la prosa contradice la tirada, inspecciona la entrada de narración y el posprocesamiento. Compara las salidas contra la misma escena guardada.

Maneja respuestas inválidas e inciertas

Un esquema necesita una vía explícita para la incertidumbre. El modelo quizá no sepa si el jugador está haciendo una pregunta de reglas, tomando una acción dentro del mundo o describiendo varias acciones a la vez. Permítele devolver un resultado acotado de «necesita aclaración» o «no se propone prueba», en lugar de forzar una elección de regla con confianza. Valida los identificadores de personajes y objetos de escena referenciados contra el estado actual, y rechaza cambios que excedan la acción permitida. Un esquema no puede demostrar que un objeto exista realmente en la aventura.

Un rechazo, una respuesta incompleta, un esquema no admitido, un resultado de herramienta ausente o una versión obsoleta de la escena no deberían convertirse silenciosamente en un evento narrativo aceptado. Registra una razón segura y reintenta dentro de límites definidos; de lo contrario, pide una acción más clara o muestra un error recuperable.

Una lista de verificación práctica de aceptación

Antes de aceptar un turno generado, comprueba: (1) ¿La acción propuesta coincide con las palabras del jugador? (2) ¿Cada personaje y objeto referenciado existía en la escena actual? (3) ¿El motor decidió si se necesitaba una tirada y registró el resultado? (4) ¿Los cambios de estado fueron validados y guardados una sola vez? (5) ¿La prosa coincide con esos hechos aceptados y deja la siguiente opción al jugador? (6) ¿Una recarga puede reproducir la misma ubicación, tirada y consecuencia? Estas comprobaciones son una guía de diseño, no una afirmación del rendimiento medido de Playworlds.

Los jugadores necesitan ver qué intentó su personaje, qué resolvieron las reglas y qué opción queda. Playworlds presenta mundos, fichas de personaje, dados y aventuras en curso en un solo lugar. Prueba una acción pequeña y luego compara la respuesta con el estado visible del juego. Nuestra guía de acciones ayuda a formular esa acción con precisión.