Cómo diseñar un juego de bot con IA con reglas claras, memoria y capacidad de elección del jugador

Comience con un bucle principal que pueda jugarse sin IA

Escriba el bucle en una sola frase: Mostrar la situación → aceptar una acción → verificar las reglas → actualizar el estado → mostrar la consecuencia y las siguientes opciones. Cada turno debe completar ese bucle o explicar por qué no puede continuar.

Antes de redactar el prompt de personalidad, defina el objetivo, las acciones disponibles, los costos de las acciones y las condiciones de finalización. Debería poder ejecutar el juego con fichas de notas o una hoja de cálculo. Esto permite inspeccionar la mecánica antes de que el diálogo generado introduzca variaciones.

Considere un juego pequeño llamado *Paquete del festival* (*Festival Parcel*). El jugador dispone de cinco unidades de tiempo para entregar un paquete. Puede elegir una ruta directa o una ruta por el jardín y, opcionalmente, recoger una cinta decorativa antes de salir. Un bot interpreta al mensajero del festival, quien explica las rutas y comenta sobre la entrega.

Las reglas propuestas son deliberadamente compactas:

Muestre estas reglas antes de la primera elección. Explique que las acciones de entrega finalizan la sesión, por lo que los jugadores deben recoger la cinta con antelación. Una entrega que gasta la última unidad de tiempo se realiza con éxito, ya que la comprobación de éxito ocurre en primer lugar.

Este prototipo cuenta con un inicio completo, un espacio de decisión y un final. Los personajes o ubicaciones adicionales deben ganarse su lugar aportando decisiones útiles a ese bucle.

Haga del estado explícito la autoridad para los resultados

Considere el estado como el registro del juego sobre lo que es real. El texto de la conversación puede explicar ese registro, pero no debe modificarlo en silencio.

