Estados de error en juegos de texto: cómo distinguir un contratiempo de un problema de entrada o de entrega
En un juego de texto estilo chat, un turno fallido no siempre significa que el jugador haya tomado una mala decisión. Es posible que la escena haya llegado a un contratiempo de ficción válido, que el juego no admita la redacción utilizada, que el personaje no tenga la información necesaria para actuar o que el mensaje no haya llegado a enviarse. Estas situaciones requieren comentarios diferentes y distintos efectos de reintento. Clasifique primero la causa y luego informe al jugador sobre qué ha cambiado y qué puede suceder a continuación.
Empiece preguntándose qué ha fallado
Una primera pregunta práctica es: ¿entendió el juego la acción prevista y la resolvió dentro de la ficción? En caso afirmativo, el resultado puede ser un contratiempo. En caso negativo, determine si el problema reside en la entrada, en la información de la que dispone el personaje o en la entrega por parte del sistema. Esta distinción en cuatro partes es una ayuda de diseño que se deduce de cómo los sistemas de ficción interactiva separan el análisis sintáctico (parsing), las reglas del mundo, el flujo de la historia y el comportamiento de deshacer; no se trata de un estándar técnico universal. La documentación de Inform, por ejemplo, describe el analizador sintáctico y el modelo de mundo simulado como partes independientes de un juego, y su analizador puede reportar varias razones distintas por las que un comando no coincidió. (Manual del diseñador de Inform 6: Introducción, Manual del diseñador de Inform 6 §33: Cómo ayudar al analizador a salir de apuros)
Trate el mensaje como parte del contrato de respuesta del juego. Debe responder a tres cuestiones: qué ocurrió, si cambió el estado ficcional y qué puede hacer el jugador ahora. Una línea breve como «El barco de papel zozobra antes de alcanzar la otra orilla. La nota doblada sigue en tu mano. Puedes probar por un canal más ancho o buscar otra forma de cruzar» hace que el contratiempo, el objeto conservado y el siguiente paso queden totalmente claros.
1. Un contratiempo de ficción válido
Un contratiempo es adecuado cuando el juego comprendió la acción, la contrastó con la escena actual y generó deliberadamente una consecuencia dentro del mundo. Tal vez el jugador intente llevar demasiados libros de la biblioteca a la vez y uno de ellos se deslice hacia una silla cercana. O tal vez un barco de papel haga agua antes de llegar al otro lado de un arroyo poco profundo. El desenlace puede ser incómodo o sorprendente sin que el intercambio se convierta en un juicio hacia el jugador.
El rasgo definitorio es el cambio de estado. Si la escena dice que el barco se hundió, ese desenlace debe ser una realidad en la historia. Si el jugador puede recuperarlo, explique cómo; si el barco ha desaparecido, no dé a entender que reintentar con el mismo texto deshará ese suceso. Un reintento podría consistir en fabricar otro barco, elegir otra ruta o continuar a partir de la escena modificada. La opción exacta dependerá de las reglas del juego.
Un mensaje de contratiempo útil nombra la acción intentada, la consecuencia y la continuación disponible. No debe disfrazar una acción admitida como si fuera un error de entrada solo porque el resultado haya sido desfavorable. A la inversa, no dé a entender que ocurrió una consecuencia si el juego no cambió realmente el estado de la historia. Esa distinción permite al jugador comprender si está continuando desde una nueva situación o corrigiendo un comando que no llegó a procesarse.
2. Entrada no admitida: el juego no pudo resolver la redacción
Una entrada no admitida significa que el sistema no puede asignar el mensaje del jugador a una acción que este reconozca. El jugador podría escribir «preguntar al panadero por los albaricoques» en una escena en la que el juego solo acepta un conjunto reducido de opciones mediante botones, o bien emplear un nombre que el analizador sintáctico no reconozca. Esto dice algo sobre la cobertura de la interfaz, no sobre la calidad de la idea del jugador.
Los analizadores sintácticos de ficción interactiva ilustran por qué una respuesta útil debe ser específica: Inform enumera errores independientes para un verbo no reconocido, una referencia poco clara, una entrada insuficiente o un objeto que no se puede ver. Su manual también muestra cómo un juego puede sustituir un error genérico del analizador por un mensaje más informativo. (Inform 7 §18.35: Cómo imprimir un error del analizador) En un juego de chat, una respuesta concisa podría ser: «No puedo procesar "preguntar por los albaricoques" aquí. Puedes preguntar por el reparto o elegir un tema del mostrador».
Ofrezca una vía de solución. Según la interfaz, esto podría significar mostrar opciones reconocidas, formular una única aclaración orientada o invitar al jugador a reformular el mensaje. No narre un comando no admitido como si fuera un fracaso en la ficción: si no se ejecutó ninguna acción, indíquelo con claridad. Mantenga intacta la escena anterior y aclare que enviar una entrada corregida reintentará el mismo momento en lugar de rebobinar un suceso de la historia.
3. Conocimiento del personaje no disponible: una pregunta válida aún sin respuesta
A veces, la entrada es comprensible, pero el personaje no sabe lo suficiente como para actuar en consecuencia. Un jugador puede preguntarle al ayudante del tendero adónde se envió un paquete, antes de que el ayudante haya visto el recibo. El juego puede reconocer la pregunta y, al mismo tiempo, retener de forma legítima una respuesta definitiva.
Esto difiere de una entrada no admitida: el tema o la acción son válidos, y la limitación pertenece a la información de la que dispone el personaje en la ficción. Marque ese límite con claridad. Por ejemplo: «Mina no ha visto el albarán de entrega, así que no puede decirte la calle. La etiqueta del paquete sigue en el mostrador». Si el jugador puede inspeccionar la etiqueta, preguntar a otra persona o volver más tarde, mencione esa vía. Si no, indique lo que se sabe en realidad en lugar de inventar una pista o tratar la pregunta como si estuviera mal formulada.
Decida si esta respuesta hace avanzar el tiempo o cambia el estado. Si hacer la pregunta es una acción normal dentro del mundo, el juego puede registrar esa conversación o modificar la forma en que un personaje responda más adelante. Si el juego prevé que las preguntas sobre conocimientos no consuman turnos, conserve la escena y permita que se formule otra pregunta a continuación. El jugador no debería tener que adivinar si una petición de información gastó una oportunidad en silencio.
4. Fallo técnico de entrega: la acción podría no haber llegado a la historia
Un fallo de entrega ocurre fuera de la ficción: una respuesta agota el tiempo de espera, aparece por duplicado o se interrumpe a mitad de una frase. El juego no puede afirmar con certeza que el personaje actuó o que la historia avanzó a menos que sepa que la acción se procesó. Esto es diferente de un mensaje dentro del mundo como «el mensajero no pudo encontrar la dirección», que es un resultado ficticio.
Utilice una redacción de estado clara e informe del estado confirmado. Si el juego puede verificar que el turno no se procesó, indíquelo y permita que el jugador vuelva a enviarlo. Si no puede determinar si el turno se procesó, evite invitar a una repetición a ciegas que podría ejecutar la acción dos veces. Explique brevemente la incertidumbre y ofrezca una forma de comprobar la escena actual o de reanudar desde el último punto confirmado. Estas son recomendaciones de diseño que se desprenden de la necesidad de distinguir una falta de coincidencia en la entrada de un desenlace de la historia; los sistemas de ficción citados no definen un protocolo universal para los fallos de entrega en el chat.
Cuando la entrega se restablezca, recupere el último mensaje confirmado o muestre un resumen conciso de la escena y de la acción más reciente que conste como completada. Identifique este resumen expresamente como un resumen, no como un nuevo turno de la historia. Si el jugador decide reenviar, aclare si se tratará como un nuevo intento. Esa pequeña muestra de transparencia evita que una acción duplicada se confunda con una repetición deliberada.
Haga que reintentar, deshacer y reanudar signifiquen cosas distintas
Estas palabras describen diferentes efectos sobre el estado, así que evite utilizarlas indistintamente. Un reintento envía una acción de nuevo en el estado actual; no debe borrar en silencio una consecuencia establecida. Un deshacer restaura un estado anterior. Un reanudar continúa desde el último estado confirmado tras una interrupción. Un reiniciar comienza la historia desde el principio.
El manual de Harlowe para Twine documenta que deshacer consiste en volver al pasaje anterior y descartar los cambios en las variables realizados en el pasaje actual; describe reiniciar como volver a cargar la página para comenzar la historia de nuevo. También señala que el historial para deshacer puede estar limitado. Estas mecánicas demuestran por qué un control debe comunicar su alcance en lugar de depender de una etiqueta imprecisa como «probar de nuevo». (Manual de Harlowe 3.3.8: undo y restart)
Una secuencia de decisión compacta ayuda a mantener la coherencia de la interfaz:
¿El juego entendió y resolvió la acción? En caso afirmativo, reporte el resultado ficcional y el estado restante.
¿El sistema no logró asignar la redacción a una acción admitida? Explique qué no pudo procesar y muestre una vía de solución; conserve la escena.
¿Se entendió la acción, pero el personaje carece de información? Explique el límite del conocimiento y cualquier forma dentro del mundo de averiguar más.
¿El procesamiento o la entrega son inciertos? Indique lo que está confirmado y luego ofrezca una forma segura de comprobarlo o continuar.
Si el jugador quiere retroceder, identifique el control como «Deshacer» e indique qué momento o qué cambios restaura. Reserve «Reiniciar» para empezar desde cero.
Una breve comprobación de coherencia para cada mensaje de error
Antes de publicar o enviar una respuesta, contrástela con el estado de la historia. Si describe un contratiempo, ¿cambió realmente el mundo? Si describe una entrada no admitida, ¿evitó el juego fingir que la acción había tenido lugar? Si el personaje carece de conocimientos, ¿distingue la respuesta eso de un comando no reconocido? Si falló la entrega, ¿sabe el jugador si el turno llegó a procesarse? Por último, ¿hace el control de reintento o reanudación lo que promete su etiqueta?
Un juego de texto resulta justo cuando sus comentarios ayudan al jugador a distinguir lo que experimentó el personaje de lo que la interfaz no pudo hacer. Unas consecuencias claras preservan la historia; unas instrucciones de entrada específicas hacen posible otro intento; unos límites de conocimiento honestos mantienen la coherencia de la ficción; y una vía de recuperación definida proporciona al jugador un camino fiable para seguir adelante.