Qui n'a jamais, pendant une session de jeu, traîté les développeurs d'incompétents finis à la vue d'un gros bug bien baveux ? Ne mentez pas, on l'a tous fait au moins une fois. Pourtant, on est tous d'accord pour dire que développer un jeu, quel qu'il soit, est tout sauf une mince affaire. Programmation, game design, dessin, architecture, les connaissances requises sont énormes et la plupart d'entre-nous seraient incapables de faire un bonhomme qui marche sans que ça foire quelque part. Les meilleurs jeux ne doivent pas seulement être excellents, ils doivent aussi bénéficier d'une finition remarquable afin d'éviter qu'une très vilaine erreur de programmation viennent gâcher la fête. Vous avez réalisé un chef d'oeuvre mais vos dragons volent à l'envers ? Avouez que ça fait un peu tache quand même...

Pourtant, aujourd'hui, nous allons justement parler d'erreurs de programmation, mais dans un sens bénéfique. Oui, quelques fois, un bug aura permis à des développeurs d'ouvrir la voie vers de nouveaux horizons. Dans certains cas, des moments drôles qui sont devenus iconiques sans gâcher le plaisir, dans d'autres, des éléments de gameplay qui auront modelé le jeu, voire un genre tout entier. Et le résultat peut être parfois impressionnant : et si je vous disais qu'une des plus grandes licences du jeu vidéo était née d'une erreur de programmation ? On en reparle un peu plus bas, promis !

Quand Gandhi devient le Dieu de la Guerre

Mais commençons doucement avec ces petites erreurs qui, finalement, ont été "gardées au montage", involontairement ou non, parce qu'elles étaient drôles ou intéressantes. Pour que vous compreniez l'idée, entâmons avec un exemple plutôt connu : Gandhi dans la série Civilization. Si vous ne voyez pas de quoi je parle, faisons simple. Alors que dans cette série de jeux de stratégie/gestion au tour par tour, le joueur essaie de faire grandir une civilisation au fil des âges, l'attitude naturelle des leaders gérés par le CPU étant prévue pour être très représentative de leur attitude dans la vie réelle. Naturellement, Gandhi est donc censé y prôner la paix et la non-violence non ? Pourtant, dans la série, Gandhi est connu pour être complètement taré, vous menaçant d'attaques nucléaires à la moindre petite contrariété ! Etait-ce volontaire de la part des programmeurs ? Non. Mais comment en est-on arrivé là ?

Voici les explications : lors de la conception du premier opus, Gandhi avait été programmé, en toute logique, avec un niveau d'agression minimal. Une donnée cachée gérant son aggressivité de base avait été réglée sur le chiffre 1, alors qu'elle pouvait monter jusqu'à 10 selon les leaders. Manque de bol, les programmeurs avaient raté une chose : en faisant évoluer sa civilisation, il était possible de changer son régime politique, avec des répercussions sur certaines statistiques. Lorsqu'une civilisation passait à la démocratie, le leader prenait automatiquement une valeur de -2 à sa caractéristique d'aggressivité. Si tous les autres leaders restaient dans le positif, notre cher Gandhi provoquait un bug. Le jeu utilisant des variables en octet pour la programmation (comme pratiquement tous les jeux), le négatif n'existe pas. En dessous de zéro, il y a donc... 255, le nombre maximal possible, fatalement bien au dessus de n'importe quel autre leader. Etant donné que l'accès à la démocratie pour les civilisations se faisait souvent dans les mêmes eaux que l'accès au nucléaire, voilà que Gandhi passait d'instigateur de la paix à psychopathe de la bombe atomique en un instant ! Autant dire que de nombreux joueurs ont été surpris, et c'est peu de le dire.

En temps normal, le bug aurait été simplement corrigé et puis basta. Pourtant, dans Civilization, le cas était tellement drôle qu'il est devenu un running gag. Dans tous les opus suivants, Gandhi est réglé (maintenant volontairement) pour péter un plomb dès qu'il passe à la démocratie, ou plus récemment, dès qu'il accéde au nucléaire. Et voilà qu'un mythe était né. Aujourd'hui, Civilization ne serait pas Civilization sans Psycho-Gandhi et les fans de la série acceptent largement cette entorse à l'histoire, juste pour le fun.

