Établir les règles avant de demander une salle jouable

Rédigez un prompt de jeu de tir tactique en trois étapes : définissez les règles de l’affrontement, demandez une salle jouable, puis comparez un futur jeu aux états attendus. Un contrat de règles concis rend visibles le placement et le minutage avant que des armes, ennemis ou cartes supplémentaires ne brouillent la boucle de jeu.

Relay Room est un exemple fictif original, résolu par calcul manuel. Ces modèles de prompt n’ont pas été exécutés ; aucun jeu, test de jeu ou résultat mesuré n’est revendiqué. Utilisez les séquences ci-dessous comme états attendus lors d’une vérification future, et non comme des comportements observés.

Éviter les panoramas sur la furtivité et le genre

Cet article s’adresse à une personne qui imagine un jeu de tir tactique et a besoin d’un brief ciblé, réalisable et vérifiable. Il fournit un prompt de règles, un prompt d’affrontement et un prompt de validation future, tous liés à une salle déterministe. Son périmètre est plus restreint qu’un guide général du genre : il se concentre sur l’acceptation des actions, la ligne de tir, le rythme de l’ennemi et les états qu’un test ultérieur devra consigner.

Il répond aussi à un autre besoin qu’une collection de prompts sur la furtivité. Relay Room ne comporte ni patrouille, ni bruit, ni camouflage, ni jauge de détection, ni objectif de fuite. Le joueur voit un drone de sécurité annoncer une voie de tir, quitte la case visée, puis profite d’une action pour tirer. Il n’y a ni personne à secourir, ni reconstruction de carte, ni campagne, ni sélection de personnage, ni éditeur de scénario. Ces systèmes nécessiteraient chacun un contrat de règles distinct.

Gardez un périmètre volontairement réduit : un opérateur, un fusil, une menace mécanique, quatre positions reliées et cinq manches. Il ne s’agit pas de prétendre que c’est la seule façon de concevoir le genre, mais de montrer comment préciser les actions autorisées, les changements après une action acceptée et les éléments qui doivent rester inchangés après un refus.

Définir Relay Room avant de rédiger le prompt de création

L’objectif fictif est de neutraliser un drone de sécurité ennemi, le Rook, avant la fin de la manche 5 tout en gardant l’opérateur en vie. Le parcours relié est : Abri d’entrée → Couloir central → Abri est → Abri nord. Chaque position a une ligne de tir (LOS) fixe entre le joueur et le Rook ; la géométrie des abris est distincte de la possibilité de tirer depuis cette position.

La LOS est évaluée depuis la position de tir indiquée ; s’accroupir, se pencher ou dépenser une action de visée supplémentaire ne fait pas partie de cet exemple.

État initial : joueur dans l’Abri d’entrée, santé 2/2, munitions du fusil 2/2, santé du Rook 2, volet fermé, manche 1. Le joueur dispose d’une action acceptée par manche : avancer d’une case adjacente, tirer une fois ou attendre. Le Rook agit après une action acceptée. Aux manches 1 et 3, il marque le Couloir central, la case qu’il visera à la manche suivante. Aux manches 2 et 4, il tire : la salve inflige un dégât uniquement si le joueur occupe la case marquée. Si la salve touche une case vide, le volet du capteur du Rook s’ouvre pour exactement la prochaine action acceptée.

Un tir sur le Rook n’est légal que si quatre conditions sont réunies : le Rook est actif, il reste des munitions, le volet est ouvert et la LOS est dégagée depuis la position actuelle. Un tir légal retire un point de santé au Rook et une cartouche du fusil. Pendant une fenêtre ouverte, tout tir, déplacement ou attente acceptés consomment la fenêtre et ferment le volet avant la prochaine phase ennemie prévue. Le déplacement et l’attente ne consomment pas de munitions, mais dépensent l’action. Le choix est donc conséquent : tirer pendant l’ouverture ou y renoncer pour se repositionner.

Une entrée refusée ne se comporte pas comme un déplacement accepté. Un tir bloqué depuis l’entrée, un tir sur volet fermé, un tir sans munitions ou un déplacement invalide ne modifient ni le créneau d’action, ni la manche, les munitions, le volet ou le calendrier ennemi. Un bref message de refus permet de corriger l’action dans le même créneau. À zéro santé, le Rook est neutralisé et l’affrontement s’arrête immédiatement ; à zéro santé, le joueur perd. Le joueur perd aussi si le Rook est encore actif à la fin de la manche 5. Le redémarrage restaure exactement l’état initial.

Dérouler les scénarios réussi et raté

La stratégie sûre consiste à quitter la case annoncée avant chaque salve, puis à utiliser les deux fenêtres ouvertes pour tirer depuis des positions où la LOS est dégagée. L’ordre des phases compte : la salve du Rook survient après l’action acceptée du joueur, et le volet ne s’ouvre qu’après la résolution de la phase de tir.

