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.
Les prototypes sont l’un des domaines où le game design a énormément évolué ces derniers mois. Les nouveaux algorithmes de machine learning et d’automatisation permettent à tout le monde d’aller beaucoup plus vite pour produire les artefacts dont on a besoin pour apprendre et faire apprendre à son équipe. C’est une vraie avancée, mais ça peut exacerber une tendance que j’ai observée dans certaines équipes : créer un prototype trop sophistiqué qui finit par se transformer en démo.
Le prototype sert à apprendre, à répondre à des questions. La démo sert à convaincre, à obtenir le feu vert, à vendre. Le problème apparaît quand on crée un prototype trop léché pour sembler convaincant, mais trop ambigu pour qu’on puisse vraiment dire qu’on était en train d’apprendre. On finit par n’apprendre grand-chose et ne convaincre personne.
Un exemple concret. Si c’est la première fois que vous me lisez, sachez que je suis consultant en game design spécialisé dans l’idéation et la pré-production de nouveaux jeux vidéo, principalement free-to-play. J’ai un petit studio, et avec mes collaborateurs la semaine dernière, nous avons créé ce prototype sous Godot :
- Le projet a démarré lundi avec une vision que je mûris depuis un moment, et que j’ai concrétisée dans un document de vision
- Mon assistant Eduard a recherché d’autres jeux et m’a remis un concept document mercredi
- Le jeudi, j’ai donné ce document à Claude Code en lui demandant de me générer un prototype de base
- Du vendredi au dimanche, j’ai fait de courtes interventions en fonction des idées qui me venaient pendant que je faisais autre chose.
Après avoir livré le résultat à mon assistant, il l’a testé pendant une journée entière et m’a donné son point de vue. La discussion a rapidement dérivé vers des problèmes du type « le circuit généré est monotone » ou « on n’arrive pas à percuter les voitures ». Des choses qui comptent à partir de la démo, mais pas à ce stade. À deux, en discutant, on a réussi à identifier le vrai apprentissage, ce qu’on aime dans ce prototype. On le met de côté, on le documente, et on passe à la prochaine phase d’apprentissage.
Si on n’avait pas été à deux, si on avait été dans une entreprise plus grande, on aurait probablement dû préparer une présentation avec les learnings pour aligner tout le monde. C’est comme ça que j’aime avancer — mais je vous le dis : la tentation de vouloir régler les problèmes techniques ou améliorer les « intelligences » artificielles des adversaires virtuels a été forte. Pourquoi ? Parce que maintenant c’est facile, c’est rapide.
Vous pouvez le faire, mais votre concurrent aussi. Pour moi, ce qui fait la différence, c’est de se concentrer sur les bonnes choses au bon moment. Aujourd’hui plus que jamais, le discernement est indispensable — un contact m’a dit que les délais de validation sur l’App Store s’allongent considérablement vu le volume d’apps « vibe-codées » qui arrivent aux modérateurs. Si on doit attendre plus longtemps pour nos validations, autant que ce soit pour quelque chose qui en vaille vraiment la peine.