Quelle taille donner à votre premier jeu ?

Assez petit pour être terminé : une action, un écran, une façon de gagner ou de perdre, quelques minutes de jeu. Voici comment y ramener une idée plus grande.

Assez petit pour que vous puissiez le terminer : une seule chose que fait le joueur, un écran, une façon de gagner ou de perdre, et un jeu entier qui se joue en quelques minutes. Si vous pouvez le construire en un week-end, ou en deux semaines de soirées, c'est la bonne taille. Un assistant de programmation IA vous amène plus vite à une version jouable, mais il ne change pas la réponse, et cet article explique pourquoi. Pour réduire une idée plus grande, écrivez le jeu en une phrase, gardez seulement ce dont cette phrase a besoin, et déplacez tout le reste dans une liste appelée « plus tard ».

À quoi ressemble un petit jeu ?

Utilisez quatre limites.

• Une action. Le joueur se déplace, ou saute, ou associe des éléments, ou vise. Une seule de ces choses.
• Un écran, ou un niveau qui se répète et devient plus difficile.
• Une façon de gagner ou de perdre. Un score à battre, un chronomètre ou des vies qui s'épuisent.
• Quelques minutes entre l'appui sur « démarrer » et le résultat.

Deux repères publics montrent qu'un jeu qui respecte ces limites est un vrai jeu.

Le premier est une game jam. Dans la catégorie Compo de Ludum Dare, une personne crée un jeu à partir de zéro en 48 heures ; la catégorie Jam donne 72 heures et autorise les équipes. Son règlement décrit la participation idéale comme un jeu joué dans le navigateur, en quelques minutes, seul. C'est ce que disait la page du règlement le 9 octobre 2026.

Le second est un tutoriel. Le 2D breakout game de MDN comptait onze leçons le même jour : un canvas, une balle qui bouge, des murs, une raquette, la fin de partie, un champ de briques, un score et une victoire, des vies supplémentaires, puis des animations, des boutons et un peu de hasard. Cette liste donne une bonne image de ce que « complet » veut dire à cette taille.

Pourquoi la petite taille compte-t-elle encore quand une IA écrit le code ?

Parce qu'écrire le code n'a jamais été tout le travail. Un assistant raccourcit l'écriture. Trois choses restent à votre charge.

Vous devez toujours jouer chaque modification. Quelqu'un doit lancer le jeu après chaque modification, l'essayer et décider s'il est meilleur qu'avant. Ce quelqu'un, c'est vous.

Les fonctionnalités se multiplient. Une nouvelle fonctionnalité doit fonctionner avec toutes celles qui existent déjà. Trois fonctionnalités forment trois paires qui peuvent entrer en conflit. Six en forment quinze. Douze en forment soixante-six. La vérification grandit beaucoup plus vite que la liste des fonctionnalités.

Une demande touche plus que ce qu'elle nomme. « Ajoute une boutique » ressemble à une seule tâche. Elle modifie le score, l'écran de pause, les commandes et ce qui est sauvegardé, et chacun de ces points doit être vérifié ensuite, quel que soit l'auteur du code.

Un petit jeu est un jeu que vous pouvez garder en tête. Vous pouvez décrire une modification avec précision, lire ce qui est revenu et remarquer ce qu'elle a cassé.

Que coûte plus tard chaque fonctionnalité supplémentaire ?

Elle coûte de nouveau chaque fois que vous ajoutez une plateforme ou une langue. Nous l'avons vu avec KittenGalaxy, le jeu de tir hébergé sur HeapPlay.

Quand nous avons ajouté des commandes tactiles, le travail s'est compté par écran, pas par jeu : le menu, la saisie du nom, le vol, la boutique, le défi de maths et les écrans de fin de partie et de fins ont chacun eu besoin de leurs propres commandes. Quand le jeu est passé en dix langues, chaque écran a été vérifié dans chacune d'elles, comme l'indique la page du jeu.

