Beat und Trefferfenster vor weiteren Songs festlegen

Ein Prompt für ein Rhythmusspiel braucht vor weiteren Songs vier Dinge: Uhr, Zielbeats, erlaubte Abweichung eines Tippens und ein eindeutiges Ergebnis für Treffer und Fehlschläge. Formulieren Sie diese Regeln in einfacher Sprache, rechnen Sie einige Eingaben von Hand nach und fordern Sie eine kleine spielbare Schleife an. Das ergibt ein prüfbares Briefing, beweist aber nicht, dass generiertes Audio oder Timing funktioniert.

Lantern Pulse ist eine fiktive Einspur-Chart, die den Timingvertrag konkret macht. Die Zahlen sind ein verfasstes Papierbeispiel und weder Ausgabe eines ausgeführten Prompts noch spielbarer Build oder gemessener Synchronisationstest.

Die Beat-Chart vor weiteren Inhalten festlegen

Benennen Sie zunächst die Chart-Uhr. In diesem Beispiel beginnt sie bei t = 0 beim Drücken von „Play“. Es gibt weder Einzähler noch Vorlauf. Bei 120 Schlägen pro Minute dauert ein Beat 60 / 120 = 0.5 Sekunden. Die Zielbeats 2, 4 und 6 liegen eine, zwei und drei Sekunden nach Beginn der Uhr.

Das ist ein Zeitplan und keine Audiodatei. Ein Spiel kann die Ziele relativ zur Beat-Uhr anzeigen, aber ein echtes Lied wirft Fragen auf, die dieses Modell bewusst offenlässt: Wo beginnt die Wiedergabe? Entsteht Geräteverzögerung? Wie wird die Chart kalibriert? Bleiben Musik und visuelle Ziele auf verschiedener Hardware synchron? Halten Sie das getrennt von der ersten Regelübung.

Auch der Startzustand sollte genauso klar sein wie das Tempo: eine Spur, drei ungelöste Ziele, Combo null und Zielindex null. Noch wurde nichts getroffen. Ein Neustart stellt diesen Zustand wieder her. Der Lauf endet, sobald das Zeitfenster des letzten Ziels abgelaufen ist; dann werden Treffer, Fehlschläge und finale Combo festgehalten.

Eine spielbare Schleife mit klarer Eingaberegel prompten

Ein Prompt sollte beschreiben, was Spielende tun können und was das Spiel entscheiden muss. „Im Takt zur Musik tippen“ lässt Uhr, zulässige Abweichung, Verspätung und Feedback offen. Ein stärkerer Prompt gibt für jeden Punkt eine prüfbare Regel an. Bei Lantern Pulse zählt ein Tipp als Treffer, wenn sein Zeitstempel höchstens 80 Millisekunden vor oder nach dem aktiven Ziel liegt, einschließlich beider Grenzen. Jedes Ziel wird genau einmal aufgelöst. Läuft die späte Frist ohne Treffer ab, wird ein Fehlschlag gezählt, die Combo auf null gesetzt und weitergeschaltet. Ein Tipp außerhalb jedes offenen Fensters wird ignoriert.

Hier ist eine anpassbare Vorlage. Sie fordert einen begrenzten Prototyp und eine Möglichkeit, Regelverhalten zu prüfen. Sie wurde nicht ausgeführt; es wird weder Ausgabe noch Build behauptet.

Erstelle einen kleinen Einspur-Rhythmusspiel-Prototyp auf Grundlage dieses Briefs.

Uhr: Chartzeit beginnt bei 0, sobald Play gedrückt wird. Feste Beat-Uhr mit 120 BPM verwenden; keinen Einzähler oder Vorlauf ergänzen.
Ziele: Noten auf Beat 2, 4 und 6 (1,00, 2,00 und 3,00 Sekunden nach Play).
Eingabe: Ein Tipp trifft nur das aktuelle ungelöste Ziel, wenn die absolute Timingabweichung höchstens 80 ms beträgt, einschließlich Grenzwerte. Jedes Ziel genau einmal auflösen. Tipps außerhalb aller offenen Zielfenster ignorieren.
Verspätung: Läuft das aktuelle Ziel über Zielzeit + 80 ms hinaus, einen Fehlschlag zählen, Combo löschen und weiterschalten. Einen späteren Tipp nicht nachträglich als Treffer werten.
Feedback: Jeder Treffer erhöht die Combo und beleuchtet ein Laternenfeld. Ein Fehlschlag setzt Combo auf 0 und löscht die Felder. Aktives Ziel und Timinglinie anzeigen, ohne ausschließlich auf Textfeedback zu setzen.
Ende und Neustart: Nach Ablauf der späten Frist von Ziel 3 beenden; Trefferzahl, Fehlzahl und finale Combo zeigen. Neustart stellt ruhige Chart, Combo 0 und Ziel 1 wieder her.

Diesen ersten Entwurf auf eine Spur und drei Tipps begrenzen. Eine sichtbare Möglichkeit zur Prüfung von Zielzeit, Eingabeabweichung, Treffer-/Fehlschlagergebnis und resultierender Combo bereitstellen. Keine Audiosynchronisierung behaupten, solange sie nicht separat kalibriert und getestet wurde.

Der Prompt trennt Chartregeln von Implementierungsannahmen. Er verlangt weder Notenbewertungen noch Gesundheit, Haltenoten, mehrere Spuren, Punktmultiplikator oder Hintergrundgefahren. Jedes davon würde einen weiteren Zustand oder eine Timingfrage hinzufügen, bevor die Grundschleife verstanden ist. Ergänzen Sie eine Funktion erst, wenn sie einer konkreten Entscheidung dient.

