Mit der Abhängigkeit statt mit Rollennamen beginnen

Ein asymmetrisches Koop-Spiel funktioniert, wenn die Spielenden unterschiedliche Informationen haben und jede Person eine Aktion ausführen kann, die der anderen nicht zur Verfügung steht. Beginnen Sie mit einem gemeinsamen Ziel, legen Sie fest, was jede Rolle sehen und verändern kann, und machen Sie das Ergebnis für beide sichtbar. Bitten Sie anschließend um eine kleine Begegnung und eine Möglichkeit, die Regeln zu prüfen, bevor Sie das Spiel erweitern.

Die folgenden Prompts verwendenLaternen-Relais, ein eigens entwickeltes Lehrkonzept für eine Höhlenrettung mit zwei Personen vor Ort, die per Sprache kommunizieren. Es wurde weder gebaut noch getestet. Die Hüterin liest eine Routenkarte und verstellt einen entfernten Verschluss; der Kundschafter dreht einen physischen Spiegel und meldet den sichtbaren Strahlabschnitt. Das sind Annahmen für dieses Beispiel und keine Aussagen über SEELE-Funktionen.

Beginnen Sie mit der Abhängigkeit statt mit den Rollennamen

Vervollständigen Sie vor der Benennung der Rollen diesen Satz: „Wir erreichen[gemeinsames Ziel]erst, wenn eine Person[verdeckte Information]nutzt, um[Aktion]auszuführen, und die andere[andere Information]nutzt, um[andere Aktion]auszuführen.“ Wenn eine der Aktionen wegfallen kann, ohne die Lösung zu verändern, sind die Rollen zwar unterschiedlich benannt, aber noch nicht voneinander abhängig.

Für einen Prompt zu einem asymmetrischen Koop-Spiel sollten Sie zuerst das gemeinsame Ziel festlegen, dann die Informationsgrenze und eine exklusive Aktion für jede Rolle definieren. Beschreiben Sie den Moment, in dem eine Person die Rückmeldung der anderen braucht, sowie eine sichtbare Bestätigung der Zustandsänderung. So sind „unterschiedliche Fähigkeiten“ an einen tatsächlichen Rätselablauf gebunden, statt zwei voneinander unabhängige Charakterbeschreibungen zu bleiben.

Ein dokumentiertes Beispiel für geteilte Informationen findet sich im offiziellen Remote-Play-Leitfaden zuKeep Talking and Nobody Explodes: Die entschärfende Person sieht die Bombe, aber nicht das Handbuch; die Fachleute sehen das Handbuch, aber nicht die Bombe. Laternen-Relais verwendet eine andere Welt und andere Regeln. Die hilfreiche Designfrage lautet lediglich: Welche Information muss zwischen den Rollen ausgetauscht werden, bevor eine Aktion gelingen kann?

Geben Sie beiden Rollen eine notwendige Aufgabe

In Laternen-Relais kennt die Hüterin die feste Höhlenroute und die möglichen Fernverschlüsse, kann aber nicht erkennen, welcher Strahlabschnitt gerade beleuchtet ist. Der Kundschafter sieht den aktuellen Strahl und einen physischen Spiegel, aber weder die Routenkarte noch die Stellung des Fernverschlusses. Er richtet den Spiegel aus und meldet den beobachteten Abschnitt. Die Hüterin nutzt diese Meldung, um die passende Verschlusseinstellung zu wählen. Erst dann kann der Strahl das Rettungstor erreichen.

Dies ist eine Rollenvereinbarung: Jede Seite hat eigene Informationen, eine daran gebundene Aktion und einen Grund zur Kommunikation. Füllen Sie vor einem vollständigen Prompt die Tabelle mit konkreten Substantiven und Verben aus, auf die eine spielende Person zeigen kann. „Der Späher ist schnell“ reicht nicht; „der Späher sieht die Druckplatte und kann sie gedrückt halten“ gibt der anderen Rolle eine konkrete Abhängigkeit.

