Zuerst ein vollständiges kleines Abenteuer planen
Ein Prompt für gemütliche Erkundung braucht mehr als eine sanfte Farbpalette und einen ruhigen Schauplatz. Geben Sie der spielenden Person eine wiederholbare Aktion, eine Route mit erkennbarem Ziel, eine verzeihende Möglichkeit zur Erholung und ein klares Ende. So lässt sich die erste Anfrage leichter prüfen als eine lange Liste aus Landschaftsbildern und Stimmungsbegriffen.
Mossglass Crossing ist ein eigenständiges Papierbeispiel in diesem Leitfaden: eine paddelnde Person, eine ruhige Bucht, drei geordnete Bojentore und ein Anleger in einer letzten kleinen Bucht. Route, Steuerung, Beispielprompts und erwartete Zustände sind fiktives Designmaterial. Es wurde kein Prompt ausgeführt und kein Build oder Spieltest bereitgestellt. Das Beispiel zeigt, wie man eine Idee spezifiziert und prüft – kein verifiziertes Spielergebnis.
Halten Sie den ersten Ausflug klein genug, um ihn in wenigen Sätzen zu beschreiben. Verändert eine angeforderte Funktion weder nächste Entscheidung noch Routenstatus, Erholung oder Ende, lassen Sie sie im ersten Durchgang weg.
Die ruhige Stimmung in spielbare Grenzen übersetzen
„Gemütlich“ kann für verschiedene Erstellende Unterschiedliches bedeuten. Übersetzen Sie den Begriff in überprüfbares Verhalten: kein Timer, kein Schaden, kein Treibstoff und kein verlorener Fortschritt; breite, leicht erkennbare Tore; und eine Erholungsaktion, die das Kajak in sicheres Wasser bringt, ohne bereits passierte Tore rückgängig zu machen. Die Route hat weiterhin Reihenfolge und Ziel, bestraft aber keine langsame Wendung.
In Mossglass Crossing ist der Anleger von der Startstelle aus sichtbar und der Kanal hat keine Abzweigungen. Jedes Torpaar liegt quer über der Route. Ein sanftes Kielwasser und eine leicht schaukelnde Boje bestätigen eine gültige Passage. Die Rückmeldung gehört zur jeweiligen Aktion; für dieses Beispiel braucht es deshalb weder Timer noch Punktzahl, Sammelobjekt, Tagebuch oder komplizierte HUD-Anzeige.
Das sind Entscheidungen für dieses vorgeschlagene Design und keine allgemeingültigen Regeln für gemütliche Spiele. Hängt eine andere Idee von optionalen Entdeckungen, Begegnungen oder ziellosem Erkunden ab, ergänzen Sie diese erst, nachdem feststeht, wie sie die Route verändern und woran ein zufriedenstellender Haltepunkt zu erkennen ist.
Den Regelvertrag vor dem Szenenprompt schreiben
Legen Sie vor einer Anfrage zu Felsen und Schilf fest, wie die Person sich bewegt, was als Fortschritt gilt, was eine Erholung verändert und wann der Ausflug endet. Benennen Sie Durchfahrtsrichtung und nächstes Tor, damit ein späteres Tor nicht vorzeitig zählt und eine Rückwärtsfahrt den Fortschritt nicht stillschweigend verändert.
| Regel | Mossglass-Vorschlag | Erwartete Rückmeldung |
|---|---|---|
| Startzustand | Am Anleger beginnen mitrouteProgress = 0, Prüfungpoint am Anleger und Abschluss=false. | Das erste Tor ist das nächste Ziel; der Anleger in der Bucht ist weiter hinten am selben Kanal sichtbar. |
| Steuerung | Vorwärts halten zum Paddeln; Links und Rechts steuern; Rückwärts paddelt langsam; „Erholen“ versetzt das Kajak; „Interagieren“ ist für den letzten Anleger. | Jede Taste hat eine einzelne definierte Wirkung; Steuern allein bringt keinen Fortschritt. |
| Geordnete Durchfahrt | Von der Anfahrtsseite durch die Lücke des nächsten Bojenpaars fahren. Gültige Vorwärtsdurchfahrten zählen Tor 1, dann 2, dann 3. | Fortschritt steigt pro neu erreichtem Tor genau einmal. Falsche Richtung, übersprungenes oder bereits passiertes Tor verändert ihn nicht. |
| Rückmeldung | Bei gültiger Durchfahrt schaukeln die Bojen leicht und das Kielwasser zieht durch die Lücke. | Die Handlung erhält eine kleine passende Rückmeldung; für das Design ist keine numerische HUD-Anzeige nötig. |
| Erholung | Berührt das Kajak eine flache Uferbank, hält es an. „Erholen“ setzt es in sicheres Wasser neben dem zuletzt passierten Tor oder bei Fortschritt 0 an den Anleger zurück. | Position ändert sich;routeProgressund Abschluss ändern sich nicht. |
| Ende und Neustart | „Interagieren“ beendet den Ausflug nur am Anleger der Bucht und bei Fortschritt 3. Neustart aus jedem Zustand bringt zur Startstelle zurück, setzt Fortschritt auf null, löscht Abschluss und stellt den Start-Checkpoint wieder her. | Ein früher Anfahrtsversuch am Anleger überspringt keine Tore. Neustart stellt denselben bekannten Anfangszustand her. |
Der Zustandsübergang lässt sich so zusammenfassen: Nur das Tor, das als Nächstes in Vorwärtsrichtung durchfahren wird, verändertrouteProgress; „Erholen“ ändert nur den Standort; der Anleger beendet den Ausflug erst bei 3/3. Behalten Sie diesen Satz beim Schreiben der Szene neben dem Prompt.
Dieses Bild ist eine Konzeptdarstellung des entworfenen Zustands 2/3 und kein Spiel-Screenshot. Es veranschaulicht, wie physische Orientierungspunkte die Reihenfolge vermitteln können, ohne gleich zu Beginn einen Zähler hinzuzufügen.
Eine Folge aus drei Prompts verwenden
Trennen Sie Regelklärung, erste Build-Anfrage und spätere Korrektur. Jeder Prompt sollte Eingabe, Grenzen, erwartete Ausgabe und deren Prüfmethode nennen. Die ersten beiden Vorlagen können vor einem Build angepasst werden; die dritte ist erst nach einer tatsächlichen Beobachtung zu verwenden.
Prompt A: unklare Regeln offenlegen
Ich plane ein kleines gemütliches Erkundungsspiel für Einzelpersonen namens Mossglass Crossing.
Dies ist ein fiktives Designbriefing und kein Bericht über ein vorhandenes Spiel.
Die spielende Person startet neben einem Anleger im Kajak. Ziel ist, drei Bojenpaare der Reihe nach
und jeweils von der Anfahrtsseite durch die Lücke zu passieren und danach an einem sichtbaren Anleger
in einer Bucht zu „Interagieren“. Vorwärts paddelt, Links/Rechts steuert, Rückwärts paddelt langsam,
„Erholen“ setzt das Kajak in sicheres Wasser neben das zuletzt passierte Tor (oder bei 0/3 an den Anleger),
und „Interagieren“ ist dem letzten Anleger vorbehalten. Eine gültige Vorwärtsdurchfahrt des nächsten
Tors erhöht routeProgress um eins. Falsche Richtung, übersprungene oder doppelte Durchfahrten ändern
den Fortschritt nicht. Erholung ändert die Position, nicht den Fortschritt. Der Anleger beendet den Ausflug
nur bei 3/3. Neustart stellt den Startzustand wieder her und löscht Fortschritt und Abschluss.
Entwirf noch keine Landschaft und baue noch nichts. Gib zurück: (1) Zustands- und Übergangstabelle,
(2) unklare oder widersprüchliche Regeln, (3) erwartete Ergebnisse für eine Rückwärtsdurchfahrt von Tor 1,
einen frühen Versuch an Tor 3 bei 0/3, Erholung nach Tor 2 und frühe Interaktion am Anleger. Ändere keine
Regeln stillschweigend. Kennzeichne vorgeschlagene Entscheidungen als Designentscheidungen und nicht
als beobachtetes Verhalten.Lesen Sie zuerst die Liste der Unklarheiten. Entscheiden Sie offene Punkte selbst, bevor Sie einen Build anfordern; andernfalls kann ein späteres Ergebnis einer Annahme folgen, die nie beabsichtigt war.
Prompt B: die minimale Route anfordern
Erstelle anhand dieser Designspezifikation einen kleinen Echtzeit-3D-Prototyp zur Kajak-Erkundung
in Third-Person-Ansicht für eine Person. Schauplatz ist eine ruhige Kalksteinbucht mit Anleger, einem
durchgehenden Kanal, drei breiten Bojenpaaren und einem letzten Anleger in einer Bucht. Halte den ersten
Durchgang kompakt und gut lesbar. Verwende eine erwachsene paddelnde Person in einem rötlichen Holzkajak.
Beim Zurücksetzen steht das Kajak am Anleger: routeProgress = 0, completion = false, Anleger als Erholungspunkt.
Vorwärts halten zum Paddeln; Links/Rechts steuern; Rückwärts paddelt langsam; „Erholen“ bringt das Kajak
in sicheres Wasser neben das zuletzt passierte Tor oder zum Start; „Interagieren“ ist für den letzten Anleger.
Nur die Vorwärtsdurchfahrt durch die Lücke des nächsten Tors erhöht routeProgress genau einmal. Rückwärts-,
frühe spätere und doppelte Durchfahrten bewirken nichts. Erholung verändert nur die Position. „Interagieren“
schließt den Ausflug nur am Anleger der Bucht ab, wenn routeProgress = 3. Neustart stellt den vollständigen
Startzustand wieder her.
Zeige bei einer gültigen Durchfahrt einfache wortlose Rückmeldung, etwa ein leichtes Schaukeln der Bojen
und das durch die Lücke ziehende Kielwasser. Halte den Kanal durchgehend und mit sicheren Abständen.
Lasse Timer, Schaden, Treibstoff, Sammelobjekte, Abzweigungen, NSCs, Wetter, Tagebuch, Ressourcen,
Punktzahl und zusätzliche Aufgaben weg. Ergänze keine Mechanik, die Fortschritt oder Abschluss verändert.
Gib mit dem Prototyp eine kurze Zusammenfassung von Steuerung und Zustandsregeln. Falls eine Regel nicht
darstellbar ist oder geändert werden muss, liste die Abweichung ausdrücklich auf. Behaupte keine Umsetzung
oder Prüfung, bevor der Prototyp tatsächlich gebaut und überprüft wurde.Dies ist eine Anfrage für einen festgelegten Prototyp und kein Beleg dafür, dass der Workspace Steuerung oder Torlogik umsetzt. Vergleichen Sie tatsächliche Ausgabe mit dem Vertrag, bevor Landschaft oder Route erweitert werden.
Prompt C: eine beobachtete Abweichung korrigieren
Nur nach einem echten Build und einer Wiederholung derselben Prüfung verwenden. Keine Beobachtung erfinden.
Wiederholbare Aktion: [genaue Eingabe und Startzustand]
Erwarteter Zustand laut schriftlichem Vertrag: [Fortschritt, Position, Abschluss]
Im Build beobachteter Zustand: [tatsächliches Ergebnis]
Ändere nur die kleinste Regel oder Steuerung, die für diese Abweichung verantwortlich ist. Bewahre alle
anderen aufgeführten Regeln. Erkläre vor der Änderung, welcher Zustandsübergang fehlerhaft ist. Sage danach
genau, wie ich dieselbe Prüfung wiederhole. Kannst du das Ergebnis nicht durch Prüfen oder Ausführen des
Builds bestätigen, nenne, was ungeprüft bleibt, statt Erfolg zu melden.Prompt C ist ein wiederverwendbares Korrekturformat und keine Behauptung, dass dieses Beispiel eine beobachtete Abweichung erzeugt hat. Nur eine echte Aktion und ein reales Ergebnis können die Beobachtungsfelder füllen.
Eine Route von Hand durchspielen und dann prüfen
Verwenden Sie einen kurzen Ablauf, um zu prüfen, ob die schriftlichen Regeln in sich schlüssig sind. Dies ist eine manuelle Rechnung über die vorgeschlagenen Regeln und kein Spielablauf oder Spieltest.
| Schritt | Aktion der spielenden Person | Erwarteter Zustand |
|---|---|---|
| Start | Neben dem Anleger beginnen. | Fortschritt 0/3; Anleger ist Checkpoint; Abschluss=false. |
| 1 | Vorwärts durch Tor 1 paddeln. | Fortschritt wird 1/3; Tor 1 ist der aktuelle Checkpoint. |
| 2 | Durch Tor 2 steuern. | Fortschritt wird 2/3; Tor 2 ist der aktuelle Checkpoint. |
| 3 | In die flache Uferbank treiben und „Erholen“ drücken. | Kajak kehrt neben Tor 2 zurück; Fortschritt bleibt 2/3; Abschluss bleibt false. |
| 4 | Vorwärts durch Tor 3 paddeln. | Fortschritt wird 3/3; Abschluss bleibt bis zur Interaktion am Anleger false. |
| 5 | Den Anleger der Bucht erreichen und „Interagieren“ drücken. | Abschluss wird true, mit ruhiger Anlege-Rückmeldung. |
Die erwartete Folge lautet 0/3 → 1/3 → 2/3 → Erholung bei 2/3 → 3/3 → Anleger abgeschlossen. Erholung verändert den Ort, aber nicht den Routenfortschritt; Anlegen ändert den Abschlussstatus erst nach allen drei Vorwärtsdurchfahrten. Das Bild ist ein Konzept für dieses Ende und kein Beleg für ein fertiges Spiel.
| Check | Aktion aus bekanntem Zustand | Erwartetes Ergebnis |
|---|---|---|
| Falsche Richtung | Bei 0/3 Tor 1 von der hinteren Seite passieren. | Fortschritt bleibt 0/3. |
| Tor überspringen | Bei 0/3 vorwärts durch Tor 2 fahren. | Fortschritt bleibt 0/3; Tor 1 ist weiterhin das nächste Ziel. |
| Tor doppelt passieren | Bei 1/3 Tor 1 erneut oder im Kreis durchfahren. | Fortschritt bleibt 1/3; Tor 2 bleibt als Nächstes an der Reihe. |
| Erholung bei null | Bei 0/3 eine Uferbank berühren und „Erholen“ drücken. | Zum Anleger zurückkehren; Fortschritt bleibt 0/3. |
| Erholung bei zwei | Bei 2/3 eine Uferbank berühren und „Erholen“ drücken. | Neben Tor 2 zurückkehren; Fortschritt bleibt 2/3. |
| Früher Anleger | Bei 2/3 den Anleger der Bucht erreichen und „Interagieren“ drücken. | Ausflug wird nicht abgeschlossen; Fortschritt bleibt 2/3. |
| Neustart | Nach Abschluss neu starten. | Zum Anleger mit 0/3, Abschluss false und wiederhergestelltem Start-Checkpoint zurückkehren. |
Dies sind Abnahmetests für den eigenen Build. Bis dahin bleiben sie erwartete Ergebnisse aus den schriftlichen Regeln und keine Beobachtungen. Ein tatsächliches Protokoll sollte Regelversion, Eingaben, erwarteten und beobachteten Zustand enthalten.
Eine Überarbeitung auf Belegen gründen
Weicht ein echtes Ergebnis vom erwarteten Zustand ab, notieren Sie vor jeder Promptänderung Startzustand, genaue Eingabe, erwartetes und beobachtetes Ergebnis. Ändern Sie anschließend nur die betroffene Regel oder Steuerung und wiederholen Sie dieselbe Aktion. Bleibt Fortschritt nach einer gültigen Durchfahrt von Tor 2 etwa bei 1/3, prüfen Sie zunächst Beschreibung der Durchfahrtsrichtung und der Bedingung für das nächste Tor, bevor Sie eine neue Karte oder ein Belohnungssystem ergänzen.
Halten Sie erwartete und beobachtete Werte in getrennten Notizen fest. Ein Papierdurchlauf zeigt interne Konsistenz, nicht ob eine generierte Steuerung reagiert, ein Tor leicht passierbar ist oder eine Person Rückmeldungen versteht. Gibt es keinen Build, lassen Sie das Feld für Beobachtungen leer und behandeln Sie den nächsten Schritt als Plan.
Das Briefing an einen Erstellungs-Workspace übergeben
Die aktuelle Free-AI-Game-Maker-Seite sagt, dass Erstellende eine Spielidee in Alltagssprache beschreiben, ein spielbares 2D- oder 3D-Ergebnis prüfen, im Workspace weiterarbeiten und vor der Generierung angezeigte Koin-Kosten und Kontooptionen ansehen können. Das sind allgemeine Ablaufangaben der Produktseite. Sie dokumentiert weder Kajakfahren, geordnete Bojentore, Checkpoint-Erholung, die genaue Steuerung hier noch einen erfolgreichen Durchlauf von Mossglass Crossing.
Nutzen Sie Ihren kurzen Vertrag als Eingabe und prüfen Sie, was der Workspace tatsächlich zurückgibt. Ändert das Ergebnis Durchfahrtsregel, Erholungszustand, Steuerung oder Abschlussbedingung, vergleichen Sie die Abweichung mit der Tabelle und entscheiden, ob Prompt oder Design geändert werden soll. Die Kategorienamen sind allgemeine Planungsverweise; sie garantieren nicht, dass genau diese Route wie beschrieben erstellt wird.
Den Vertrag zum nächsten Schritt mitnehmen
Prüfen Sie fünf Punkte, bevor eine zweite Route oder Aktivität hinzukommt: Aktion der spielenden Person, geordnete Orientierungspunkte, Fortschrittsänderung, Verhalten bei Erholung und Abschlussbedingung. Eine kompakte Route mit diesen Teilen ergibt eine klare erste Anfrage und eine konkrete Möglichkeit, ein echtes Ergebnis zu beurteilen.
Wenn Sie Ihre eigene Spielidee gestalten möchten, öffnen Sie denkostenlosen KI-Spiel-Generator. Bringen Sie ein überprüfbares Briefing mit, prüfen Sie Ergebnis und aktuelle Generierungskosten im Workspace und behandeln Sie jede ungeprüfte Mechanik als offene Frage, bis Sie sie kontrolliert haben.
Häufig gestellte Fragen
Ist Mossglass Crossing ein spielbares oder getestetes Spiel?
Nein. Mossglass Crossing ist ein eigens entworfenes Lehrbeispiel auf Papier. Die Route wurde anhand der Regeln in diesem Artikel von Hand durchgespielt; es liegen weder Prompt-Ausführung noch generierter Build, Nutzerablauf oder Spieltest vor. Verwenden Sie es als Spezifikationsübung und überprüfen Sie Ihren eigenen Build, bevor Sie Steuerung oder Routenverhalten als beobachtet beschreiben.
Sollte der Fortschritt sinken, wenn das Kajak ein Tor rückwärts passiert?
In diesem Design nicht. Nur die Vorwärtsdurchfahrt durch das nächste Tor erhöht den Fortschritt; falsche Richtung, übersprungene oder doppelte Durchfahrt lassen den Wert unverändert. Sollen Spielende beim Zurücksetzen Fortschritt verlieren, beschreiben Sie dies als eigene Regel mit Auslöser und Rückmeldung, statt die Durchfahrtsrichtung für sich sprechen zu lassen.
Was sollte „Erholen“ nach Berühren einer Uferbank ändern?
Hier ändert „Erholen“ nur die Position. Bei 0/3 kehrt das Kajak zum Start zurück; nach einem gültigen Tor wird es neben dem zuletzt passierten Tor in sicheres Wasser gesetzt. Fortschritt und Abschluss bleiben gleich. Soll Ihr Spiel bei Erholung Fortschritt zurücksetzen, benennen Sie den Zustand genau und ergänzen Sie dafür eine eigene Prüfung.
Wie kann eine ruhige Route trotzdem ein klares Ziel bieten?
Nutzen Sie Orientierungspunkte und ein Ende ohne Timer. In diesem Beispiel zeigen drei sichtbare Torpaare das jeweils nächste Ziel, während ein entfernter Anleger das Ende des Ausflugs markiert. Eine verzeihende Erholung senkt die Folgen eines Steuerfehlers; lokales Kielwasser bestätigt eine gültige Passage, ohne Punktedruck hinzuzufügen.
Garantiert ein Prompt, dass die Route in einem Spiel-Generator funktioniert?
Nein. Die offizielle Produktseite beschreibt einen allgemeinen Ablauf von der Idee zu einem spielbaren Ergebnis, verifiziert aber weder Kajakregeln noch konkrete Steuerung, Tore oder Erholung. Prüfen Sie das tatsächliche Ergebnis anhand schriftlicher Tests. Gibt es noch keinen Build, beschreiben Sie Prompts und Prüfungen als Plan statt als getestetes Ergebnis.
