Nous fabriquons nos jeux à deux nous-mêmes, et nous les testons nous-mêmes. Une partie de ce travail, ce sont des gens qui jouent sur un canapé. La plus grande partie, non. Avant qu'un original sorte, il passe par dix-huit vérifications automatiques. Elles ouvrent le jeu dans un vrai navigateur, lisent ce qui est à l'écran, appuient sur les touches, touchent les dispositions pour téléphone et essaient de résoudre les niveaux. Cet article parle des bugs que ces vérifications ont trouvés. Chacun d'eux avait survécu à un test avec de vrais joueurs.
Le bug qui a survécu à tous les tests
Chacun de nos jeux affiche ses commandes en bas de l'écran. Dans sept des douze premiers originaux, cette ligne était fausse pendant la partie. Elle montrait les touches du menu au lieu des touches du jeu. Sumo Smash, notre jeu le plus joué, avait ce bug. Personne ne l'a remarqué. Le jeu fonctionnait parfaitement, il ne vous disait simplement jamais comment jouer. La correction tenait en une ligne par jeu. La leçon était plus grande : nos vérifications lisaient le code, pas l'écran.
Lire ce qu'on dit au joueur
Alors nous avons écrit une vérification qui joue au lieu de lire. Elle lance une partie en solo, attend la fin du compte à rebours et lit la phrase vraiment affichée à l'écran. Si cette phrase cite les touches du menu, la vérification échoue. Ensuite, nous avons remis exprès l'ancien bug dans un jeu. La vérification l'a attrapé. Un test qui ne peut pas échouer n'est pas un test, alors nous cassons nos propres vérifications avant de leur faire confiance.
Des menus qui se chevauchaient sur téléphone
Nos menus de titre sont dessinés à un pourcentage de la hauteur de l'écran, plus quelques pixels pour chaque ligne. Cela marche sur un ordinateur portable. Sur un téléphone tenu à l'horizontale, les lignes tombaient les unes sur les autres. La capture d'écran d'un joueur le montrait sur un jeu. Quand nous avons vérifié chaque jeu sur cinq tailles d'écran, dix-huit sur vingt et un avaient le même problème quelque part. Chaque menu de titre est maintenant une seule pile qui mesure son propre espace, et la vérification fait tourner chaque jeu à chaque taille avant une sortie.
De vrais contacts, pas des faux
Plusieurs originaux permettent à deux personnes de partager un seul téléphone. L'écran se coupe en deux et chaque pouce reçoit son propre stick. Le risque est silencieux. Si la moitié droite envoie discrètement les touches du joueur de gauche, l'écran a l'air parfait et un joueur ne peut tout simplement pas bouger. Notre vérification tactile utilise de vrais événements tactiles du navigateur, pas des appuis de touches simulés. Pour chaque moitié, elle liste les touches qui doivent se déclencher et celles qui ne doivent jamais se déclencher. Nous l'avons testée en branchant exprès une moitié sur la mauvaise touche. Elle a échoué, et c'est exactement ce que nous voulions.
Des niveaux impossibles à résoudre
Les jeux de réflexion ont droit à un solveur. Tether est un puzzle coopératif où deux orbes reliés par une corde doivent tous les deux se tenir sur des plateformes en même temps. Dans la première version, aucun niveau n'avait de solution. Les plateformes étaient placées aux deux extrémités, plus éloignées l'une de l'autre que la longueur de la corde. À l'œil, tout semblait correct. Les chiffres disaient le contraire.
Beam avait un problème plus subtil. Chaque niveau pouvait se résoudre avec un certain angle de la lumière. Mais trois niveaux sur six commençaient avec le marcheur dans le noir, et le noir est un chronomètre. Résoluble sur le papier, fatal dès la première image. La vérification teste maintenant l'angle de départ, pas seulement l'existence d'une réponse.
Color Gates est allé le plus loin. Une vérification a chiffré chaque niveau en secondes. Elle a découvert que trois niveaux sur six pouvaient être terminés sans jamais utiliser la mécanique principale du jeu, parce que les deux joueurs pouvaient simplement jouer chacun leur tour. Toute la conception a été reconstruite autour de plaques de pression que les deux joueurs doivent tenir en même temps. Une mécanique qu'on peut contourner en s'organisant n'est pas une mécanique.
Une règle, enfreinte quatre fois
Chaque original suit le même petit contrat. Espace sur un écran titre tout juste ouvert lance une partie en solo. La touche 2 lance une partie à deux. Échap ramène à l'écran titre. Nous avons écrit cette règle et nous l'avons quand même enfreinte quatre fois. Deux jeux coopératifs démarraient à deux joueurs par défaut, si bien qu'un visiteur seul qui appuyait sur Espace recevait un orbe et un partenaire immobile. Nous les avons corrigés, puis une nouvelle vérification a trouvé le même bug encore vivant dans deux jeux plus anciens. Une règle enfreinte quatre fois n'est pas une règle. C'est de la chance. Maintenant, une vérification fait tourner les trente jeux et contrôle le contrat.
Casser nos propres vérifications exprès
Chaque vérification ci-dessus a été testée contre une erreur volontaire. Remettre le bug, lancer la vérification, confirmer qu'elle échoue. C'est plus important qu'il n'y paraît. Dans un jeu de course, une vérification de la règle de score passait même après que nous avions réécrit la règle de façon fausse. La vérification supposait la règle au lieu de la tester. Elle échantillonne maintenant chaque moment où l'on marque. Une vérification qui n'échoue jamais ne vous apprend rien.
Pourquoi c'est important pour vous
Rien de tout cela ne rend un jeu amusant. Ce sont les gens sur un canapé qui en décident, et nous testons toujours chaque original avec de vrais joueurs. Ce que font les vérifications, c'est retirer les bugs qu'un test avec des joueurs ne peut pas voir. Une indication qui ment, un menu qui se chevauche sur votre téléphone, un niveau impossible à résoudre. Ce sont ces bugs qui font fermer l'onglet sans jamais dire pourquoi. Si vous voulez le côté conception de cette histoire, lisez les jeux que nous avons tués et comment nous équilibrons nos jeux. Ou ouvrez simplement les originaux et voyez si cela a marché.
