Ein Stealth-Action-Prompt wird nützlich, wenn er erklärt, was die Wache prüft, wann die Prüfung stattfindet und was die spielende Person davor tun kann. Beginnen Sie mit einem kurzen Korridor, zwei Deckungspunkten, einer exponierten Karte und einem festen Scanplan. So lässt sich ein Regelwerk verfolgen, bevor eine spielbare Szene angefordert wird.
Archive Shift ist ein fiktives Papierbeispiel. Die drei Promptvorlagen sind unausgeführt; die Routen über sechs Züge sind von Hand berechnet. Es ist eine Entwurfs- und Prüfmethode, kein generiertes Spiel, Spieltest oder beobachtetes Ergebnis.
Eine kleine Patrouillenroute anlegen
Geben Sie dem Level ein sichtbares Ziel und eine Druckquelle. In Archive Shift dringt eine Agentin bei A in ein Orbitalarchiv ein, nimmt bei C eine Datenkarte und verlässt es über E. Die Wache scannt nach jeder Aktion einen Sektor. Bei B und D kann Deckung genutzt werden; C bleibt ungeschützt. Daraus entsteht eine Entscheidung: C sofort überqueren oder bei B auf ein sichereres Zeitfenster warten.
| Sektor | Was befindet sich dort? | Was kann die spielende Person tun? |
|---|---|---|
| A | Eingang | Hier ohne Karte starten. |
| B | Erste Deckung | Hineingehen und dann einen Scan abwarten. |
| C | Exponierte Datenkarte | Dorthin gehen und mit separater Aktion interagieren. |
| D | Zweite Deckung | Auf dem Rückweg Deckung erreichen. |
| E | Ausgang | Mit Karte ankommen, um zu gewinnen. |
Die Route über fünf Sektoren hält das Ziel verständlich: Beim Darüberlaufen wird die Karte nicht automatisch genommen; der Ausgang zählt erst mit Karte in der Hand. Die zwei Deckungspunkte machen Warten bedeutsam, ohne Tarnanzeige, Geräuschsystem, Ausschalten, Waffe, Gesundheitsleiste oder zufälliges Patrouillenverhalten.
Die Szene stellt Route und Feedback vor. Der leere Kartenplatz gibt einen Grund zum Weiterspielen; unveränderte Alarmanzeige zeigt, dass ein Scan auf Deckung in diesem Beispiel sicher ist.
Erkennung und Aktionsreihenfolge vor Bewegung festlegen
Ein Patrouillenplan ist nur mit explizitem Timing prüfbar. Archive Shift beginnt mit der Figur bei A, keiner Karte und Alarm 0/2. Jede Aktion kostet einen Zug. Zulässig sind: einen benachbarten Sektor bewegen, am Ort warten oder bei C mit „Interagieren“ die Karte nehmen. Nach der Aktion scannt die Wache den nächsten Sektor dieser festen Folge: B, C, C, D, E, C.
| Regel | Auflösung | Für einen späteren Build prüfen |
|---|---|---|
| Bewegung | Nur einen Sektor entlang A–B–C–D–E bewegen; kostet einen Zug. | Zwei Sektoren dürfen nicht in einer Aktion durchquert werden. |
| Warten | Einen Zug am aktuellen Ort bleiben, danach nächsten Scan auflösen. | Warten in Deckung schaltet Patrouillenplan trotzdem weiter. |
| Interagieren | Bei C einen Zug aufwenden, um Karte zu nehmen und zu behalten. | Karte nicht allein durch Bewegung einsammeln; Scan erfolgt danach. |
| Deckung | Übereinstimmender Scan bei B oder D erhöht Alarm nicht. | Nur die zwei genannten Sektoren gelten als Deckung. |
| Scan in Exposition | Passen Figur und Scan bei C zusammen, Alarm um eins erhöhen. | Scan nach der Aktion ausführen, nicht davor. |
| Endzustand | Alarm 2 sperrt Route und bedeutet Niederlage. E mit Karte erreichen bedeutet nach Auflösung des Zuges Sieg. | Alarmausfall hat Vorrang, falls Scan Alarm auf 2 erhöht. |
Formulieren Sie die Reihenfolge klar: eine gültige Aktion wählen, anwenden, Wache zum nächsten aufgeführten Sektor bewegen, Erkennung auflösen und dann Niederlage oder Ausgang mit Karte prüfen. So entfällt die übliche Unklarheit, ob die Wache vor oder nach Bewegung prüft. Fiktive Regeln enthalten weder Sichtlinie noch Geräusch, abnehmenden Alarm, Diagonalbewegung oder Alternativroute. Ergänzen Sie so etwas erst, wenn sich die Grundschleife beurteilen lässt.
Eine sichere Route mit schnellem Fehlschlag vergleichen
Die sichere Route wartet in Deckung, damit der erste Scan von C vorbeigeht, bevor die Agentin den offenen Bereich betritt. Jede Zeile hält Position nach Aktion, folgenden Scan und resultierenden Zustand fest. So lässt sich die Erklärung wiederholen, statt sich auf den Eindruck zu verlassen, die Route „fühle sich schleichend an“.
| Zug | Aktion und Position der Figur | Scan nach Aktion | Karte / Alarm |
|---|---|---|---|
| Start | Bei A | — | Keine Karte; 0/2 |
| 1 | A→B gehen | B | Deckung fängt Übereinstimmung ab; 0/2 |
| 2 | Bei B warten | C | Figur anderswo; 0/2 |
| 3 | B→C gehen | C | Exponierte Übereinstimmung; 1/2 |
| 4 | Bei C interagieren; Karte nehmen | D | Karte gehalten; 1/2 |
| 5 | C→D gehen | E | Karte gehalten; 1/2 |
| 6 | D→E gehen | C | Karte gehalten; Ausgang erreicht; Sieg bei 1/2 |
Vergleichen Sie den schnellen Weg. Zug 1 führt A→B, Scan B ist harmlos. Zug 2 führt B→C, während der erste C-Scan kommt; Alarm steigt auf 1. Zug 3 nimmt „Interagieren“ die Karte, aber der zweite aufeinanderfolgende C-Scan trifft die Agentin weiterhin ungeschützt; Alarm erreicht 2 und Route wird gesperrt. Die Aktion nimmt zwar die Karte, doch am Zugende hat Niederlage Vorrang. Ein Zug Warten verhindert wiederholte Exposition.
Die Mechanikszene entspricht Zug 2: Karte liegt noch am Pult, Agentin bleibt bei B, Scanmarkierung liegt auf C und Alarm ist weiterhin 0/2. Bei einem Prototyp sollten alle vier sichtbaren Fakten mit der Regelspur verglichen werden und nicht nur, ob die Figur verborgen aussieht.
Drei Prompts mit getrennten Aufgaben verwenden
Bitten Sie nicht einen einzigen langen Prompt, Regeln zu erfinden, Raum zu bauen und Ergebnis in derselben Antwort zu prüfen. Teilen Sie die Arbeit in konkrete Eingaben und begrenzte Ausgaben mit Prüfmöglichkeit auf. Vorlagen lassen sich anpassen, wurden aber nicht ausgeführt. Ersetzen Sie Titel- oder Grafikplatzhalter und prüfen Sie jedes künftige Ergebnis an derselben Zugfolge.
Prompt A: Regelvertrag schließen
Entwirf ein kleines Stealth-Action-Spiel namens Archive Shift mit festem Raum: A Eingang, B Deckung, C exponierte Datenkarte, D Deckung, E Ausgang. Figur startet bei A ohne Karte und Alarm 0/2. Zulässige Aktionen: einen benachbarten Sektor bewegen, am Ort warten, bei C mit Interagieren Karte nehmen. Jede Aktion kostet einen Zug. Nach jeder Aktion scannt die Wache den nächsten Sektor genau in dieser Folge: B, C, C, D, E, C. Übereinstimmender Scan bei B oder D wird wegen Deckung ignoriert; Übereinstimmung bei C erhöht Alarm um eins. Alarm 2 sperrt Route und bedeutet Niederlage. Karte bleibt nach Aufnahme erhalten. E mit Karte erreichen bedeutet nach Zugauflösung Sieg. Keine weiteren Mechaniken.
Gib kompakte Zustandstabelle, Aktionsregeln, Ereignisreihenfolge, Sieg-/Niederlagenprüfung und Neustartzustand zurück. Mehrdeutigkeit markieren, statt ein System dazuzuerfinden. Löse dann von Hand beide Folgen auf: sicher = Gehen, Warten, Gehen, Interagieren, Gehen, Gehen; eilig = Gehen, Gehen, Interagieren. Für jeden Zug Position, Scansektor, Kartenstatus, Alarm und Endzustand auflisten. Abnahme: sichere Route gewinnt mit Alarm 1/2; schnelle Route verliert durch Alarm 2 in Zug 3.Diese erste Anfrage übersetzt Genrebegriffe in Zustandsübergänge. Ihre Abnahme fängt Timing- und Interaktionsfehler ab, bevor Grafikdetails sie verdecken.
Prompt B: Eine spielbare Szene anfordern
Regelvertrag aus Prompt A: [freigegebenen Vertrag hier einfügen]
Erstelle eine spielbare Szene für einen orbitalen Archivkorridor mit fünf angrenzenden Sektoren A–E. Zeige Figur, zwei Deckungsblöcke B und D, exponierte Karte C und Ausgang E. Verwende klare Schulterkamera und zurückhaltendes Alarmfeedback. Die spielende Person muss einen Sektor bewegen, warten und mit Karte interagieren können. Nach jeder Aktion den nächsten Scan sichtbar zeigen. Deckung soll Übereinstimmung bei B oder D ignorieren; Übereinstimmung bei C erhöht Alarm; „Interagieren“ ist eine separate Aktion; Karte wird zum Ausgang getragen.
Gib Szenenlayout, Steuerung, Zustandsanzeige und Ereignisfolge zurück. Erster Build bleibt bei diesem Raum und diesen Regeln. Keine Waffen, Ausschaltungen, Zufallspatrouillen, zusätzlichen Wachen, Geräusch, Gesundheit, Timer oder weiteres Ziel ergänzen. Abnahme: Lesende erkennen aktuellen Sektor, nächsten Scan, Kartenstatus, Alarm, Aktionsergebnis und Neustart aus Anfangszustand. Konzeptbild nicht als spielbare Szene behandeln.Die zweite Anfrage verlangt die kleinste spielbare Darstellung des Vertrags. „Scan zeigen“ sollte einen verständlichen Hinweis vor der nächsten Entscheidung meinen; nach einer Aktion muss Feedback zeigen, ob Alarm sich verändert hat. Gestaltung des Korridors bleibt frei, Regeln bleiben fest.
Diese Ergebnisillustration zeigt den Sollzustand nach der sicheren Route und belegt keine Ausgabe von Prompt B. Gefüllter Kartenplatz, Ausgangsmarker und Alarmanzeige eins von zwei sind drei sichtbare Prüfpunkte für spätere Reviewer.
Prompt C: Künftigen Build ohne Raten prüfen
Regelvertrag: [freigegebenen Vertrag hier einsetzen]
Erwartete Spuren: [sichere und schnelle Spur hier einsetzen]
Belege eines beobachteten Builds: [tatsächliches Laufprotokoll oder Aufnahme anhängen oder leer lassen, wenn nichts vorliegt]
Prüfe einen künftigen Archive-Shift-Build anhand des Vertrags und der Sollspuren. Behaupte keine Ausführung, wenn kein echtes Laufprotokoll oder beobachteter Zustand vorliegt. Fordere pro Prüfung Aktion, Zustand davor, Wachscan, Zustand danach, Alarm, Karte und Endresultat an.
Prüfungen: (1) Deckung bei B ignoriert Scan B; (2) Warten bei B rückt Folge zu C weiter, ohne Alarm; (3) Bewegung B→C vor Scan C erhöht Alarm auf 1; (4) Interagieren bei C kostet Zug und nimmt Karte; (5) nächster C-Scan während Eilroute erhöht Alarm auf 2 und bedeutet Niederlage; (6) sichere Folge aus sechs Aktionen erreicht E mit Karte und Alarm 1; (7) Neustart stellt A, keine Karte, 0/2 und nächsten Scan B wieder her.
Tabelle mit Sollzustand, vom Tester geliefertem beobachtetem Zustand, Übereinstimmung/Abweichung und erster Abweichung zurückgeben. Fehlen Beobachtungsdaten, Feld leer lassen und menschliche Prüfmethode beschreiben; niemals Ergebnis erfinden. Bei erster Abweichung eine Regelklärung empfehlen und auf neuen beobachteten Lauf warten, bevor Behebung bestätigt wird.Diese dritte Anfrage trennt erwartetes Ergebnis von echter Beobachtung. Ein späterer Tester kann Aufnahme oder Laufprotokoll liefern; ohne das ist die richtige Ausgabe eine Checkliste und kein Bestehensurteil.
Die erste Abweichung diagnostizieren, nicht das ganze Spiel
Weicht ein späterer Build von der Spur ab, notieren Sie den ersten Zug, in dem sich der Zustand unterscheidet. Spätere Abweichungen können Folgen dieses ersten Fehlers sein. Bestimmen Sie mithilfe der Tabelle die zu prüfende Regel und wiederholen Sie dieselbe Eingabe, nachdem jeweils nur eine Regel geändert wurde.
| Beobachtetes Symptom | Zu prüfende Regel | Nächster kontrollierter Test |
|---|---|---|
| Figur wird beim Warten auf B entdeckt. | Wird B vor Scanauflösung als Deckung klassifiziert? | Neustart, bei B warten und prüfen, ob Alarm 0 bleibt. |
| Wache scannt, bevor Bewegung angewendet wird. | Ist Scan-Timing umgekehrt? | In Zug 1 A→B gehen und prüfen, dass danach Scan B erfolgt. |
| Karte erscheint ohne Interaktion. | Wird Aufnahme fälschlich automatisch ausgeführt? | Ohne Interaktion auf C gehen und prüfen, ob Karte liegen bleibt. |
| Ausgang gelingt ohne Karte. | Fehlt Inventarprüfung in Siegbedingung? | Kontrolliert E ohne Karte erreichen und Endzustand prüfen. |
Bewahren Sie für eine echte Prüfung den tatsächlichen Vorher-/Nachherzustand statt eines Eindrucks auf. Weicht das Ergebnis ab, aktualisieren Sie Regel oder Umsetzungsanfrage und zeichnen einen neuen Lauf auf. Die Beispiele hier enden bei Papierrechnung, weil weder Prompt noch Buildnachweis vorliegt.
Briefing in einen allgemeinen Spieleablauf übergeben
Die aktuelle Free-AI-Game-Maker-Seite beschreibt Eingabe in einfachem Englisch, eine erste spielbare 2D-/3D-Version, Browsertests und Verfeinerung durch Folgeprompts. Das sind Angaben zu einem allgemeinen Ablauf; sie bestätigen Archive Shift nicht, garantieren keine Umsetzung dieser Regeln und zeigen kein generiertes Ergebnis.
Wenn Sie den Free AI Game Makerverwenden, geben Sie kompakten Regelbrief, prüfen Sie ausgegebene Zustände und vergleichen Übergänge mit der Tabelle. Vor dem Absenden Modellwahl, Koin-Guthaben und angezeigte Kosten im Workspace kontrollieren. Kandidatenpfad und Herkunfts-Slug des Artikels sind vorläufig, bis die Seitenroute bestätigt ist.
Archive-Shift-Regeln und Bilder sind fiktives Lehrmaterial und weder Online-Spiel noch Kundenbeispiel oder SEELE-Ausgabe. Der Nutzen liegt in wiederholbarer Anfrage und Prüfung: Patrouillenfolge nennen, Deckung definieren, sichere Wahl und Fehlschlag durchspielen und erste Abweichung zur Klärung nutzen.
Häufige Fragen
Was sollte ein erster Prompt für ein Stealth-Action-Spiel festlegen?
Startzustand der Figur, ein Ziel, genaues Scan-Timing der Wache, erlaubte Aktionen, Deckungsverhalten sowie Sieg- und Niederlagenbedingungen. Ergänzen Sie eine erwartete Route mit einer Aktion pro Zug. So lassen sich Regeln prüfen, bevor Waffen, mehrere Wachen, Geräusch oder weitere Systeme die Diagnose erschweren.
Ist Archive Shift ein echtes oder getestetes Spiel?
Nein. Archive Shift ist ein eigenständiger fiktiver Entwurf zur Erklärung eines Promptablaufs. Sichere Route über sechs und Niederlage über drei Züge sind anhand der Regeln von Hand aufgelöst. Es wurde weder Prompt ausgeführt noch Build geprüft; Test oder Spielerbeobachtung wird nicht behauptet.
Warum Scan-Timing der Wache festlegen?
Dieselbe Bewegung kann sicher oder entdeckt sein, je nachdem, ob die Wache davor oder danach prüft. In diesem Beispiel handelt die spielende Person zuerst, die Wache scannt danach. Diese Reihenfolge macht Übergang B→C, wiederholten C-Scan, Alarmzuwachs und Niederlage reproduzierbar.
Was bewirkt Deckung in diesem Beispiel?
Nur B und D sind Deckung; nur übereinstimmender Scan dort wird ignoriert. Deckung stoppt weder den Zeitplan der Wache noch sammelt sie die Karte ein oder schützt exponiertes C. Diese enge Regel gibt einen Grund, bei B zu warten, ohne zweites Tarnsystem.
Was tun, wenn ein künftiger Build von der Spur abweicht?
Notieren Sie ersten abweichenden Zug mit Aktion, Scansektor, Position, Kartenstatus und Alarm vor und nach Auflösung. Prüfen Sie die verantwortliche Übergangsregel, präzisieren einen Punkt, starten neu und wiederholen dieselbe Folge. Eine Papiererwartung beweist kein gewünschtes Buildverhalten.
