Einen Koop-Platformer mit klarer Prompt-Abfolge planen

Ein Koop-Platformer braucht eine klare gemeinsame Bedingung: Was tut jede Person, wann zählen Aktionen zusammen und was passiert, wenn eine Person verfehlt? Definieren Sie diese kleine Schleife, bevor Sie ein langes Level anfordern. Twinspan Relay ist ein eigens erfundenes Papierbeispiel, kein bestehender Build oder Spieltest. Das 1,5-Sekunden-Paarfenster und die 4-Sekunden-Brücke wurden gewählt, damit die Regeln leicht prüfbar sind; es sind keine gemessenen Balancingwerte.

Den Koop-Vertrag definieren

Schreiben Sie den Aktionsablauf als Zustandsfolge, nicht als Stimmung wie „die Spielenden sollen zusammenarbeiten“. Twinspan Relay gibt beiden Kuriere dieselben Lauf- und Sprungaktionen. An jeder Relaisstelle muss Spieler A die blaue Plattform und Spieler B die bernsteinfarbene berühren. Die erste richtige Landung startet einen gemeinsamen Timer. Erreicht die zweite Person rechtzeitig ihre passende Plattform, erscheint eine kurze Brücke; beide müssen sie überqueren, bevor sie wieder verschwindet. Der Checkpoint rückt erst vor, wenn beide angekommen sind.

Der Vertrag legt auch fest, wie ein Fehler aussieht. Eine falsche Plattform, ein Sturz oder ein abgelaufener Timer bringt beide zum letzten gemeinsamen Checkpoint zurück und entfernt die Brücke. In diesem Lehrdesign bleibt niemand allein zurück und kein Leben geht verloren. Erreicht eine Person den Checkpoint, während die andere noch unterwegs ist, bleibt er inaktiv, bis beide dort sind. Der Fortschritt gehört damit zum Teamzustand.

Die Tabelle macht Timing und Wiederherstellung für beide sichtbar. Bestätigen Sie vor weiterer Gestaltung, dass jede Zeile Auslöser, Zustandsänderung und Folgezustand enthält. Lautet das einzige Ergebnis „die Brücke öffnet sich“, muss der Prompt noch festlegen, wann sie schließt und wie das Team sich erholt.

Prompt 1: gemeinsame Regeln formulieren

Nutzen Sie einen kurzen Vertrags-Prompt, um Spielerzahl, Bildschirmumfang, gemeinsames Ziel und Wiederherstellung festzulegen. Fragen Sie nach offenen Annahmen, statt den Builder Lücken stillschweigend füllen zu lassen.

Plane einen lokalen Koop-Platformer für zwei Personen auf einem gemeinsamen Bildschirm. Beide haben dieselben Lauf- und Sprungbewegungen; keine Person hat Sonderfähigkeiten. Das gemeinsame Ziel ist, drei Paare von Landerelais zu überqueren und gemeinsam einen Ausgang zu erreichen.

An jedem Relais muss Spieler A auf der blauen und Spieler B auf der bernsteinfarbenen Plattform landen. Die erste richtige Landung startet ein Paarfenster von 1,5 Sekunden. Landet die zweite Person vor Ablauf auf ihrer zugewiesenen Plattform, entsteht für 4 Sekunden eine durchgehende begehbare Brücke. Beide müssen den nächsten gemeinsamen Checkpoint erreichen, bevor die Brücke schließt. Eine falsche Plattform, ein Sturz, ein verpasstes Paarfenster oder ein Brücken-Timeout bringt beide zum letzten gemeinsamen Checkpoint zurück und löscht aktiven Timer und Brücke. Der Checkpoint rückt nur vor, wenn beide dort sind. Der Ausgang öffnet sich erst, wenn beide ihre passenden letzten Plattformen erreichen. Neustart bringt beide zum Start-Checkpoint zurück und löscht alle Timer.

Gib eine Zustandstabelle für Position beider Personen, zugewiesene Plattformen, Paar-Timer, Brücken-Timer, gemeinsamen Checkpoint und Ausgangszustand zurück. Liste alle übrigen Annahmen auf. Halte den Plan lokal am selben Bildschirm; ergänze weder Online-Netzwerk, asymmetrische Kräfte, Leben noch Zufallsereignisse.

Dieser Prompt ist eine Designvorlage und kein Bericht über einen Durchlauf. Er verlangt sichtbare Zustände zur Prüfung. Weist das resultierende Steuerungsschema den beiden Controllern unterschiedliche Tasten zu, prüfen Sie, ob beide weiterhin dieselben Aktionen ausführen können und ob vor der ersten Lücke die Eingaben für jede Person erklärt werden.

Den Prompt für eine Lücke schreiben

Übertragen Sie den Vertrag in eine kleine Begegnung mit Start, Interaktion und erkennbarem Checkpoint. Verwenden Sie nur ein Plattformpaar und eine Lücke, damit ein verwirrendes Ergebnis weniger mögliche Ursachen hat. Legen Sie fest, was die Spielenden vor dem Sprung sehen, wie die erste Landung den Timer startet und wie die verbleibende Brückenzeit angezeigt wird.

