Unterwasser-Survival lässt sich leichter prototypisieren, wenn es eine Route, ein Bergungsziel und zwei gut lesbare Grenzen gibt. Beginnen Sie mit einem Oberflächendock, einem Felsvorsprung und einem Graben. Legen Sie für jede gültige Aktion Sauerstoffkosten fest, zeigen Sie die Tiefenbelastung mit einem zweiten Zähler und bestimmen Sie genau, wann eine Niederlage geprüft wird. Teilen Sie dann KI-Anfragen auf: zuerst die Regeln, dann den kleinsten spielbaren Abschnitt und erst später eine gezielte Reparatur anhand beobachteten Verhaltens.
Blueglass Reach ist ein origineller fiktiver Entwurf für ein manuell berechnetes Lehrbeispiel. Kein Prompt wurde ausgeführt, und es gibt weder einen spielbaren Build noch einen Test. Sauerstoff- und Dichtungswerte sind erfundene Spieleinstellungen, keine reale Tauchberatung.
Einen einzelnen Tauchgang als Umfang wählen
Ein erster Unterwasser-Prototyp braucht weder Weltkarte noch Sauerstoffwirtschaft, Basisbau oder verschiedene Meerestiere. Er braucht eine kurze Reise, bei der klar ist, was geborgen werden soll und ob die Rückkehr möglich ist. In Blueglass Reach gibt es einen Taucher und eine versiegelte Vermessungskapsel: abtauchen, scannen, einsammeln und zum Moon Pool zurückkehren.
Halten Sie die Route klein genug, um sie als Folge von Orten statt als Koordinatensystem zu prüfen. D0 ist das Oberflächendock Moon Pool. D1 ist ein Felsvorsprung zwischen Pool und Graben. D2 ist der Blue Trench, in dem die Kapsel liegt. Bewegung ist nur zwischen benachbarten Knoten erlaubt. Zum Ab- und Auftauchen dient dieselbe Route, sodass sich jede Kostenänderung prüfen lässt, bevor Grafik oder Zusatzaufgaben hinzukommen.
| Knoten | Was der Taucher sieht | Routenentscheidung |
|---|---|---|
| D0 – Moon Pool | Oberflächendock, Seilanker und einziger sicherer Rückkehrpunkt | Hier starten; gewonnen ist nur die Rückkehr mit Kapsel |
| D1 – Felsvorsprung | Breite Kante zwischen klarem Oberflächenwasser und dunklerem Graben | In einzelnen Kanten nach D0 oder D2 bewegen |
| D2 – Blue Trench | Eine versiegelte Vermessungskapsel und ein schmaler Rückweg nach oben | Scannen, einsammeln oder weiter; Nachfüllen und Reparatur gibt es nicht |
Dies ist ein Einzelspieler-Abschnitt mit einem Tauchgang. Koop-Rollen, dauerhafte Fortschritte, verbundene Siedlungen, Herstellung und erneuerbare Ressourcen bleiben bewusst außen vor. Diese Systeme würden andere Designfragen beantworten und die Prüfung des ersten Rückwegs erschweren.
Sauerstoff- und Druckkosten vor dem Prompt festlegen
Legen Sie Anfangszustand und Aktionsreihenfolge fest, bevor ein Tool eine Szene erzeugen soll. Der Taucher startet bei D0 mit Sauerstoff 8/8, Anzugdichtung 5/5, ohne Scan und ohne Kapsel. Jede gültige Aktion kostet einen Sauerstoffpunkt. Eine gültige Aktion, die bei D2 beginnt oder endet, kostet außerdem genau einen Dichtungspunkt, auch wenn die Bewegung die Kante D1–D2 überquert. Ungültige Aktionen werden zurückgewiesen, bevor Kosten anfallen.
Die Tiefenbelastung ist eine einfache Spielmarke und simuliert weder Taucher noch Anzug. Die reale Annahme ist enger: Laut NOAA steigt der Wasserdruck mit der Tiefe um ungefähr eine Atmosphäre je 33 Fuß (10,06 Meter) Abstieg. Diese Richtung kann eine Herausforderung mit zunehmender Tiefe anregen, bestätigt jedoch weder den erfundenen Dichtungszähler noch dessen Schrittweite, Ausrüstung oder Sicherheitsfolgerungen. Die NOAA-Erklärung zum Druck stützt nur die physikalische Grundannahme.
| Regel | Designvertrag | Später prüfen |
|---|---|---|
| Bewegen | Nur zu einem benachbarten Knoten bewegen; 1 Sauerstoff zahlen, danach 1 Dichtungspunkt, falls der Weg bei D2 beginnt oder endet | Position, Sauerstoff und Dichtung nach jeder Kante |
| Scannen | Einmalig bei D2; 1 Sauerstoff und 1 Dichtung zahlen, dann scanned auf true setzen | Kapsel erscheint; beide Zähler werden genau einmal aktualisiert |
| Einsammeln | Einmalig bei D2 nach dem Scan; 1 Sauerstoff und 1 Dichtung zahlen, dann capsuleCarried auf true setzen | Bodenhalterung ist leer und Taucher trägt die Kapsel |
| Warten | An jedem Knoten erlaubt; 1 Sauerstoff zahlen und bei D2 zusätzlich die Dichtungskosten | Kein Missionsfortschritt, aber Zähler ändern sich |
| Ungültige Aktion | Nicht benachbarte Bewegung, verfrühten oder wiederholten Scan sowie verfrühtes/wiederholtes Einsammeln ohne Zustandsänderung zurückweisen | Position, Zähler und Flags bleiben unverändert |
| Endzustand prüfen | Nach gültiger Aktion zuerst Sauerstoff oder Dichtung auf null prüfen; erst danach D0 mit getragener Kapsel prüfen | Eine Ressource auf null bedeutet Niederlage, selbst wenn der Taucher mit dieser Aktion D0 erreicht hat |
Wickeln Sie jeden gültigen Zug gleich ab: einen Sauerstoff abziehen, Bewegung oder Missionsaktion anwenden, einen Dichtungspunkt abziehen, falls die Aktion bei D2 begann oder endete, dann Niederlage vor Sieg prüfen. Ein erfolgreiches Einsammeln darf seine Kosten nicht aufheben; eine Rückkehr ist kein Sieg, wenn der Sauerstoff zuvor null erreicht hat. Reset stellt das ganze Anfangszustands-Tupel wieder her und ist keine kostenlose Aktion während des Tauchgangs.
Das Bild zeigt die genaue Entscheidung nach dem Einsammeln: Die Kapsel ist aus der Halterung genommen, der Taucher trägt sie und der Aufstieg ist frei. Die zwei verbliebenen Dichtungspunkte reichen für den Weg D2 nach D1 und lassen einen für das letzte Stück nach D0 übrig, weil D1 nach D0 den Tiefenknoten nicht berührt.
Regeln in drei KI-Prompts aufteilen
Packen Sie Weltenbau, Umsetzung und Tests nicht in eine übergroße Anfrage. Jeder Prompt hat unten einen eigenen Zweck und eine prüfbare Ausgabe. Es sind kopierfertige Vorlagen, keine aufgezeichneten Modellläufe. Lassen Sie die Regeln zwischen den Prompts unverändert, damit sich spätere Beobachtungen einer bestimmten Anfrage zuordnen lassen.
Prompt 1: einen Implementierungsvertrag anfordern
Entwirf einen kleinen originellen Einzelspieler-Prototyp für Unterwasser-Survival namens Blueglass Reach. Gib vor dem Programmieren einen knappen Implementierungsvertrag nur für diese Route aus: Moon Pool D0 ↔ Felsvorsprung D1 ↔ Blue Trench D2. Der Taucher startet bei D0 mit Sauerstoff 8/8 und Dichtung 5/5. Bei D2 liegt eine versiegelte Vermessungskapsel. Jede gültige Aktion kostet genau einen Sauerstoffpunkt. Bewegung nur entlang einer angrenzenden Routenkante. Bei D2 einmal scannen, um die Kapsel aufzudecken. Nach dem Scan bei D2 einmal einsammeln. Warten ist erlaubt, bringt aber keinen Fortschritt. Eine gültige Aktion, die bei D2 beginnt oder endet, kostet genau einen Dichtungspunkt; eine ungültige Aktion kostet nichts und ändert nichts. Reihenfolge: Sauerstoffkosten, Aktionseffekt, gegebenenfalls eine Tiefenkosten-Einheit, Niederlage bei Sauerstoff oder Dichtung null, ansonsten Sieg nur bei D0 mit Kapsel. Reset stellt den Anfangszustand wieder her. Liefere Zustandsschema, Aktionsbedingungen, Übergangsreihenfolge, Sieg-/Niederlagebedingungen und eine kompakte Prüftabelle. Keine Mehrspielerfunktion, Basis, Herstellung, Sauerstoffnachfüllung, dauerhaften Fortschritte, Zufallswerte oder zusätzliche Knoten ergänzen. Kennzeichne Zahlen als erfundene Spieleinstellungen, nicht als reale Tauchberatung.Prüfen Sie den zurückgegebenen Vertrag anhand des Knotengraphen und der Kostenreihenfolge. Er sollte den Sprung D0–D2, einen zweiten Scan und Einsammeln vor dem Scan zurückweisen, ohne Zähler zu ändern. Fügt die Regelübersicht eine kostenlose Aktion hinzu oder berechnet sie bei D1–D2 zweimal Dichtungskosten, korrigieren Sie sie vor einem Build-Prompt.
Prompt 2: den kleinsten spielbaren Abschnitt anfordern
Erstelle anhand des Blueglass-Reach-Vertrags unten den kleinsten spielbaren Ein-Tauchgang-Prototyp in deiner verfügbaren Laufzeitumgebung. Zeige einen Taucher in Third-Person-Ansicht, die drei verbundenen Tiefenorte, ein Scan-Ziel bei D2, eine sammelbare Kapsel und einen klaren Rückweg. Biete Bewegung zu einem benachbarten Ort, einmaligen Scan, gesperrtes Einsammeln, Warten ohne Fortschritt und Reset. Sauerstoff und Dichtung bleiben als Zähler oder Punkte sichtbar; Scan, Fund, Niederlage und Rückkehr erhalten unterscheidbare, lesbare Rückmeldungen. Setze die Aktionsreihenfolge exakt um: ungültige Aktionen ohne Kosten zurückweisen; Sauerstoff abziehen; Aktion ausführen; einen Dichtungspunkt abziehen, wenn die Aktion bei D2 beginnt oder endet; Niederlage durch Sauerstoff/Dichtung vor Sieg bei D0 mit Kapsel prüfen. Keine Basis, weitere Taucher, Herstellungswirtschaft, zweites Ziel, Zufallswürfe oder Druck-/Medizinsimulation hinzufügen. Liefere Build oder Code samt Startanleitung und kurzer manueller Prüfliste. Jeder Fall bleibt unbestätigt, bis jemand ihn tatsächlich ausführt. Kann die Laufzeit keinen spielbaren Build liefern, benenne diese Einschränkung statt Erfolg zu behaupten.Die Anfrage verlangt Interaktionen und Rückmeldungen, an denen sich die Regeln prüfen lassen; sie garantiert nicht, dass ein Tool sie umsetzt. Wird später ein echter Build geliefert, testen Sie Kanten, Scan-Voraussetzung, Einsammeln, beide Zähler, Reihenfolge der Niederlage und Reset. Nicht beobachtetes Verhalten bleibt unbestätigt.
Prompt 3: Beobachtungen vergleichen und eine Reparatur anfordern
Prüfe den tatsächlichen Blueglass-Reach-Build und die unten bereitgestellten Laufnotizen. Leite keinen Erfolg aus dem Designbrief ab. Liste je Fall erwarteten Zustand, beobachteten Zustand, Belege und bestanden/fehlgeschlagen/unbestätigt. Vergleiche zuerst: (A) sichere Route mit sechs Aktionen ab O8/S5 endet bei D0 mit Kapsel und O2/S1; (B) nach Einsammeln führt Warten und Aufstieg bei D1 zu Dichtung 0 und Niederlage; (C) dieselbe sichere Route ab O6 erreicht mit der letzten Aktion Sauerstoff 0 und verliert vor der Siegprüfung; (D) Einsammeln vor Scan wird ohne Zustandsänderung zurückgewiesen; (E) Reset stellt D0/O8/S5/kein Scan/keine Kapsel wieder her. Fehlt eine Beobachtung, markiere sie als unbestätigt. Schlage bei einem Fehler die kleinste Code- oder Regeländerung vor und nenne anschließend nur die betroffenen Fälle für einen erneuten Lauf. Keine Funktionen ergänzen und keinen Test als bestanden melden, wenn die Laufnotizen das nicht sichtbar belegen.
Tatsächliche Laufnotizen/Screenshots/Zustandsprotokoll: [nur nach echtem Lauf einsetzen; sonst leer lassen und „nicht ausgeführt“ melden].Der dritte Prompt verlangt Belege. Ohne tatsächliche Laufnotizen besteht die korrekte Ausgabe aus unbestätigten Prüfpunkten und keiner Erfolgsbehauptung. So bleibt die Handrechnung ein nützliches Ziel, ohne als Prototyp-Ergebnis ausgegeben zu werden.
| Prompt-Aufgabe | Erwartete Ausgabe | Abnahmekriterium |
|---|---|---|
| 1. Regeln | Zustandsschema, Voraussetzungen, Übergangsreihenfolge, Endregeln und kompakte Fälle | Jede Aktion und jeder Kostenpunkt entspricht dem Vertrag; kein zusätzliches System erscheint |
| 2. Spielbarer Abschnitt | Kleine Route mit Bewegung, Scan, Einsammeln, Rückmeldung, Zählern und Reset | Spielende erkennen, welche Eingabe welchen Zustand geändert hat; fehlende Funktionen werden ehrlich benannt |
| 3. Validierung/Reparatur | Soll-Ist-Vergleich und eine gezielte Korrektur, falls eine echte Abweichung besteht | Fehlende Beobachtungen bleiben unbestätigt; nur betroffene Fälle werden erneut ausgeführt |
Rückweg und Niederlagen auf Papier prüfen
Verfolgen Sie die Route Zug für Zug, bevor Sie Code anfordern. Start: D0, Sauerstoff 8, Dichtung 5. Der sichere Weg umfasst sechs Aktionen: zum Felsvorsprung, hinab, scannen, einsammeln, aufsteigen und zurückkehren. Nur Aktionen, die D2 berühren, kosten Dichtung; jede gültige Aktion kostet einen Sauerstoffpunkt.
| Schritt | Position | Sauerstoff | Dichtung | Scan/Kapsel |
|---|---|---|---|---|
| Start | D0 | 8 | 5 | Nein / nein |
| Zum Felsvorsprung | D1 | 7 | 5 | Nein / nein |
| Zum Graben absteigen | D2 | 6 | 4 | Nein / nein |
| Scannen | D2 | 5 | 3 | Ja / nein |
| Einsammeln | D2 | 4 | 2 | Ja / ja |
| Zum Felsvorsprung aufsteigen | D1 | 3 | 1 | Ja / ja |
| Zum Moon Pool zurückkehren | D0 | 2 | 1 | Ja / ja – Erfolg |
Die Route gelingt, weil beide Zähler bei der Rückkehr mit Kapsel größer als null sind. Scan und Einsammeln sind zwei getrennte Aktionen. Ab- und Aufstieg zählen jeweils einmal als Tiefenbelastung; die Kante D1–D2 kostet nicht zwei Dichtungspunkte.
Zwei nahe Alternativen prüfen die Reihenfolge der Endbedingungen. Wartet der Taucher nach dem Einsammeln bei D2, sinkt Sauerstoff von 4 auf 3 und Dichtung von 2 auf 1. Beim nächsten Aufstieg sinken sie auf Sauerstoff 2 und Dichtung 0; die Runde endet als Niederlage, bevor eine Rückkehr zählen kann. Startet dieselbe Route mit Sauerstoff 6, erreicht der Taucher D0 mit Sauerstoff 0 und Dichtung 1; da zuerst Niederlage geprüft wird, verliert er. Mit Startwert 7 bleiben bei D0 Sauerstoff 1 und Dichtung 1; nach den Regeln gewinnt diese Route.
Dieses Ergebnisbild ist eine Konzeptdarstellung des Endzustands. Das grüne Docklicht signalisiert die fiktive Ankunft, nicht einen erzeugten Prototyp oder eine funktionierende Druckmechanik.
Nur anhand beobachteten Verhaltens überarbeiten
Weicht ein realer Build vom Vertrag ab, notieren Sie den ersten abweichenden Zustand. Halten Sie Eingabe, Startknoten, Sauerstoff, Dichtung, Scan-Flag, Kapsel-Flag, erwarteten und tatsächlichen Folgezustand sowie den beobachteten Beleg fest. Ein späterer Fehler kann auf frühere falsch geänderte Kosten oder Flags zurückgehen; schreiben Sie daher nicht sofort den ganzen Prompt um.
- Erste Abweichung finden. Vergleichen Sie das tatsächliche Ergebnis mit der passenden Zeile der Papierprüfung und nicht mit einem vagen Eindruck, dass der Tauchgang falsch wirkte.
- Kleinste betroffene Regel benennen. Dazu zählen Nachbarschaft, Scan-Voraussetzung, einmalige Aktionen, die einmaligen D2-Dichtungskosten oder die Reihenfolge Niederlage vor Sieg.
- Eine gezielte Reparatur anfordern. Lassen Sie unabhängige Steuerung, Szenenlayout und Kosten unverändert, damit die nächste Beobachtung die gewünschte Änderung isoliert.
- Nur betroffene Prüfungen erneut ausführen. Eine Änderung der Einsammel-Voraussetzung erfordert den Fall „zu frühes Einsammeln“; eine Änderung der Endreihenfolge den Rückkehrfall mit Sauerstoff null.
- Status ehrlich angeben. Eine Designtabelle beschreibt erwartetes Verhalten. Ein Prompt ist eine noch nicht ausgeführte Anweisung. Nur aufgezeichnetes Verhalten eines echten Builds kann eine Erfolgsbehauptung stützen.
Ohne tatsächlichen Build und Laufnotizen endet die Arbeit beim Papiervertrag. Erfinden Sie weder einen erwarteten Screenshot noch beschreiben Sie eine vorgeschlagene Reparatur als getestet. Wenn Sie später ein echtes Tool mit den drei Prompts verwenden, prüfen Sie die Ausgabe selbst, kontrollieren Sie aktuelles Modell und angezeigte Kosten und berichten Sie nur, was tatsächlich sichtbar ist.
Einen ersten Unterwasser-Survival-Prototyp starten
Beginnen Sie mit einem Tauchgang, von dem eine Rückkehr möglich ist. Eine kurze Knotenroute, ein Ziel und eine klare Reihenfolge der Niederlage ergeben ein kleines Bau- und Prüfziel. Die Handrechnung ist eine Grundlage für eigene Tests, kein Beweis für einen Build. Mit einem knappen Brief können Sie den Free AI Game Maker verwenden, um eine erste spielbare Richtung zu erkunden, und danach prüfen, was tatsächlich funktioniert und was noch einen Durchlauf braucht. Prüfen Sie vor einer Generierungsanfrage im Workspace das ausgewählte Modell, das verfügbare Koin-Guthaben und die angezeigten Kosten.
Häufige Fragen
Was ist die kleinste Unterwasser-Survival-Schleife für einen Prototyp?
Nehmen Sie einen Taucher, eine Route mit Oberflächenpunkt und tieferem Ziel sowie eine Rückkehrbedingung. Geben Sie eine kleine Zahl verständlicher Aktionen und Zustandswerte vor und verfolgen Sie jede Änderung. An einem kompakten Abschnitt erkennen Sie, ob Ziel, Weg und Niederlage verständlich sind, bevor Kreaturen, Herstellung oder eine größere Welt hinzukommen.
Modelliert der Dichtungszähler realen Tauchdruck?
Nein. Der Verlust eines Dichtungspunkts nahe D2 ist eine erfundene Spielregel, mit der sich der Rückweg leicht berechnen lässt. NOAA stützt nur die allgemeine physikalische Tatsache, dass der Druck mit der Tiefe um ungefähr eine Atmosphäre je 33 Fuß Abstieg zunimmt. Der Zähler modelliert weder Physiologie noch Ausrüstung, sichere Grenzen oder Tauchpraxis.
Warum sollten ungültige Aktionen alle Werte unverändert lassen?
Wird ein ungültiger Zug oder ein Einsammeln vor dem Scan ohne Ressourcenverbrauch zurückgewiesen, erkennen Spielende klar, welche Regel sie verfehlt haben. Zugleich entsteht ein deterministischer Test: Ändern sich Position, Sauerstoff, Dichtung oder Flags trotz Zurückweisung, weicht die Umsetzung vom Vertrag ab. Eine andere Zurückweisungsregel ist möglich, muss aber Kosten benennen und ausdrücklich getestet werden.
Wann sollte ich eine Prompt-Reparatur anfordern?
Fordern Sie sie an, nachdem eine echte Beobachtung die erste Abweichung zwischen Soll- und Ist-Zustand zeigt. Nennen Sie Aktion, Startwerte, erwartetes und beobachtetes Ergebnis sowie genau eine Regel zur Änderung. Nicht beobachtete Fälle bleiben unbestätigt; führen Sie danach die von der Änderung betroffenen Prüfungen erneut aus.
Wurden die Blueglass-Reach-Prompts ausgeführt oder getestet?
Nein. Es sind wiederverwendbare Prompt-Vorlagen für ein erfundenes Szenario; die Routenberechnung wurde anhand der Artikelregeln von Hand durchgeführt. Es wird weder eine Modellausführung noch ein spielbarer Build oder Testlauf behauptet. Nutzen Sie die Folge als Abnahmeziel für einen künftigen Build und berichten Sie anschließend nur tatsächlich beobachtete Zustände.