Aucun de ces deux travaux n'était une erreur. Mais la taille des deux dépendait du nombre d'écrans que le jeu avait déjà. Un jeu à un seul écran paie ce prix une fois.

Comment ramener une idée à cette taille ?

1. Écrivez le jeu en une phrase : ce que fait le joueur, et comment cela se termine. Par exemple : « Vous dirigez un vaisseau à gauche et à droite et vous tirez sur des envahisseurs jusqu'à épuisement de vos vies. »
2. Listez tout le reste de ce que vous avez imaginé. Des boss, une boutique, deux joueurs, une histoire. Notez tout, pour que rien ne se perde.
3. Gardez seulement ce dont la phrase a besoin. Si la phrase reste vraie sans une fonctionnalité, celle-ci va dans la liste « plus tard ». Elle est reportée, pas supprimée.
4. Réduisez le contenu avant de réduire l'idée. Un type d'ennemi, pas cinq. Une vague qui accélère, pas vingt niveaux.
5. Fixez la durée avant de commencer. Un week-end, ou deux semaines de soirées. Quand vous prenez du retard, retirez quelque chose du jeu et gardez la date.

Voici cet exemple après la coupe.

Comment garder cette taille en travaillant avec un assistant ?

• Mettez la phrase et la liste « plus tard » dans un fichier du projet, et indiquez-le à l'assistant au début de chaque session.
• Demandez un élément à la fois, et jouez au jeu avant de demander le suivant.
• Enregistrez une version qui fonctionne avant chaque demande, sous forme de commit dans la gestion de versions, pour pouvoir annuler une mauvaise modification.
• Quand une modification apporte plus que ce que vous avez demandé, retirez le surplus. Les fonctionnalités que personne n'a demandées font aussi partie du périmètre.

Comment savoir qu'il est terminé ?

Décidez-le avant de commencer, et écrivez-le. Un premier jeu est terminé quand :

• un inconnu peut le lancer depuis un lien sans un mot de votre part ;
• les commandes sont affichées à l'écran ;
• on peut perdre, et recommencer sans recharger la page ;
• vous y avez joué du début à la fin sur chaque appareil que vous dites pris en charge, et vous dites quels appareils vous n'avez pas essayés.

Mettez-le ensuite là où les gens peuvent y jouer. Un jeu aussi petit reste un jeu : les règles de proposition de HeapPlay demandent un vrai jeu jouable avec un lien officiel, et ne fixent aucune taille minimale. Vous pouvez le proposer sans compte, et un éditeur examine chaque proposition avant qu'elle n'apparaisse.

Que devient la liste « plus tard » ?

Elle devient votre plan, dans un ordre que vous n'avez plus à deviner. Une fois que des gens jouent à la petite version, ce qu'ils disent vous indique quel élément prendre en premier. Ajoutez celui-là, publiez-le comme une nouvelle version, et écoutez de nouveau.

Questions fréquentes

Combien de temps un premier jeu doit-il prendre ? Il n'existe pas de réponse mesurée. Choisissez une limite que vous pouvez tenir, puis ajustez le jeu à cette limite. Ludum Dare donne à ses participants 48 ou 72 heures.

Un clone d'un classique suffit-il ? Comme exercice, oui : vous savez déjà à quoi ressemble « terminé ». Avant de le montrer à d'autres, changez une chose pour qu'il soit le vôtre.

Mon premier jeu doit-il être le jeu de mes rêves ? Faites d'abord sa plus petite partie jouable, et gardez le reste dans la liste « plus tard ».

Puis-je commencer plus grand parce qu'un assistant IA écrit le code ? Vous arriverez plus vite à une version jouable. Jouer, vérifier et décider restent à vous, et ce travail grandit avec chaque fonctionnalité.

Un jeu de trois minutes vaut-il la peine d'être publié ? Oui, s'il est complet. Les joueurs peuvent le noter et donner leur avis, et les développeurs vérifiés peuvent enregistrer chaque nouvelle version et ce qui a changé.