El capítulo sobre el estado de Robert Nystrom en *Game Programming Patterns* (https://gameprogrammingpatterns.com/state.html) describe las máquinas de estados finitos mediante estados, entradas y transiciones permitidas. También demuestra cómo los indicadores booleanos combinados de manera imprecisa pueden producir combinaciones no válidas. Aplique ese principio al ciclo de vida de su juego: utilice un único estado de sesión, como activo, entregado o fallido, con transiciones definidas.

Para el prototipo de entrega, basta con una pequeña especificación de estado:

Deduzca la postal del jardín a partir de la ruta seleccionada en lugar de almacenar un segundo valor que pudiera contradecirla. De igual modo, calcule las acciones disponibles en cada momento a partir del estado y las reglas.

Utilice un orden de procesamiento fijo: interprete la solicitud, valide su acción y parámetros, calcule el resultado, confirme el cambio de estado y luego nárrelo. Proporcione al narrador el resultado confirmado y las siguientes acciones permitidas. No debe inventar un segundo cálculo.

Por ejemplo, después de recoger la cinta, el resultado fidedigno es: quedan cuatro unidades de tiempo, la cinta está recogida y ambas rutas son viables. El bot puede describir el color de la cinta, siempre que ese color no tenga ningún efecto mecánico. No puede añadir un costo de tiempo no anunciado ni otorgar una segunda cinta.

Puede crear prototipos de estas condiciones con una herramienta narrativa existente. El tutorial oficial de ficción interactiva de Inkle (https://www.inklestudios.com/ink/web-tutorial/) explica las elecciones condicionales, el seguimiento del contenido visitado previamente, las variables y los finales explícitos. Esas características ofrecen una base útil para probar el juego diseñado antes de añadir la narración de la IA.

Ofrezca a los jugadores opciones que puedan comprender e influenciar

Para este diseño, evalúe la capacidad de acción (agency) según si el jugador puede anticipar una diferencia significativa y luego observarla en el resultado. Varios botones con redacciones distintas que conducen a un resultado idéntico aportan poco para poner esto a prueba.

En *Festival Parcel*, la decisión de la ruta da cabida a diferentes preferencias del jugador:

Estos son cálculos ilustrativos basados en las reglas establecidas. Proporcionan una ayuda sencilla para la toma de decisiones: elija la entrega directa para terminar antes, recoja la cinta como decoración o tome la ruta del jardín para obtener la postal. El tiempo restante es aquí un detalle del final; no otorga puntos en secreto.

Si más adelante el juego recompensa un resultado particular, revele ese sistema de puntuación antes de la decisión. De lo contrario, los jugadores no podrán evaluar el balance que usted pretendía.

Admita texto libre junto con las acciones visibles. «Vamos por el camino panorámico» puede asociarse a la entrega por el jardín. «Hazlo especial» es ambiguo: podría significar recoger la cinta, tomar la ruta del jardín o ambas cosas. Solicite una breve aclaración sin consumir tiempo.

Para el primer prototipo, acepte una acción de juego por mensaje. Si el jugador solicita una secuencia, presente sus pasos y pídale que elija la primera acción. Esto evita ejecutar parcialmente un plan cuyos pasos posteriores resulten no estar disponibles.

Haga que las solicitudes no admitidas sigan siendo informativas. Si el jugador pide volar, explique que las rutas disponibles son la directa y la del jardín, junto con sus costos. El texto libre puede ampliar la expresividad mientras el sistema de acciones mantiene un conjunto predecible de capacidades.

Defina qué recuerda el bot y qué puede saber

Divida la memoria en tres capas, cada una con un propósito diferente.

El estado fidedigno de la sesión almacena recursos, progreso, rutas seleccionadas y finales. Persiste al guardar y recargar, y cambia únicamente a través de acciones validadas.

Un registro de eventos de la sesión guarda las acciones confirmadas y sus consecuencias. Una entrada podría indicar que la acción 2 recogió la cinta y redujo el tiempo de cinco a cuatro. Esto facilita la depuración y los resúmenes precisos. Mantenga identificadores de acción para que una solicitud repetida no pueda aplicar el mismo evento dos veces.

El contexto narrativo contiene el diálogo reciente y un resumen compacto utilizado para mantener el tono y la continuidad. Puede recortarse sin borrar el estado real del juego.

La guía de Anthropic sobre ingeniería de contexto efectiva (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) aborda tanto el resumen del historial de conversaciones como el mantenimiento de notas persistentes fuera de la ventana de contexto. También advierte que una síntesis agresiva puede hacer perder detalles importantes. La implicación de diseño aquí es conservar los hechos mecánicos exactos en un almacenamiento estructurado y utilizar los resúmenes para la continuidad conversacional.

Establezca límites de conocimiento, así como límites de almacenamiento. Un personaje solo debe recibir los datos que tiene permitido saber. Si una versión posterior incluye una ruta oculta, manténgala fuera del contexto de ese personaje hasta que se cumpla la condición para descubrirla. El estado disponible para el motor del juego no tiene por qué estar disponible en su totalidad para el narrador.

Para este juego pequeño, conserve el progreso dentro de la sesión guardada y bórrelo al iniciar una nueva partida. Evite deducir preferencias duraderas del jugador a partir de la elección de una sola ruta. Si añade una preferencia guardada, como descripciones más breves, hágala explícita y editable.

Pruebe la memoria con una secuencia concreta: recoja la cinta, guarde, recargue, consulte el estado y seleccione la entrega por el jardín. La cinta debe figurar como recogida, deben quedar cuatro unidades de tiempo antes de la entrega y el tiempo final debe ser cero.

Diseñe respuestas independientes para los fallos del juego y los fallos del sistema

Un objetivo no cumplido es parte del juego. Una solicitud de generación fallida es un problema de implementación. Asígneles consecuencias distintas.

En el caso de un fallo en el juego, mencione la regla que puso fin a la partida. Después de esperar tres veces, solo quedan dos unidades de tiempo, por lo que ninguna ruta de entrega es viable. Finalice de inmediato con una explicación clara y una opción para reiniciar, en lugar de dejar al jugador en una sesión activa imposible de ganar.

Para los fallos de implementación, defina el comportamiento de recuperación antes de añadir una narración elaborada:

No sustituya en silencio una partida guardada ilegible por un juego nuevo. Eso oculta el progreso perdido y hace que la siguiente respuesta resulte engañosa.

Cree un mensaje de resultado simple para cada acción: qué sucedió, qué cambió y qué está disponible a continuación. La narración expresiva del bot puede acompañar a este resultado. Durante un tiempo de espera agotado o una respuesta contradictoria, el mensaje simple aún permite que el jugador continúe.

Concluya los finales con un resumen preciso. Mencione la cinta solo si se recogió y la postal solo en el caso de la ruta del jardín. La prosa generada debe preservar las distinciones que el jugador se dedicó a elegir a lo largo de la sesión.

Pruebe las reglas y, a continuación, la interpretación del bot

Primero, pruebe el juego con texto fijo. Cubra cada acción, final y condición límite. Luego añada el bot y repita esas pruebas empleando redacciones variadas. Esto permite separar una regla rota de una solicitud malinterpretada.

Invite a jugadores representativos a completar una entrega sin darles instrucciones. Pídales que expliquen qué esperan antes de elegir y qué creen que cambió después. La guía de Nielsen Norman Group sobre pruebas de usabilidad con el método de pensar en voz alta (https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/) recomienda contar con participantes y tareas representativas mientras se deja que los participantes hablen; también advierte que las intervenciones del facilitador pueden influir en el comportamiento.

Utilice la observación junto con el registro de acciones. Anote los intentos de acción, las solicitudes de aclaración, los resultados inesperados y cualquier discrepancia entre la narración y el estado confirmado. Pregunte si los jugadores entendieron las opciones de forma independiente a si disfrutaron eligiendo entre ellas.

Lista de verificación compacta para pruebas de juego. Corrija los errores en las reglas y la gestión del estado antes de ampliar el mundo. Si los jugadores comprenden las opciones pero las encuentran poco interesantes, modifique las alternativas. Si disfrutan de las decisiones pero no pueden predecir los costos, mejore la presentación. Amplíe el prototipo cuando sus elecciones existentes sigan siendo comprensibles a través de diferentes redacciones, sesiones guardadas y rutas de error.

Sigue explorando este tema