Sans LLM, créer un jeu prend 3 mois ; avec un LLM, 3 jours

• 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
  • Backend : https://github.com/marianogappa/tictactoe-backend
  • Frontend : https://github.com/marianogappa/tictactoe-frontend
  • Démo : https://marianogappa.github.io/tictactoe-frontend/

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

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 GameState ne 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
• GameState n’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.js dans le head, 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