Un prompt de construction voxel est plus facile à vérifier lorsqu’il précise les cases modifiables, l’évolution des ressources, les conditions de stabilité d’un bloc et le critère de victoire. Commencez par ce contrat de règles, demandez ensuite un prototype très limité et vérifiez sur papier si un seul bloc de réserve ferme la boucle de ressources du pont.
Ce guide utilise Mosslight Span, un exercice fictif solo où l’on construit un pont vers une balise. La carte, les règles et la comparaison v0-v1 sont des éléments pédagogiques originaux calculés à la main. Les trois modèles de prompt n’ont pas été exécutés ; aucun jeu jouable ni résultat de test n’est revendiqué. Utilisez les nombres comme états attendus, pas comme résultat d’un prototype.
Le résultat pratique est une courte séquence : définir un monde modifiable, préciser l’extraction et la pose, demander une implémentation bien délimitée et comparer tout futur jeu à des vérifications établies. Cette séquence transforme une idée en demande vérifiable sans prétendre qu’un jeu a déjà été créé.
Définir un petit monde modifiable
Une première portion voxel utile a besoin d’une destination, d’un obstacle, d’un choix de ressources et d’un signal de fin. Mosslight Span rassemble ces éléments dans un passage étroit. L’explorateur commence sur une plateforme stable proche en surface, en (0,1), avec deux blocs de pierre. De l’autre côté d’un ravin de trois cases, les positions x=1, x=2 et x=3 sont vides ; une plateforme lointaine et une balise éteinte occupent x=4. L’unique objectif est d’atteindre cette balise.
La vue d’ouverture présente un choix de conception, pas une réussite. Deux blocs ne peuvent remplir trois cases vides : faut-il modifier les ressources ou trouver un autre itinéraire ? L’exemple choisit un bloc de réserve exposé sur une plateforme latérale stable en (0,0,y=1), au-dessus d’un cube de base permanent. Sa face latérale est adjacente à la case de départ (0,1), à hauteur d’interaction. Depuis le départ, une action Miner le récupère sans déplacement ; l’explorateur reste en (0,1) et l’inventaire passe de deux à trois.
Gardez le reste du niveau fermé. Seules les trois cases du ravin acceptent des blocs posés. Chaque bloc doit partager une face avec la plateforme proche ou avec la chaîne de pont déjà soutenue. Les plateformes permanentes et les blocs posés ne sont pas minables. Il n’y a ni ennemi, ni recette d’artisanat, ni autre ressource, ni minuterie, ni événement aléatoire ni itinéraire alternatif. Une extraction, une pose ou un déplacement invalide ne change pas l’état. Redémarrer restaure précisément l’état initial de la version choisie.
Ces limites rendent le prompt plus utile, car chaque action demandée correspond à un état visible. « Monde voxel » laisse ouverts la carte, la portée des interactions, la zone de construction et l’objectif. Une petite portion réduit les hypothèses à vérifier.
Préciser les règles d’extraction, de pose et de soutien
Des verbes comme extraire, poser et marcher doivent provoquer un changement d’état précis. Dans cet exemple papier, l’extraction est une action unique contre le bloc de réserve latéral exposé. Elle ne déplace pas le joueur et n’exige pas une approche séparée. La pose utilise un curseur de construction sur les trois cases du passage : elle coûte donc aussi une action sans avancer vers la cible. Le déplacement avance ensuite d’une seule case orthogonale sur une surface soutenue.
| Action | Cible valide et coût | Changement d’état à vérifier |
|---|---|---|
| Miner la réserve | Depuis (0,1), cibler uniquement le cube exposé en (0,0,y=1), adjacent par une face à hauteur d’interaction ; coût : une action. | La réserve disparaît, l’inventaire augmente d’une unité et l’explorateur reste en (0,1). |
| Poser un bloc de pont | Cibler une case vide x=1, 2 ou 3 à z=1 ; elle doit être reliée par une face à la plateforme proche ou à la chaîne soutenue. | L’inventaire baisse d’une unité et la rangée contiguë soutenue s’allonge d’une case. |
| Se déplacer | Avancer d’une case orthogonale exactement sur une surface soutenue. | La position change ; entrer en (4,1) après la création de la route allume la balise et gagne. |
L’ordre compte. Si le jeu permet de poser dans le vide sans soutien, le problème de ressources disparaît. Si l’extraction est possible à toute distance, l’emplacement de la réserve n’a plus d’importance. Si la pose avance l’explorateur, le budget d’actions change. Énoncez ces détails avant de demander une version jouable et précisez qu’une action refusée ne consomme pas silencieusement de ressource et ne déplace pas le joueur.
Dans la vue mécanisme ci-dessous, la réserve a déjà été récupérée depuis le départ sans déplacement, puis les blocs x=1 et x=2 ont été posés. L’explorateur reste sur la plateforme proche, un cube de pierre reste disponible et x=3 est la prochaine pose soutenue valide.
Préparer trois prompts dans l’ordre
Ne demandez pas à un seul prompt d’inventer les règles, de construire le monde et d’évaluer lui-même sa réussite. Donnez à chaque demande une entrée et une sortie claires. Le premier prompt fixe le contrat, le deuxième demande une seule petite boucle et le troisième n’intervient qu’après une observation réelle.
Prompt 1 : verrouiller les règles avant l’implémentation
Conçois une petite boucle solo de construction voxel appelée {game_name}. Utilise les coordonnées de surface {grid_and_start}, un seul objectif {goal} et l’inventaire initial {inventory}. Définis les blocs modifiables, la portée exacte de l’extraction, son effet sur l’inventaire, les conditions de validité d’une pose, la propagation du soutien, les déplacements autorisés et les états précis de victoire et de redémarrage. Pour la carte fournie, récupère depuis la case de départ le bloc de réserve exposé et adjacent par une face, avec une seule action Miner et sans déplacement ; renvoie ses coordonnées et le coût de l’action. Fournis (1) un tableau des coordonnées, (2) un tableau des actions et états, (3) les cas limites d’inventaire vide et de case non soutenue et (4) cinq vérifications d’acceptation. N’ajoute aucune mécanique non demandée. Signale les contradictions avant de proposer l’implémentation.
Pour Mosslight Span, renseignez l’entrée avec le passage de cinq cases, la balise éteinte en x=4 et deux blocs de départ. Placez la réserve en (0,0,y=1), adjacente au départ (0,1) à hauteur d’interaction, et demandez une seule action Miner sans déplacement. Faites répéter l’inventaire après chaque action. Si le contrat ajoute un aller-retour, une extraction à distance ou une autre source, corrigez les règles avant le prompt suivant.
Prompt 2 : demander uniquement la boucle minimale
Implémente uniquement ce contrat de règles voxel approuvé comme une petite boucle jouable : {approved_contract}. Respecte chaque coordonnée, quantité d’inventaire et coût d’action, y compris une action Miner depuis la case de départ pour récupérer sans bouger la réserve adjacente par une face. Ajoute des retours visuels sans texte pour une pose valide ou refusée, le changement d’inventaire, un déplacement soutenu, la victoire à la balise et le redémarrage. Ne rends modifiables que les blocs autorisés par le contrat. N’ajoute ni ennemi, ni artisanat, ni autre ressource, ni événement aléatoire, ni multijoueur, ni deuxième objectif ni monde plus vaste. Fournis les commandes, un bref résumé de l’implémentation et une liste de preuves observables pour chaque vérification d’acceptation. Marque toute fonctionnalité non construite ou non observée comme non vérifiée.
La limite à une boucle est un choix de conception, pas une promesse sur la réponse d’un générateur. Un créateur futur pourra ajouter du décor lorsque les règles de ressources et de soutien seront visibles. Demandez un résumé d’implémentation et les vérifications exécutées afin de distinguer l’observé du prévu.
Prompt 3 : corriger uniquement après une observation
État attendu approuvé : {expected_state}. Observation réelle fournie par une personne : {observed_state_or_blank}. Compare uniquement l’observation fournie aux règles attendues. Si elle est vide, retourne une liste de vérification humaine et ne diagnostique aucun résultat. Si elle est présente, identifie le premier écart, la règle concernée et la modification minimale d’une seule variable qui pourrait le corriger. Précise quelle vérification d’acceptation doit être rejouée et quels contrôles antérieurs doivent rester inchangés. Ne prétends pas qu’une correction a fonctionné avant d’avoir reçu une nouvelle observation.
Ce troisième prompt refuse délibérément d’inventer un résultat. Si un futur jeu s’arrête après deux blocs, une observation utile consignera l’inventaire initial, la réserve visée, la position avant l’extraction, l’état de la réserve après l’action et le refus de pose. Ces faits permettent de distinguer un problème de portée d’interaction, de quantité de ressources ou de soutien. Sans eux, l’étape suivante consiste à capturer l’état, pas à déclarer un correctif.
Hand-check the bridge resource loop
Calculer à la main la boucle de ressources du pont
| Version et action | Cases du pont remplies | Inventaire | Résultat manuel |
|---|---|---|---|
| Départ v0 | 0 | 2 | Aucun cube de réserve. |
| v0 : poser x=1 puis x=2 | 2 | 0 | Les deux blocs sont soutenus, mais x=3 reste vide. |
| v0 : tenter de poser x=3 | 2 | 0 | Refusé, car l’inventaire est vide ; la plateforme éloignée reste inaccessible. |
| v1 : extraire depuis le départ sans bouger | 0 | 3 | Le bloc exposé adjacent par une face disparaît ; l’inventaire passe de 2 à 3. |
| v1 : poser x=1, x=2 puis x=3 | 3 | 0 | Chaque bloc rejoint la plateforme proche ou la chaîne soutenue. |
| v1 : aller de x=0→1→2→3→4 | 3 | 0 | Quatre déplacements soutenus atteignent la plateforme éloignée ; entrer en x=4 allume la balise. |
Count the full V1 route as one Mine + three Place + four Move = eight actions. The final state has a contiguous three-cell bridge, an empty inventory, the explorer on the far platform and the beacon lit. This is the expected result calculated from the authored rules, not a measured result. The V0 trace shows why the one-cube change matters: without it, the third placement cannot be paid for.
Lorsque vous créerez ultérieurement une version, vérifiez l’ordre des événements ainsi que l’état final. Récupérez la réserve avant de poser les blocs ; effectuez les trois poses avant de traverser le pont ; n’allumez la balise qu’à l’entrée dans x=4. Si un effet visuel apparaît plus tôt, comparez son déclencheur au contrat au lieu de supposer que l’image ou le code définit une règle différente.
Comparer un futur jeu avec des observations réelles
Une liste d’acceptation utile nomme un état de départ, une action et la modification attendue. Pour cette carte, vérifiez d’abord qu’une action Miner depuis (0,1) récupère uniquement la réserve exposée en (0,0,y=1), ne déplace pas l’explorateur et fait passer l’inventaire de deux à trois. Vérifiez ensuite qu’on ne peut pas extraire un bloc éloigné ou couvert, que Poser x=1 à x=3 consomme exactement trois blocs dans cet ordre et que la troisième pose v0 est refusée avec un inventaire vide.
Ensuite, testez séparément le soutien et le déplacement. Chaque nouveau bloc de pont doit rejoindre la plateforme proche ou le bloc précédent soutenu ; une cible sans soutien doit être refusée sans changement d’inventaire. À chaque action, l’explorateur ne se déplace que d’une case orthogonale et uniquement sur une surface soutenue. Quatre déplacements peuvent atteindre x=4 une fois le pont complet, où la balise s’allume. Redémarrer doit restaurer la réserve, l’inventaire, la position du joueur et la balise éteinte de la version choisie.
Consignez ce que vous voyez réellement : version, action, état avant, entrée, position après, inventaire, état de la case cible et éventuel signal de victoire. Si une vérification n’a pas été exécutée, marquez-la comme non vérifiée. Un test d’acceptation écrit n’est pas une observation d’un résultat jouable.
Transmettre le brief voxel à Workspace
Une fois les règles délimitées, un créateur peut transmettre le court contrat à un workflow de création de jeux. La page officielle Free AI Game Maker actuelle répertorie une carte de départ Voxel Sandbox Builder pour poser et casser des blocs afin de construire un monde insulaire. Cette description générale ne confirme ni Mosslight Span, ni ces règles de pont, ni le comportement du soutien ni un résultat issu de ces prompts.
La page officielle Free AI Game Maker décrit un flux général : décrire un jeu en langage courant, examiner dans le navigateur un premier résultat jouable en 2D ou 3D, puis l’affiner avec des prompts successifs. Elle recommande également de vérifier le modèle sélectionné, le solde Koin disponible et le coût affiché avant l’envoi. Fournissez les règles délimitées, examinez le résultat réellement produit et comparez-le aux vérifications ci-dessus. Ne présumez pas d’une implémentation voxel ou d’une traversée réussie avant de les observer.
Si vous souhaitez commencer à structurer cette idée, utilisez Free AI game maker. Gardez la première demande réduite, inspectez le résultat généré avant d’itérer et vérifiez le coût affiché avant de continuer. Il s’agit d’un point de départ général de création de jeux, pas d’une garantie de résultat voxel.
FAQ
Que doit contenir un prompt IA pour un jeu de construction voxel ?
Indiquez la zone modifiable, la position de départ, les blocs disponibles, la portée exacte de l’extraction, les règles de pose, les conditions de soutien, le déplacement, l’objectif et le comportement du redémarrage. Demandez ensuite un petit tableau des changements d’état et des vérifications d’acceptation. Ces détails rendent plus facile à examiner le résultat futur qu’une demande vague de bac à sable voxel ouvert, tout en laissant le thème visuel flexible.
Pourquoi définir la portée d’extraction avant le prompt de création ?
La portée modifie le budget d’actions. Dans Mosslight Span, le bloc exposé est adjacent par une face à la case de départ et se récupère avec une seule action Miner, sans déplacement. Si le prompt ne précise pas la portée, le jeu pourrait exiger une approche distincte ou autoriser une extraction à distance, ce qui changerait l’itinéraire et le nombre d’actions. Traitez cette portée exacte comme une règle fictive à tester ultérieurement.
Comment l’exemple obtient-il assez de blocs pour traverser ?
La v0 commence avec deux blocs alors qu’il en faut trois : la troisième pose est refusée avec un inventaire à zéro. La v1 ajoute un bloc de réserve exposé que l’on peut récupérer depuis la case de départ en une action, sans déplacement. Les trois blocs suffisent alors à remplir le pont.
Les prompts Mosslight Span ont-ils été exécutés ou le jeu testé ?
Non. Mosslight Span est un exercice fictif original ; ses modèles de prompts ont été rédigés pour cet article sans être envoyés à un générateur de jeux. Les tableaux sont des calculs manuels. Aucun jeu jouable, aucune partie observée et aucun résultat de test ne sont présentés comme réels.
Que faire si un futur jeu contredit la séquence attendue ?
Capturez le premier état divergent, avec la version, la position du joueur, l’inventaire, la case cible, l’action et le retour obtenu. Comparez cette observation à la vérification correspondante, modifiez une seule règle ou un seul détail d’implémentation puis rejouez la même séquence. Sans observation, utilisez une liste de vérification pour en recueillir une au lieu d’écrire un résultat supposé.
