Sans LLM, créer un jeu prend 3 mois ; avec un LLM, 3 jours
(marianogappa.github.io)- Un ingénieur logiciel avec 15 ans d’expérience partage son expérience de développement en Go d’un jeu de cartes de son enfance
- Sans LLM (grand modèle de langage), il a mis 3 mois à développer « Truco », en résolvant manuellement tous les problèmes, de la conception de l’UI au déploiement serverless
- Pour créer « Escoba », il a utilisé un LLM afin d’accélérer fortement la conversion du code backend et la vitesse d’implémentation, avec la majeure partie fonctionnelle dès le premier prompt
- La seconde partie de l’article propose, avec un exemple de Tic-Tac-Toe, un guide pas à pas permettant à chacun de créer un jeu à l’aide d’un backend Go, d’une conversion en WASM et d’une intégration React
- En revanche, le frontend React et la gestion de l’état du jeu via WASM nécessitent toujours un débogage et une implémentation manuels
Introduction
- Un ingénieur logiciel avec 15 ans d’expérience réalise qu’il n’a en fait jamais vraiment créé ni déployé de jeu lui-même
- Il décide de développer en Go l’un des jeux de cartes auxquels il jouait avec ses amis pendant son enfance en Argentine
Truco : 3 mois sans LLM
- À partir du 18 juin 2024, il commence à développer le jeu de cartes Truco avec un backend Go. Il écrit le frontend avec seulement des connaissances minimales de React
- L’implémentation de l’UI a été le plus grand défi. Pour éviter de fournir un serveur, il a utilisé TinyGo pour transpiler en WASM (WebAssembly), puis a déployé les fichiers statiques sur GitHub Pages
- Comme il n’y avait pas de LLM à disposition, il a dû trouver lui-même tous les détails et progresser par essais et erreurs, ce qui lui a pris environ 3 mois
- L’objectif n’était ni la publicité ni la monétisation, mais simplement de terminer le jeu, qui continue d’être joué régulièrement un an après sa sortie
- Jouer à Truco : https://marianogappa.github.io/truco-argentino
- Backend (Golang) : https://github.com/marianogappa/truco
- Frontend (React) : https://github.com/marianogappa/truco-argentino
Escoba : 3 jours avec un LLM
- Un an plus tard, lors d’un voyage en Argentine pour rendre visite à sa famille, il apprend à son neveu Escoba, le deuxième jeu de cartes le plus populaire
- Cette fois, il utilise un LLM (Claude) : il duplique le backend de Truco, décrit les règles d’Escoba dans un prompt et demande une refactorisation du code
- Dès le premier prompt, l’implémentation est presque parfaite, et il ne reste qu’à corriger quelques bugs mineurs et à ajouter quelques fonctionnalités à la main
- Le frontend a toutefois nécessité plusieurs jours d’implémentation et de débogage manuels. Les limites du LLM, son niveau en React et l’environnement particulier où l’état du jeu est géré dans WASM ont tous constitué des défis
- Jouer à Escoba : https://marianogappa.github.io/escoba-de-15
- Backend (Golang) : https://github.com/marianogappa/escoba
- Frontend (React) : https://github.com/marianogappa/escoba-de-15
Étapes : comment créer son propre jeu
- L’article présente un guide pratique minimal et des exemples de code pour permettre à d’autres d’essayer eux-mêmes de développer un jeu
- Un dépôt d’exemple Tic-Tac-Toe est fourni, qu’il est possible de forker pour démarrer
Développement du backend
- Un backend au tour par tour permet de concevoir clairement les fonctionnalités
- Conserver une architecture serverless, et éviter une structure où des humains jouent entre eux sans serveur commercial, est un choix réaliste
Développement du frontend
- Le frontend doit réaliser les tâches suivantes
- demander au backend la création d’un nouveau
GameState - afficher l’état dans l’UI
- fournir une interface pour sélectionner les actions valides
- envoyer une commande au backend lorsqu’une action est appliquée
- interroger le backend quand c’est au tour du bot
- demander au backend la création d’un nouveau
Conversion du backend en WASM
- Pour compiler le code Go en WASM, utiliser
GOARCH=wasm GOOS=js go build - La taille importante du binaire peut poser problème, d’où l’usage de TinyGo pour la réduire
- Pour exporter vers le frontend les fonctions nécessaires, il faut écrire en Go un point d’entrée distinct (par ex.
main_wasm.go) et bifurquer au moment du build - Dans la fonction principale, il faut bloquer avec
select {}afin d’éviter que le programme ne se termine immédiatement
Intégration des données entre backend et frontend
- Les structures Go flexibles comme
GameStatene peuvent pas être sérialisées/désérialisées directement dans WASM - Il est donc nécessaire d’échanger toutes les données au format JSON
- En s’appuyant sur la documentation fournie par TinyGo, les entrées comme les sorties sont transmises via sérialisation JSON
Interface frontend-backend
- Dans le frontend, les fonctions du backend sont appelées directement
GameStaten’est géré qu’à l’intérieur de WASM et le frontend ne peut pas le muter ; le backend reste toujours la source de vérité- Après recompilation du WASM, il faut remplacer le fichier ; un exemple d’automatisation via Makefile est fourni
Environnement d’exécution WASM
- Pour l’exécution, il faut inclure
wasm_exec.jsdans lehead, puis créer l’instance et la lancer à l’aide de ce script
Conclusion
- Créer un jeu a été une expérience plaisante, et l’approche Go + WASM + React est accessible à toute personne souhaitant essayer
- L’aide des LLM a fortement amélioré la productivité, mais les compétences frontend et l’expérience en débogage restent essentielles
- Chacun peut tenter de développer son propre jeu avec cette architecture, et cela vaut la peine d’essayer
4 commentaires
Si le code généré utilise
document.getElementByIddans React, quel LLM a bien pu être utilisé….On a presque l’impression d’un titre putaclic..
« Si on le crée à partir de zéro, il faut 3 mois ; si on refait quelque chose de similaire, 3 jours »
On dirait que l’auteur original ne sait pas vraiment ce qu’il fait d’habitude.
Avis Hacker News
Ce que j’apprécie dans ce billet, c’est qu’il pointe quelque chose que beaucoup de développeurs négligent. En développement de jeux, le code lui-même a rarement été le véritable goulot d’étranglement. Même un développeur solo peut créer rapidement des mécaniques sans IA. Les vraies difficultés se situent dans les couches moins visibles au-dessus : l’équilibrage de la boucle de jeu, le réglage de la difficulté, la création d’assets cohérents, le polish nécessaire pour retenir l’attention du joueur plus de cinq minutes, etc. C’est aussi pour cela qu’on n’a pas vu Steam se remplir de jeux exceptionnels depuis l’arrivée des LLM. La technologie a abaissé une barrière, mais les plus grandes sont toujours là. C’était déjà le cas avec l’essor d’Unity dans les années 2010. Le moteur a démocratisé le développement de jeux, mais au lieu d’une explosion du nombre de bons jeux, on a surtout vu augmenter le nombre de tentatives. Les LLM font la même chose pour le code, et les modèles d’image pour l’art, mais aucun de ces outils ne dit quel jeu est vraiment amusant. La question qui m’intéresse est plutôt : que se passerait-il si l’IA ne faisait pas que l’implémentation, mais aussi le playtest ? Autrement dit, si elle pouvait faire tourner des milliers de boucles et indiquer quelles mécaniques retiennent les joueurs simulés, on passerait du simple hack de productivité à un véritable partenaire de design. On n’en est pas encore là, mais ce billet ressemble à un premier point de donnée dans cette direction
À propos de l’idée qu’un avenir pourrait émerger où l’IA ne se contenterait pas d’implémenter, mais ferait aussi des playtests en bouclant des milliers de fois pour mesurer à quel point un jeu captive davantage les joueurs, cela soulève une question : comment l’IA pourrait-elle simuler un joueur, et pourquoi serait-elle réellement capable de juger de ce qui va captiver un humain réel ?
J’aimerais contester l’exemple de l’essor d’Unity dans les années 2010 en disant qu’il n’y a pas eu tant de très bons jeux que ça. En réalité, comparé à l’époque XBLA, l’énorme volume de jeux que nous avons aujourd’hui aurait été impossible sans des outils comme Unity, Godot, Gamemaker, Renpy ou RPG Maker. Il y a donc clairement eu une croissance spectaculaire, non seulement qualitative mais aussi quantitative
Pour moi, le test décisif de l’IA générative, c’est sa capacité à produire une spritesheet complète pour un jeu d’action 2D en pixel art. Par exemple, ne serait-ce que sortir parfaitement les mouvements d’un tank ou d’un personnage principal. Jusqu’ici, je n’ai encore jamais vu de cas de réussite
Je pense que l’idée centrale est bien : « l’IA ne peut pas dire si votre jeu est réellement amusant ». L’IA ne peut pas vivre un jeu comme un humain le fait, ni d’ailleurs vivre quoi que ce soit d’autre comme un humain. Elle ne peut au mieux que faire une certaine prédiction à partir de données d’évaluation humaine sur des jeux similaires. Autrement dit, l’IA ne peut pas apprécier votre jeu. Cette réalité fondamentale va définir le rôle des humains à l’ère de l’IA. L’IA peut produire des documents ou du code d’une manière approximativement humaine à partir de données passées, mais il existe une intégration et une expérience significatives que seuls de vrais humains peuvent apporter. Il y a un point où la valeur humaine ne peut pas être remplacée, même s’il faudra peut-être changer notre manière de regarder cette valeur
Ce schéma vaut aussi au-delà du développement de jeux. Comme beaucoup s’y attendent, le coding agentique a un potentiel énorme, mais pour l’instant seules certaines tâches sont résolues à une vitesse écrasante, comme des démos webapp rapides ou l’intégration de petites bibliothèques, alors que l’application au vrai logiciel de grande ampleur reste encore insuffisante. Que ce soit la manière dont les modèles ont été entraînés ou notre savoir-faire pour les utiliser, tout cela reste encore immature. Ce n’est pas surprenant. Même git, après son apparition, n’a été correctement adopté que par des entreprises d’élite pendant cinq ans, puis il a encore fallu cinq ans pour qu’il se généralise. Au final, on y est aujourd’hui très habitués, mais les LLM sont à mon avis encore plus difficiles à bien utiliser que git. Je me demande si cela n’aurait pas progressé plus vite s’il y avait eu moins d’exagération du type « c’est fini, tout est révolutionné » autour de chaque produit, chaque OSS, chaque billet de blog. Nous sommes encore dans l’essai-erreur et l’expérimentation, et cela prend du temps. Il ne faut pas juger trop vite. Si tout avait déjà été résolu, nous serions au moins ensevelis sous des logiciels bien meilleurs qu’aujourd’hui, alors qu’en réalité on est à peine en train d’atteindre un certain équilibre. Et c’est déjà assez impressionnant pour une technologie apparue depuis seulement un ou deux ans
Les 3 mois d’avance du LLM reposaient sur le code, l’utilisation du jeu précédent comme template, et surtout sur toute l’expérience accumulée ainsi que les erreurs faites en codant à la main
Au départ, je pensais que c’était juste un titre accrocheur, mais le passage disant en substance « j’ai copié le backend de Truco, donné à Claude une longue explication des règles d’Escoba, puis lui ai fait refactorer le code » m’a vraiment surpris. Je me demande combien de temps cela prendrait à une personne pour faire ce refactoring elle-même. Peut-être plus de trois jours, ou peut-être pas
Un autre point important est que c’était le premier jeu du participant. Au premier essai, il faut affronter un grand nombre d’inconnues, mais si l’on recommence après l’avoir déjà fait une fois, avec l’expérience et les enseignements acquis, on pourrait refaire le même projet bien plus vite que trois mois, même sans LLM
D’expérience, quand on répète le même projet une deuxième ou troisième fois, ce qui prenait plusieurs mois la première fois tombe facilement à un tiers du temps ensuite
<i>Tousse</i> J’ai déjà développé quelque chose en 24 heures, et il y a des exemples sur nordicgamejam.com. À l’époque, il n’y avait ni LLM, ni GenAI, ni Unity ; Microsoft XNA et C# étaient ce qu’on avait de mieux. L’art était lui aussi très rudimentaire, souvent dessiné à la main dans Paint. Et pourtant, il en sortait chaque année suffisamment de jeux amusants, dont certains sont même devenus connus du grand public, comme Baba is You ou Braid. Le code n’était pas le goulot d’étranglement ; personnellement, je suis convaincu que le vrai bottleneck, c’est la communication entre les membres de l’équipe
À lire ce fil de commentaires, beaucoup semblent écrire sans réelle expérience du développement de jeux. En pratique, les projets sur lesquels les LLM sont utilisés ici sont déjà très présents dans les données d’entraînement. Par exemple, ce sont aussi des projets abordés dans des cours d’initiation à la programmation, et dans les pays d’Europe du Sud il existe énormément de jeux proches du jeu de cartes décrit dans ce blog. Moi-même, en première année d’université, sans aucune expérience, j’ai implémenté Moon Patrol en Python depuis zéro ; cela m’a pris deux à trois mois en codant trois nuits blanches par semaine. Faire un jeu de cartes est encore plus simple que ça. Les LLM ont évidemment leur utilité, mais ce genre d’exemple simple n’est pas adapté pour benchmarker la productivité ou l’utilité des LLM pour le code
J’ai fait ce genre de travail avec un LLM en y revenant par intermittence pendant quelques jours : stacky. Au total, cela représente environ deux jours de vrai travail. Au début, c’était du développement from scratch, puis c’est devenu davantage du brownfield, sans intention particulièrement sérieuse d’en faire quelque chose d’achevé. Mais à mesure que j’ajoutais des détails et des fonctionnalités, les idées continuaient d’arriver, comme la super rotation, le DAS, etc. Le jeu n’est encore complété qu’à 10 ou 20 %. Une version WebGL tourne aussi. Mais si j’essayais d’en faire le Tetris ultime, j’aurais probablement droit à un procès, et je n’ai pas les moyens de payer une licence, donc j’ai arrêté. Au final, j’y ai surtout gagné en confiance et en expérience. Récemment, après avoir vu sur HN un lien au sujet des fonctions paramétriques, j’ai aussi créé en une ou deux heures le playground graphy. Là encore, on finit par passer énormément de temps sur les détails. Quand on sait clairement ce qu’on veut, ce genre de travail avec un LLM peut être très agréable
Je développe des jeux en amateur de façon régulière depuis un certain niveau, et j’en ai terminé plusieurs. Pourtant, en lisant ce fil, j’ai l’impression que beaucoup n’ont pas une grande expérience concrète du développement de jeux. Je ne peux pas être d’accord avec l’idée que coder est facile dans le développement de jeux. Trouver une idée originale ou une variation intéressante sur un genre est au contraire relativement simple ; la vraie difficulté, c’est bien davantage l’implémentation dans le code. Par exemple, imaginer un Vampire Survivors multijoueur avec de la personnalisation de BattleMechs, c’est facile ; l’implémenter uniquement avec un LLM est presque impossible. Le cas discuté ici repose sur les règles d’un jeu de cartes déjà totalement connu, donc c’est aussi simple qu’un jeu de serpent. Ce n’est pas une critique envers l’auteur du billet, mais je veux simplement souligner que beaucoup jugent le développement sans réelle expérience pratique du développement de jeux
Je ne suis pas d’accord avec l’idée que le code est la partie difficile du développement de jeux. Bien sûr, ça peut l’être, mais le vrai défi, c’est d’inventer quelque chose de nouveau et d’amusant. Une fois qu’on a une bonne idée, on peut la découper en petits morceaux, itérer, et finir par l’implémenter. Le vrai mur, c’est le moment où l’on part d’une page blanche pour décider quoi créer. Aller se promener, tout essayer, c’est un problème que l’art affronte depuis des millénaires. Le code, en revanche, reste au fond un travail d’ingénierie. J’apprends aussi le développement de jeux en ce moment, avec en parallèle des maths, et apprendre l’algèbre vectorielle ou les quaternions a été bien plus facile que de décider : « quel jeu ai-je vraiment envie de faire ? »
Globalement d’accord, mais pour moi c’est au contraire imaginer de nouvelles idées ou tenter quelque chose de créatif qui a toujours été le plus difficile. Je peux coder à peu près n’importe quelle mécanique de jeu, mais la partie écriture/créativité est vraiment ardue. Si cela vient naturellement à quelqu’un, cette personne a vraiment de la chance. Ce n’est pas quelque chose d’inné pour tout le monde
Si l’objectif est de créer un jeu entièrement côté client, je me demande pourquoi il est question d’un « backend », et pourquoi seule cette partie de l’application utiliserait une pile technique différente du reste
J’ai l’impression qu’il ne reste presque plus, dans l’industrie du logiciel, de domaines où une idée peut être réalisée facilement et rapidement. La concurrence est déjà si intense que même sur des marchés minuscules, on se retrouve à rivaliser directement avec du capital-risque mondial et de l’IA mondiale. Avant, on pouvait au moins trouver une niche que les grandes entreprises ignoraient. Aujourd’hui, qu’il s’agisse d’un grand VC ou d’une niche, il faut de toute façon se battre contre le monde entier. Au final, il ne reste soit que de petits marchés demandant une technologie extrêmement complexe, soit des domaines peu rentables, à forte probabilité d’échec et au cycle de vie court — ce qui est précisément le cas de la plupart des jeux. Dans le premier cas, il faut un marketing de terrain, presque au niveau d’aller voir chaque client pour expliquer le produit. De mon expérience dans l’industrie du jeu, même avant d’entrer vraiment en phase de développement, un « gros succès » ressemble déjà à « obtenir un million de vues et disparaître totalement six mois plus tard ». Comme il y a très peu de revenus récurrents, le simple fait de se lancer devient extrêmement démotivant. Faire un jeu comme Minecraft relève presque de la loterie. Cela dit, l’industrie du jeu reste, malgré tout, plus méritocratique que beaucoup d’autres secteurs du logiciel. La qualité et le plaisir de jeu ont tout de même un lien avec l’adoption. Dans d’autres secteurs, c’est un labyrinthe de régulation, d’effets de réseau créant des monopoles, ou de contrôle gouvernemental. Franchement, j’aimerais presque qu’au début l’État dise clairement : « ce domaine est déjà verrouillé par telle entreprise, n’allez pas y créer une startup, faites autre chose », au moins pour éviter de perdre un an
Je me demande à quel moment on comprendra enfin qu’un projet greenfield, totalement nouveau, est le pire cas possible pour benchmarker les compétences de coding agentique
J’aime les LLM parce qu’ils me permettent de manipuler le code d’une manière plus proche de la façon dont j’abstrais un programme dans ma tête. Quand je lis du code, je le comprends presque comme un AST, en transformant fonctions et appels en nœuds abstraits d’entrées et de résultats. Grâce aux LLM, le travail consistant à retransformer cela en code concret devient extrêmement simple. Plus besoin d’aller chercher partout des exemples correspondant à une idée ou de fouiller dans sa mémoire ; il suffit de demander au LLM d’écrire un bout de code répétitif comme une initialisation WiFi. Au final, on peut assembler un programme comme des briques de Lego. C’était déjà possible avant les LLM, mais cela demandait beaucoup plus d’efforts. Grâce à eux, je développe facilement dans toutes sortes de langages. Je n’apprends pas forcément beaucoup la structure interne ou la syntaxe des langages, mais c’est justement là tout l’intérêt. Le langage et la syntaxe sont des détails secondaires par rapport au flux logique du programme. Comme on est passé du code machine à l’assembleur, puis au C et à des langages de plus en plus haut niveau, on va désormais se rapprocher de plus en plus non pas du « code », mais du « programmer » lui-même. Personne ne sait quelle sera la forme finale, mais il est clair qu’on passera de plus en plus de temps à programmer, et de moins en moins à écrire