Vibe Coding : Comment Créer un Jeu Complet sans Écrire une Seule Ligne de Code avec l’IA

Vibe Coding : Comment Créer un Jeu Complet sans Écrire une Seule Ligne de Code avec l’IA

Je viens de terminer la création d’un incroyable jeu de stratégie, et je l’ai fait grâce au Vibe Coding – sans écrire une seule ligne de code. Je vais vous montrer exactement comment j’ai procédé. Les seules instructions que j’ai données étaient que je voulais un jeu de stratégie sci-fi au tour par tour basé sur une grille 2D. J’ai d’abord consulté Grock pour élaborer le concept, les règles et obtenir des conseils généraux. En quelques heures seulement, j’avais un jeu entièrement fonctionnel avec gestion de ressources, différents vaisseaux, un système de combat, un système de construction et une intelligence artificielle contre laquelle jouer. C’est vraiment incroyable.

Création du Concept Initial

Après avoir obtenu le concept initial, je me suis tourné vers Cursor avec Claude 3.7 Thinking. J’ai commencé avec un concept très simple : je voulais un jeu sur une grille 10×10, au tour par tour, dans un univers sci-fi. Grock a proposé le nom « Nebula Dominion ».

J’ai ensuite copié ce concept dans Cursor et demandé de construire le cadre du jeu. Il a mis en place les bases dans main.py et a commencé à utiliser des dépendances comme PyGame et NumPy. Il a créé des dossiers pour les images et les sons, ainsi qu’un fichier README contenant toutes les règles et les mécaniques de base du jeu.

Quand j’ai exécuté le code, j’ai immédiatement rencontré un problème courant : des modules manquants. Claude 3.7 Thinking a instantanément identifié et résolu le problème en installant les modules nécessaires.

Mise en Place de la Structure du Jeu

Nous avons ajouté un répertoire de jeu et un fichier gamestate.py pour gérer l’état du jeu. J’ai accepté tous les changements sans examiner le code et j’ai lancé le programme pour voir ce qui se passerait. Une grille vierge 10×10 est apparue à l’écran – c’était prêt !

Il était temps de donner vie à cette grille 10×10. J’ai demandé à Cursor et Claude 3.7 Thinking de consulter le fichier README, de comprendre le concept du jeu et ses mécaniques, puis de commencer à développer les éléments nécessaires.

Création des Unités de Jeu

Les éléments initiaux comprenaient quatre types de vaisseaux différents :
– La Corvette : un éclaireur rapide
– Le Mech : pour le combat terrestre
– Le Dreadnought : le puissant cuirassé
– Le Drone : pour extraire des ressources des planètes

J’ai commencé à cliquer pour voir ce qui fonctionnait. Le jeu avait déjà plusieurs fonctionnalités, comme les points de vie pour chaque unité et leur capacité de déplacement, mais il y avait encore beaucoup de problèmes et ce n’était pas un jeu complet.

Ajout de l’Intelligence Artificielle

Comme je n’avais pas de deuxième joueur disponible pour tester le jeu, j’ai simplement demandé à Cursor de créer une IA contre laquelle je pourrais jouer. Je ne pouvais pas vraiment distinguer les différentes unités, alors j’ai demandé à Cursor d’étiqueter chaque unité pour plus de clarté. Maintenant, quand je terminais mon tour, l’IA effectuait ses mouvements.

Amélioration de l’Interface Utilisateur

J’avais vraiment besoin d’infobulles pour voir le statut d’une unité : combien de points de vie elle possède, sa portée de déplacement, son type, etc. J’ai donc ajouté des infobulles au survol de la souris, ce qui a considérablement amélioré l’expérience.

Le déplacement des unités était encore très rudimentaire et manquait de fluidité. Par exemple, si vous cliquiez sur une unité puis sur une autre, vous deviez d’abord désélectionner la première unité avant de pouvoir sélectionner la seconde, ce qui n’avait aucun sens. J’ai donc amélioré cet aspect : lorsque vous sélectionnez une unité puis une autre, la première est automatiquement désélectionnée.

J’ai également voulu rendre évident quand une unité n’avait plus de mouvements disponibles, alors je l’ai grisée après qu’elle ait atteint son nombre maximum de déplacements.