Die Tabelle zeigt auch einen häufigen Fehler: Wenn die Karte der Hüterin bereits den aktuellen Strahlabschnitt zeigt, liefert die Meldung des Kundschafters keine neue Information. Wenn der Kundschafter das Ziel durch Drehen des Spiegels allein erreichen kann, ist die Hüterin nur Zuschauerin. Schließen Sie diese Lücken in den Regeln, bevor Sie Dialoge, weitere Räume oder Figurenentwicklung hinzufügen.

Nutzen Sie drei Prompts, um von Regeln zu einem Raum zu gelangen

Trennen Sie die Anfragen, damit jede Antwort eine Aufgabe hat. Definieren Sie zuerst die Rollenvereinbarung. Bitten Sie als Nächstes um eine kompakte spielbare Interaktion oder, falls das gewählte Werkzeug die benötigte Steuerung nicht unterstützt, um eine strukturierte Designübergabe. Fragen Sie zuletzt nach einem Bewertungsplan, der auf Ihre echten Beobachtungen wartet. Die folgenden Prompts für ein asymmetrisches Koop-Spiel sind Vorlagen: Ersetzen Sie die Platzhalter und behalten Sie im Blick, dass das Beispiel nicht getestet wurde.

Prompt 1: Rollenvereinbarung definieren

Entwirf ein Koop-Spielkonzept für genau [Anzahl der Spielenden] Personen.
Gemeinsames Ziel: [ein Satz, der beschreibt, was die Gruppe erreichen muss].
Annahme zur Kommunikation: [wie die Spielenden Informationen austauschen].

Gib für jede Rolle an:
- welche Informationen nur diese Rolle beobachten kann;
- welche Aktion nur diese Rolle ausführen kann;
- welcher Zustand sich nach der Aktion ändert;
- welches Signal die Rolle den anderen melden kann.

Zeige die Abhängigkeit in dieser Reihenfolge: Information, Meldung, Entscheidung der Partnerrolle, Aktion und gemeinsame Rückmeldung. Beschreibe eine kurze Begegnung mit Ausgangszustand, gültigen Aktionen, Erfolgsbedingung, Fehlerbedingung und Reset-Zustand. Entferne anschließend jede Rolle einzeln und erkläre, ob die Begegnung weiterhin lösbar ist. Kann eine Rolle entfallen, ohne die Lösung zu verändern, überarbeite die Abhängigkeit. Füge noch keine Räume, Fortschrittssysteme oder zusätzlichen Mechaniken hinzu.

Gib eine Rollentabelle, eine Tabelle der Zustandsübergänge und alle Regeln zurück, für die noch eine Designentscheidung nötig ist. Behaupte nicht, das Spiel sei gebaut oder getestet worden.

Diese erste Anfrage verlangt einen Designvertrag, keine ausgearbeitete Welt. Prüfen Sie, ob jede Rolle etwas bemerken, etwas tun und etwas melden kann, das die nächste Entscheidung der Partnerrolle beeinflusst. Erfindet die Antwort ein Implementierungsdetail, das Sie noch nicht festgelegt haben, lassen Sie es als offene Entscheidung stehen, statt es als geklärtes Verhalten zu behandeln.

Prompt 2: den ersten Raum abgrenzen

Entwirf einen Rätselraum für eine Höhlenrettung mit dem Namen Laternen-Relais. Dies ist ein fiktives Lehrkonzept für zwei Personen vor Ort, die per Sprache kommunizieren. Dieser Prompt wurde weder ausgeführt noch getestet.

Gemeinsames Ziel: Den Leuchtfeuerstrahl zum Rettungstor lenken.
Ansicht und Aktion der Hüterin: Die Hüterin sieht eine feste Routenkarte und die Optionen des Fernverschlusses, jedoch weder die aktuelle Höhlenansicht noch den aktuellen Strahlabschnitt. Nur sie kann eine Einstellung des Fernverschlusses ändern.
Ansicht und Aktion des Kundschafters: Der Kundschafter sieht den aktuellen Strahl und einen physischen Spiegel, jedoch weder die Routenkarte noch den Zustand des Fernverschlusses. Nur er kann den Spiegel drehen und melden, welcher Strahlabschnitt beleuchtet ist.
Die Routenkarte zeigt mögliche Wege; die Meldung des Kundschafters identifiziert den aktuellen Strahlabschnitt. Die Hüterin braucht diese Meldung, um den passenden Verschluss zu wählen. Spiegel und Verschluss müssen beide richtig eingestellt sein, bevor der Strahl das Rettungstor erreicht.

