Modelos de IA y jugabilidad
Esfuerzo de razonamiento para turnos de RPG con IA: cuándo gastar más
Compara ajustes de razonamiento de GPT-6 Astra, GPT-6 Sol, GPT-6 Luna, Claude Opus 5.5 y Gemini para turnos de RPG con IA según éxito, latencia y costo.
Un saludo y una decisión de campaña son trabajos distintos
Que un posadero indique dónde están los establos no plantea el mismo problema que decidir si una promesa, una pista oculta y una tirada fallida alteran el próximo capítulo de la campaña. Para el jugador, ambos pueden parecer un mismo cuadro de texto, pero el trabajo detrás es distinto. Un RPG con IA que use el mismo esfuerzo de razonamiento en cada turno puede gastar tiempo en diálogos simples y aun así carecer de un plan claro para decisiones difíciles.
La alternativa es una política de enrutamiento que se pueda poner a prueba. Usa el estado actual y las consecuencias de una acción para decidir cuánto trabajo del modelo está justificado. Esta es una propuesta de diseño de aplicación, no una afirmación de que Playworlds enruta los turnos en directo con la política siguiente. Tampoco significa que un modelo de lenguaje deba tomar todas las decisiones. Los hechos conocidos del inventario, los resultados de dados y las banderas guardadas de misiones pertenecen al estado oficial del juego.
Lo que un control de esfuerzo puede y no puede hacer
Los proveedores de modelos exponen distintos controles de esfuerzo o pensamiento, con valores admitidos y predeterminados diferentes. La guía de GPT-6 de OpenAI describe ajustes de esfuerzo para Astra, Sol y Luna. La guía de Opus 5.5 de Anthropic recomienda recalibrar el esfuerzo al migrar desde un modelo anterior. La documentación de Gemini de Google describe niveles de pensamiento para los modelos admitidos. Una etiqueta como “alto” es, por tanto, un ajuste dentro del sistema de un proveedor, no una cantidad estandarizada de cómputo que pueda compararse directamente con el “alto” de otro proveedor.
Aumentar el esfuerzo puede darle al modelo más margen para trabajar una tarea compleja, pero no aporta un mapa ausente, ni corrige una ficha de personaje equivocada, ni repara una integración con la API. Tampoco promete un mejor turno de juego. Comienza dejando clara la tarea y la fuente de verdad; luego compara ajustes en las mismas escenas. Mantén separadas las señales en lenguaje natural, como “piensa más”, del control de API para poder evaluar el efecto de cada una.
Enruta según la decisión, no según el lenguaje dramático
No dejes que una frase elaborada del jugador active automáticamente un razonamiento costoso. “Dirijo un discurso magnífico al capitán de la guardia” puede seguir siendo una conversación sencilla si los hechos relevantes ya se conocen. Por el contrario, “le doy la carta” puede tener consecuencias si la carta revela un secreto, rompe una promesa o avanza el reloj de una facción. Enruta según el estado y la decisión sin resolver. Una vez validada la decisión, la prosa puede ser breve o elaborada según el estilo de la escena.
Una medida útil es detectar primero entradas faltantes o contradictorias. Si el juego no puede confirmar qué carta está en el inventario, haz una aclaración puntual o lee la fuente del inventario. Gastar más esfuerzo en un prompt incompleto suele producir una suposición expresada con más seguridad, no una resolución más acertada. Mantén la capacidad del juego para decir que un hecho es desconocido.
El puente hundido: dos turnos, dos presupuestos
Aquí hay una secuencia ilustrativa, no una sesión registrada de Playworlds. En un puente en ruinas, el jugador pregunta a un barquero si el cruce está abierto. El mapa actual indica que la barca del sur sigue operando. Una respuesta breve y fundamentada puede responder a la pregunta y dejar al jugador libre para embarcar o investigar. Hay poca razón para reconsiderar toda la campaña solo para decir dónde está la barca.
Más tarde, el jugador ofrece al barquero una carta sellada para obtener pasaje. La historia guardada dice que la carta pertenece a un aliado desaparecido, el barquero trabaja secretamente para la facción rival y el jugador prometió no revelar la ubicación del aliado. Esa decisión puede cambiar relaciones y acceso futuro. Antes de la narración, un paso de decisión más profundo puede necesitar conciliar esos hechos e identificar si la carta está realmente presente. La regla o el motor de juego siguen siendo dueños de cualquier prueba, y el jugador sigue siendo dueño de la decisión de entregarla.
Mide turnos completados, no solo el precio por token
Para comparar ajustes, reproduce estados guardados representativos con la misma versión de modelo, prompt, herramientas y requisitos de salida. Registra si el turno termina correctamente: se respeta el resultado de la regla proporcionada, los hechos guardados siguen siendo consistentes, el jugador obtiene una opción de siguiente paso significativa y la actualización del estado es completa. Incluye los intentos fallidos y los reintentos necesarios. Una respuesta barata que debe corregirse dos veces puede costar más tiempo y dinero que una respuesta exitosa con un ajuste más alto.
Mide el tiempo hasta el primer texto útil y el tiempo hasta un turno completado, ya que una frase temprana puede llegar mientras el trabajo decisivo sigue pendiente. Registra tiempos de espera medianos y los más lentos, tokens totales y costo facturado, tasa de corrección y los tipos de errores que cada ajuste produce. Para una comparación simple, el costo por turno exitoso es igual al gasto total de todos los intentos dividido entre el número de turnos completados correctamente. Informa también las cifras originales; una sola proporción puede ocultar una muestra pequeña.
Elige el ajuste más pequeño que supere el umbral de calidad
Una lista de verificación práctica es: identificar la pregunta sin resolver, leer el estado oficial, comprobar si una regla determinista puede responderla y elegir un nivel de esfuerzo admitido para la tarea restante del modelo. Después de la respuesta, verifica el resultado contra el estado antes de presentarlo como resuelto. Si el ajuste falla con frecuencia en una categoría de escenas, aumenta el esfuerzo o cambia el flujo de trabajo y vuelve a probar. Si maneja escenas rutinarias con fiabilidad, evita añadir demora solo porque el turno suena dramático.
Esta política debe revisarse a medida que cambien los modelos y las APIs. Mantén cada evaluación vinculada a su identificador de modelo y fecha, y evita tratar la etiqueta de esfuerzo de un proveedor como un estándar transferible de diseño de juego. Para los jugadores, el objetivo es más simple: una historia que responda con prontitud las preguntas ordinarias y trate las decisiones con consecuencias con suficiente cuidado para hacer que la siguiente decisión sea significativa. Elige un mundo de Playworlds y observa cómo un primer objetivo pequeño da paso a decisiones más importantes.