Les deux tirs sont acceptés : au début des manches 3 et 5, le volet est ouvert, le Rook est actif, il reste des munitions et la LOS est dégagée depuis les abris est et nord. Chaque impact ferme le volet et fait avancer la prochaine phase prévue. Les salves dans le Couloir central manquent leur cible parce que l’opérateur a quitté la case marquée.

La stratégie ratée montre pourquoi l’avertissement compte. Déplacez-vous dans le Couloir central à la manche 1 : le Rook le marque. Attendez sur place à la manche 2 : la salve touche, la santé passe de 2 à 1 et le volet s’ouvre. À la manche 3, tirez depuis le centre ; la LOS est dégagée, le tir est donc légal. Les munitions passent à 1 et la santé du Rook à 1. Le volet se ferme et le centre est de nouveau marqué. Attendez dans le couloir à la manche 4 : la salve suivante fait passer la santé à 0. La défaite est immédiate ; aucun tir n’a lieu à la manche 5. Il s’agit d’un calcul manuel fondé sur les règles fictives, pas d’un test de jeu.

Rédiger trois prompts : règles, jeu et validation

Séparez les rôles des prompts. Une étape consacrée aux règles doit repérer les contradictions avant l’implémentation. Une demande de création doit décrire un seul affrontement sans réclamer de fonctionnalités supplémentaires. Un prompt de validation n’est utile que si un jeu accessible existe et qu’une personne peut observer son état. Ces modèles sont des textes prévus, ils n’ont pas été envoyés à un modèle.

Prompt 1 : préciser et vérifier les règles

Rédige un contrat de règles déterministe pour l’affrontement fictif de jeu de tir tactique Relay Room ci-dessous. N’invente aucune mécanique. Fournis (1) les variables d’état et leurs valeurs initiales, (2) la carte des positions reliées et la LOS entre joueur et Rook à chaque position, (3) les règles des actions acceptées et refusées, (4) l’ordre exact des phases joueur/ennemi aux manches 1 à 5, (5) les conditions de victoire, de défaite et de redémarrage, et (6) un tableau de transitions pour les scénarios sûr et raté.

État initial : joueur dans l’Abri d’entrée ; santé 2/2 ; munitions 2/2 ; santé du Rook 2 ; volet fermé ; manche 1. Positions reliées : Abri d’entrée → Couloir central → Abri est → Abri nord. LOS du joueur : entrée bloquée par le mur pare-souffle plein ; centre dégagé ; est dégagé par une ouverture latérale ; nord dégagé par-dessus une barrière basse. Les barrières est et nord bloquent le tir direct du Rook, tandis que le joueur conserve une ligne de tir dégagée.

Une action acceptée par manche : avancer d’une position adjacente, tirer ou attendre. Un tir exige un Rook actif, des munitions, un volet ouvert et une LOS dégagée. Une action invalide ou bloquée refusée ne change ni le créneau d’action, ni la manche, les munitions, le volet ou le calendrier ennemi. Après une action acceptée, résoudre la phase prévue du Rook. Aux manches 1 et 3, marquer le Couloir central ; aux manches 2 et 4, tirer sur cette case. Si elle est occupée, la salve retire un point de santé ; sinon, elle la manque. Après une salve de tir, ouvrir le volet pour exactement la prochaine action acceptée. Tout tir, déplacement ou attente accepté consomme cette fenêtre et la ferme avant la phase ennemie suivante ; déplacement et attente ne dépensent pas de munitions. Un tir inflige un dégât au Rook et consomme une cartouche. Neutraliser le Rook à zéro santé et terminer immédiatement. Défaite à zéro santé joueur ou si le Rook est encore actif après la manche 5. Le redémarrage restaure exactement l’état initial.

Vérifie manuellement chaque transition des deux scénarios et signale les contradictions sans les corriger silencieusement. Donne l’état attendu après chaque action et chaque phase ennemie. Aucun gameplay ni résultat de test observé n’est disponible.

Vérifiez le tableau obtenu pour repérer tout écart dans l’ordre des phases : une réparation, une action supplémentaire ou une deuxième salve changerait la conception. Si les règles écrites contredisent les séquences sûres ou ratées, corrigez le contrat avant d’en faire une demande de création.

Prompt 2 : demander un affrontement jouable

Crée un premier prototype de jeu de tir tactique à la première personne pour l’affrontement fictif Relay Room, selon le contrat de règles approuvé. Construis une seule salle fixe avec quatre zones reliées : Abri d’entrée, Couloir central, Abri est, Abri nord, et un petit drone de sécurité Rook. Respecte les lignes de tir et les abris décrits. Affiche lisiblement la manche, la santé du joueur, les cartouches du fusil, la santé du Rook, la case menacée et l’état du volet.

