Définir les coûts de plongée et les règles de retour

La survie sous-marine est plus simple à prototyper si le joueur suit un itinéraire, récupère un objet et doit surveiller deux limites faciles à lire. Commencez par un quai en surface, un plateau rocheux et une fosse. Attribuez un coût en oxygène connu à chaque action valide, rendez l’exposition en profondeur visible sur un second indicateur et fixez le moment exact du contrôle d’échec. Séparez ensuite les demandes à l’IA : d’abord les règles, puis la plus petite portion jouable et enfin, plus tard, une demande de correction fondée sur des observations réelles.

Blueglass Reach est un concept fictif original servant d’exemple pédagogique calculé à la main. Aucun prompt n’a été exécuté et aucun prototype ni test jouable n’existe. Les valeurs d’oxygène et d’étanchéité sont des paramètres inventés pour le jeu, pas des conseils de plongée. Les faits physiques sont limités à la brève source NOAA citée plus bas.

Limiter le prototype à une seule plongée

Un premier prototype de survie sous-marine n’a pas besoin d’une carte du monde, d’une économie d’oxygène, de construction de base ni de plusieurs espèces marines. Il lui faut un trajet court où le joueur peut voir ce qu’il doit récupérer et s’il pourra revenir. Blueglass Reach utilise un plongeur et une capsule d’étude scellée : descendre, scanner, récupérer puis revenir à la piscine lunaire.

Gardez un itinéraire qu’on peut lire comme une suite de lieux plutôt que comme un système de coordonnées. D0 est le quai de surface de la Piscine lunaire. D1 est un plateau rocheux entre la piscine et la fosse. D2 est la Fosse bleue, où repose la capsule. Le déplacement n’est autorisé qu’entre des nœuds voisins. Le même itinéraire sert à descendre et à remonter : chaque coût peut être vérifié avant d’ajouter du décor ou un autre objectif.

Il s’agit d’une portion solo, limitée à une seule plongée. Elle exclut volontairement les rôles coopératifs, la progression persistante, les colonies reliées, l’artisanat et une boucle de ressources renouvelables. Ces systèmes répondraient à d’autres questions de conception et rendraient plus difficile l’interprétation d’un premier résultat.

Définir les coûts d’oxygène et de pression avant le prompt

Établissez l’état initial et l’ordre des actions avant de demander une scène à un outil. Ici, le plongeur commence en D0 avec oxygène 8/8, étanchéité de combinaison 5/5, aucun scan et aucune capsule. Chaque action valide coûte un point d’oxygène. Une action valide qui commence ou se termine en D2 coûte aussi un point d’étanchéité, une seule fois même si un déplacement traverse l’arête D1–D2. Les actions invalides sont refusées avant l’application de l’un ou l’autre coût.

La règle d’exposition à la profondeur est un jeton de jeu simple, pas une simulation d’un plongeur ou d’une combinaison. Le principe réel est plus limité : la NOAA indique que la pression de l’eau augmente d’environ une atmosphère tous les 33 pieds (10,06 mètres) de profondeur. Cette tendance peut inspirer un défi de profondeur croissante, mais elle ne valide ni le compteur d’étanchéité inventé, ni son coût d’un point, ni une conclusion sur les équipements ou la sécurité. Le lien NOAA pressure explanation n’étaye que ce principe physique général.

Résolvez chaque tour valide dans le même ordre : retirer un point d’oxygène, appliquer le déplacement ou l’effet de l’objectif, retirer un point d’étanchéité si l’action commence ou se termine en D2, puis vérifier l’échec avant la victoire. Ne faites pas disparaître son coût lors d’une récupération réussie et ne comptez pas le retour comme une victoire si l’oxygène est tombé à zéro. Réinitialiser restaure le tuple de départ complet ; ce n’est pas une action gratuite pendant la plongée.