Die Mechanikabbildung zeigt das zweite Ziel auf Beat 4 als Treffer. Das erste Ziel hat bereits ein Feld beigetragen, dieser Treffer fügt das zweite hinzu. Ein visueller Impuls markiert den Kontakt; die Zweierleiste vermittelt die Combo, ohne zu behaupten, die fiktive Chart sei umgesetzt.

Dieselben Tipps anhand der Basisregel von Hand prüfen

Bevor Sie ein Spielwerkzeug um eine Schleife bitten, vergleichen Sie die Regeln mit einer kurzen Spur. Abweichung ist Tippzeit minus Zielzeit. Ein positiver Wert ist verspätet, ein negativer früh. Bei inklusivem ±80-ms-Fenster gelten Abweichungen von −80 bis +80 ms als Treffer.

Die ersten zwei Tipps liegen in ihren Fenstern, die Combo steigt von null auf eins und dann zwei. Der dritte ist 90 ms verspätet. Die Basisfrist lautet 3,00 + 0,08 = 3,08 Sekunden; bei 3,09 s ist das Ziel bereits verfehlt und der späte Tipp kann den Fehlschlag nicht rückgängig machen. Die Spur endet mit zwei Treffern, einem Fehlschlag und Combo null.

Die Frist muss notiert werden. Sonst behandeln zwei Implementierungen einen Tipp nach Zielschluss womöglich unterschiedlich: Eine zählt verspäteten Treffer, eine ignoriert ihn still und eine dritte lässt das Ziel unbegrenzt aktiv. Der Prompt muss Auflösungsereignis und Weiterschaltzeit festlegen.

Eine Timingregel ändern und Spur erneut prüfen

Für ein toleranteres Fenster ändern Sie nur die Abweichung von ±80 auf ±100 ms. Beat-Uhr, Zielzeiten, Tippzeitpunkte, Fehlschlagfeedback und Neustart bleiben gleich. Der dritte Tipp bleibt bei 3,09 Sekunden, also +90 ms gegenüber dem Ziel bei 3,00. Im neuen Fenster zählt er als Treffer. Die fiktive Spur ergibt drei Treffer und finale Combo drei.

Dies ist ein kontrollierter Papiervergleich, weil sich nur eine verfasste Variable geändert hat. Er belegt weder, dass ±100 ms besser wirken, noch dass ein reales Gerät die Abweichung registriert oder ein generierter Build mit Musik synchronisiert. Das sind getrennte Design- und Testfragen. Hängt das Spielerlebnis von einem Soundtrack ab, messen und kalibrieren Sie den Audioweg, statt die Beispielabweichung als universelle Einstellung zu behandeln.

Das Ergebnisbild zeigt die überarbeitete Handrechnung: Alle drei Ziele sind aufgelöst und alle drei Combo-Felder leuchten. Es ist eine Konzeptillustration des Sollzustands und weder Screenshot noch Beweis für getestetes Gameplay.

Grenzfälle in Abnahmekriterien verwandeln

Eine kurze Prüfliste erleichtert die Sichtung des Prompts. Notieren Sie je Fall Eingabe, erwarteten Zielzustand und sichtbares Feedback. Prüfen Sie Grenzen ausdrücklich, damit „im Fenster“ im Brief und in einer späteren Umsetzung dieselbe Bedeutung hat.

Diese Fälle ersetzen keinen Spieltest. Sie machen einen Prototyp prüfbarer, indem das erwartete Verhalten vor dem Ergebnis feststeht. Weicht ein Build ab, bestimmen Sie zunächst, ob der Prompt unklar war, die Umsetzung eine klare Regel verfehlte oder die Timingquelle kalibriert werden muss. Überarbeiten Sie die engste Ursache und wiederholen Sie denselben Fall, statt Chart, Grafik und Toleranz zugleich zu ändern.

Das Briefing in einen allgemeinen Erstellungsablauf übernehmen

Die aktuelle offizielle Free-AI-Game-Maker-Seite beschreibt Eingabe in einfachem Englisch, eine erste spielbare 2D- oder 3D-Version, Browsertests und Verfeinerung mit Folgeprompts. Sie wirbt mit kostenlosen Koins und empfiehlt, Kosten vor jeder Generierung zu prüfen; die Kosten-FAQ verweist auf gewähltes Modell, Koin-Guthaben und angezeigte Kosten im Workspace. Das sind allgemeine Ablaufinformationen, kein Beleg für Rhythmusspiel-Audio oder korrektes Timing.

Für den ersten Durchlauf gehören Uhrenstart, Tempo, Zielliste, Toleranz, Verspätungsregel, Feedback, Endzustand und Neustart in ein kompaktes Briefing. Prüfen Sie anschließend das tatsächliche Verhalten: Beginnt die Uhr zum angegebenen Zeitpunkt? Wird jedes Ziel einmal aufgelöst? Stimmen Treffer- und Fehlschlagfeedback mit den Regeln überein? Bei Audio sind Musik und visuelles Timing separat auf dem Zielgerät zu testen. Prüfen Sie Kosten vor jeder Generierung; das ersetzt keine getrennte Timing- und Audioprüfung.

Mit einer Chart beginnen und gezielt erweitern

Ein hilfreicher Prompt fürs Rhythmusspiel ist ein kleiner Interaktionsvertrag: Uhr definieren, Zielbeats auflisten, inklusives Trefferfenster festlegen, verspätete Frist bestimmen und Feedback zeigen. Lantern Pulse zeigt Handprüfung und Vergleich einer Toleranzänderung, ohne empirische Ergebnisse zu behaupten. Sobald die Grundschleife verständlich ist, fügen Sie jeweils eine Spur, einen Song oder Notentyp hinzu.

Wenn Sie einen Regelentwurf in einen allgemeinen Ausgangspunkt für ein spielbares Spiel überführen möchten, erkunden Sie den Free AI Game Maker.