Write Three AI Prompts for a Tactical Shooter

Build a tactical-shooter prompt in three passes: define the encounter rules, ask for one playable room, then compare a future build against expected states. A short rules contract makes positioning and timing visible before extra weapons, enemies, or maps can obscure the loop.

Relay Room is an original fictional example resolved by hand. These prompt templates have not been run, and no game build, playtest, or measured result is claimed. Use the traces below as expected states for a future check, not as observed behavior.

Keep this prompt library out of stealth and genre overviews

This article is for a designer who has a tactical-shooter idea but needs a focused brief that can be implemented and checked. Its deliverable is a rules prompt, an encounter prompt, and a future-validation prompt tied to one deterministic room. That is narrower than a broad guide to tactical shooters: it spends its space on action acceptance, line of sight, enemy timing, and the state a later test should record.

It also solves a different problem from a stealth prompt library. Relay Room has no patrol route, noise, concealment, detection meter, or escape-card objective. The player sees one security drone telegraph a lane, leaves that tile, and uses a one-action opening to shoot. It does not add a rescue target, map rebuild, campaign route, character selection, or scenario editor. Those systems would each require a different rules contract.

Keep the scope deliberately small: one operator, one rifle, one mechanical threat, four connected positions, and five rounds. The point is not to claim that this is the only way to design the genre. It is to show how a prompt can say what is legal, what changes after an accepted action, and what must remain untouched after a rejected one.

Define Relay Room before writing a build prompt

The fictional objective is to disable one hostile security drone, called the Rook, before the end of round 5 while keeping the operator alive. The connected room route is Entry Cover → Center Lane → East Cover → North Cover. Each position has a fixed player-to-Rook line of sight (LOS); the cover geometry is separate from whether the operator can fire from that position.

LOS is checked from the named firing position; crouching, leaning, or spending another aim action is not part of this example. Center Lane is the only exposed position. East and North let the player see the Rook while their barriers block its direct shot.

The starting state is player at Entry Cover, health 2/2, rifle ammunition 2/2, Rook health 2, shutter closed, and round 1. There is one accepted player action each round: move one adjacent space, fire once, or hold. The Rook acts after an accepted player action. Mark rounds are 1 and 3; it paints Center as the tile it will fire on in the following round. Fire rounds are 2 and 4; the volley damages the player by one only if the player occupies the marked Center tile. A successful volley at an empty tile opens the Rook's sensor shutter for exactly the next accepted player action.

A Rook shot is legal only when four checks are true: the Rook is active, ammunition remains, the shutter is open, and LOS is clear from the current position. A legal shot removes one Rook health and one rifle round. During an open window, an accepted shot, move, or hold consumes the window and closes the shutter before the next scheduled enemy phase. Move and hold use no ammunition, but they still spend the action. This makes the choice consequential: the player can use the opening to shoot or give it up to reposition.

Rejected input behaves differently from an accepted move. An occluded shot from Entry, a shot at a closed shutter, an empty-ammo shot, or invalid movement changes no action slot, round, ammo, shutter, or enemy schedule. The player receives a concise rejection cue and can correct the input in the same slot. The Rook is disabled at zero health, which ends the encounter immediately; player health at zero is a loss, and an active Rook at the end of round 5 is also a loss. Restart restores the exact initial state.

Trace the safe and failing encounters

The safe line moves off the painted tile before each volley, then spends the two open windows on shots from positions with clear LOS. The phase order matters: the Rook's volley resolves after the accepted player action, and the shutter opens only after the Fire phase has resolved.

Both shots are accepted: at the start of rounds 3 and 5 the shutter is open, the Rook is active, ammunition remains, and the player's LOS from East and North is clear. Each hit closes the shutter and advances the next scheduled phase. The Center volleys miss because the operator left the marked lane first.

The failing line exposes why the warning matters. Move to Center in round 1 and the Rook marks it. Hold there in round 2: the volley hits, health falls from 2 to 1, and the shutter opens. In round 3, fire from Center; the shot is legal because LOS is clear, so ammo falls to 1 and Rook health falls to 1. The shutter closes and Center is marked again. Hold in Center during round 4 and the next volley reduces health from 1 to 0. The loss is immediate; there is no round-5 shot. This is a hand calculation from the fictional rules, not a playtest result.

Write three prompts for rules, play, and validation

Keep the prompt jobs separate. A rules pass should identify contradictions before implementation. A build request should express one encounter without asking for extra features. A validation prompt is only useful after there is an accessible build and someone can observe actual state. These templates are planned text, not prompts sent to a model.

Prompt 1: specify and audit the rules

Write a deterministic rules contract for the fictional Relay Room tactical-shooter encounter below. Do not invent mechanics. Return (1) the state variables and starting values, (2) the connected position map and player-to-Rook LOS at each position, (3) the accepted-action and rejected-action rules, (4) the exact player/enemy phase order for rounds 1–5, (5) the win, loss, and restart conditions, and (6) a transition table for the safe and failing traces.

