Cet article a été écrit à l’origine en italien par Paolo Gambardella. Il a été traduit par un agent d’intelligence artificielle et peut contenir des inexactitudes.
Da ce que je comprends, Miyamoto n’a jamais écrit une seule ligne de code dans ses jeux. Dans un ancien Iwata Asks, Toshihiko Nakago, le programmeur principal, raconte comment ça fonctionnait. Miyamoto et Takashi Tezuka dessinaient les niveaux au crayon sur d’immenses feuilles de papier millimétré. L’équipe de Nakago saisissait les données à la main, bloc par bloc. Le soir, ils gravaient tout sur une ROM et les deux designers jouaient le niveau. Les corrections revenaient sous forme de notes au crayon sur la feuille. “On arrivait à peine à boucler un cycle de modifications par jour”, dit Nakago.
Un cycle par jour. Aujourd’hui, avec un modèle de langage ouvert à côté de l’éditeur, j’en fais un toutes les deux minutes.
J’ai déjà écrit que le génie solitaire est un mythe et je le pense toujours : sans Nakago, il n’y aurait pas eu Super Mario. Aujourd’hui, une partie de ce dialogue entre designer et programmeur est assurée par un modèle. Le dialogue reste quand même, et la façon dont Miyamoto s’y inscrivait dit beaucoup sur ce que devient notre métier.
Le designer comme réalisateur
J’aime imaginer Miyamoto comme quelqu’un qui savait ce qu’il voulait et savait le communiquer. Son travail, c’était de décrire : où se trouve le bloc, jusqu’où monte le saut, ce que fait le Goomba quand il percute un tuyau. La traduction en assembly, c’était aux autres de s’en charger.
Avec l’IA, il se passe quelque chose de similaire. Je peux décrire une mécanique, les états d’un personnage, les cas limites, et obtenir un script pour Godot ou Unity qui les exécute. La qualité du résultat dépend de la clarté de mes idées — je consommerai plus ou moins de tokens selon la précision de ma description.
Le designer décide ce qui doit se passer, pourquoi, et quelle sensation ça doit produire. Écrire le code devient une partie du processus qu’on peut déléguer. J’en parlais hier à propos des juniors : la mission a toujours été d’instruire une machine pour qu’elle devienne un jeu.
Les limites d’aujourd’hui
La NES avait 2 Ko de RAM de travail. Nakago raconte qu’ils partaient à la chasse aux octets libres : avec vingt octets disponibles, tu pouvais ajouter dix blocs à un niveau. De ces contraintes sont nées des solutions qui sont entrées dans la légende, comme les nuages et les buissons de Super Mario Bros., qui sont le même dessin avec une couleur différente.
Miyamoto ne programmait pas, mais il connaissait parfaitement ces contraintes. C’est pour ça qu’il demandait des choses faisables.
L’IA a aussi ses limites, et ceux qui l’utilisent doivent les connaître de la même façon. Le modèle oublie ce qui sort de sa fenêtre de contexte. Il donne des réponses différentes à la même question. S’il tourne en temps réel dans un jeu, chaque appel a un temps de réponse et un coût. Ceux qui les connaissent peuvent concevoir autour, et parfois transformer ces limites en mécaniques : un personnage qui se souvient mal, un oracle imprévisible, un monde qui change à chaque fois que tu le visites.
Dix cycles par jour, puis cent
Dans la même interview, Nakago dit qu’avec les outils arrivés ensuite, ils pouvaient modifier un niveau dix ou vingt fois par jour. Aujourd’hui, le cycle entre idée, implémentation et test se réduit presque à zéro. Je change la gravité, je rejoue, je la change encore.
Ça déplace le goulot d’étranglement. Avant, la limite, c’était la vitesse à laquelle quelqu’un arrivait à implémenter une modification. Maintenant, la limite, c’est la vitesse à laquelle j’arrive à comprendre si la modification fonctionne. Et pour le comprendre, je dois jouer, ressentir, comparer. Le feel d’un saut, ça se trouve uniquement avec la manette en main.
Ce que l’IA ne sait pas
L’IA écrit du code, ébauche des dialogues, génère des assets en quelques secondes. Mais elle ne sait pas quand un niveau est trop long, quand un ennemi arrive au mauvais moment, quand un saut devient frustrant. Elle n’éprouve ni joie, ni ennui, ni tension. Elle imite bien les solutions que d’autres ont déjà trouvées ; choisir laquelle garder, c’est l’affaire de celui qui joue.
C’est pour ça que je crois que la valeur du game designer se déplace encore davantage vers le goût, le rythme et la psychologie du joueur. Ce sont les qualités qui ont rendu le travail de Miyamoto intemporel, et il les exerçait avec un crayon et une feuille à carreaux.
Trois choses à entraîner dès demain
- Écris des specs qu’une autre personne pourrait exécuter. Prends une mécanique que tu connais bien — par exemple le saut de Mario — et décris-la en dix lignes. Donne-la ensuite à un modèle et observe ce qui en sort. Chaque écart entre ce que tu avais en tête et ce que tu vois est un endroit où ta description était floue.
- Étudie les limites de ton outil. Miyamoto connaissait la mémoire de la NES ; toi, apprends ce que le modèle fait mal : là où il se perd, ce qu’il oublie, quand il invente. Ce sont des informations de design.
- Joue plus que tu ne génères. Si une itération coûte deux minutes, il est facile d’en produire cinquante sans en jouer vraiment aucune. Fixe des moments où tu prends la manette et tu juges, et écris ce que tu as ressenti avant de demander la modification suivante.