L’image illustre le choix juste après la récupération : la capsule a quitté son logement, le plongeur la porte et l’itinéraire vers la surface reste ouvert. Deux points d’étanchéité suffisent à remonter de D2 à D1 et en laissent un pour le déplacement final jusqu’au quai.

Transformer les règles en trois prompts d’IA

Ne regroupez pas le monde, l’implémentation et les tests dans une seule demande démesurée. Chaque prompt ci-dessous a un rôle distinct et un résultat qu’on peut examiner. Ce sont des modèles prêts à copier, pas des prompts enregistrés lors d’une exécution. Gardez les valeurs numériques qualifiées de paramètres fictifs.

Prompt 1 : demander un contrat d’implémentation

Conçois un petit prototype original de survie sous-marine solo appelé Blueglass Reach. Avant d’écrire du code, fournis un contrat d’implémentation concis pour le seul itinéraire Piscine lunaire D0 ↔ Plateau D1 ↔ Fosse bleue D2. Le plongeur commence en D0 avec oxygène 8/8 et étanchéité 5/5. Une capsule d’étude scellée se trouve en D2. Chaque action valide coûte exactement un point d’oxygène. Ne se déplacer que le long d’une arête adjacente. Scanner une fois en D2 pour révéler la capsule. La récupérer une seule fois en D2 et uniquement après le scan. Attendre est légal mais ne fait pas progresser l’objectif. Une action valide qui commence ou se termine en D2 retire exactement un point d’étanchéité ; une action invalide ne coûte rien et ne modifie rien. Résoudre dans cet ordre : coût d’oxygène ; effet de l’action ; coût d’exposition en profondeur s’il s’applique ; échec si oxygène ou étanchéité vaut zéro ; sinon victoire uniquement si le plongeur est en D0 avec la capsule. La réinitialisation restaure l’état initial. Fournis le schéma d’état, les préconditions, l’ordre des transitions, les conditions de victoire et d’échec et un petit tableau de tests. N’ajoute ni multijoueur, ni base, ni artisanat, ni recharge d’oxygène, ni progression persistante, ni valeurs aléatoires, ni nœuds de carte supplémentaires. Qualifie les nombres de paramètres de conception fictifs, pas de conseils de plongée.

Comparez le contrat retourné au graphe des nœuds et à l’ordre des coûts. Il doit refuser une tentative de saut direct D0–D2, un second scan et une récupération avant le scan sans modifier de compteur. Si le tableau ajoute une action gratuite ou applique le coût de D2 deux fois sur un déplacement, corrigez le contrat avant la création.

Prompt 2 : demander la plus petite portion jouable

À partir du contrat Blueglass Reach ci-dessous, crée la plus petite version jouable d’un prototype d’une seule plongée dans l’environnement de jeu disponible. Montre un plongeur en troisième personne, les trois profondeurs reliées, une cible de scan en D2, une capsule récupérable et un itinéraire de retour lisible. Fournis un déplacement d’un nœud adjacent, un Scan utilisable une seule fois, une récupération soumise à sa condition, une attente sans progression et une réinitialisation. Affiche l’oxygène et l’étanchéité sous forme de compteurs ou de repères simples ; distingue clairement le scan, la récupération, l’échec et le retour. Respecte exactement cet ordre : refuser une action invalide sans coût ; dépenser l’oxygène ; appliquer l’action ; retirer un point d’étanchéité si l’action commence ou se termine en D2 ; vérifier l’échec par oxygène ou étanchéité avant la victoire en D0 avec la capsule.

N’ajoute ni base, ni autre plongeur, ni économie d’artisanat, ni deuxième objectif, ni tirage aléatoire, ni simulation de pression ou médicale. Fournis le jeu ou le code, les instructions d’exécution et une courte liste de tests manuels. Marque chaque cas comme non vérifié jusqu’à ce qu’une personne l’exécute réellement. Si l’environnement ne peut fournir un jeu jouable, indique cette limite au lieu de prétendre que le prototype fonctionne.

