Mon jeu enseignait la mauvaise touche
Sur la page itch, les plaquettes du tutoriel annonçaient A et D. Sur un clavier AZERTY, la touche à presser porte Q. Le tout premier geste que le jeu enseigne montrait la mauvaise touche à son public. La cause : le web ne sait pas ce que grave ton clavier.
Trouvé en ouvrant la page itch, pas par le filet
La démo 0.1.0 de Sillon venait d'arriver sur itch, jouable dans le navigateur. J'ouvre la page, comme un joueur. Sous les pieds du conducteur, les deux plaquettes du tout premier geste annoncent « A » et « D ». Sur mon clavier AZERTY, la touche à presser porte Q. Le sifflet, lui, annonçait Q là où il faut appuyer sur A. Le jeu enseignait la mauvaise touche, dès la première seconde, à la partie francophone de son public. Et mes 57 assertions navigateur étaient vertes : aucune ne relisait ces plaquettes-là.
La force qui devient piège
Godot enregistre les touches en position physique. C'est une force : le « A » d'un clavier QWERTY sort en Q sur un AZERTY tout seul, ZQSD est gratuit, la main du joueur trouve les mêmes touches sans que je fasse rien. Mais nommer une touche à l'écran exige l'opération inverse : savoir ce que grave la disposition du joueur à cette position-là.
Sur desktop, le moteur sait répondre. Sur l'export web, la fonction qui traduit une position en gravure rend « Not supported by this display server », et je l'ai lu en console au lieu de le supposer. Mon repli retombait alors, en silence, sur le nom QWERTY de la position. Voilà la mauvaise touche : pas une valeur inventée, une valeur par défaut prise pour une réponse.
Le périmètre réel est petit et ça se mesure : entre QWERTY et AZERTY, seules les positions A, Q, W, Z et M changent de gravure, et ma configuration d'entrées n'en utilise que deux. Deux lettres fausses suffisaient à casser le premier contact.
Ne pas nommer ce qu'on ne sait pas confirmer
Le correctif livré tient en une règle : on ne nomme pas ce qu'on ne sait pas confirmer. Sur le web, une lettre ambiguë rend désormais le vide, et l'affichage passe à l'événement suivant de l'action. La marche à gauche porte aussi la flèche gauche : le web affiche « Gauche », vrai sur tous les claviers. Le sifflet n'a que sa lettre : il n'affiche rien du tout. Un cabochon muet est moins grave qu'un cabochon menteur.
Même les flèches s'écrivent en mots : le caractère fléché sortait en tofu dans la police du web, et les triangles du régulateur sont dessinés, jamais écrits. Une forme géométrique ne peut pas manquer d'une police.
La solution propre qui tuait le build
Le navigateur sait pourtant répondre : l'API de disposition du clavier m'a bien rendu ses 48 positions, vérifié dans la page. Mais elle répond par une promesse, après le démarrage, alors que mes cabochons se construisent pendant l'initialisation de la scène. L'attendre à cet endroit fait tomber le wasm sur une erreur d'accès mémoire : la build web ne démarre plus du tout, et mes huit suites navigateur sont passées d'un coup à aucun verdict. J'ai livré le repli honnête et noté le mode d'échec dans le code ; la vraie traduction attendra la 0.1.1.
Le chemin que personne ne joue
Restait un problème de filet : ce chemin du vide n'est jamais emprunté en test. Le natif lit sa disposition, le harnais headless n'est pas concerné. Une option force donc le jeu à se croire sur un clavier inconnu, et le filet la joue à chaque passage, en relisant les étiquettes réellement posées à l'écran. Rouge aux deux mutations que j'ai essayées contre elle.
Ce que j'en retiens
Le bug n'était pas dans la traduction manquante, il était dans le repli qui répondait quand même. Chaque fois qu'une plateforme ampute une capacité, la question à poser est : que rend mon code à la place, et est-ce un aveu ou une invention ? Un système qui avoue ses limites se corrige ; un système qui invente se découvre sur la page publique, par un joueur.