Starting state: player at Entry Cover; player health 2/2; rifle ammo 2/2; Rook health 2; sensor shutter closed; round 1. Connected positions: Entry Cover → Center Lane → East Cover → North Cover. Player LOS: Entry blocked by the solid blast wall; Center clear; East clear through the side firing opening; North clear over the low barrier. East and North barriers block the Rook's direct shot while the player's firing line remains clear.

One accepted player action per round: move one adjacent position, fire once, or hold. A shot requires active Rook + remaining ammo + open shutter + clear LOS. A rejected invalid/occluded action changes no action slot, round, ammo, shutter, or enemy schedule. After an accepted action resolve the scheduled Rook phase. Rounds 1 and 3 mark Center; rounds 2 and 4 fire at Center. If occupied, the volley removes one player health; otherwise it misses. After a Fire volley, open the shutter for exactly the next accepted player action. Any accepted shot, move, or hold consumes that window and closes it before the next enemy phase; move/hold spend no ammo. A shot deals one Rook damage and spends one round. Disable the Rook at zero health and end immediately. Lose at player health zero or with an active Rook after round 5. Restart restores the exact initial state.

Manually check every transition in these traces and flag contradictions without silently fixing them. Return expected state after each action and enemy phase; no observed gameplay or test result is available.

Inspect the returned table for phase-order drift: a repair, extra action, or second volley would change the design. If the written rules disagree with the safe/failing traces, resolve the disagreement in the contract before turning it into a build request.

Prompt 2: request one playable encounter

Create a small first-person tactical-shooter prototype for the fictional Relay Room using the approved rules contract. Build one fixed, connected room with Entry Cover, Center Lane, East Cover, North Cover, and one compact Rook security drone. Preserve the specified sightlines and cover behavior. Show the round, player health, rifle rounds, Rook health, warning tile, and shutter state with clear, readable game feedback.

Implement exactly one accepted player action per round: move one adjacent space, fire, or hold. A shot is accepted only for an active Rook, remaining ammunition, an open shutter, and clear player-to-Rook LOS. An accepted shot deals one damage and uses one round. After the scheduled enemy phase, Fire rounds 2 and 4 open the shutter for exactly the next accepted player action. An accepted move or hold consumes that action and closes the shutter without spending ammo. A rejected invalid or occluded action must leave the action slot, round, ammo, shutter, and Rook schedule unchanged and allow a correction in the same slot. Implement immediate win at Rook health 0; loss at player health 0 or active Rook after round 5; restart to the exact start.

Do not add other enemies, weapons, stealth, rescue objectives, maps, random damage, reloads, or unlisted actions. Provide controls and visible feedback for accepted/rejected actions. Treat this as a design request only: do not report that it has been executed, built, or tested unless verifiable output is supplied.

Ask for feedback that is inspectable: the marked tile should be visible before the volley, a safe move should clear it, and a rejected shot should leave every specified field unchanged. Those requirements tell a reader what to look for without assuming a particular engine or code structure.

Prompt 3: validate a future build against expected states

Only if an accessible playable Relay Room build is supplied, run the safe trace and the failing trace exactly as written in the approved rules table. Record actual state after every player action and enemy phase: position, player-to-Rook LOS, accepted/rejected action, round, marked tile, player health, ammo, Rook health, shutter, scheduled phase, and terminal result. Compare each observed value with the expected value. Mark the first divergence and stop that trace if the encounter ends early.

Specifically check the four LOS positions; the one-action window after rounds 2 and 4; an accepted move/hold consuming and closing the window; and a rejected occluded shot at Entry Cover leaving action slot, round, ammo, shutter, and Rook schedule unchanged. Do not infer a pass from a prompt response or concept image. If no build or run evidence is available, return NOT RUN and leave all actual-observation cells blank.

Keep expected and actual states in separate columns. That small discipline prevents a manually computed example from being presented later as something a player or product actually did.

Compare a future build with the paper contract

Before using the third prompt, prepare a short observation sheet. Record only what a player can verify in the supplied build; do not fill the actual column from the rules. One failure can be localized by comparing the first state that differs from expectation.

A future implementation check should also test the negative path. Try an occluded shot from Entry Cover before changing position. The expected result is a rejection cue with the same round, ammo, shutter, and enemy schedule. If the build advances anyway, the first correction belongs in action acceptance, not in the damage values.

Take a focused encounter to an AI FPS workflow

As described on its official page, the AI FPS Game Generator focuses on one first-person encounter: set an objective, threat, and player response, then review route and weapon feedback and tune one detail after replay. Its sample prompt names a browser FPS with a pulse rifle, two slow drones, a health-and-ammo HUD, hit feedback, an exit condition, and restart. The Free AI Game Maker page describes plain-English prompts, a playable first 2D or 3D version, browser testing, and follow-up prompt refinement. These are product-page descriptions; neither verifies Relay Room or promises its exact rules.

To start your own creation pass, provide the room map, action budget, LOS rules, telegraph schedule, health, ammunition, terminal conditions, and restart state. If you submit a generation request, review the selected model, available Koin balance, and displayed generation cost in Workspace first. If a playable result is returned, compare its behavior with the expected table rather than assuming every rule carried over. AI FPS game.