Un autre problème était que je ne pouvais pas vraiment voir ce que faisait l’IA, car son tour se déroulait instantanément. J’ai donc demandé de ralentir le processus et de déplacer chaque pièce une par une pour que je puisse suivre ce qui se passait.

Implémentation du Système de Combat

À ce stade, le jeu fonctionnait plutôt bien, mais il manquait un système de combat. Quand j’essayais d’attaquer une autre unité, rien ne se produisait. J’ai donc ajouté un système de combat : si deux pièces ennemies sont adjacentes, elles peuvent s’attaquer mutuellement.

La logique était encore très simple : chaque unité avait un nombre de coups et un score de santé, et chaque coup réduisait la santé d’un montant exact. Ce n’était pas très sophistiqué, mais c’était fonctionnel.

J’ai également voulu voir un aperçu du combat, afin qu’en cliquant sur une unité, on puisse avoir une idée si on va bien s’en sortir dans cette bataille ou non. Cela devrait être familier aux joueurs d’autres jeux de stratégie au tour par tour.

Amélioration des Mécaniques de Jeu

Ensuite, je me suis concentré sur deux choses : les couloirs de distorsion (warp lanes) et l’interface utilisateur. Pour les couloirs de distorsion, je m’attendais à ce que différents couloirs apparaissent sur la carte et qu’en étant sur un couloir, on puisse se téléporter vers n’importe quelle autre case qui est également un couloir de distorsion, mais cela ne fonctionnait pas comme prévu. J’ai donc simplement expliqué comment je voulais que les couloirs de distorsion fonctionnent, et le problème a été résolu.

J’ai également demandé que les couloirs de distorsion apparaissent à au moins une case d’écart et j’ai ajouté des indicateurs visuels de portée de déplacement. Ainsi, en cliquant sur une unité, on peut voir jusqu’où elle peut se déplacer et où elle peut aller.

Cependant, nous ne pouvions toujours pas attaquer les bases, et la notion de bases n’était pas encore vraiment implémentée. J’utilisais les termes « base » et « centre de commandement » de manière interchangeable, ce qui a fini par me causer des problèmes plus tard et que j’ai dû corriger.

Conseil pour le Vibe Coding

Permettez-moi de faire une pause pour partager un conseil important que j’ai appris en faisant du Vibe Coding : ayez une spécification très claire. Vous pouvez utiliser l’IA pour vous aider à rédiger cette spécification, mais si vous utilisez une terminologie différente comme « base » versus « centre de commandement », cela se reflétera dans le code et vous aurez des problèmes, car une base et un centre de commandement sont deux choses très différentes dans le code réel.

Implémentation des Bases

Je voulais vraiment faire des bases une partie essentielle du jeu, c’est donc ce sur quoi je me suis concentré ensuite. Tout d’abord, j’ai créé des bases et les ai rendues attaquables. J’avais maintenant ma première condition de victoire : si vous détruisez la base ennemie, vous gagnez. Il y a donc cette notion d’exploration, mais aussi de ne pas trop s’éloigner pour ne pas laisser sa base vulnérable aux attaques, ce qui entraînerait la défaite.

J’ai ensuite commencé à développer un menu de construction. Je voulais pouvoir construire différentes unités. Au début, lorsque vous construisiez quelque chose, l’unité apparaissait immédiatement, mais j’ai pensé qu’une période d’attente d’un tour serait intéressante. Ainsi, vous sélectionnez une unité à construire, et au tour suivant, cette unité apparaît et devient utilisable.

Bien sûr, chaque type de vaisseau coûte un montant différent de nebula (la ressource du jeu), ce qui rend l’économie du jeu plus dynamique. Les drones coûtaient moins cher, les dreadnoughts plus cher, etc.

Amélioration des Visuels

À ce stade, je me suis rendu compte que les visuels très basiques, qui n’étaient que des carrés, des triangles et des formes similaires, ne seraient pas suffisants. J’ai donc commencé à ajouter des visuels en utilisant des sprites, mais j’ai fait cela hors caméra.

