États d'échec dans les jeux textuels : comment distinguer un revers d'un problème de saisie ou de transmission
Dans un jeu textuel de type messagerie, un tour infructueux ne signifie pas toujours que le joueur a fait un mauvais choix. La scène a peut-être atteint un revers narratif valide, le jeu ne prend peut-être pas en charge la formulation choisie, le personnage manque peut-être des connaissances nécessaires pour agir, ou le message n'a peut-être pas été acheminé. Ces situations appellent des retours différents et des effets de nouvelle tentative distincts. Identifiez d'abord la cause, puis expliquez au joueur ce qui a changé et ce qui peut se passer ensuite.
Commencez par vous demander ce qui a échoué
Une première question pratique est : le jeu a-t-il compris l'action voulue et l'a-t-il résolue dans la fiction ? Si oui, le résultat est peut-être un revers narratif. Si non, déterminez si le problème vient de la saisie, des informations dont dispose le personnage ou de l'acheminement par le système. Cette distinction en quatre volets est une aide à la conception déduite de la manière dont les systèmes de fiction interactive séparent l'analyse syntaxique, les règles de l'univers, le déroulement de l'histoire et les mécanismes d'annulation ; il ne s'agit pas d'une norme technique universelle. La documentation d'Inform, par exemple, décrit l'analyseur syntaxique et le modèle d'univers simulé comme des éléments distincts d'un jeu, et son analyseur peut signaler plusieurs raisons différentes pour lesquelles une commande n'a pas correspondu. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)
Considérez le message comme faisant partie du contrat de réponse du jeu. Il doit répondre à trois questions : que s'est-il passé, l'état de la fiction a-t-il changé, et que peut faire le joueur à présent ? Une courte phrase telle que « Le bateau en papier chavire avant d'atteindre l'autre rive. La note pliée est toujours dans votre main. Vous pouvez essayer un bras d'eau plus large ou choisir un autre moyen de traverser » rend le revers, l'objet conservé et l'étape suivante parfaitement lisibles.
1. Un revers narratif valide
Un revers est approprié lorsque le jeu a compris l'action, l'a évaluée par rapport à la scène actuelle et a délibérément produit une conséquence au sein de l'univers. Peut-être que le joueur essaie de porter trop de livres de bibliothèque à la fois et que l'un d'eux glisse sur une chaise voisine. Peut-être qu'un bateau en papier prend l'eau avant d'atteindre l'autre côté d'un ruisseau peu profond. Le résultat peut être contraignant ou surprenant sans pour autant transformer l'échange en un jugement porté sur le joueur.
La caractéristique déterminante est le changement d'état. Si la scène indique que le bateau a coulé, cette issue doit être vraie dans l'histoire. Si le joueur peut le récupérer, expliquez comment ; si le bateau a disparu, n'insinuez pas qu'en réessayant avec le même texte, l'événement sera annulé. Une nouvelle tentative pourrait signifier fabriquer un autre bateau, choisir un autre itinéraire ou continuer à partir de la scène modifiée. L'option exacte dépend des règles du jeu.
Un message de revers utile nomme l'action tentée, la conséquence et la suite possible. Il ne doit pas présenter une action prise en charge comme une erreur de saisie simplement parce que le résultat a été défavorable. Inversement, n'insinuez pas qu'une conséquence a eu lieu si le jeu n'a pas réellement modifié l'état de l'histoire. Cette distinction permet au joueur de comprendre s'il continue à partir d'une nouvelle situation ou s'il corrige une commande non traitée.
2. Saisie non prise en charge : le jeu n'a pas pu interpréter la formulation
Une saisie non prise en charge signifie que le système ne parvient pas à associer le message du joueur à une action qu'il prend en charge. Le joueur pourrait taper « demander des abricots au boulanger » dans une scène où le jeu n'accepte qu'un ensemble restreint de boutons de choix, ou utiliser un nom que l'analyseur ne reconnaît pas. Cela révèle les limites de l'interface, et non la qualité de l'idée du joueur.
Les analyseurs de fiction interactive illustrent pourquoi un retour utile doit être précis : Inform liste des erreurs distinctes pour un verbe non reconnu, une référence ambiguë, une saisie trop courte ou un objet introuvable à la vue. Son manuel montre également comment un jeu peut remplacer une erreur générique d'analyseur par un message plus informatif. (Inform 7 §18.35: Printing a parser error) Dans un jeu textuel façon messagerie, une réponse concise pourrait être : « Je ne comprends pas 'demander des abricots' ici. Vous pouvez poser des questions sur la livraison ou choisir un sujet sur le comptoir. »
Proposez une solution de rattrapage. Selon l'interface, cela peut consister à afficher les choix reconnus, à poser une question de clarification ciblée ou à inviter le joueur à reformuler. Ne racontez pas une commande non prise en charge comme un échec narratif : si aucune action n'a été exécutée, indiquez-le clairement. Laissez la scène précédente intacte et précisez que l'envoi d'une saisie corrigée permettra de rejouer le même instant plutôt que de rembobiner un événement de l'histoire.
3. Connaissances indisponibles du personnage : une question valide restée pour l'instant sans réponse
Parfois, la saisie est compréhensible, mais le personnage n'en sait pas assez pour agir en conséquence. Un joueur peut demander à l'apprenti d'un commerçant où un colis a été livré, avant même que l'apprenti n'ait vu le reçu. Le jeu peut reconnaître la question tout en retenant légitimement une réponse définitive.
Cela diffère d'une saisie non prise en charge : le sujet ou l'action est valide, et la limite relève des informations du personnage au sein de la fiction. Marquez nettement cette frontière. Par exemple : « Mina n'a pas vu le bordereau de livraison, elle ne peut donc pas vous donner le nom de la rue. L'étiquette du colis est toujours sur le comptoir. » Si le joueur peut examiner l'étiquette, interroger quelqu'un d'autre ou revenir plus tard, mentionnez cette possibilité. Si ce n'est pas le cas, indiquez ce qui est réellement connu au lieu d'inventer un indice ou de traiter la question comme si elle était mal formulée.
Déterminez si cette réponse fait avancer le temps ou modifie l'état du jeu. Si poser la question constitue une action normale dans l'univers, le jeu peut enregistrer cette conversation ou modifier la manière dont un personnage réagira plus tard. Si le jeu prévoit que les questions d'information ne coûtent rien, préservez la scène et laissez une autre question suivre. Le joueur ne devrait pas avoir à deviner si une demande d'information a silencieusement consommé une opportunité.
4. Défaillance technique de transmission : l'action n'a peut-être jamais atteint l'histoire
Un échec de transmission se produit en dehors de la fiction : une réponse expire, apparaît en double ou s'interrompt au milieu d'une phrase. Le jeu ne peut pas affirmer de façon fiable que le personnage a agi ou que l'histoire a progressé, à moins de savoir que l'action a été traitée. Cela se distingue d'un message intradiégétique tel que « le coursier n'a pas pu trouver l'adresse », qui est un résultat fictionnel.
Employez des termes simples pour décrire l'état et rapportez l'état connu. Si le jeu peut vérifier que le tour n'a pas été traité, dites-le et permettez au joueur de le renvoyer. S'il ne peut pas déterminer si le tour a été traité, évitez d'inviter à une répétition aveugle qui risquerait d'exécuter l'action deux fois. Expliquez brièvement l'incertitude et proposez un moyen de vérifier la scène actuelle ou de reprendre à partir du dernier point confirmé. Ce sont des recommandations de conception déduites de la nécessité de distinguer un échec de reconnaissance de saisie d'un dénouement narratif ; les systèmes de fiction cités ne définissent pas de protocole universel pour les pannes de transmission en messagerie.
Lorsque la transmission est rétablie, restaurez le dernier message confirmé ou affichez un récapitulatif concis de la scène et de la dernière action connue comme ayant abouti. Étiquetez explicitement ce récapitulatif comme tel, et non comme un nouveau tour de l'histoire. Si le joueur choisit de renvoyer son message, précisez s'il sera considéré comme une nouvelle tentative. Cette petite touche de transparence évite qu'une action en double ne soit prise pour une répétition délibérée.
Attribuez des sens bien distincts à réessayer, annuler et reprendre
Ces termes décrivent des effets d'état différents, évitez donc de les utiliser de manière interchangeable. « Réessayer » soumet à nouveau une action dans l'état actuel ; cela ne doit pas effacer silencieusement une conséquence établie. « Annuler » rétablit un état antérieur. « Reprendre » poursuit à partir du dernier état confirmé après une interruption. « Recommencer » relance l'histoire depuis le début.
Le manuel Harlowe de Twine documente l'annulation (« undo ») comme le fait de revenir au passage précédent en oubliant les modifications de variables apportées dans le passage en cours ; il décrit le redémarrage (« restart ») comme le rechargement de la page pour recommencer l'histoire. Il précise également que l'historique d'annulation peut être limité. Ces mécaniques démontrent pourquoi une commande doit communiquer sa portée au lieu de s'en remettre à une vague étiquette « essayer à nouveau ». (Harlowe 3.3.8 Manual: undo and restart)
Une séquence de décision synthétique aide à maintenir la cohérence de l'interface :
Le jeu a-t-il compris et résolu l'action ? Si oui, indiquez le résultat fictionnel et l'état qui en découle.
Le système n'a-t-il pas réussi à associer la formulation à une action prise en charge ? Expliquez ce qu'il n'a pas pu interpréter et proposez une voie de rectification ; préservez la scène.
L'action a-t-elle été comprise, mais le personnage manque d'informations ? Expliquez la limite des connaissances et tout moyen diégétique d'en apprendre davantage.
Le traitement ou l'acheminement est-il incertain ? Indiquez ce qui est confirmé, puis proposez un moyen sûr de vérifier ou de continuer.
Si le joueur souhaite revenir en arrière, nommez la commande « Annuler » et précisez le moment ou les modifications qu'elle restaure. Réservez « Recommencer » au redémarrage complet.
Une brève vérification de cohérence pour chaque message d'échec
Avant de valider une réponse, confrontez-la à l'état de l'histoire. Si elle décrit un revers, l'univers a-t-il réellement changé ? Si elle décrit une saisie non prise en charge, le jeu a-t-il évité de feindre que l'action s'est produite ? Si le personnage manque de connaissances, la réponse distingue-t-elle cela d'une commande introuvable ? Si la transmission a échoué, le joueur sait-il si le tour a été traité ? Enfin, la commande pour réessayer ou reprendre fait-elle bien ce que son libellé promet ?
Un jeu textuel paraît équitable lorsque ses retours aident le joueur à faire la part entre ce que le personnage a vécu et ce que l'interface n'a pas pu accomplir. Des conséquences claires préservent l'histoire ; des indications de saisie précises rendent une nouvelle tentative envisageable ; des limites de connaissances honnêtes maintiennent la cohérence de la fiction ; et un chemin de rétablissement bien défini offre au joueur une voie fiable pour aller de l'avant.