Im Twinspan-Beispiel leuchten die beiden Plattformen in verschiedenen Farben und liegen auf gegenüberliegenden Felsvorsprüngen. Die erste passende Landung startet das 1,5-Sekunden-Fenster; die zweite bildet die Brücke. Der temporäre Weg muss als Route erkennbar sein, während der dahinterliegende Checkpoint inaktiv bleibt, bis beide Kuriere ankommen.

Prompt 2: ein Relais anfordern

Halten Sie die erste Build-Anfrage eng. Neben Bewegung gehören auch Neustart und sichtbare Statussignale zur Koop-Schleife; fordern Sie sie daher mit an.

Erstelle anhand dieses Regelvertrags einen kleinen lokalen Platformer-Prototyp für zwei Personen. Verwende einen gemeinsamen Bildschirm, zwei Controller und dieselben Lauf- und Sprungaktionen für beide. Baue eine erreichbare Lücke mit sicherer Startplattform, einer blauen Landeplattform für Spieler A, einer bernsteinfarbenen für Spieler B und einem gemeinsamen Checkpoint auf der anderen Seite.

Zeige beide Personen, ihre zugewiesenen Plattformfarben, das 1,5-Sekunden-Paarfenster nach der ersten richtigen Landung und eine deutliche Anzeige für den 4-Sekunden-Brückentimer, sobald beide passenden Plattformen besetzt sind. Die Brücke muss eine durchgehende begehbare Fläche sein. Der Checkpoint rückt nur vor, wenn beide Personen ihn vor dem Schließen der Brücke berühren. Stürzt jemand ab, landet auf der falschen Plattform, kommt nach Ablauf des Paarfensters an oder verpasst den Brückentimer, bringe beide zum vorherigen Checkpoint zurück und lösche den aktiven Zustand. Füge Neustart hinzu, der beide an den Anfang bringt.

Die Kamera soll beide Personen und die ganze Lücke zeigen. Ergänze einen kompakten Steuerungsbildschirm. Füge weder weitere Lücken noch Sammelobjekte, gegnerische Angriffe, Sonderkräfte, Zufallsereignisse oder Onlinespiel hinzu. Nenne, welche Regeln umgesetzt und welche noch ungeprüft sind; leite aus der Anfrage keinen erfolgreichen Build ab.

Eine gute Spezifikation garantiert keine Umsetzung. Prüfen Sie bei Verwendung eines Build-Tools, ob sich Statussignale bei jedem Auslöser ändern und ob die zweite Person noch handeln kann, während die erste wartet. Speichern Sie tatsächlichen Prompt und Build-Version, bevor Sie spätere Änderungen vergleichen.

Die Route erst nach dem ersten Relais erweitern

Sobald ein echter Build mit einer Lücke dieselben Tests aus Sicht beider Personen besteht, können Sie die Route erweitern, ohne die Kernregel zu ändern. Behalten Sie Plattformfarben, Timer, Brückendauer, Neustart und Checkpoint-Verhalten bei. Variieren Sie jeweils nur eine geometrische Eigenschaft wie Lückenbreite oder Landhöhe, damit sich spätere Fehler leichter lokalisieren lassen.

Der Erweiterungsprompt sollte diese Invarianten beibehalten und eine Routenübersicht anfordern, die aktives Relais und Checkpoint zeigt. Ergänzen Sie nicht automatisch eine neue Fähigkeit, nur weil eine spätere Lücke schwieriger ist. Entscheiden Sie zuerst, ob die Herausforderung Timing, Kommunikation oder Sprungweite testen soll.

Prompt 3: zwei weitere Relais hinzufügen

Erst nachdem die Ein-Lücken-Version anhand ihrer Abnahmetests geprüft wurde, erweitere dieselbe lokale Koop-Route um zwei weitere gepaarte Landerelais und einen Endausgang. Behalte Bewegungsaktionen, blaue/bernsteinfarbene Plattformzuordnung, 1,5-Sekunden-Paarfenster, 4-Sekunden-Brücke, gemeinsamen Checkpoint, Rücksetzung bei Verfehlen/Sturz und Neustart bei. Ändere zwischen den Relais nur Abstand der Lücken, Landehöhe und Gestaltung.

Beide Personen bleiben sichtbar, wenn ein Paarsignal erscheint. Zeige aktuellen gemeinsamen Checkpoint, aktives Relais und für jede Person, ob sie vor der Lücke, auf ihrer Plattform, auf der Brücke oder am Checkpoint steht. Das letzte Tor öffnet sich nur, wenn beide ihre passenden Ausgangsplattformen erreichen. Gib eine kompakte Routenkarte und Liste der Zustandsübergänge zurück. Ergänze weder Netzwerk, neue Kräfte, Gegner noch Zufallsregeln. Wurde keine Ein-Lücken-Version geprüft, kennzeichne dies als geplante Erweiterung und nicht als verifiziert.