Autorise exactement une action acceptée du joueur par manche : avancer d’une case adjacente, tirer ou attendre. Un tir n’est accepté que si le Rook est actif, que des munitions restent, que le volet est ouvert et que la LOS du joueur est dégagée. Un tir accepté inflige un dégât et consomme une cartouche. Après la phase ennemie prévue, les tirs des manches 2 et 4 ouvrent le volet pour exactement la prochaine action acceptée. Un déplacement ou une attente acceptés consomment cette action et ferment le volet sans utiliser de munitions. Une action invalide ou bloquée refusée ne doit modifier ni le créneau, ni la manche, les munitions, le volet ou le calendrier du Rook ; autorise une correction dans le même créneau. Victoire immédiate à zéro santé du Rook ; défaite à zéro santé du joueur ou si le Rook reste actif après la manche 5 ; le redémarrage rétablit l’état initial exact.

N’ajoute pas d’autres ennemis, armes, furtivité, objectifs de sauvetage, cartes, dégâts aléatoires, rechargement ou actions non spécifiées. Affiche les commandes et un retour clair pour les actions acceptées ou refusées. Il s’agit seulement d’une demande de conception : ne dis pas que le prototype a été créé ou testé sans résultat vérifiable.

Demandez des retours vérifiables : la case marquée doit être visible avant la salve, un déplacement sûr doit en dégager le joueur et un tir refusé doit laisser inchangés tous les champs spécifiés. Ces exigences indiquent quoi examiner sans imposer un moteur ou une structure de code.

Prompt 3 : valider un futur jeu par rapport aux états attendus

Uniquement si un jeu Relay Room accessible et jouable est fourni, exécute exactement le scénario sûr et le scénario raté décrits dans le tableau de règles approuvé. Consigne l’état réel après chaque action du joueur et phase ennemie : position, LOS joueur-Rook, action acceptée ou refusée, manche, case marquée, santé du joueur, munitions, santé du Rook, volet, phase prévue et résultat final. Compare chaque valeur observée à la valeur attendue. Signale le premier écart et arrête le scénario si l’affrontement se termine prématurément.

Vérifie précisément les quatre positions de LOS ; la fenêtre d’une action après les manches 2 et 4 ; la consommation et la fermeture de la fenêtre après un déplacement ou une attente acceptés ; et le refus d’un tir bloqué depuis l’Abri d’entrée sans changement du créneau, de la manche, des munitions, du volet ou du calendrier du Rook. Ne déduis pas une réussite d’une réponse à un prompt ou d’une image conceptuelle. Si aucun jeu ou résultat d’exécution n’est disponible, réponds NON EXÉCUTÉ et laisse toutes les cellules d’observations réelles vides.

Gardez les états attendus et observés dans des colonnes distinctes. Cette précaution évite qu’un exemple calculé à la main soit ensuite présenté comme le comportement réel d’un joueur ou d’un produit.

Comparer un futur jeu au contrat papier

Avant d’utiliser le troisième prompt, préparez une courte fiche d’observation. Notez uniquement ce qu’une personne peut vérifier dans le jeu fourni ; ne remplissez pas la colonne du réel à partir des règles. Comparez les états et localisez l’échec au premier écart.

Une future vérification de l’implémentation doit également essayer le chemin négatif. Tentez un tir bloqué depuis l’Abri d’entrée avant de bouger. Le résultat attendu est un message de refus sans changement de manche, de munitions, de volet ou de calendrier ennemi. Si le jeu avance malgré tout, la première correction concerne l’acceptation des actions, pas les dégâts.

Transmettre un affrontement ciblé à un outil de création FPS par IA

Selon sa page officielle, AI FPS Game Generator se concentre sur un affrontement à la première personne : définir un objectif, une menace et la réponse du joueur, puis examiner le parcours et les retours sur les armes et ajuster un détail après une nouvelle partie. Son exemple de prompt décrit un FPS dans le navigateur avec un fusil à impulsion, deux drones lents, une interface de santé et de munitions, des retours de tir, une condition de sortie et un redémarrage. La page Free AI Game Maker décrit des prompts en langage courant, une première version jouable en 2D ou 3D, des tests dans le navigateur et des améliorations par prompts. Ce sont des descriptions de pages produit : aucune ne confirme Relay Room ni ne garantit l’application de ses règles exactes.

Pour lancer votre propre création, fournissez la carte, le budget d’actions, les règles de LOS, le calendrier des avertissements, la santé, les munitions, les conditions de fin et l’état de redémarrage. Avant d’envoyer une demande de génération, vérifiez dans Workspace le modèle sélectionné, le solde Koin disponible et le coût affiché. Si un jeu jouable est renvoyé, comparez son comportement au tableau attendu au lieu de supposer que toutes les règles ont été reprises. Le lien AI FPS game est le point d’entrée général approuvé pour créer des jeux FPS.