Créer Clean Break : un jeu de réflexion 3D avec OpenGame

Jouez à Clean Break, un jeu de réflexion pour navigateur composé de six niveaux et réalisé dans OpenGame Studio. Visez le mécanisme, modifiez le mouvement de ses pièces et guidez la caisse marquée vers la zone de récupération sans endommager la machine bleue. Chaque tentative accorde trois tirs. L’interface du jeu est en anglais.

Le terrain d’entraînement de la V16 publiée. Cette capture provient du jeu réellement jouable.

Le résultat a demandé 16 tâches de génération, plusieurs séances de test dans le navigateur et des corrections du jeu comme de la plateforme. Voici comment nous avons défini une première énigme, repéré ses défauts en jouant et transformé ces observations en demandes de modification précises.

Commencer par une décision compréhensible

Avant Clean Break, nous avions essayé un jeu de livraison. Les trajets et les objectifs fonctionnaient, mais le créateur trouvait les rues trop étroites et la conduite peu convaincante. Ajouter des décors ne résolvait pas ce problème. Nous avons arrêté cette piste et choisi une autre interaction.

Dans Clean Break, le joueur observe un mécanisme depuis une perspective fixe, choisit où tirer et regarde les conséquences. En retirant le déplacement du personnage et la caméra libre, nous réduisions le nombre de commandes à rendre claires.

Le premier concept restait trop simple : toucher une seule goupille pour gagner immédiatement laissait peu de place à la découverte. Pendant la discussion dans Studio, nous en avons fait un problème d’équilibre en deux étapes : modifier l’équilibre de la poutre, puis libérer la caisse. Inverser l’ordre devait produire une conséquence différente et compréhensible.

Nous avons aussi limité la simulation aux charnières, appuis, effets de gravité et mouvements guidés. La disponibilité d’un moteur général de destruction par corps rigides n’avait pas été vérifiée. Cette limite a orienté le choix des énigmes.

Discuter de la SPEC avant de générer

Nous avons défini le jeu dans la conversation Studio et validé la SPEC avant de lancer la génération. Les exigences étaient concrètes :

• Une caméra oblique fixe montrant le mécanisme et sa destination.
• Une visée libre à la souris, avec trois tirs au maximum.
• Une caisse marquée, une zone de récupération et une machine bleue à protéger.
• Des résultats différents selon les tirs et leur ordre.
• Une relance immédiate, y compris pendant le mouvement des objets.
• Un jeu téléchargeable.

Ce prompt de départ en anglais résume le concept. C’est un modèle réutilisable, pas une transcription du tout premier prompt ni une garantie de reproduire V16 en une génération.

Discuss a small English-language 3D puzzle game before generating code.

The player inspects a mechanism from a fixed oblique camera, aims,
and fires up to three shots. The goal is to move a marked crate into
salvage without hitting a protected blue machine.

Start with one puzzle requiring two consequential actions.
A wrong order must have a visible, understandable consequence.
Success must follow the crate's position and contact with objects.

Explain which support, hinge, gravity, and collision behavior the
available runtime can reliably support. Keep the simulation bounded.

Define the controls, win and loss conditions, last-shot resolution,
reset behavior, and downloadable output. Return a SPEC for review
before generating the game.

Les critères d’acceptation sont essentiels : ils permettent de tester autre chose que la simple apparition d’une scène.

Jouer la première énigme de plusieurs façons

Après la première génération, nous avons joué sur le site avec la souris et le clavier : séquence correcte, séquence incorrecte, puis tir volontairement manqué suivi des deux actions utiles.

Ce dernier cas compte. Après le dernier tir, le jeu ne doit pas déclarer une défaite alors que la caisse est encore en train d’atteindre sa destination.

Nous avons aussi réinitialisé pendant un mouvement et cliqué rapidement plusieurs fois pour vérifier qu’aucune munition supplémentaire n’était dépensée pendant la résolution d’une action.

La première version proposait une vraie chaîne de causes et d’effets, mais la scène était sombre et le canon partiellement coupé. Nous avons demandé une amélioration ciblée de la lisibilité. Un test dans une fenêtre haute a ensuite révélé un plafond de distance de caméra qui laissait la zone de récupération hors champ. Cela a fait l’objet d’une correction distincte.

Le rythme était toujours le même : jouer, décrire le défaut observé, demander un ensemble cohérent de changements, puis rejouer.

Étendre le jeu après avoir validé son fonctionnement

Nous sommes passés d’une énigme à trois, puis à six. Une génération réussie ne signifiait pas que chaque nouveau niveau était jouable.

Dans le deuxième terrain, la caisse ne glissait pas comme prévu. La lecture du code téléchargé a aidé à expliquer le problème : la pente était insuffisante face au frottement configuré. Une goupille pouvait aussi tomber sur la machine protégée, et le pont manquait de dégagement.

Nous avons transmis ces observations à Studio. La version suivante a été générée par le site ; nous n’avons pas présenté un jeu réparé localement comme un résultat de Studio.

Le cinquième terrain a nécessité deux tentatives de réparation. L’angle d’une liaison et la position initiale de la deuxième caisse étaient incorrects. La bonne solution échouait toujours, et un chemin censé être mauvais ne se comportait pas comme prévu. V11 a été la première version dont nous avons terminé les six niveaux.

« Corrige la physique » était trop vague. Un rapport utile indique le niveau, les actions, le résultat visible et ce qu’il faudra vérifier après correction.

Rédiger les modifications à partir des observations

Une amélioration visuelle ultérieure a introduit un autre défaut : après Continue, des pièces détachées du niveau précédent restaient visibles dans le suivant. Tester chaque niveau séparément aurait pu le masquer.

Voici un extrait exact de la demande pour V14 :