Les cas fun similaires

Comme on vient de le voir, il suffit parfois d'un clic pour voir naître des mèmes. Un autre cas étonnant concerne la poitrine de Lara Croft dans la série Tomb Raider. D'après les développeurs, l'un des traits physiques les plus caractéristiques de la demoiselle (avant le reboot) serait né d'une simple erreur de données lors de la création du modèle 3D. Plus précisément, pendant la création du personnage, des données avaient été implémentées pour gérer la proportion de chaque partie du corps de Lara. Le concepteur a malencontreusement tapé un chiffre de trop lorsqu'il gérait la poitrine, pour un résultat complètement démesuré, bien au-delà du résultat final. Bien évidemment, il s'est rendu compte tout de suite de l'erreur, mais l'idée a tellement fait rire l'équipe qu'ils ont finalement décidé de lui donner les mamelles polygonales les plus fameuses du jeu vidéo. Et voilà le travail !

Et quand on regarde l'histoire du jeu vidéo, il est fou de voir le nombre de fois où les développeurs se sont rendus compte d'un bug avant la sortie d'un jeu, pour finalement se dire "Baah, allez, c'est drôle, on le met quand même" ! C'est notamment le cas de The Elder Scrolls V : Skyrim, Bethesda étant assez connu pour leur côté "on laisse couler si c'est fun". Non, les géants n'étaient pas censés envoyer les joueurs valdinguer dans la stratosphère à chaque coup de massue. Mais le bug, découvert avant la sortie du jeu, était tellement fun que les développeurs l'ont laissé créant ainsi l'hilarité général. Il en va de même pour l'idée de mettre un panier sur la tête d'un NPC pour voler des choses sans se faire remarquer. Un simple abus de l'IA qui aurait été corrigé s'il n'était pas drôle. A l'inverse, la possibilité pour les poules de dénoncer des crimes, un autre impact inattendu de l'IA, a été corrigé avant la sortie du jeu. J'ai presque envie de dire dommage...

Autre exemple, dans Left 4 Dead 2, c'est en se trompant de chiffre qu'un programmeur a involontairement augmenté le taux d'apparition des Witches dans la sucrerie du niveau Hard Rain. Se disant finalement que c'était une bonne idée, les développeurs ont alors rajouté au background des Witches qu'elles adoraient le sucre. Et vu les nombreux souvenirs de joueurs dans cette satanée sucrerie, diable que ce fut une bonne idée !

Encore un cas, dans Grand Theft Auto : San Andreas. Vous avez sans doute remarqué qu'il n'était pas rare de voir un avion s'écraser en pleine ville (surtout près de Vinewood) n'est-ce pas ? Et bien il s'agit à la base d'une banale erreur de pathfinding, la route virtuelle empruntée par les avions passant parfois malencontreusement dans le sol. Là encore, un bon moment de "allez c'est fun, on le met quand même". Soit dit en passant, la série GTA semble coutumère du fait puisque dans GTA V, c'est carrément une cinématique jouée par des acteurs via motion capture qui a été, volontairement, laissée ingame alors qu'elle aurait initialement due être dans les bêtisiers : dans une scène où Trevor débarque pour discuter avec Franklin, Steven Ogg, l'acteur qui jouait Trevor, s'est pris les pieds dans une barrière et tomba au sol avec la délicatesse d'un éléphant dans un magasin de porcelaine. Plutôt que de reprendre la scène, Steven se mit à improviser en restant dans la peau du personnage, menaçant soudainement l'acteur qui joue Franklin (Shawn Fonteno) d'une façon digne des tendances psychopathes de Trevor. Même si on peut clairement voir que Shawn est surpris au début, ce dernier rentre dans le jeu et le résultat a fait son chemin jusqu'au produit final. Voici la scène en question :