Cette demande précise les interactions et retours visuels nécessaires pour examiner les règles ; elle ne garantit pas qu’un outil les implémentera. Si un vrai jeu est fourni ultérieurement, vérifiez les liaisons, le verrou de scan, la récupération, les deux compteurs, la priorité de défaite et la réinitialisation à partir des observations réelles.

Prompt 3 : comparer les observations et demander une correction ciblée

Examine le jeu Blueglass Reach réel et les notes d’exécution fournies ci-dessous. Ne déduis pas une réussite du brief de conception. Pour chaque cas fourni, indique l’état attendu, l’état observé, les preuves fournies et le statut : réussi, échoué ou non vérifié. Compare d’abord : (A) la route sûre de six actions depuis O8/E5 revient en D0 avec capsule en O2/E1 ; (B) après la récupération, Attendre puis remonter amène l’étanchéité à zéro en D1 et entraîne une défaite ; (C) la même route depuis O6 fait tomber l’oxygène à zéro à la dernière action et entraîne une défaite avant le contrôle de victoire ; (D) récupérer avant le scan est refusé sans modifier l’état ; (E) la réinitialisation restaure D0/O8/E5/sans scan/sans capsule. Si une observation manque, marque le cas non vérifié. En cas d’échec, propose la plus petite modification de code ou de règle permettant de rétablir le contrat, puis ne liste que les cas à réexécuter. N’ajoute pas de fonctionnalités et ne marque aucun test réussi sans notes visibles qui l’établissent.

Notes d’exécution, captures d’écran ou journal d’état réels : [à remplir uniquement après une exécution réelle ; sinon laisser vide et signaler « non exécuté »].

Le troisième prompt est conditionné par des preuves. Sans notes d’exécution réelles, la réponse correcte est une liste de vérifications non confirmées et aucune réussite revendiquée. Le calcul manuel reste une cible utile sans être présenté comme le résultat d’un prototype.

Vérifier sur papier l’itinéraire de retour et les échecs

Avant de demander du code, parcourez l’itinéraire une action à la fois. Commencez en D0 avec oxygène 8 et étanchéité 5. Le chemin sûr comporte six actions : aller au plateau, descendre, scanner, récupérer, remonter et revenir. Seules les actions qui commencent ou se terminent en D2 consomment un point d’étanchéité.

La route réussit car les deux compteurs restent au-dessus de zéro lorsque le plongeur revient avec la capsule. Le scan et la récupération sont deux actions séparées. La descente et la remontée comptent chacune comme une action d’exposition en profondeur ; le passage D1–D2 ne coûte pas deux points sur une même action.

Deux variantes proches vérifient l’ordre des conditions terminales. Après la récupération, si le plongeur attend en D2, l’oxygène passe de 4 à 3 et l’étanchéité de 2 à 1. La remontée suivante réduit ces valeurs à oxygène 2 et étanchéité 0 : la partie se termine en défaite avant le retour. Si le même parcours de six actions commence avec oxygène 6, le dernier déplacement ramène le joueur en D0 avec oxygène 0 et étanchéité 1 ; la défaite est vérifiée avant la victoire. Avec 7 au départ, il reste oxygène 1 et étanchéité 1 en D0, donc la route réussit selon les règles écrites.

Cette image de résultat est une illustration conceptuelle de l’état terminal. Le feu vert du quai indique l’arrivée dans ce scénario fictif ; il ne prouve ni qu’un prototype généré a fait remonter le plongeur ni qu’une mécanique de pression fonctionne.

Ne réviser qu’à partir d’un comportement observé

Si un vrai jeu diverge du contrat, notez le premier état différent. Consignez l’entrée, le nœud de départ, l’oxygène, l’étanchéité, l’indicateur de scan, l’indicateur de capsule, l’état suivant attendu, l’état suivant observé et les preuves. Une erreur ultérieure peut provenir d’un coût ou d’un indicateur déjà incorrect ; ne réécrivez pas tout le prompt d’emblée.

