Feindwellen lesbar machen, bevor weitere Angriffe dazukommen
Um mit KI einen Side-Scrolling-Brawler zu entwerfen, beginnen Sie mit einem Raum, in dem der Spieler einen Angriffshinweis lesen, der Spur ausweichen und sich erholen kann, bevor der nächste Gegner einen Treffer prüft. Eine kleine Begegnung zeigt, ob Timing und Gegnerrollen verständlich sind. Dieses Beispiel beschreibt einen fiktiven Entwurf, keinen generierten Build oder Spieltest.
Raum und Timing unten sind fiktive Designparameter und weder Prompt-Ergebnis noch Spielbuild, Spielertest oder beobachtete SEELE-Ausgabe. Der Vergleich ist eine handgerechnete Timingrevision, keine gemessene Verbesserung.
Halten Sie den ersten Ablauf eng gefasst: read the tell → dodge the lane → regain the action → punish recovery → clear the pack → open the next room. . Die zentrale Designentscheidung ist, wann der nächste Gegner im Verhältnis zur Ausweich-Abklingzeit eintritt. Dies ist eine Einführung in das Timing einer Gegnergruppe und weder Rückstoßsystem noch Ricochet-Rätsel.
Zwei Gegnerrollen und Aktionsreihenfolge festlegen
Nennen Sie den Raum Foundry Walk. Er reicht horizontal von Position 0 bis 12 und hat eine nahe und eine ferne Spur. Der Spieler beginnt bei x=2 in der nahen Spur; das Ausgangstor steht bei x=11. Der Rusher startet bei x=0, signalisiert 0,75 Sekunden lang seinen Angriff und stürmt dann um drei Einheiten durch die nahe Spur. Der Guard tritt nach einer Verzögerung d bei x=2,5 ein, signalisiert 0,75 Sekunden lang einen Feger und prüft danach ein festes Rechteck von x=1,5 bis 3,5 über beide Spuren. Beide Gegner erholen sich 0,75 Sekunden lang nach ihrem Angriff.
| Akteur oder Zustand | Feste Regel des ersten Raums | Was der Spieler erkennen kann |
|---|---|---|
| Rusher | Startet bei x=0 in der nahen Spur; kündigt 0,75 Sekunden an; stürmt +3 durch die nahe Spur; prüft den Treffer nach der Spieleraktion; erholt sich von t=1,0 bis 1,75. | Ein klares Signal markiert vor der Bewegung die Angriffsbahn in der nahen Spur. |
| Guard | Tritt nach Verzögerung d bei x=2,5 in der nahen Spur ein; kündigt einen 0,75-Sekunden-Feger an; prüft das feste Rechteck x=1,5 bis 3,5 über beide Spuren; erholt sich dann 0,75 Sekunden. | Ein breites Feger-Signal zeigt, dass ein einfacher Spurwechsel das Trefferrechteck nicht verlässt. |
| Spieler | Beginnt bei x=2 in der nahen Spur. Das Ausweichen wechselt zu x=3 in die andere Spur; erneut verfügbar 0,75 Sekunden nach Ende des Ausweichens. | Aktionszustand und Abklingzeit müssen von der Angriffserholung unterscheidbar sein. |
| Gruppe und Tor | Rusher und Guard besiegen, damit sich das Tor hebt. Erreicht der Spieler es, lädt ein zweiter Raum mit denselben Regeln. Reset stellt Gesundheit, Positionen, Verzögerung und Tor wieder her. | Niederlage und geöffnetes Tor erhalten getrennte sichtbare Rückmeldungen. |
Die nahe Spur des Rushers kreuzt die Startposition x=2 des Spielers. Bei t=0,75 wird der Ausweichbefehl vor der Trefferprüfung des Sprints ausgeführt; der Spieler wechselt von (2, nahe) zu (3, fern). Der Sprint des Rushers führt von x=0 bis x=3 in der nahen Spur und verfehlt ihn. Der Angriff ist ausgewichen, aber nicht die spätere breite Fegerzone des Guards.
Ein Wechsel zwischen zwei Spuren ist gegen den Rusher nützlich, aber kein allgemeiner sicherer Zustand: Das festgelegte Rechteck des Guards deckt beide Spuren ab. Diese Unterscheidung verhindert ein häufiges Lesbarkeitsproblem. Ein Angriffshinweis muss die tatsächliche Trefferfläche zeigen.
Eine kleine Begegnung mit sichtbarem Feedback prompten
Ein hilfreicher Prompt benennt Arena, Spielersteuerung, Zustandsänderungen der Gegner, Aktionsreihenfolge, Trefferfeedback und Reset. Er sagt auch, was vorerst nicht ergänzt werden soll. Das folgende Beispiel ist ein Entwurf.
Erstelle einen kompakten 2,5D-Brawler-Raum in Seitenansicht namens Foundry Walk. Nutze eine horizontale Arena von 0 bis 12 mit naher und ferner Spur. Der Spieler startet bei x=2 in der nahen Spur, das geschlossene Ausgangstor steht bei x=11. Der Rusher beginnt bei x=0, zeigt vor einem Sprint von drei Einheiten durch die nahe Spur 0,75 Sekunden lang einen deutlichen Angriffshinweis. Der Guard kommt bei x=2,5 in der nahen Spur an und wartet d Sekunden; danach zeigt er 0,75 Sekunden lang einen breiten Feger über das feste Rechteck x=1,5 bis 3,5 in beiden Spuren.
Der Spieler kann ausweichen: ein Schritt zur Position x=3 in der anderen Spur. Das Ausweichen dauert 0,25 Sekunden; die Abklingzeit beginnt danach und endet 0,75 Sekunden später. Bei Zeitgleichheit wird die Spieleraktion vor der Trefferprüfung aufgelöst. Rusher prüft nur seine nahe Angriffsspur; Guard prüft sein beschriebenes Rechteck über beide Spuren.
Beide Gegner erholen sich nach dem Angriff 0,75 Sekunden. Während der Erholung kann ein naher Treffer sie verwunden. Beide benötigen einen Treffer. Das Tor öffnet erst, wenn beide besiegt sind. Zeige deutliche Hinweise, Trefferbereiche, Erholung, Gesundheit und Torzustand. Reset stellt die Ausgangspositionen und Verzögerung wieder her. Füge keine weiteren Gegner oder Angriffe hinzu.Prüfen Sie ein künftiges Ergebnis anhand dieser Regeln, bevor Sie Funktionen ergänzen. Kontrollieren Sie, ob es genau einen Rusher und Guard gibt, die Hinweise vor der Trefferprüfung erscheinen, ein Ausweichen bei t=0,75 vor dem Sprinttreffer ausgewertet wird und das Guard-Rechteck beide Spuren abdeckt.
Nachvollziehen, warum ein Spawn nach einer halben Sekunde das Ausweichen überlappt
Verwenden Sie eine Zeitleiste, statt die Welle als „zu schnell“ zu beschreiben. Die Ausgangsverzögerung des Guards ist d=0,5 Sekunden. Sein 0,75-Sekunden-Hinweis endet und die Trefferprüfung erfolgt bei t=1,25. Das Ausweichen des Spielers endete bei t=1,0; die Abklingzeit läuft bis t=1,75. Daher ist das Ausweichen bei der Prüfung nicht verfügbar, und x=3 liegt im Guard-Rechteck.
| Zeit | Spielerzustand im Papierablauf | Ereignis und Prüfung des Gegners | Festgelegte Folge |
|---|---|---|---|
| 0,00–0,75 | Bei x=2 in der nahen Spur; kann den Hinweis des Rushers lesen. | Rusher kündigt seinen Sprint durch die nahe Spur an. | Vorgesehene Reaktion ist ein zeitlich passendes Ausweichen, kein blinder Angriff. |
| 0,75 | Ausweichen endet bei x=3 in der fernen Spur. | Rusher sprintet von x=0 bis x=3 in der nahen Spur und prüft dann seine Bahn. | Der Spurwechsel vermeidet den Treffer in der nahen Spur. |
| 1,00 | Ausweichanimation endet; Abklingzeit läuft bis 1,75. | Rusher beginnt sein Erholungsfenster. | Der Spieler kann einen Treffer während der Erholung planen, muss aber den Zeitplan des Guards beachten. |
| 1,25 | Ausweichen nicht verfügbar; x=3 liegt weiter im Bereich des Guards. | Bei d=0,5 prüft der Guard x=1,5–3,5 über beide Spuren. | Der Spieler erleidet in diesem Papierbeispiel einen festgelegten Treffer. |
Das Rechteck des Guards umfasst nahe und ferne Spur. Das Ausweichen vor dem Rusher schützt den Spieler deshalb nicht vor diesem Feger. Bei x=3 liegt er außerdem innerhalb des horizontalen Bereichs von 1,5 bis 3,5.
Eine Timingänderung auf Papier prüfen
Ändern Sie nur die Spawn-Verzögerung des Guards von 0,5 auf 1,5 Sekunden. Position, 0,75-Sekunden-Hinweis, feste Trefferfläche über beide Spuren, Schaden, Spielerbewegung, Rusherbahn und Torbedingung bleiben gleich. Die spätere Verzögerung verschiebt die Trefferprüfung auf t=2,25. Dann ist das Ausweichen wieder verfügbar; der Spieler kann zu x=4 wechseln, außerhalb des Rechtecks.
Dies ist eine Papierberechnung mit einer veränderten Variable. Sie belegt weder, dass 1,5 Sekunden Spaß machen, noch dass Spieler bequem reagieren können oder die Implementierung die Reihenfolge einhält. Dafür wären ein spielbarer Build und echte Beobachtungen nötig.
Das vollständige Ergebnis geht über ein sicheres Ausweichmanöver hinaus. Rusher und Guard brauchen jeweils einen lesbaren Zustand, ein Trefferfenster und anschließend eine eindeutige Niederlagenreaktion. Erst wenn beide besiegt sind, darf das Tor aufgehen.
Den ersten Raum prüfen, bevor er erweitert wird
Scheitert ein künftiger Build an der Begegnung, suchen Sie die erste Stelle, an der sein sichtbarer Zustand von den Regeln abweicht. Ändern Sie nicht mehrere Zeitwerte zugleich: Spawn, Hinweis, Abklingzeit und Trefferprüfung haben unterschiedliche Funktionen.
| Symptom | Zuerst prüfen | Gezielte Korrektur |
|---|---|---|
| Der Rusher trifft, bevor sein Hinweis endet. | Endzeit des Hinweises, Sprintbeginn und Zeitstempel der Trefferprüfung vergleichen. | Den Hinweis von 0,75 Sekunden wiederherstellen und die Reihenfolge Spieleraktion-vor-Trefferprüfung bestätigen. |
| Die Warnung des Guards zeigt eine Spur an, trifft aber beide. | Signalfläche mit x=1,5–3,5 in beiden Spuren vergleichen. | Vorschau und Kollisionsregel in Einklang bringen; das festgelegte Rechteck nicht stillschweigend verkleinern. |
| Dasselbe Ausweichen ist zu unterschiedlichen Zeiten verfügbar. | Beginnt die Abklingzeit erst nach Ende des 0,25-Sekunden-Ausweichens? | Verfügbarkeit bei 1,75 nach dem Ausweichen bei t=0,75 beibehalten und beide Zeitpläne erneut prüfen. |
| Ein besiegter Gegner blockiert das Tor weiterhin. | Wartet der Gruppensieg auf beide Niederlagenmarker? | Tor erst öffnen, wenn Rusher und Guard besiegt sind; Reset soll es wieder schließen. |
| Ein Angriff verfehlt während des Erholungsfensters. | Abstand, Spur, Auswahl des nächsten Gegners und Verwundbarkeit mit einem Treffer prüfen. | Reichweite von 1,5 Einheiten in derselben Spur beibehalten und jeweils einen Treffer testen. |
Trennen Sie beobachtete Ergebnisse vom Papierzeitplan. Für einen echten Prototyp sollten Build-Version, genaue Eingaben, sichtbare Hinweise, Trefferprüfung, Reset und einwilligungsbasierte Spielbeobachtung protokolliert werden.
Einen KI-Spielbauer als Startablauf verwenden
SEELEs aktuelle Seite zum Free AI Game Maker beschreibt einen allgemeinen Ablauf: Spielidee in Alltagssprache formulieren, eine spielbare 2D- oder 3D-Erstversion erzeugen, im Browser testen und mit Folgeprompts überarbeiten. Sie garantiert weder diese Angriffsreihenfolge noch Trefferflächen oder Timing.
Geben Sie für diesen Entwurf Arena, Spieleraktionen, Angriffshinweise, Zeitstempel, Trefferflächen, Siegbedingung und Reset in einem fokussierten Briefing an. Ist ein spielbares Ergebnis verfügbar, prüfen Sie es anhand der Tabelle. Behandeln Sie ein Bild oder einen Prompt nicht als Beleg dafür, dass die Mechanik funktioniert.
So wird der nächste Schritt sinnvoll: Ein Ersteller kann einen allgemeinen Prompt-zu-Spiel-Ablauf verwenden, um die Idee zu erkunden, und zugleich die konkrete Logik im tatsächlichen Build prüfen.
Mit einem gut lesbaren Brawler-Raum fortfahren
Halten Sie die erste Begegnung auf einen Rusher, einen Guard, eine Ausweichregel und ein Tor beschränkt, das erst nach dem Sieg über beide Gegner öffnet. Prüfen Sie zuerst, ob jeder Hinweis zur tatsächlichen Trefferfläche passt; danach kann weiteres Kampftempo hinzukommen.
Wenn Sie das Briefing in einen Prototyp überführen möchten, starten Sie mit dem Free AI game maker, prüfen Sie aktuelle Generierungskosten und vergleichen Sie das spielbare Ergebnis mit dem Raumvertrag. Behalten Sie die Zeittabelle, prüfen Sie einen echten Build und ändern Sie eine Variable nach der anderen.
Häufige Fragen
Was ist der erste Ablauf in einem Side-Scrolling-Brawler?
Beginnen Sie mit einem lesbaren Hinweis, Ausweichen in eine andere Spur, Erholungsfenster und klarer Rückmeldung, wenn die Gruppe besiegt ist. Der Spieler sollte wissen, wohin ein Angriff führt und wann ein Gegner verwundbar ist.
Warum führt die Verzögerung des Guards von 0,5 Sekunden zu einem Treffer?
Nach dem Ausweichen bei t=0,75 endet dieses bei t=1,0; erneut verfügbar ist es erst bei t=1,75. Der Guard mit d=0,5 beendet seinen 0,75-Sekunden-Hinweis bei t=1,25, während der Spieler noch innerhalb seines Rechtecks steht und nicht ausweichen kann.
Zählt die Überarbeitung auf 1,5 Sekunden als Spieltest?
Nein. Die Handrechnung zeigt, dass das definierte Ausweichen bei der verschobenen Guard-Prüfung bei t=2,25 wieder verfügbar ist und den Spieler vor der Prüfung zu x=4 bewegen kann. Sie zeigt nicht, dass ein generiertes Spiel oder ein echter Spieler so reagiert.
Was sollte ich in einem spielbaren Brawler-Prototyp prüfen?
Vergleichen Sie jeden Angriffshinweis mit der tatsächlichen Trefferfläche, bestätigen Sie, dass die Spieleraktion bei gleichem Zeitstempel zuerst verarbeitet wird, messen Sie die Ausweich-Abklingzeit und prüfen Sie Verwundbarkeit, Gruppensieg und Reset in einem echten Build.
Kann ein KI-Spielbauer dieses Gegner-Timing garantieren?
Nein. Der allgemeine Produktablauf garantiert kein bestimmtes Timing. Ein Briefing in Alltagssprache kann den gewünschten Ablauf beschreiben; ein spielbares 2D- oder 3D-Ergebnis muss trotzdem gegen die konkreten Regeln geprüft werden.