De l'erreur à l'élément de gameplay

Jusqu'ici, on ne peut pas vraiment parler d'impact sur le monde du jeu vidéo. Tout au plus, il s'agît d'anecdotes drôles sans grand impact. Pourtant, vous n'avez peut-être pas conscience d'éléments de gameplay auxquels vous adhérez, qui sont pourtant nés dans des conditions similaires. Voici un exemple concret : les principes de combos et de cancels, indécrottables du genre jeu de baston, sont tous les deux nés par erreur. Lors du développement d'un même jeu. Street Fighter II.

L'histoire est d'ailleurs assez drôle car dans les deux cas, les développeurs ont décidé de laisser le "bug" ingame sans avoir à aucun moment conscience du pouvoir de leur "création". En ce qui concerne les Combos, le développeur Noritaka Funamizu s'est rendu compte alors qu'il travaillait sur le bonus stage de la destruction de voiture qu'il était possible d'enregistrer des coups avant la fin du coup suivant, ce qui permettait de les enchaîner rapidement. Compte tenu de la relative difficulté d'enclencher ce "bug", l'équipe s'est dit que ça n'allait pas poser de problème majeur et qu'au pire, les bons joueurs pourraient en profiter un peu. Ce qu'ils n'avaient pas prévu, c'est qu'il allait être possible de faire des enchaînements dévastateurs et que les combos allaient tout simplement créer le genre jeu de baston, qui jusque là n'existait que de façon tout à fait sporadique ! Même chose pour le "cancel", qui consiste à faire une attaque qui arrête l'animation de l'attaque précédente, réduisant ainsi le temps entre les coups ce qui permet de faire de nouvelles combinaisons tout en surprenant l'adversaire. Là aussi, ce n'était absolument pas prévu mais le "problème" semblait trop rare et inutilisable pour les programmeurs...

Etonnant non ? Je n'irai pas jusqu'à dire que Street Fighter II ne doit son succès qu'à des erreurs de programmation mais soyons clairs : le jeu de baston entier ne serait rien sans eux ! D'ailleurs, toujours dans les jeux de combat, sachez que la technique du Wavedash dans Super Smash Bros. Melee (faire une esquive aérienne vers le bas pour glisser sur le sol) n'avait même pas été découverte par les développeurs du jeu, qui la considèrent d'ailleurs encore aujourd'hui comme un bug (impossible à faire dans les opus suivants, du coup). Aujourd'hui, Super Smash Bros Melee reste le titre de la série le plus compétitif et sans aucun doute le plus impressionnant à voir dû à la rapidité des combats grâce au Wavedash, et ceci malgré ses 15 ans d'âge et les deux épisodes sortis par la suite.