Zeige den Ausgangszustand, jede gültige Aktion, Rückmeldung zu ungültigen Aktionen, den Erfolgszustand, einen Fehler- oder Zeitüberschreitungszustand und einen Reset zum Start. Verwende einen physischen Spiegel und einen Fernverschluss. Füge weder Kampf noch Inventar, Kampagnenfortschritt, Online-Netzwerk, Sprachchat-Software oder einen zweiten Raum hinzu. Halte die Informationen der beiden Rollen in den vorgeschlagenen Ansichten getrennt.

Kann das verfügbare Entwicklungstool keine zwei lokalen Eingaben oder getrennten Ansichten darstellen, liefere stattdessen eine strukturierte Übergabe zu Mechanik und Oberfläche, anstatt das Konzept als spielbar darzustellen. Kennzeichne alle Mechaniken, für die noch eine Entscheidung nötig ist. Gib eine Zustandstabelle und eine kurze Abnahmeliste zurück.

Prüfen Sie nach der Antwort zuerst die Zustandstabelle und erst dann die visuelle Gestaltung. Fragen Sie, ob eine falsche Verschlusseinstellung ein sichtbares und korrigierbares Ergebnis hat, ob der Kundschafter einen Strahlzustand melden kann, ohne die Karte der Hüterin zu sehen, und ob die Hüterin anhand der Meldung eine sinnvolle nächste Aktion wählen kann. Kann das Werkzeug oder die Laufzeit diese Einschränkungen nicht darstellen, ist die Designübergabe dennoch nützlich, aber kein Beleg für ein funktionierendes Koop-Spiel.

Prompt 3: tatsächlich erhobene Beobachtungen auswerten

Werte die Beobachtungen aus, die ich für dieses Koop-Spiel mit einem Raum bereitstelle.
Erfinde keine Aktionen, Spieltestnotizen oder erfolgreichen Ergebnisse.

Designvereinbarung: [vereinbarte Rollentabelle und Ausgangszustand einfügen].
Beobachtete Abfolge: [nur aufgezeichnete Aktionen und Reaktionen einfügen].
Erwartetes Ergebnis: [regelbasiertes Ergebnis angeben].
Tatsächliches Ergebnis: [angeben, was die Spielenden oder das Spiel gezeigt haben].
Erster Verwirrungsmoment: [früheste Unklarheit zitieren oder beschreiben].

Vergleiche die beobachtete Abfolge Schritt für Schritt mit der Vereinbarung. Benenne die erste Abweichung, erkläre, welche Regel oder welches Signal betroffen ist, und schlage eine begrenzte Änderung vor. Behalte Raum, Rollen und alle nicht betroffenen Regeln bei. Fehlt eine Beobachtung oder ist sie mehrdeutig, frage, was als Nächstes aufgezeichnet werden soll. Behaupte nicht, das Design habe funktioniert, wenn die bereitgestellte Beobachtung dies nicht stützt.
Gib die geänderte Zeile, das nun sichtbare Verhalten und eine Folgeprüfung für eine spätere Sitzung zurück.

Die Eingaben sind wichtiger als das Wort „bewerten“. Ohne beobachtete Abfolge kann das Modell nur eine Designprüfung vorschlagen, aber nicht berichten, wie sich Spielende verhalten haben. Sobald Sie Beobachtungen sammeln, nennen Sie das erwartete Ergebnis und den ersten verwirrenden Moment. So kann eine Änderung die kleinste Abweichung beheben, statt beide Rollen neu zu schreiben.

Prüfen Sie, ob beide Personen wichtig sind

Eine Rollentabelle beschreibt die Absicht; der Raum benötigt weiterhin beobachtbare Prüfungen. Gehen Sie die Begegnung vom Ausgangszustand aus durch und fragen Sie bei jedem Schritt, was jede Person weiß. Die folgenden Prüfungen sind eine vorgeschlagene Methode für Ihr eigenes Design, keine Ergebnisse eines Laternen-Relais-Spieltests.

