Un jeu qui s’ouvre dans un navigateur n’est pas nécessairement un projet dont on peut poursuivre le développement. La question suivante est de savoir si l’on peut le reproduire, expliquer ses règles et ajouter une fonctionnalité sans compromettre la partie d’origine. Pour le vérifier, conservez une version de référence et définissez précisément une petite extension : une capture d’écran ou l’assurance que le code est modifiable ne suffisent pas. Cet article propose un test de continuation reproductible pour un petit jeu de collecte d’étoiles. Il ne s’agit pas d’un compte rendu d’essai effectué : aucun projet source, aucune exécution de référence ni aucun correctif d’extension n’étaient disponibles pour cette ébauche. L’exigence de résultats réels reste donc insatisfaite. Utilisez le protocole pour recueillir les preuves manquantes ; ses critères d’acceptation ne constituent pas des conclusions sur SEELE ou sur un projet généré.
1. Définir le projet et ses règles d’origine
Utilisez un cas de test délimité : un jeu pour navigateur sur ordinateur, avec déplacement aux flèches, cinq étoiles à collecter, une partie de 30 secondes, une victoire lorsque les cinq étoiles sont ramassées, une défaite à la fin du temps imparti et un redémarrage complet. Il s’agit du cas de test prévu, pas d’une version existante. Procurez-vous le véritable projet modifiable, ses ressources, ses déclarations de dépendances et ses instructions de démarrage. Notez la version du générateur ou de l’outil lorsqu’elle est accessible, la révision du projet, l’environnement d’exécution, le navigateur et le système d’exploitation.
Distinguez les fichiers sources d’un aperçu hébergé ou d’un paquet compilé. Les ressources absentes, les dépendances non documentées ou l’impossibilité d’obtenir les sources sont des constats à noter, pas des lacunes à combler silencieusement. Si le projet fourni diffère du cas prévu, documentez ses règles existantes avant de choisir une extension équivalente et limitée. Conservez une copie intacte et une copie de travail distincte afin que les modifications ultérieures n’effacent pas les preuves initiales.
2. Reproduire la version de référence avant toute réparation
Suivez les instructions fournies dans un répertoire vierge. Conservez les commandes exactes, les sorties d’installation, le journal de démarrage et la console du navigateur. N’inventez pas de commande sous prétexte que le projet ressemble à un framework connu. Si l’installation échoue, gardez l’erreur et notez séparément toute intervention. Une version de référence réparée par l’évaluateur reste une version réparée : ce n’est pas une réussite sans réserve du projet livré.
Exécutez quatre scénarios : collecter une étoile et rester à son emplacement ; collecter les cinq ; laisser le temps expirer ; redémarrer après chaque fin de partie. Vérifiez que chaque étoile n’est comptée qu’une fois, que le mouvement s’arrête après la fin et que tous les états de la partie sont réinitialisés. Pour chaque scénario, consignez l’action, le résultat attendu, le résultat observé et la révision. Conservez les échecs avec autant de soin que les réussites.
3. Retracer la règle à modifier
Repérez le code réel ou la logique modifiable qui relie le déplacement, la détection de contact, l’état de collecte, le compteur affiché et la vérification de victoire. Dans vos notes, utilisez les noms de fichiers ou identifiants d’événements réels. Expliquez quel élément gère le chronomètre et quelle action de réinitialisation le restaure. Une explication plausible de l’IA ne suffit pas : confrontez-la au projet.
Cherchez les compteurs dupliqués ou la logique de réinitialisation dispersée entre des systèmes sans rapport. Ce sont des points à examiner, pas des preuves automatiques d’une mauvaise architecture. L’objectif pratique est de déterminer où intégrer l’objet bonus et quels comportements existants doivent rester inchangés. Notez les incertitudes avant de demander le correctif.
4. Ajouter une étoile bonus bleue au même projet
Enregistrez la révision de référence, puis demandez cette unique modification. L’exemple distingue délibérément le nouvel effet sur le temps du compteur de collecte existant :
Ajoute une étoile bonus bleue à ce jeu existant. Lors du premier contact avec elle pendant une partie active, retire-la et ajoute trois secondes au temps restant. Elle ne doit ni augmenter le compteur des étoiles normales ni modifier le seuil de victoire de cinq étoiles. Le redémarrage rétablit l’étoile bonus. Une partie terminée ne peut pas reprendre. Préserve le déplacement, les étoiles normales, la fin du temps imparti et toutes les règles de fin d’origine. Identifie les fichiers ou événements réellement concernés avant de proposer le plus petit correctif possible. Ne remplace pas le jeu ni les ressources sans rapport.Examinez la modification proposée avant de l’exécuter. Notez les fichiers ou événements modifiés, les dépendances ajoutées et toute restructuration. Demandez pourquoi un sous-système sans rapport a changé. Un nouveau jeu autonome avec un objet bleu ne démontre pas la continuation de la version de référence, même si son aperçu paraît similaire. Conservez le correctif avec son explication afin qu’une autre personne puisse examiner la même révision.
5. Revérifier les anciens comportements, les cas limites et le retour arrière
Répétez tous les scénarios de référence. Collectez ensuite l’étoile bonus une fois et restez à son ancien emplacement : le temps ne doit augmenter qu’une fois et le compteur normal ne doit pas changer. Redémarrez, collectez-la à nouveau et vérifiez la réinitialisation. Testez le contact près de la fin du temps imparti et après une fin de partie ; le nouvel objet ne doit pas relancer une partie terminée. Notez les hypothèses sur l’ordre des images si des événements simultanés peuvent influer sur le résultat.
Lorsqu’une vérification échoue, conservez la révision défaillante et une courte séquence permettant de reproduire le problème avant de demander une autre réparation. Revenez à la version de référence conservée et rejouez un scénario de référence. Ce n’est qu’après cette vérification que vous pourrez indiquer que le retour arrière a été reproduit. Aucun correctif réussi, résultat sans régression, délai de réparation ou résultat de retour arrière n’a été établi ici.
Ce que SEELE peut apporter et ce qui doit être vérifié
SEELE décrit un processus de création de jeux en langage naturel faisant intervenir scènes, ressources et code de jeu. Un petit jeu généré constitue donc un point de départ pertinent pour ce test. Fournissez d’abord un bref cahier des charges, puis vérifiez ce que le processus actuel livre réellement : un résultat jouable, un projet modifiable, des fichiers sources ou un autre artefact. Ces livrables ne sont pas interchangeables.
À l’étape de continuation, fournissez le contexte du projet existant et l’unique exigence concernant l’étoile bonus. Examinez la modification produite au lieu de supposer qu’une révision en langage naturel préserve correctement l’état du jeu. L’accès au projet, la compatibilité du moteur et les détails d’export doivent être confirmés dans le compte et le résultat réels. La description du produit justifie l’essai de ce processus ; elle ne démontre ni la reproductibilité, ni l’architecture, ni la maintenabilité de ce projet.
Les preuves nécessaires à une véritable conclusion
- Archive des sources d’origine ou du projet modifiable, ressources nécessaires et révision de référence stable.
- Instructions d’installation réelles, détails de l’environnement, sorties des commandes et erreurs ou réparations au démarrage.
- Relevé des scénarios de référence et preuve d’exécution continue pour la victoire, la défaite et le redémarrage.
- Explication liée au code ou aux événements réels, demande d’extension exacte et correctif vérifiable.
- Révisions avant et après, observations des tests de non-régression et des cas limites, et retour arrière reproduit.
- Conclusion limitée à ce projet et à cette extension, mentionnant les échecs non résolus.
Tous ces éléments permettant de conclure sont actuellement absents. Une modification réussie de l’étoile bonus étayerait une conclusion limitée sur la continuation, pas une promesse concernant le réseau, la migration des sauvegardes ou le développement à l’échelle d’un produit en production. Une livraison incomplète doit rester visible dans le rapport plutôt que d’être remplacée par une conclusion générale selon laquelle « le code généré par IA est modifiable ».
Conclusion : recueillir d’abord les preuves de la prochaine modification
Évaluez la continuation à partir d’une modification qui résiste à l’examen et aux tests de non-régression. Commencez par des éléments de projet reproductibles, préservez les règles d’origine et limitez suffisamment l’extension pour rendre toute modification inattendue visible. Cette ébauche fournit la méthode, pas le résultat manquant : un verdict pratique sur la maintenabilité reste impossible tant que le projet, le correctif et les preuves d’exécution ne sont pas disponibles. Pour la suite, utilisez dans SEELE le bref cahier des charges du jeu de collecte d’étoiles et conservez les livrables réels avant de demander l’étoile bonus. Si les sources manquent ou si l’installation échoue, arrêtez-vous, documentez le blocage et ne considérez pas un aperçu soigné comme une preuve que le développement peut continuer.
Test de continuation : preuves à recueillir
Ce tableau organise les vérifications proposées dans l’article. Il ne présente pas les résultats d’un test effectué.
| Vérification | Observation attendue | Preuves à conserver |
|---|---|---|
| Installation de référence | Le projet fourni peut être ouvert et exécuté selon ses propres instructions. | Révision du projet, étapes d’installation, dépendances et notes d’exécution. |
| Partie d’origine | Le déplacement, les cinq objets à collecter, le chronomètre, la victoire, la défaite et le redémarrage respectent le cas de test défini. | Journal de test reproductible et révision de référence. |
| Extension limitée | La règle demandée pour l’étoile bonus fonctionne sans modifier les comportements sans rapport. | Demande de modification, correctif ou révision, et vérifications de la nouvelle règle. |
| Non-régression et retour arrière | Les tests d’origine réussissent toujours et la modification peut être identifiée et annulée. | Résultats des tests avant et après, et référence du retour arrière. |
Questions fréquentes
Un aperçu hébergé peut-il prouver qu’un jeu est maintenable ?
Non. Un aperçu hébergé peut montrer le fonctionnement observable du jeu, mais il ne prouve ni l’exhaustivité des sources, ni la reproductibilité de l’installation, ni les conséquences d’une modification du code. Utilisez-le comme un élément du dossier. Une conclusion sur la continuation nécessite aussi les éléments modifiables, une version de référence conservée, une modification vérifiable et des tests de non-régression dans l’environnement d’exécution visé.
Faut-il être programmeur pour effectuer ce test ?
Vous pouvez consigner les scénarios visibles par le joueur sans être programmeur, mais un examen fiable des sources et des dépendances nécessite une personne connaissant le langage ou l’éditeur du projet. Distinguez ces responsabilités. Demandez à une personne qualifiée de vérifier la modification réelle au lieu de prendre une explication assurée de l’IA ou un écran d’accueil fonctionnel pour un examen d’architecture.
Que faire si l’extension fonctionne mais que l’installation reste non documentée ?
Signalez une réussite partielle, pas une livraison sans réserve. L’extension peut fonctionner dans un environnement déjà configuré alors qu’un nouveau développeur ne peut toujours pas la reproduire. Conservez la révision qui fonctionne, notez les étapes d’installation réellement utilisées et répétez-les à partir des éléments fournis avant de qualifier le projet de reproductible de manière indépendante.