D'autres exemples ? Les début du genre FPS ont vu naître tout un tas de techniques dues aux moteurs de jeu utilisés, encore frais pour les programmeurs. Si aujourd'hui, le Rocket Jump (profiter d'une explosion pour sauter plus haut/loin) fait tellement partie de l'écosystème qu'une classe entière de Team Fortress 2 est basée dessus, il n'avait pas été prévu comme tel lors de la conception du jeu Doom. Merci à Quake d'en avoir fait une vraie feature incorporée au gameplay par la suite. Et puisqu'on parle de Quake, le strafe jumping est aussi une utilisation bête et méchante du moteur de jeu, là encore pas prévue par les développeurs. Appuyer sur une direction (gauche ou droite) est une donnée pour le jeu qui s'ajoute à la vitesse du joueur. L'erreur, c'est qu'elle n'est pas normalisée, ce qui permet au joueur de dépasser la vitesse limite en l'utilisant en même temps qu'un saut et en bougeant sa souris dans la direction du strafe. Essayez de jouer online à Quake sans connaître ce "bug", et vous comprendrez vite votre douleur tellement il s'agît aujourd'hui d'un des éléments de gameplay de base des fast FPS. Un peu plus tard, c'est la façon dont sont gérées les pentes par le moteur 3D dans Tribes qui lui donna son gameplay si particulier. Si les développeurs n'avaient pas conscience de l'impact que ça allait avoir dans le premier jeu, ils ont parfaitement sauté sur l'occasion pour en faire une des features principales de sa suite, Tribes 2 : Ascend.

Mais si on parle ici de physique dans les premiers moteurs 3D, n'oublions pas qu'il suffit parfois d'un pauvre petit clic raté pour redéfinir un genre, ou inclure de nouvelles idées. En cela, la série Final Fantasy n'est pas étrangère à l'affaire, et ceci dès son premier épisode. En effet, dans le premier Final Fantasy sorti fin 1987, deux petites cases de la carte du monde, au nord de Pravoka, avait été codées avec les données d'une autre zone plus au nord à laquelle on ne pouvait accéder que bien plus tard dans le jeu. Une micro-erreur qui peut sembler anodine, mais qui eut une répercussion sur le genre J-RPG : les combats aléatoires des deux cases en question étaient donc ceux prévus dans l'autre région, avec des monstres fatalement bien plus forts que ceux normalement rencontrés dans la région de Pravoka, très tôt dans la partie.

Du coup, les joueurs habiles pouvaient utiliser ces monstres pour gagner des tonnes d'expérience bien plus rapidement que prévu et ainsi casser la courbe de difficulté du jeu. Les joueurs étaient tellement persuadés qu'il s'agissait d'un secret volontaire et l'idée plût tellement à Square Enix que tous les Final Fantasy, voire pratiquement tous les J-RPG offrent depuis des zones de leveling plus ou moins cachées, souvent appelées "Peninsules de Pouvoir" par les fans en relation avec la péninsule de Pravoka. Si vous vous demandiez pourquoi il existait un petit coin avec des dragons niveau 60 dans vos premières heures de jeu de Final Fantasy IX, vous savez maintenant pourquoi.

Trois derniers cas très intéressants

On a déjà vu à quel point de simples bugs pouvaient impacter le jeu vidéo. Mais pour bien finir, abordons trois cas plutôt drôles dont vous connaissez les conséquences, mais peut-être pas les origines.

A la fin des années 90, les équipes de Capcom travaillaient sur le premier Onimusha. Alors qu'il démarrait un autre projet, Hideki Kamiya essayait un peu le jeu de ses collègues et y découvrit un bug étonnant qui permettait de continuer à enchaîner les ennemis alors que ces derniers étaient suspendus dans les airs. Si ce bug fut rapidement corrigé pour Onimusha, Hideki Kamiya adorait l'idée à tel point qu'il en a fait l'intérêt principal du jeu sur lequel il était en train de travailler. Et c'est quelques années plus tard, en 2001, que sortait un certain Devil May Cry, dans lequel Dante jongle avec ses ennemis tout en scorant un maximum selon la classe des combos ! Tout le concept d'un jeu et de ses suites est bel et bien partie d'un vulgaire bug.

Mais si l'impact de Devil May Cry sur le jeu vidéo dans sa globalité reste discutable, il en est autrement pour la série qui suit. Car c'est une des plus grandes licences du jeu vidéo qui doit sa naissance, entre autres choses, à un bug ! En 1995, DMA Design était une boîte britannique à laquelle on devait le fameux Lemmings. Après un certain Unirally qui leur aura valu un étonnant procès avec Pixar qui mériterait un article à lui tout seul, le développeur s'attela à un jeu PC intitulé Race'n'Chase et dont l'idée était de jouer à "flic ou voyou" en voiture. Un peu à la Need For Speed mais avec une vue du dessus en 2D et la possibilité de jouer la police. Jusque là, tout va bien. Sauf qu'un jour, un programmeur fit une légère petite erreur alors qu'il touchait à l'intelligence artificielle des policiers gérés par l'IA. Ils étaient soudainement réglés pour foncer sur le joueur coûte que coûte, au péril de leur propre vie et ceci jusqu'à la mort de ce dernier ! Dans la plupart des cas, le programmeur aurait changé sa ligne de code et la production aurait repris normalement. Sauf qu'ici, les développeurs se sont amusés à essayer de survivre le plus longtemps possible dans ces conditions... et ils se sont vraiment bien marrés. Du coup, de fil en aiguille, l'idée de jouer les flics dans le jeu disparut et DMA Design changea le concept pour nous laisser jouer un hors-la-loi qui doit constamment éviter la police. Le titre étant moins axé sur la dualité flic/voyou et le choix entre les deux, il fut changé pour finalement s'appeler... Grand Theft Auto. S'il aura fallu le troisième épisode pour voir la série atteindre de nouveaux cieux (avant que DMA Design soit renommé Rockstar North), il est toujours drôle de comprendre son origine.

Enfin, voici une dernière anecdote qui, je pense, finira d'asseoir l'impact réel de la programmation et de ses aléas dans l'avancée du jeu vidéo. Vous le savez, dans la plupart des jeux, la difficulté se veut graduelle. Plus vous avancez et plus le jeu vous résiste en étant plus dur, plus complexe, plus rapide. Aujourd'hui, c'est quelque chose qui semble acquis mais dans les années 70, c'était loin d'être le cas.

Vient alors un certain Space Invaders. Sorti en 1978, ce jeu était considéré comme une révolution à bien des égards. Oui, avec les standards contemporains, il peut paraître désuet, mais celui qu'on considère comme le premier shoot'em up (même s'il est prédaté par Spacewar!) a pratiquement sauvé le jeu vidéo à lui seul dans une période bien compliquée après le crash de 1977. Le concept ? Des aliens en ligne descendent de plus en plus vite vers la terre et vous devez les éradiquer grâce à votre petit vaisseau au bas de l'écran. L'atout majeur du jeu ? Plus vous détruisez de vaisseaux, plus les aliens restants se déplacent rapidement, ce qui les rend plus compliqués à gérer. Simple et génial, Space Invaders réussissait à devenir addictif avec une idée incroyable. Sauf que de l'aveu même du développeur Tomohiro Nishikado, l'idée en question venait initialement de limitations techniques ! En effet, l'accélération de la vitesse de jeu n'était pas due à la volonté du créateur, mais aux limitations de la mémoire de la machine ! Moins de choses à afficher à l'écran = processing plus rapide = augmentation de la vitesse de l'action = augmentation de la difficulté. Elle est pas belle la vie ? Alors certes, ici, il ne s'agît pas d'un bug de programmation mais plutôt de limitations dues à la technologie mais peu importe, l'histoire était trop belle pour ne pas être racontée.

Le plus drôle, c'est que des années plus tard, le genre shoot'em up utilisa ces mêmes limitations techniques pour l'effet inverse. Avec Gradius III et la profusion d'effets techniques à l'écran, les joueurs se rendirent compte qu'il était plus facile d'éviter les tirs adverses grâce aux ralentissements. Dans les années 90, le genre a vu la naissance des danmaku, des shoot'em up dans lesquels les ennemis lâchent des murs de projectiles qu'il n'est possible d'esquiver que grâces aux limitations de la machine : l'action se ralentit et on avait le temps de comprendre où passer. Voilà comment on assista à la création d'un sous-genre...

Il existe encore des dizaines et des dizaines d'anecdotes drôles et intéressantes et j'aurais été ravi de toutes les partager avec vous, mais je pense que vous avez compris l'idée. Si la création d'un jeu vidéo est blindée d'aléas plus pénibles les uns que les autres, il n'est pas rare, grâce à un mélange de chance et de génie, que des idées naissent à partir de ces imprévus. Je ne sais pas si tout cela vous aidera à mieux apprécier les bugs que vous rencontrerez en jeu, 99% d'entre eux n'ayant aucun intérêt ludique, mais ce petit coup d'oeil dans le rétro nous permet au moins de voir à quel point le hasard peut, parfois, bien faire les choses.