Ändern Sie jeweils nur eine Sache. Ist die Meldung mehrdeutig, präzisieren Sie das Signal, bevor Sie ein Hinweissystem ergänzen. Ist eine Rolle untätig, verkürzen Sie die Schritte zwischen ihrer Beobachtung und ihrer Aktion. Ist das Ziel schwer zu erkennen, verbessern Sie zuerst die Strahl- oder Tor-Rückmeldung, bevor Sie ein weiteres Rätsel hinzufügen. Eine eng begrenzte Änderung erhält die Aspekte, die Sie weiterhin auswerten möchten.

Überarbeiten Sie anhand einer echten Beobachtung

Sobald Sie das Design mit Spielenden beobachten können, notieren Sie vier Dinge: die Aktion, das erwartete Ergebnis, das tatsächliche Ergebnis und den ersten Moment, in dem jemand zögerte oder etwas missverstand. Vermeiden Sie Schlussfolgerungen wie „Die Hüterin war langweilig“, wenn es keinen konkreten Moment zur Prüfung gibt. Eine Notiz wie „Die Hüterin konnte beide Verschlüsse wählen, bevor der Kundschafter den Strahl gemeldet hatte“ verweist auf eine konkrete Abhängigkeit, die sich ändern und erneut prüfen lässt.

Lassen Sie den restlichen Raum unverändert, während Sie diese Regel überarbeiten. Wiederholen Sie dann denselben Ausgangszustand und prüfen Sie, ob die Meldung die Entscheidung der Partnerrolle verändert. Das beweist weder Ausgewogenheit noch allgemeine Nutzbarkeit; es liefert eine nachvollziehbare nächste Frage. Solange keine tatsächlichen Beobachtungen vorliegen, beschreiben Sie das Problem als zu prüfendes Risiko und nicht als Spielergebnis.

Eine fokussierte Aufgabenbeschreibung in einen Erstellungsablauf übernehmen

Sobald der Papiervertrag schlüssig ist, können Sie die fokussierte Idee in einem Spiele-Erstellungsablauf ausprobieren und das Ergebnis prüfen. Die aktuelle offizielle Seite von SEELE fürFree AI game makerbeschreibt natürlichsprachliche Spielbeschreibungen, die Prüfung spielbarer 2D- oder 3D-Ergebnisse und Iterationen in Workspace. Außerdem sollen vor dem Erstellen die angezeigten Generierungskosten und Kontooptionen geprüft werden. Diese allgemeinen Ablaufinformationen bestätigen weder lokalen Koop-Modus noch zwei gleichzeitige lokale Eingaben, Sprachkommunikation oder diesen fiktiven Raum.

Nehmen Sie das gemeinsame Ziel, die erste Spieleraktion, Szenenzustände und Rückmeldungen in Ihre Anfrage auf. Prüfen Sie dann, ob das Ergebnis jede Steuerung und Rolle tatsächlich darstellt, bevor Sie es als Koop-Prototyp behandeln. Kann der verfügbare Ablauf zwei Ansichten oder Eingaben nicht ausdrücken, verwenden Sie das Ergebnis als Designgrundlage und planen die passende Implementierung separat. Für das Rätsel ist die Seite zumAI puzzle game makerrelevant, weil sie eine Regel, einen sichtbaren Hinweis, eine Lösungsaktion und ein Ergebnis behandelt; sie belegt keine Unterstützung für Mehrspieler.

Ein gutes erstes Ergebnis ist das kleinste, das sich anhand Ihrer Vereinbarung prüfen lässt. Behalten Sie den Raum nur dann bei, wenn jede Rolle Informationen oder Aktionen beiträgt, ungültige Entscheidungen erklärt werden und der Erfolgszustand sichtbar aus dem Zusammenspiel beider Rollen folgt. Sind diese Prüfungen nicht erfüllt, überarbeiten Sie eine Regel oder fordern eine Designübergabe an, bevor Sie den zweiten Raum ausbauen.