Transformer l’idée en test, pas en liste de souhaits
Vous pouvez créer un jeu avec l’IA en définissant une boucle jouable, en demandant une petite implémentation et en vérifiant le résultat avant d’en ajouter davantage. Un prompt est une entrée, pas une preuve que les fonctionnalités demandées fonctionnent. Après la génération, la question utile n’est pas « Cela ressemble-t-il à un jeu ? », mais « Le joueur peut-il agir, atteindre l’objectif, comprendre son échec et recommencer ? »
Ce guide associe un exemple SEELE documenté et conservé à un descriptif pédagogique distinct. L’exemple dispose d’un lien jouable et d’enregistrements ; le descriptif pédagogique n’a été ni généré ni testé pour ce brouillon. Séparer ces catégories évite de confondre un processus plausible avec une réussite rapportée.
Ce que montre l’exemple documenté de survie face aux zombies
L’article source décrit un enregistrement de génération SEELE d’octobre 2026 demandant un jeu Three.js de survie face aux zombies à la première personne. Les fonctionnalités demandées comprenaient le déplacement avec verrouillage du pointeur, les armes à feu, le rechargement, la visée, l’accroupissement, le sprint, les objets à ramasser et une mini-carte.
La description de l’enregistrement du résultat dans l’article source identifie une arme en vue subjective, une interface de santé et de munitions, une mini-carte, un compteur de vagues, des ennemis et une invite de ramassage. L’enregistrement de gameplay de 21,5 secondes ne couvre qu’une partie de la première vague. Ces éléments visibles ne prouvent pas à eux seuls le fonctionnement du rechargement, de l’accroupissement, de chaque interaction de ramassage, d’une session complète de cinq vagues ni la compatibilité avec d’autres navigateurs. Ce sont les limites de l’exemple publié, pas le compte rendu d’une nouvelle session terminée en pratique.
L’image documente le processus guidé par prompt pour ce projet précis.
Ouvrir le projet jouable existant.
Copier un descriptif réduit pour une première version
Utilisez l’exemple pédagogique suivant lorsqu’un jeu de tir comporte trop de systèmes en interaction pour une première tentative :
Exemple pédagogique, pas une version testée : crée Signal Run, un jeu pour navigateur sur un seul écran en vue de dessus. Le joueur se déplace avec WASD ou les flèches, ramasse trois batteries et atteint une sortie visible. Affiche le nombre de batteries et les commandes. Un danger se déplace horizontalement entre deux points fixes. Un contact affiche un écran de défaite ; atteindre la sortie sans toutes les batteries affiche un message indiquant la condition requise. Ramasser les trois puis atteindre la sortie affiche un écran de victoire. R recommence après l’une ou l’autre issue et restaure le joueur, les batteries, le compteur et le danger. Utilise des formes provisoires lisibles. N’ajoute ni ennemis, armes, sauvegardes, réseau, niveaux supplémentaires ni paiements. Explique les composants du projet modifiés et donne des vérifications pour déplacement, collecte, victoire, défaite et redémarrage.
La création de jeux guidée par prompt de SEELE est pertinente pour passer du descriptif au prototype. Les commandes et le comportement de réinitialisation demandés doivent toutefois être vérifiés dans le résultat réel ; la formulation du prompt ne les garantit pas.
Étape 1 : examiner la première boucle jouable
Avant de peaufiner, exécutez la version cible prévue et suivez les commandes affichées dans le jeu. Vérifiez les déplacements dans toutes les directions et confirmez qu’on ne peut pas sortir de la zone de jeu. Ramassez une batterie, puis repassez à son ancien emplacement : le compteur ne doit pas augmenter une deuxième fois.
Essayez la sortie trop tôt et notez le message. Terminez le parcours de collecte et vérifiez la victoire. Touchez volontairement le danger et vérifiez la défaite. Recommencez après les deux issues. Si le danger se réinitialise mais pas les batteries, signalez cette différence précise au lieu de demander à l’IA de « réparer le jeu ».
Étape 2 : utiliser le cas pour créer un registre de vérification
Pour chaque fonctionnalité, conservez quatre champs : comportement demandé, preuves disponibles, comportement observé et statut. Dans l’exemple des zombies, une mini-carte visible appartient au champ des preuves ; la précision du suivi de position reste non vérifiée tant qu’elle n’a pas été testée. Une demande de rechargement relève de la spécification jusqu’à ce que vous puissiez enregistrer l’action et les changements de munitions.
Appliquez la même discipline à Signal Run. « Trois batteries demandées » ne signifie pas « trois objets distincts correctement comptés ». Marquez les points incertains comme non vérifiés au lieu de combler le manque par une légende affirmative. Ce registre réduit la portée du prochain prompt et donne aux collaborateurs une description fiable de la version.
Étape 3 : modifier une règle et rejouer la boucle
Après avoir sauvegardé une version fonctionnelle, demandez une seule modification : réduire de 20 % la vitesse du danger tout en préservant son trajet et toutes les règles de collecte. Répétez la même traversée depuis le même point de départ, comparez les temps et testez à nouveau les deux états de fin.
Si le déplacement se casse après une modification visuelle sans rapport, revenez à la version fonctionnelle connue et réduisez la portée de la demande. Fournissez l’erreur exacte, l’environnement cible, le comportement attendu et la séquence de reproduction la plus courte. Évitez d’empiler de larges réécritures sur un échec inexpliqué.
Étape 4 : vérifier séparément les livrables techniques
Un lien jouable ne constitue pas la livraison d’un projet source. Avant de compter sur un outil pour poursuivre le développement, vérifiez les options d’accès au projet et d’export du forfait actuel. Si le format demandé est disponible, sauvegardez une copie versionnée et inventoriez son point d’entrée, ses fichiers sources, ressources, manifeste de dépendances, fichier de verrouillage et instructions d’exécution. Demandez ce qui a été généré, ce qui est une dépendance et ce qui nécessite un service distinct. Ne publiez pas d’identifiants, de points d’accès privés ni de jetons de compte avec le projet.
Dans un dossier vierge séparé, suivez les commandes documentées d’installation et d’exécution pour ce moteur ou framework précis. Notez la version de l’environnement d’exécution et toute dépendance manquante. Répétez déplacement, collecte, victoire, défaite et redémarrage sans dépendre de l’espace de travail hébergé. Si la version locale échoue ou si l’export n’est pas disponible, consignez cette limite ; un aperçu hébergé ne peut pas combler le manque de preuve. Aucun export source ni lancement local n’a été établi pour l’exemple de zombies conservé.
Étape 5 : préparer un partage limité et honnête
Avant de partager, vérifiez le chargement dans un environnement propre, la lisibilité des commandes, le son s’il existe, le focus clavier et le redémarrage. Examinez les conditions actuelles de l’outil et des ressources pour l’usage prévu. Testez un second navigateur ou appareil avant de déclarer sa prise en charge. Reliez les affirmations de performance à un matériel identifié et à une méthode consignée, pas à la fluidité apparente d’un extrait intégré.
Commencez votre propre petit prototype avec SEELE et le descriptif ci-dessus. Conservez la version fonctionnelle, le prompt exact et ses notes de test avant d’en demander davantage. L’étape à atteindre est une boucle vérifiée, pas une longue liste de fonctionnalités : un nouveau joueur peut se déplacer, comprendre l’objectif, atteindre les deux issues et recommencer. N’ajoutez des niveaux et des ressources plus riches que lorsque cette boucle peut être démontrée sans explication de son créateur. Si poursuivre hors de l’espace de travail est important pour votre projet, traitez la livraison du code source et l’exécution locale dans un environnement propre comme des critères d’acceptation distincts plutôt que comme des hypothèses tirées de l’aperçu.
Tableau des preuves et de l’acceptation
Ce tableau organise les vérifications proposées dans l’article. Il ne présente pas les résultats d’un test effectué.
| Affirmation ou tâche | Ce que la source ou le descriptif établit | Ce qui reste à vérifier |
|---|---|---|
| Exemple de survie enregistré | L’article décrit un court enregistrement de gameplay et identifie des éléments d’interface et des ennemis visibles. | Ne pas déduire d’un court extrait le comportement d’une session complète ou la compatibilité des navigateurs. |
| Boucle jouable | Le descriptif pédagogique propose une action, un objectif, un état d’échec et un redémarrage. | Exécuter chaque comportement dans la version réelle et consigner le résultat. |
| Modification | Le processus demande une modification limitée. | Répéter les vérifications de référence après son application. |
| Livraison technique | La livraison est une étape distincte du processus. | Inspecter les fichiers réels, instructions de configuration et usages autorisés. |
FAQ
Une courte vidéo de gameplay peut-elle prouver que tout le jeu fonctionne ?
Non. Elle n’étaye que ce qui est visible pendant la période enregistrée. Une interface peut apparaître sans que toutes les règles sous-jacentes soient correctes. Utilisez une liste de fonctionnalités, des entrées reproductibles et des enregistrements ciblés plus longs pour établir les comportements. Distinguez vidéo de processus, aperçu visuel et test de gameplay terminé.
Dois-je comprendre chaque fichier généré ?
Vous devez en comprendre assez pour tester le jeu, protéger les versions fonctionnelles et localiser les changements pertinents. Demandez à l’assistant d’expliquer les composants et hypothèses en termes simples. Pour un comportement propre à un moteur que vous ne connaissez pas, consultez sa documentation actuelle. Évitez d’accepter une vaste réécriture de code uniquement parce que son explication semble techniquement convaincante.
Quand remplacer les graphismes provisoires ?
Une fois la boucle lisible et reproductible. Remplacez les ressources par petits groupes et vérifiez à nouveau collision, échelle, contraste, chargement et droits. Des médias attrayants peuvent améliorer la communication, mais ne vérifient pas une mécanique non testée. Identifiez honnêtement les images conceptuelles au lieu de les présenter comme des captures d’un résultat généré fonctionnel.
Choisissez un flux de travail pour le prochain jalon jouable
Utilisez un créateur de jeu lorsque la prochaine décision peut être testée dans une boucle jouable par navigateur. Si un projet dispose déjà d'un moteur, d'actifs ou d'une base de code, testez un assistant sur une modification limitée au sein de cet environnement. Conservez une liste de contrôle d'exportation et d'actifs à côté des notes de test de jeu afin qu'un résultat jouable et un projet portable puissent être évalués séparément.
