Un jeu créé après plus de 20 ans grâce au vibe coding : Mirror Break Out
(mirror-breakout-web.vercel.app)À l’été 2004, alors que je terminais mon service militaire, je me demandais comment occuper mon temps libre et j’ai commencé à concevoir un jeu. À l’époque, mon frère étudiait le game graphic design, alors je me disais qu’une fois démobilisé, ce serait bien de créer quelque chose ensemble. (Ah… moi, je suis un simple étudiant en lettres. Zéro bagage technique.)
Comme c’était un défi amateur, je voulais faire quelque chose de petit et simple. En partant d’un casse-briques (Arkanoid), l’un des jeux les plus abordables à réaliser, j’y ai ajouté un nouveau mode d’affrontement. C’était déjà un jeu dont d’innombrables versions existaient, mais je n’en avais vu aucune conçue comme la mienne.
Après ma démobilisation, j’ai réuni mon frère et quelques-uns de ses amis pour monter une équipe avec ambition, mais très vite chacun a eu ses propres contraintes et le projet est tombé à l’eau. Je me suis dit que je le ferais à la prochaine occasion, mais cette occasion n’est jamais revenue. Les années ont passé, et même en travaillant, cette idée me revenait parfois. À une époque où j’avais essayé d’apprendre un peu Python, j’en avais même fait mon objectif, mais c’était une tâche bien trop difficile pour moi.
Et puis le temps a continué à passer, encore et encore, jusqu’à l’été dernier, plus de 20 ans plus tard. Après une réunion, je dînais avec les dirigeants des entreprises présents, et tous disaient qu’avec l’IA on pouvait désormais créer énormément de choses, au point qu’ils avaient tous envie de relancer une startup. Stimulé par cette discussion, je suis rentré chez moi le soir et j’ai installé Claude Code, dont j’entendais parler sans l’avoir essayé. Et deux heures plus tard… bam !!
Je me demandais quel premier projet lui confier, puis j’ai repensé à cette idée d’il y a 20 ans et je lui ai donné mes instructions. Environ deux heures plus tard, sous mes yeux, une raquette et une balle bougeaient et cassaient des briques. Le frisson que j’ai ressenti à ce moment-là… Vous avez sans doute l’habitude de ce genre de témoignage maintenant qu’on en voit partout, mais six mois plus tard, je ne peux plus vivre sans Claude Code.
J’ai ensuite peaufiné le jeu petit à petit, et il est désormais à un niveau où je peux au moins le présenter comme une démo, alors je prends mon courage à deux mains pour le partager. Et en plus sur GeekNews, où je me contentais de lire en silence jusque-là !! À l’origine, je l’avais imaginé comme un jeu de duel à deux joueurs, mais la fonctionnalité multijoueur était une marche trop haute pour moi, donc j’en ai fait une version où l’on affronte l’ordinateur.
Pour le présenter simplement,
- C’est pour ordinateur. La version mobile n’est pas encore prise en charge.
- C’est un casse-briques où deux joueurs jouent dans le même espace, dos à dos. Le premier qui détruit toutes ses briques gagne.
- Si je rate la balle, elle passe dans la zone de l’adversaire. Si l’adversaire la rate, elle revient chez moi.
- J’y ai intégré des notions de physique du monde réel : poids, impact, accélération et inertie. C’est plus difficile qu’on ne l’imagine.
- Comme c’est une version démo, on peut rejouer en relançant une partie après chaque manche.
- Comme dans les salles d’arcade d’autrefois, si vous établissez un record, vous pouvez y inscrire votre nom.
Quelques leçons tirées du développement :
- Refactoring ! Refactoring ! Refactoring !
- J’ai enfin compris ce qu’était ce fameux refactoring dont j’entendais parler, et je me suis dit qu’il existait peut-être quelque part un enfer du refactoring.
- Au début, porté par mes rêves, j’ai morcelé les fonctionnalités dans tous les sens en imaginant Battle.net et en gonflant le projet, puis au milieu d’un déluge de bugs j’ai fini par tout remettre à zéro, avant de re-découper puis re-fusionner… C’était avant la sortie d’Opus 4.5.
- Rien qu’en réalisant ce petit projet, j’en suis arrivé à avoir un profond respect pour les programmeurs.
Heureusement, aujourd’hui j’ai davantage conscience de mes limites, je découpe le travail en petites tâches, je crée des documents de workflow, et je suis devenu quelqu’un qui tient soigneusement ses logs de développement et ses commits Git. Le plus grand bénéfice, c’est que j’ai maintenant énormément de choses que j’ai envie d’essayer. Je réfléchis activement à créer moi-même les outils dont j’ai besoin dans mon travail.
Je me demande quoi faire de ce jeu. Dans ma situation actuelle, il m’est difficile de le développer sérieusement, mais en même temps ce serait dommage de simplement l’enterrer. J’espère qu’il pourra devenir un jeu que les enfants prendront plaisir à découvrir.
J’apprends toujours beaucoup grâce aux actualités de GeekNews, et je les lis avec reconnaissance. Merci.
14 commentaires
Le concept est amusant, mais la maniabilité est vraiment mauvaise. Je ne pense pas qu’appliquer de l’inertie aux commandes dans ce type de jeu soit une bonne idée. Cela me semble être un sujet assez différent de la difficulté.
Merci pour votre avis. J’ai réfléchi au point que vous avez soulevé et j’ai réduit l’inertie de moitié pour rendre le jeu plus facile à contrôler. J’avais donné la priorité au concept physique que j’avais en tête, mais cela m’a amené à réfléchir davantage à la maniabilité du jeu et à la manière de gérer les collisions. Je vais continuer à l’améliorer. (Mon activité principale est devenue plus prenante, donc la prise en compte de vos retours a été retardée.)
Qui est donc FURY… Il a laissé un score impressionnant. ;;
Le jeu intègre des concepts physiques du monde réel comme la masse, l'impact, l'accélération et l'inertie. C'est plus difficile que je ne le pensais.
Comme la formulation laisse sentir une compréhension un peu limitée de la physique du jeu, ce serait bien de la retravailler un peu.
Veuillez le peaufiner vous-même, haha. Et évitez de frimer devant un littéraire.
Merci de vous soucier du moral des étudiants en lettres. Haha ^^
La raison pour laquelle il m’est difficile de reformuler la phrase pour vous, c’est que je n’ai pas vu le code que vous avez écrit et que je ne sais donc pas de quelle manière vous avez implémenté le moteur physique.
Je vous présente mes excuses pour la remarque non souhaitée que j’ai faite.
Beaucoup de personnes font la promotion de leurs produits, et comme il arrive souvent qu’elles les promeuvent avec l’IA ou ajoutent des explications inappropriées, je laisse parfois un commentaire. Ce n’était pas un commentaire écrit pour vous mettre en colère.
Merci pour votre intérêt. Je ne l’ai pas du tout mal pris. J’apprécie toujours les conseils. Au contraire, je n’ai pas bien compris ce qu’il faudrait corriger ni comment, donc ce serait bien si vous pouviez l’expliquer un peu plus en détail.
Pour expliquer davantage ce que je veux dire par l’application d’une physique réaliste : ce type de jeu se contente généralement d’une détection de collision et de réflexions très simples. Mais je voulais que, comme dans un vrai flipper, on ressente lors des collisions entre la balle et les briques l’énergie de l’impact liée à la masse et à la vitesse réelles. J’ai donc cherché puis utilisé Planck.js, que je trouvais plus précis qu’une bibliothèque de jeu classique. J’ai représenté le fait que lorsqu’une brique est touchée par la balle, elle est poussée par le choc et se met à tourner. Il est aussi possible, dans les paramètres, de modifier la masse de la balle, la masse des briques, l’atténuation de l’énergie de collision, la résistance, etc., ce qui permet d’obtenir des expériences différentes selon la configuration.
(Il existe un réglage que j’appelle le mode fou : si on met la masse de la balle au maximum et celle des briques au minimum, le jeu devient extrêmement dynamique.)
Le code est aussi sur GitHub.
https://github.com/gogodevelop2/mirror-breakout
Oui, pour vous faire un commentaire,
j’ai l’impression que vous avez surtout consacré davantage d’efforts à la conception des collisions, au réglage du coefficient de restitution, etc. Et en particulier, comme les collisions sont calculées et produites à partir de la masse et du coefficient de restitution de chaque élément, si je dois évoquer les points qui diffèrent de ce que vous visiez,
la masse ou la vitesse du
paddleou desbrickn’influençant en réalité que la quantité de mouvement de laball, il s’agit en substance moins d’une physique réaliste que d’une approche inspirée d’un modèle physique, où vous avez plutôt codé séparément les collisions entre la balle et les différents éléments (brick,paddle, mur).Par conséquent, plutôt que de parler de physique réaliste, il me semblerait préférable d’expliquer que vous avez repris certains éléments d’un moteur physique pour concevoir de manière dynamique les collisions et les variations de quantité de mouvement.
En particulier, comme certains changements de quantité de mouvement dus à un processus de collision peu réaliste ont été appliqués sous forme de correction de vitesse, cela peut, du point de vue des sensations de jeu, soit paraître astucieusement dissimulé, soit sembler assez peu bienveillant pour le joueur.
Pour l’expliquer un peu plus simplement,
le modèle utilise des formules et des méthodes de calcul issues de la physique, mais au final il ne reste pas réaliste,
et de nombreuses corrections ont été ajoutées pour empêcher, du point de vue du gameplay, les problèmes qui surgissent dans ces aspects non réalistes (vitesse infinie, arrêt, contrôle de la direction, etc.).
Merci pour ces explications détaillées. J’ai très bien compris. Comme c’était ma première expérience de création de jeu, je connaissais mal l’univers de la physique du jeu ainsi que l’usage approprié des termes, donc j’avais rédigé mon explication d’une manière qui pouvait prêter à confusion. Avec vos explications, je crois mieux comprendre à quel niveau les professionnels du secteur évaluent les réalisations. Je n’arrive pas à trouver comment modifier le texte principal… Je vais me renseigner et le corriger. Merci.
Merci. Haha, moi aussi, je soutiendrai vos activités de loisir !