After clearing L1 and pressing Continue, its fallen counterweight and latch remain visible in L2. More detached pins/latches accumulate in L3-L6. This is not intentional salvage dressing.

La demande précisait ensuite le comportement attendu : retirer les objets détachés lorsque l’on quitte leur niveau, restaurer le mécanisme au retour et conserver les pièces en mouvement tant que leur niveau est actif.

Voici un modèle pratique, conservé en anglais pour être réutilisé :

Baseline: identify the saved version you just played.

Observed problem: name the scene and visible symptom.
Reproduction: give the actions that produce it.
Expected result: explain what should happen instead.
Scope: identify the related changes for this revision.
Acceptance: list the routes, retries, and transitions to replay.

Return the revised SPEC for confirmation before generating.

Une demande ciblée rend l’itération compréhensible. Une modification générative ne garantit cependant pas que toutes les autres lignes de code restent intactes. Il faut donc revérifier les comportements déjà validés.

Garder les mécanismes lisibles malgré le décor

V13 comprenait déjà six terrains. La dernière passe a changé le traitement visuel tout en conservant la structure prévue des énigmes.

Le détail peut gêner le joueur. Dans le sixième terrain, une traverse décorative masquait des éléments importants et certaines étiquettes se chevauchaient. Nous avons demandé un premier plan plus ouvert et un placement des étiquettes tenant compte de leur taille réelle, avec des lignes pointant clairement vers leur cible.

Une fois la campagne fonctionnelle, nous avons essayé le style d’atelier miniature de V16 : couleurs plus claires, caisses expressives et petits accessoires. La géométrie reste simple. Nous avons accepté cette amélioration et arrêté les grandes révisions graphiques. Les deux images de scène proviennent de véritables sessions de jeu, pas de rendus conceptuels.

Distinguer les bugs du jeu des pannes de la plateforme

Certains problèmes demandaient une nouvelle version du jeu ; d’autres concernaient OpenGame. Nous avons corrigé un délai d’attente des en-têtes de réponse du fournisseur et une erreur de compression des longues conversations dans le moteur de génération. Côté site, nous avons corrigé la classification des téléchargements interrompus et ajouté une recherche de résultat déjà enregistré après l’échec d’une tâche.

V14 illustre la distinction : la tâche avait échoué et avait été remboursée, mais des fichiers utilisables existaient. Nous les avons finalement récupérés par le site, puis vérifié l’aperçu et le ZIP. L’échec initial et le remboursement sont restés dans l’historique.

Nous avons aussi commis une erreur évitable : demander une nouvelle révision avant cette récupération. V15 a renvoyé un contenu inchangé et a échoué. Malgré le remboursement, nous avons attendu 13 minutes supplémentaires.

Il faut donc diagnostiquer l’échec avant de recommencer. Un résultat enregistré mais inaccessible, une erreur de génération et un niveau injouable appellent des réponses différentes.

Le coût des itérations

Ces chiffres concernent uniquement Clean Break, sans le précédent jeu de livraison.

| Mesure | Résultat | | --- | --- | | Tâches de génération | 16 | | Initialement terminées | 11 | | Initialement échouées | 5 | | Durée cumulée des tâches | 2 heures, 43 minutes, 54 secondes | | Durée des tâches échouées | 50 minutes, 53 secondes | | Crédits débités / remboursés / nets | 160 / 50 / 110 | | Version publiée | V16 |

La durée va de la création de la tâche à sa réussite ou son échec. Elle comprend les appels au modèle, les outils, les vérifications et la sauvegarde, mais pas nos discussions, tests, diagnostics et réparations de plateforme. Ce n’est donc pas le temps total de production.

V14 reste comptée comme une tâche initialement échouée malgré la récupération. Les crédits sont des unités d’utilisation OpenGame, pas le coût facturé par le fournisseur de modèle.

Même une petite modification pouvait être longue : le flux de génération écrivait un fichier de jeu complet. Des demandes précises et des tests délibérés limitaient les itérations inutiles.

Terminer par la campagne complète et les fichiers

L’écran final après les six parcours corrects de V16.

Avant de clôturer, nous avons terminé les six niveaux de V16, téléchargé le ZIP original, publié via Studio et vérifié que le jeu démarrait sur sa page publique.

V14 avait aussi été testée sur les mauvais ordres, la victoire au dernier tir, les réinitialisations en mouvement, les transitions et différentes tailles de fenêtre. Nous n’avons pas répété tous ces cas limites sur V16. La durée d’une première partie et la conservation de la progression après actualisation n’ont pas été formellement validées.

Clean Break est un exemple publié et jouable, avec un paquet téléchargeable pour poursuivre le développement. Les graphismes et la couverture des tests peuvent encore progresser.

Réutiliser cette méthode

1. Définir une décision et sa conséquence visible.
2. Confirmer la SPEC avant de générer.
3. Jouer un parcours gagnant, un parcours perdant et un redémarrage.
4. Décrire les défauts avec des actions reproductibles.
5. Demander une révision cohérente et rejouer les comportements concernés.
6. Ajouter du contenu après avoir validé l’interaction centrale.
7. Vérifier le jeu final et son export avant de conclure.

Jouez à Clean Break, puis ouvrez OpenGame Studio pour discuter de votre propre énigme. Parcourez aussi les jeux jouables dans le navigateur pour découvrir d’autres boucles de jeu complètes. Le prompt aide à commencer ; le jeu final est né des itérations suivantes.

Note de production : cet article repose sur les sessions Studio des 26–27 septembre 2026, les prompts enregistrés, les tâches, les versions téléchargées et les tests dans le navigateur. Les captures indiquent leur version. La création et les révisions du jeu sont passées par Studio ; les corrections de plateforme étaient un travail technique distinct.