Je suis allé sur un site de téléchargement de sprites gratuits (les sprites sont simplement des animations ou des graphiques 2D que vous pouvez utiliser dans les jeux). Voici la partie la plus cool : j’ai téléchargé le dossier contenant tous les assets, je l’ai placé dans mon dossier de jeu et j’ai demandé à Cursor de consulter ce dossier, de déterminer, en fonction du nom de chaque fichier, lequel serait approprié pour chaque unité, planète, case, etc., et de les attribuer. Et ça a marché ! C’était vraiment impressionnant. Il y en avait quelques-uns qui n’avaient pas de sens, et je les ai simplement corrigés en expliquant ce que je voulais à la place.

Le jeu commençait à prendre forme et à avoir vraiment fière allure. Les vaisseaux avaient des graphismes, les planètes avaient des graphismes, les tuiles d’arrière-plan avaient des graphismes, c’était agréable.

Tests et Débogage

J’ai ensuite commencé à tester le jeu, et il y avait beaucoup de problèmes. J’ai donc commencé à les corriger. Par exemple, parfois la condition de victoire était déclenchée immédiatement après le premier tour. J’ai simplement décrit ces problèmes, laissé Cursor les corriger, et nous étions sur la bonne voie.

J’ai ajusté la logique d’accessibilité avec nebula, j’ai modifié certaines portées, certains points de vie, etc., et le jeu a commencé à ressembler à un jeu réellement bien équilibré.

Je voulais également un moyen de tester les conditions de victoire sans avoir à jouer le jeu entier à chaque fois. J’ai donc ajouté un peu de débogage où je peux déclencher la destruction de la base pour chaque joueur ou la destruction de toutes les unités pour chaque joueur. Au début, c’était avec des commandes clavier, et j’ai fini par en faire une sorte de menu caché.

J’ai testé les conditions de victoire et elles fonctionnaient parfaitement. Ensuite, j’ai refactorisé une grande partie du code (hors caméra). J’ai littéralement dit à Cursor de refactoriser le code, et il l’a fait.

Résultat Final

Au final, j’avais des déplacements, des combats, un système de construction, des conditions de victoire et toute une histoire derrière le jeu. C’était en fait un jeu plutôt cool, et j’ai beaucoup appris.

Je dirais qu’au total, j’ai probablement passé 4 heures à construire ce jeu, et la majorité de ce temps était simplement consacrée à attendre que Cursor termine, ce que je pouvais faire en arrière-plan tout en faisant d’autres choses. J’écrivais une commande, je la laissais s’exécuter pendant quelques minutes (jusqu’à 10 minutes parfois), puis je revenais voir et je continuais. C’était presque du codage asynchrone.

Conseils pour le Vibe Coding

J’ai construit d’autres projets depuis celui-ci et j’ai beaucoup appris. Voici quelques conseils :

  1. Effectuez des commits régulièrement : j’ai remarqué que lorsque je changeais une chose, trois autres se cassaient ou changeaient d’une manière inattendue. Assurez-vous donc d’utiliser Git et de faire des commits fréquents. Chaque fois que vous obtenez un état fonctionnel du jeu, faites un commit pour avoir un point de sauvegarde. Cursor peut le faire pour vous – il suffit de dire « commit le code et pousse-le sur GitHub ».

  2. Écrivez des tests au fur et à mesure : une fois que vous avez un bon état du jeu, demandez à Cursor d’écrire des tests pour vous (tests d’intégration, tests unitaires, ce que vous voulez). Les tests d’intégration sont probablement les plus appropriés. Laissez-le tester pour vous et assurez-vous que les tests passent.

Voici mon flux de travail : je fais des changements, je les teste manuellement pour m’assurer qu’ils fonctionnent, je demande à Cursor d’écrire des tests, je m’assure que tous les tests passent, puis je commit et je pousse le code, et je commence ma prochaine fonctionnalité.

C’est mon flux de travail pour ce jeu et pour d’autres projets cool que je construis. Je suis complètement fasciné par le Vibe Coding. J’apprécie vraiment le codage, je n’ai pas codé autant depuis longtemps. Je ne considère même pas cela comme du codage, c’est presque comme tricher.