/* Cet article a été mis à jour le 13/07/26 suite à un retour de Hohenstein256, qui a signalé de nombreux bugs. Le programme téléchargeable ci-après, publié en version 1.1, intègre ces correctifs qui sont décrites à la fin de cet article */
J’ai voulu essayer les capacités d’une Intelligence Artificielle générative dans le domaine de la rétroprogrammation. J’ai donc demandé à Claude, IA développée par la société Anthropic et considérée comme très performante dans le domaine de la programmation, de générer un jeu d’aventure textuel en BASIC pour Apple II.
Claude m’a posé quelques questions concernant le jeu à générer, l’univers dans lequel évolue le joueur, la complexité, etc., puis m’a généré un listing en BASIC Applesoft à télécharger. Ce premier programme était presque fonctionnel mais il comportait quelques erreurs :
- La ligne
2000était présente deux fois (erreur de numérotation). - Utilisation d’une variable
HAqui créer une erreur de syntaxe lorsqu’elle est utilisée dans un testIF...THEN, car l’interpréteur BASIC Applesoft interprète l’instructionIF PI=HA THEN...enIF PI=H AT HEN...ce qui ne veut rien dire. J’ai donc remplacé le nom de la variableHAparHG. - Il y avait quelques bugs détectable uniquement en testant le jeu :
- une fois dans la salle des moteurs, il était impossible de revenir dans le couloir central.
- Dans le couloir central, l’affichage des directions « haut » et « bas » est conditionné par le fait d’avoir récupéré la combinaison spatiale, alors que c’est l’accès qui devrait l’être.
- le programme efface immédiatement l’écran après avoir affiché les messages consécutifs aux actions, ce qui les rend illisibles.
- En restant dans la serre, le joueur récupère de l’oxygène sans rien faire.
J’ai également apporté quelques améliorations, comme la possibilité d’utiliser les raccourcis N, S, E, O, H et B pour se déplacer, et I pour afficher l’inventaire. Concernant les verbes, il suffit de saisir les 3 premières lettres. Enfin, en cas d’erreur de saisie, le joueur ne perd pas un point d’oxygène (ce que je trouve un peu sévère).
Le programme ainsi modifié est fonctionnel et peut être exécuté dans un émulateur comme AppleWin.
Voici le programme à télécharger :
Le jeu s’appelle Odyssée… il est très simple, ne comportant que 7 pièces. Le vocabulaire est également très simple, une commande étant constituée d’un seul mot (verbe ou direction) en lettres majuscules. Odyssée semble s’inspirer du jeu Space Mission pour Amstrad disponible ici en version Apple II.
En conclusion, le fait que Claude soit capable de générer un programme quasi-fonctionnel dans un langage totalement obsolète est plutôt impressionnant. Mais l’IA est-elle réellement créatrice ? Elle utilise des jeux crées par des milliers de programmeurs pour produire quelque-chose qui y ressemble… Je vous laisse juge. En tout cas, je vous promets de ne plus utiliser une IA pour produire automatiquement des jeux d’aventure sur mon site.
D’autant plus que je fais le constat suivant : j’ai passé beaucoup de temps à faire des modifications sur le programme généré par l’IA à faire des correctifs ou des évolutions pour rendre le jeu plus intéressant et cohérent.
Correctifs embarqués dans la version 1.1 publiée le 13/07/26 :
- Correction des bugs flagrants : duplication de la variable SE, score max à 100, suppression de la commande POSER, message liés à l'absence de combinaison illisible, renommage de la variable PV en CV (coffre verrouillé)
- Le FUSIBLE n'est plus grillé car il est doit utilisé en réparation.
- L'objet CODE est remplacé par une CLEF, nécessaire pour finir l'aventure. Le code est simplement affiché et sert à ouvrir le coffre.
- Le hangar est maintenant une pièce utile qu'il faut visiter pour pouvoir finir l'aventure.
- La gestion de l'oxygène a changé et devient un élément critique qu'il va falloir gérer. Le jeu devient ainsi bien plus difficile, mais plus intéressant.
- La carte du vaisseau ne sert pas sauf à donner des points.
- Amélioration mineure de l'affichage des salles, des objets et des directions.
- Je n'ai pas modifié le comportement de la commande UTILISER. L'interpréteur, rudimentaire, ne comprend que les commandes d'un seul mot en majuscules. Ainsi, le programme reste simple.
Bonjour,
J’ai relu le code en détail et j’ai trouvé plusieurs points à vérifier. Certains sont de vrais bugs possibles, d’autres sont plutôt des incohérences ou des éléments de finition.
La variable `SE` pose problème. Au début, elle sert à définir la salle de sécurité avec `SE = 5`, mais juste après elle est réutilisée avec `SE = 0` pour gérer les erreurs de commande. Du coup, quand le jeu envoie le joueur vers la salle de sécurité avec `PI = SE`, il l’envoie en réalité vers la valeur actuelle de `SE`, donc `0`, pas vers `5`. Le jeu peut encore fonctionner par hasard parce que les comparaisons utilisent aussi `SE`, mais c’est très fragile.
La commande `POSER` est affichée dans la liste des commandes au lancement, mais le parser ne contient aucun traitement pour elle. Si le joueur tape `POSER`, le jeu répondra simplement qu’il ne comprend pas la commande.
Le score final affiche `SCORE FINAL: … / 90`, mais le score maximal calculable dans le code semble être de 100. Il y a 6 objets à 5 points, donc 30 points, puis 10 points pour le coffre, 20 pour le moteur, 10 pour la plante et 30 pour l’émetteur. Total possible : 100.
La victoire peut être remplacée par la mort dans un cas précis. Quand le joueur active l’émetteur, `PS` passe à 1, mais la boucle principale retire ensuite 1 point d’oxygène avant de tester la victoire. Comme la mort est testée avant la victoire, si le joueur active l’émetteur avec 1 oxygène restant, il tombe à 0 et obtient le Game Over au lieu de la victoire.
Le bonus d’oxygène de la serre n’est pas vraiment unique. Quand le joueur monte vers la serre depuis le couloir, le code remet `OD = 0`, puis la description de la serre redonne `+2` oxygène. Résultat : en ressortant et en revenant, le joueur peut récupérer ce bonus plusieurs fois, jusqu’à revenir à 20 oxygène.
Les commandes inconnues ne consomment pas d’oxygène. Quand une commande n’est pas reconnue, le jeu met `SE = 1`, puis retourne au début de la boucle avant la ligne qui retire 1 point d’oxygène. Le joueur peut donc taper des commandes invalides sans perdre d’oxygène.
Les messages liés à l’absence de combinaison sont trop rapides. Par exemple, si le joueur tente d’aller vers la serre ou le hangar sans combinaison, le jeu affiche un message, mais il ne fait pas de pause avec `GET`. La boucle recommence directement, donc le message risque de disparaître avant d’être lu.
Les commandes `PRENDRE OUTIL` et `PRENDRE FUSIBLE` ne prennent pas forcément l’objet demandé. Le parser regarde seulement si la commande commence par `PRE`, puis la routine `PRENDRE` prend le premier objet disponible selon la pièce. Dans la salle des moteurs, si le fusible est encore présent, `PRENDRE OUTIL` prendra quand même le fusible en premier.
Le code du coffre est étrange côté logique. Le joueur peut lire le code `4-2-7` avec `EXAMINER` sur le pont, mais pour ouvrir le coffre, le jeu vérifie quand même que l’objet `CODE D’ACCES` a été pris. Donc connaître le code ne suffit pas, il faut aussi avoir ramassé l’objet code.
Le fusible est décrit comme `FUSIBLE GRILLE`, mais il sert ensuite à réparer le moteur. C’est contradictoire : soit il faut le renommer en fusible de rechange, soit préciser que le joueur remplace le fusible grillé par un fusible valide.
Le commentaire de la variable `PV` est trompeur. Le code indique `PV=PONT VERROUILLE`, mais dans les faits `PV` sert surtout à savoir si le coffre de la salle de sécurité est ouvert. Le nom ou le commentaire devrait être corrigé.
La carte du vaisseau donne 5 points quand on la prend, mais je n’ai trouvé aucune autre utilisation dans le code. Elle ne débloque pas de zone, n’aide pas à la navigation et n’intervient dans aucune énigme.
Le hangar est accessible, mais il ne sert pas vraiment à la progression. Il n’y a pas d’objet à y prendre, pas d’action spéciale à faire et aucune condition de victoire liée à cette salle.
Les commandes ne sont pas normalisées. Le code compare directement `CM$` avec `NORD`, `SUD`, `EST`, etc. Si le joueur tape une version avec une casse différente ou un espace en trop, comme `nord`, `Nord` ou `NORD `, la commande peut ne pas être reconnue.
La commande `UTILISER` ne tient pas compte de l’objet écrit par le joueur. Par exemple, `UTILISER OUTIL`, `UTILISER FUSIBLE` ou même `UTILISER NIMPORTEQUOI` peuvent déclencher la même action si le joueur est dans la bonne pièce et possède les bons objets. Le jeu se base surtout sur le lieu et l’inventaire, pas sur les mots tapés.
Bonjour, très intéressante votre analyse du code… Il y a encore beaucoup de failles dans ce programme, malgré le temps que j’ai passé à en corriger.
Avez-vous utilisé une IA pour détecter tous ces problèmes ?
Je vais mettre sur ma liste un nouvelle version du programme, mais ce n’est pas ma priorité du moment…
Merci pour tout !
Non, je n’ai pas utilisé d’IA pour détecter ces problèmes. J’ai analysé et testé le programme directement sur applewin pour les repérer tout en lisant le code.
Bonjour, j’ai pris en compte vos commentaires et publié une nouvelle version (v1.1) d’Odyssée. Les modifications / corrections sont détaillées à la fin de l’article mis à jour. Grâce à vous, le jeu est maintenant plus cohérent et plus intéressant (plus difficile également). Et il y a beaucoup moins de bugs !
Encore merci…