1. Locate the first mismatch. Compare the actual result to the matching row in the paper trace, not to a vague impression that the dive felt wrong.
2. Name the smallest rule involved. Examples include adjacency, the scan prerequisite, a once-only action, the single D2 seal cost, or loss-before-win ordering.
3. Ask for one targeted repair. Keep unrelated controls, scene layout, and costs fixed so the next observation isolates the intended change.
4. Rerun only affected checks. A change to the Collect precondition needs the early-Collect case; a change to terminal order needs the zero-oxygen return case.
5. Keep the result status honest. A design table is expected behavior. A prompt is an unrun instruction. Only recorded behavior from a real build can support a pass claim.

Sans jeu réel et notes d’exécution, arrêtez-vous au contrat papier. N’inventez pas une capture d’écran attendue et ne décrivez pas comme testée une correction proposée. Lorsque vous disposerez d’un véritable outil et utiliserez les trois prompts, examinez son résultat, puis notez uniquement ce qui a été observé. Si le jeu ne peut pas être lancé, consignez le blocage sans prétendre que l’implémentation est validée.

Démarrer un premier prototype de survie sous-marine

Commencez par une plongée dont le retour est possible. Un itinéraire de quelques nœuds, un objectif et un ordre d’échec explicite donnent une petite cible à créer et examiner. La séquence calculée à la main constitue une base pour votre test, pas une preuve qu’un jeu respecte déjà les règles. Après avoir préparé un brief concis, utilisez Free AI game maker pour explorer une première direction jouable, puis vérifiez ce qui fonctionne vraiment et ce qui demande une nouvelle version. Avant d’envoyer une demande, examinez dans Workspace le modèle sélectionné, le solde Koin disponible et le coût affiché.

FAQ

Quelle est la plus petite boucle de survie sous-marine à prototyper ?

Utilisez un plongeur, un itinéraire entre un point de surface et un objectif plus profond, et une condition de retour. Donnez au joueur peu d’actions et de valeurs clairement visibles, puis suivez leurs changements à chaque action. Une petite portion permet de vérifier si l’objectif, l’itinéraire et la condition d’échec sont compréhensibles avant d’ajouter des créatures, de l’artisanat ou un monde plus vaste.

Le compteur d’étanchéité modélise-t-il la pression réelle de la plongée ?

Non. La perte fictive d’un point d’étanchéité près de D2 a été choisie pour rendre le calcul du retour simple. La NOAA n’appuie que le fait général que la pression augmente avec la profondeur, d’environ une atmosphère tous les 33 pieds (10,06 mètres). Cela ne valide pas ce compteur fictif, un équipement réel ni une conclusion de sécurité.

Pourquoi les actions invalides devraient-elles laisser toutes les valeurs inchangées ?

Refuser un déplacement invalide ou une récupération trop précoce sans prélever de ressources explique clairement au joueur quelle règle a été enfreinte. Cela crée aussi une vérification déterministe : si une commande refusée modifie la position, l’oxygène, l’étanchéité ou les indicateurs, l’implémentation s’écarte du contrat. Une autre conception du refus est possible, mais son coût doit être précisé et testé.

Quand demander la réparation d’un prompt ?

Demandez une correction après qu’une observation réelle a identifié le premier écart entre état attendu et état réel. Incluez l’action, les valeurs de départ, le résultat attendu, le résultat observé et une seule règle à modifier. Gardez les cas non observés marqués comme tels afin qu’une proposition ne devienne pas un résultat imaginé.

Les prompts Blueglass Reach ont-ils été exécutés ou testés ?

Non. Ce sont des modèles réutilisables pour un scénario fictif original ; les calculs de l’itinéraire sont effectués à la main selon les règles de cet article. Aucun modèle n’a été exécuté et aucun prototype ou test n’est représenté. Utilisez la route comme état attendu, puis vérifiez un vrai jeu avant toute affirmation sur son comportement.