Zustände beider Personen verifizieren

Schreiben Sie wiederholbare Aktionsfolgen auf, bevor Sie entscheiden, ob ein Koop-Moment klar ist. Erfassen Sie Startposition beider Personen, erste Landung, Zeitabstand der Landungen, Öffnen der Brücke und Fortschritt am gemeinsamen Checkpoint. Die folgenden Werte sind eine Papierrechnung für Twinspan Relay und keine Beobachtungen aus einem spielbaren Build.

Beim ersten Relais landet Spieler A beit=0auf der blauen Plattform; Spieler B landet beit=1.0auf Bernstein. Eine Sekunde liegt innerhalb des 1,5-Sekunden-Paarfensters; die Brücke öffnet also beit=1.0und läuft beit=5.0ab. Beide Personen erreichen beit=3.2den Checkpoint, bevor die Brücke schließt, und der Beispielzustand rückt vor. Beim zweiten Relais kommt Spieler B beit=1.9an, nachdem das Paarfenster beit=1.5abgelaufen ist. Es bildet sich keine Brücke; beide kehren zum vorherigen gemeinsamen Checkpoint zurück.

Diese erwarteten Zustände sind Abnahmetests für einen späteren echten Build und keine Testbelege. Ein nützliches Beobachtungsprotokoll enthält Regelversion, beide Controller, Aktionen, Zeitablauf, Positionen, Relaiszustand, Checkpoint und Ergebnis. Weicht etwas ab, lassen Sie die Aktionsfolge bei der Diagnose unverändert.

Den Fehlschlag korrigieren, ohne die ganze Schleife zu ändern

Scheitert ein Paar, suchen Sie den ersten Zustand, der von der vorgesehenen Folge abweicht. Hat eine Person die Plattformzuweisung nicht gesehen, verbessern Sie Signal oder Kamerarahmen, bevor Sie den Timer ändern. Wird eine richtige Landung erfasst, aber die Brücke öffnet sich nicht, prüfen Sie Plattformzuordnung und Timerstart. Schreitet eine Person allein fort, korrigieren Sie die Checkpoint-Bedingung, bevor mehr Levelinhalt hinzukommt.

Ändern Sie bei einer echten Überarbeitung jeweils nur eine Ursache und wiederholen Sie dieselbe Aktionsfolge. Eine Kameraänderung darf nicht zugleich das Paarfenster verändern; eine hellere Plattform darf nicht gleichzeitig die Neustartregel ändern. Halten Sie Beobachtung, vermutete Ursache und vorgenommene Änderung getrennt fest. Ohne Build oder Spielerbeobachtung ist eine vorgeschlagene Korrektur eine Designidee und keine nachgewiesene Verbesserung.

Prompt 4: eine gezielte Überarbeitung anfordern

Bestimme anhand der tatsächlichen Aktionsfolge und des Zustandsprotokolls, das ich bereitstelle, den frühesten Punkt, an dem das Koop-Relais vom schriftlichen Vertrag abweicht. Trenne eine Umsetzungsabweichung von einem Sichtbarkeits-, Kamera- oder Steuerungsproblem. Schlage eine kleine Änderung vor, nenne, was gleichbleiben soll, und formuliere dieselbe Aktionsfolge als Wiederholungstest.

Erfinde weder Rückmeldung der Spielenden noch Testergebnis oder erfolgreiche Überarbeitung. Liegt kein Beobachtungsprotokoll vor, gib mögliche Ursachen als Checkliste zurück, ohne zu behaupten, eine davon sei aufgetreten. Gemeinsamen Checkpoint, Plattformzuweisung, Timer und Neustart beibehalten, sofern Belege nicht ausdrücklich zeigen, welche Regel geändert werden sollte.

Ein kleines Mehrspieler-Szenario als Übergabe nutzen

Die Multiplayer-Game-Maker-Seite von SEELE beschreibt, Spielerzahl, Rollen, gemeinsame Ziele, Interaktionsregeln und ein kurzes Szenario zu planen. Sie erklärt auch, dass Onlinespiel projektspezifische Umsetzung, Netzwerk, Synchronisierung, Hosting und Tests braucht. Das kann helfen, ein Koop-Konzept einzugrenzen, verifiziert aber weder lokale Steuerung noch die genauen Zeitregeln von Twinspan Relay. Prüfen Sie tatsächliche Zustandsänderungen beider Personen, bevor Sie den Modus erweitern.

Schreiben Sie zuerst das gemeinsame Ziel und einen Abnahmeablauf auf. Wenn Sie das kurze Mehrspielerkonzept ausarbeiten, verwenden Sie denMultiplayer-Spiel-Generator. Behandeln Sie die Seite als Planungsübergabe und bestätigen Sie das benötigte Verhalten im Projekt, das Sie tatsächlich erstellen.