Quand un jeu devrait-il proposer des choix après avoir mal interprété les saisies répétées d'un joueur ?
Après qu'un jeu a échoué à plusieurs reprises à interpréter l'action en texte libre du joueur, il devrait cesser de lui demander de reformuler et proposer un ensemble restreint et facultatif d'actions pertinentes. Laissez visible ou conservez l'action tentée, expliquez ce que font les choix proposés et offrez un moyen clair de revenir au texte libre. Il s'agit d'une étape de récupération suite à des échecs répétés, ce qui diffère d'une simple question de clarification lorsqu'une seule action est ambiguë.
Traiter les échecs répétés comme un point de récupération
Une clarification ponctuelle est utile lorsque le jeu a compris la majeure partie d'une action mais ne parvient pas à identifier le référent visé par le joueur : « Parlez-vous de la clé en laiton ou de la clé en argent ? » Un texte continuellement non reconnu relève d'un problème différent. Le système peut ne pas savoir ce que le joueur essaie de faire, ou son vocabulaire peut ne pas inclure les mots choisis par ce dernier. Répéter « Essayez d'une autre manière » force le joueur à deviner les règles cachées de l'analyseur syntaxique.
La recherche sur les interfaces de dialogue dans les jeux décrit bien cette tension : le langage libre autorise un éventail de réponses plus large, mais peut aussi échouer à comprendre ce que veulent dire les joueurs ; les menus de réponses fixes sont plus faciles à interpréter mais limitent l'expression disponible. Ces données justifient l'utilisation d'un menu de choix comme solution de repli (fallback), et non comme remplacement par défaut du texte libre. « Playing with words: from intuition to evaluation of game dialogue interfaces »
Un déclencheur pratique consiste en deux tentatives consécutives non reconnues pour une même scène ou action. Il s'agit d'une recommandation de conception, et non d'un seuil universel établi par les études citées. L'essentiel est que ce déclencheur soit prévisible, lié à la tâche en cours et activé avant que le jeu n'enferme le joueur dans une longue boucle. Un jeu peut avoir besoin d'un seuil différent si son mode de saisie est particulièrement imprécis ou si la scène fait de l'expérimentation une composante du gameplay ; il convient d'en décider délibérément et de tester l'interaction qui en résulte.
Conserver ce que le joueur a déjà essayé
Lorsque la solution de repli apparaît, conservez le dernier texte saisi dans le champ de saisie, le journal ou un autre emplacement visible. Si le jeu l'efface, le joueur devra peut-être reconstruire une action qu'il avait déjà formulée. Afficher l'expression permet également de préciser que le jeu a bien reçu la saisie, mais qu'il n'a pas pu l'associer à une action prise en charge.
Une solution de repli peut prendre acte de la tentative sans en faire porter la faute au joueur : « Impossible d'associer "soulever la grille avec le crochet" à une action ici. » Si le jeu a identifié une partie plausible de l'action, indiquez ce qu'il a reconnu : « J'ai trouvé la grille, mais je ne suis pas sûr de ce que vous voulez en faire. » Ne prétendez pas comprendre davantage que ce que le système peut réellement traiter. Cette formulation permet de distinguer une commande inconnue d'une cible connue dont l'action reste non résolue.
L'explication du W3C concernant la suggestion d'erreur (Error Suggestion) indique que lorsqu'une saisie est rejetée et qu'une correction utile est connue, le système doit la fournir. Ses exemples incluent l'affichage de valeurs acceptables ou de corrections probables. Ces recommandations sont rédigées pour le contenu web et non pour les dialogues de jeux vidéo ; leur application à un jeu relève donc d'une adaptation de conception réfléchie. Le principe partagé demeure utile : proposer une étape suivante concrète lorsque le système en a la capacité. W3C, « Understanding Success Criterion 3.3.3: Error Suggestion »
Proposer un menu court d'actions adaptées à la situation
Le menu de repli doit contenir quelques actions prédéfinies prises en charge par la scène actuelle. Par exemple, si le joueur interagit avec une grille verrouillée, les choix pourraient être « Inspecter la serrure », « Essayer la clé » et « S'éloigner ». Ce sont des options données à titre d'illustration, et non des affirmations concernant un jeu en particulier. Les options doivent décrire des actions distinctes, utiliser des verbes clairs et éviter d'orienter le joueur vers des embranchements que le jeu ne peut pas gérer pour le moment.
Gardez des options adaptées à la scène et à son état. Un menu générique comme « Explorer », « Parler » et « Utiliser un objet » s'avère moins utile si l'obstacle immédiat est un objet spécifique. À l'inverse, une option très ciblée ne doit apparaître que lorsque ses conditions sont réunies. Si la clé n'est pas dans l'inventaire du joueur, ne proposez pas « Essayer la clé ». Proposer des actions impossibles ne ferait que remplacer une confusion par une autre.
La recherche sur les dialogues de jeu montre également que le style du menu influe sur l'expérience : des phrases complètes permettent de mieux faire comprendre ce qu'un personnage va dire, tandis que des étiquettes abstraites peuvent donner à l'interaction une impression de contrôle plus stratégique. Le niveau de détail approprié dépend de l'action et de ses conséquences. Utilisez un libellé court pour une action directe ; donnez plus d'explications lorsqu'un choix risque de modifier la scène ou d'engager le joueur dans une réaction déterminante. « Playing with words: from intuition to evaluation of game dialogue interfaces »
Rendre le menu optionnel et montrer comment le quitter
Le menu doit offrir une solution pour progresser, et non désactiver silencieusement la saisie de texte libre. Incluez une option visible telle que « Continuer à taper » ou « Revenir au texte libre », et indiquez explicitement que le joueur peut l'utiliser. Si le jeu accepte le texte libre pendant que les choix sont affichés, rendez ce comportement évident ; si la sélection d'une option ferme le menu, communiquez-le également.
Nommez les boutons et les choix par l'action qu'ils accomplissent. Le système de conception du W3C (W3C Design System) recommande un texte de bouton désignant l'action de l'utilisateur plutôt qu'un libellé générique comme « Soumettre ». Dans un jeu, « Inspecter la serrure » ou « Continuer à taper » est plus informatif que « Continuer ». Ces recommandations d'interface précises proviennent des formulaires web, mais la clarté apportée par la désignation de l'action s'applique tout aussi bien aux commandes d'un jeu. W3C Design System, « Forms »
Assurez la cohérence du moyen de sortie. Si « Continuer à taper » apparaît dans un menu de récupération et « Annuler » dans un autre, les joueurs ne sauront peut-être pas si les deux conservent le même état. Si quitter le menu entraîne la perte du texte, avertissez-en le joueur au préalable. Si le joueur peut sélectionner des options au clavier, à la manette, au toucher ou par une autre méthode prise en charge, veillez à ce que les choix de récupération soient accessibles et activables via le schéma de contrôle habituel du jeu.
Éviter les boucles qui exigent une reformulation
Après avoir affiché le menu, ne revenez pas immédiatement au même message « Je n'ai pas compris ; réessayez » si le joueur effectue une autre saisie non reconnue. Cela ne ferait que relancer la boucle d'échec. Conservez plutôt la nouvelle tentative et gardez les choix proposés accessibles, ou donnez un indice plus précis si l'analyseur dispose de suffisamment d'informations pour cela. Laissez le joueur choisir une action prédéfinie, modifier son texte ou quitter l'interaction si la scène s'y prête.
Les recommandations de Microsoft concernant les solutions de repli conversationnelles préconisent de concevoir une séquence de réponses de secours, d'éviter les excuses répétées à l'identique et de préserver l'endroit où l'utilisateur s'est arrêté lorsque le système le redirige. Rédigés pour des produits conversationnels, ces conseils de transition n'ont pas à s'appliquer mot pour mot à un jeu. L'idée essentielle à retenir est de rendre chaque étape de récupération utile et d'éviter d'obliger la personne à recommencer un travail qu'elle a déjà fait. Microsoft Learn, « Design graceful fallbacks and handoffs »
Une séquence de récupération simple peut se présenter ainsi :
Première saisie non reconnue : indiquer que l'action n'a pas été comprise ; conserver le texte et fournir un indice bref et pertinent pour la scène si cela est possible.
Deuxième saisie non reconnue : afficher un petit menu d'actions prédéfinies valides, à côté du texte conservé.
À partir de ce menu : permettre au joueur de sélectionner une action, de modifier et soumettre à nouveau le texte, ou de quitter l'interaction si le jeu le permet.
Si la saisie suivante n'est toujours pas prise en charge : maintenir les options de secours disponibles et expliciter le champ d'action possible au lieu de relancer la même invite de reformulation.
Tester si la solution de repli est réellement utile
Testez la séquence avec des saisies plausibles qui diffèrent de la formulation privilégiée par le concepteur : synonymes, commandes courtes, noms d'objets et descriptions plus longues. Vérifiez que le jeu conserve la saisie après chaque échec, propose des choix valides pour la scène en cours et permet au joueur de revenir à la saisie sans perdre le fil. Testez également ce qui se produit lorsqu'un choix devient invalide parce que l'état de la scène a changé avant sa sélection.
Pour chaque test, posez-vous une question concrète : après un échec, le joueur peut-il identifier ce que le jeu n'a pas compris ? Voit-il une action suivante utile ? Peut-il continuer à explorer son idée d'origine sans être contraint de choisir une option dans le menu ? Si la réponse à l'une de ces questions est non, modifiez le message, l'ensemble des options ou le chemin de retour. Il s'agit d'une liste de contrôle d'évaluation proposée, déduite des principes d'interaction ci-dessus ; ce ne sont pas les résultats d'une étude d'utilisateurs.
L'objectif est d'obtenir une récupération encadrée : reconnaître la saisie non supportée, la conserver, offrir des choix pertinents après des échecs répétés et faire du texte libre une voie explicite pour continuer. Le menu doit limiter le besoin de deviner tout en laissant au joueur le contrôle sur son utilisation.