¿Cuándo debería un juego ofrecer opciones tras malinterpretar repetidamente las acciones del jugador?
Después de que un juego no haya logrado interpretar la acción en texto libre del jugador en más de una ocasión, debe dejar de pedir que se reformule y ofrecer un conjunto reducido y opcional de acciones relevantes. Mantén visible o conservada la acción intentada, explica lo que hace cada opción y ofrece una vía clara para regresar al texto libre. Este es un paso de recuperación ante fallos repetidos, no lo mismo que hacer una sola pregunta de aclaración cuando una única acción es ambigua.
Tratar los fallos reiterados como un punto de recuperación
Una aclaración puntual resulta útil cuando el juego ha comprendido la mayor parte de una acción, pero no puede determinar a qué referente se dirige el jugador: «¿Te refieres a la llave de latón o a la llave de plata?». El texto no reconocido de forma reiterada plantea un problema distinto. Es posible que el sistema no sepa qué intenta hacer el jugador o que su vocabulario no incluya las palabras elegidas por este. Repetir «Prueba de otra manera» deja al jugador adivinando las reglas ocultas del analizador sintáctico.
Las investigaciones sobre interfaces de diálogo en juegos describen esta tensión: el lenguaje libre puede permitir una gama más amplia de respuestas, pero también puede fallar a la hora de reconocer la intención del jugador; los menús de respuestas fijas son más fáciles de interpretar, pero limitan la expresión disponible. Esa evidencia respalda el uso de un menú de opciones como alternativa de respaldo, no como el sustituto predeterminado del texto libre. «Playing with words: from intuition to evaluation of game dialogue interfaces»
Un detonante práctico son dos intentos consecutivos no reconocidos en la misma escena o acción. Esta es una recomendación de diseño, no un umbral universal establecido por los estudios citados. Las propiedades clave radican en que el detonante sea predecible, esté vinculado a la tarea actual y se active antes de atrapar al jugador en un bucle prolongado. Un juego puede necesitar un umbral diferente si su método de entrada es especialmente propenso a errores o si la escena convierte la experimentación en parte de la jugabilidad; esto debe decidirse deliberadamente y someterse a pruebas para evaluar la interacción resultante.
Conservar lo que el jugador ya intentó
Cuando aparezca la alternativa de respaldo, conserva el último texto introducido en el campo de entrada, en el registro o en otro lugar visible. Si el juego lo borra, es posible que el jugador tenga que reconstruir una acción que ya había redactado. Mostrar la frase también ayuda a aclarar que el juego recibió la entrada, pero no la vinculó a una acción compatible.
Una alternativa de respaldo puede reconocer el intento sin culpar al jugador: «No he podido asociar “levantar la rejilla con el gancho” a ninguna acción aquí». Si el juego ha identificado una parte verosímil de la acción, indica qué reconoció: «He detectado la rejilla, pero no tengo claro qué quieres hacer con ella». No pretendas abarcar más comprensión de la que el sistema realmente posee. Esta redacción distingue entre una orden desconocida y un objetivo conocido con una acción sin resolver.
La explicación del W3C sobre la Sugerencia ante errores indica que cuando se rechaza una entrada y se conoce una corrección útil, el sistema debe proporcionarla. Entre sus ejemplos se incluye mostrar valores admisibles o correcciones probables. Esa guía está redactada para contenido web, no para diálogos de videojuegos, por lo que aplicarla a un juego constituye una adaptación fundamentada de diseño. El principio compartido es útil: proporcionar un siguiente paso concreto cuando el sistema sea capaz de hacerlo. W3C, «Understanding Success Criterion 3.3.3: Error Suggestion»
Ofrecer un menú breve de acciones adecuadas para este momento
El menú alternativo de respaldo debe contener unas pocas acciones predefinidas y compatibles con la escena actual. Por ejemplo, si el jugador interactúa con una puerta cerrada con llave, las opciones podrían ser «Inspeccionar la cerradura», «Probar la llave» y «Alejarse». Son opciones a modo de ejemplo, no afirmaciones sobre ningún juego en particular. Las opciones deben describir acciones distintas, emplear verbos claros y evitar enviar al jugador a ramificaciones que el juego no pueda gestionar en ese momento.
Mantén las opciones contextualizadas a la escena y a su estado. Un menú genérico como «Explorar», «Hablar» y «Usar objeto» puede resultar menos útil si el obstáculo inmediato es un elemento específico. Por el contrario, una opción muy específica solo debería aparecer cuando sus condiciones se cumplan. Si la llave no está en el inventario del jugador, no ofrezcas «Probar la llave». Un menú que ofrece acciones imposibles solo cambia un tipo de confusión por otro.
La investigación en diálogos de juegos también demuestra que el estilo del menú influye en la experiencia: las frases completas pueden ayudar a transmitir lo que dirá un personaje, mientras que las etiquetas abstractas pueden hacer que la interacción se perciba más como un control estratégico. El nivel de detalle adecuado depende de la acción y de sus consecuencias. Utiliza una etiqueta breve para una acción directa; ofrece más explicaciones cuando una elección pueda alterar la escena o comprometer al jugador con una respuesta notable. «Playing with words: from intuition to evaluation of game dialogue interfaces»
Hacer que el menú sea opcional y mostrar cómo salir de él
El menú debe ofrecer una vía de avance, no desactivar el texto libre de forma encubierta. Incluye una opción visible como «Seguir escribiendo» o «Volver al texto libre», e indica con claridad que el jugador puede utilizarla. Si el juego admite texto libre mientras se muestran las opciones, aclara ese comportamiento; si al seleccionar una opción se cierra el menú, comunícalo también.
Utiliza etiquetas orientadas a la acción para botones y opciones. El W3C Design System recomienda que el texto de los botones nombre la acción del usuario en lugar de recurrir a etiquetas genéricas como «Enviar». En un juego, «Inspeccionar la cerradura» o «Seguir escribiendo» resulta más informativo que «Continuar». La guía de interfaz específica procede de los formularios web, pero la claridad de denominar la acción se traslada sin problemas a los controles de un juego. W3C Design System, «Forms»
Mantén la coherencia en la vía de salida. Si en un menú de recuperación aparece «Seguir escribiendo» y en otro «Cancelar», es posible que los jugadores no sepan si ambas opciones conservan el mismo estado. Si salir del menú descartara el texto, adviértelo antes de eliminarlo. Si el jugador puede seleccionar opciones mediante teclado, mando, pantalla táctil u otro método compatible, asegúrate de que sea posible alcanzar y activar las opciones de recuperación a través del esquema de control habitual del juego.
Evitar bucles que exijan reformular constantemente
Tras mostrar el menú, no vuelvas de inmediato al mismo mensaje de «No te he entendido; inténtalo de nuevo» si el jugador introduce otra acción no admitida. Eso se limita a reiniciar el patrón de fallo. En su lugar, conserva el nuevo intento y mantén disponibles las opciones ofrecidas, o proporciona una pista más precisa si el analizador sintáctico cuenta con información suficiente para ello. Permite que el jugador elija una acción predefinida, modifique el texto o abandone la interacción si la escena lo permite.
La guía de Microsoft para contingencias conversacionales recomienda diseñar una secuencia de respuestas de respaldo, evitar disculpas reiteradas e idénticas y conservar el punto donde la persona lo dejó cuando el sistema la redirige. Está concebida para productos conversacionales, por lo que sus pautas exactas de derivación no tienen por qué aplicarse al pie de la letra a un juego. El principio aplicable es lograr que cada paso de recuperación resulte útil y evitar que la persona tenga que reiniciar un trabajo que ya había realizado. Microsoft Learn, «Design graceful fallbacks and handoffs»
Una secuencia de recuperación sencilla puede estructurarse de la siguiente manera:
Primera entrada no admitida: indica que la acción no ha sido reconocida; conserva el texto y ofrece una pista breve y relevante para la escena si se dispone de ella.
Segunda entrada no admitida: muestra un menú breve con acciones válidas predefinidas, junto al texto conservado.
Desde ese menú: permite que el jugador seleccione una acción, edite y reenvíe el texto, o salga de la interacción cuando el juego lo permita.
Si la siguiente entrada sigue sin ser admitida: mantén disponibles las opciones de recuperación y aclara el abanico de acciones posibles en lugar de reiniciar el mismo mensaje para solicitar una reformulación.
Comprobar si la alternativa de respaldo realmente resulta útil
Pon a prueba la secuencia con entradas verosímiles que difieran de la redacción preferida por el diseñador: sinónimos, órdenes cortas, nombres de objetos y descripciones más extensas. Comprueba que el juego conserve la entrada tras cada fallo, muestre opciones válidas para la escena actual y permita al jugador volver a escribir sin perder el hilo. Prueba también lo que sucede cuando una opción deja de ser válida porque el estado de la escena cambia antes de ser seleccionada.
En cada prueba, plantea una pregunta concreta: tras un fallo, ¿puede el jugador deducir qué no logró entender el juego? ¿Puede visualizar una siguiente acción de utilidad? ¿Puede seguir desarrollando su idea original sin verse obligado a seleccionar una opción del menú? Si la respuesta a cualquiera de estas preguntas es negativa, revisa el mensaje, el conjunto de opciones o la vía de retorno. Esta es una propuesta de lista de comprobación de evaluación derivada de los principios de interacción descritos; no constituye un resultado reportado a partir de un estudio de usuarios.
El objetivo es lograr una recuperación acotada: reconocer la entrada no admitida, conservarla, ofrecer opciones relevantes tras fallos reiterados y convertir el texto libre en una vía explícita de avance. El menú debe reducir la necesidad de adivinar, dejando siempre en manos del jugador la decisión de utilizarlo o no.