Direkt zum Hauptinhalt

StoryQuest Multiplayer starten

„Multiplayer" bei StoryQuest ist in Wahrheit zwei unterschiedliche Features, die sich auch kombinieren lassen. Diese Seite behandelt beide:

  • A) Twitch-Chat-Voting: dein Chat stimmt gemeinsam über den nächsten Schritt einer einzelnen Story-Session ab. Einfach, ein gemeinsamer Pfad, keine individuellen Charaktere.
  • B) Party-Modus: bis zu 8 Zuschauer joinen mit eigener Rolle, eigenem HP und gemeinsamem Gold/Inventar in eine echte Mini-RPG-Session mit Kämpfen, Loot, Händler, Statuseffekten und Zufallsereignissen. Das ist der deutlich mächtigere und für einen Stream interessantere Modus.

Beide Modi hängen an derselben Live-Session (/dashboard/storyquests/<id>/live) und lassen sich parallel nutzen: Der Chat stimmt über den Story-Fortschritt ab, während die Party ihre eigenen Kämpfe/Loot/Rollen hat.

Voraussetzungen

  • Quest existiert und ist mindestens published (Solo-Playtest hat funktioniert, siehe Erste Quest starten).
  • StoryQuest ist ein Beta-Feature (Badge im Dashboard-Menü) — teste die Session vor einem echten Stream einmal komplett durch.
  • Für Chat-Voting: eine Plattform-Verknüpfung (Twitch), damit Chat-Kommandos auslesbar sind.
  • Für das Overlay in OBS: Browser-Source mit /overlay/storyquest.php?key=<session_public_key> (bei Party zusätzlich &party_key=<party_public_key>).

A) Twitch-Chat-Voting einrichten

Öffne /dashboard/storyquests/<id>/live und klick « Live starten ». Du bekommst sofort die Overlay-URL. Im Bereich „🎮 Twitch-Chat-Voting" trägst du deinen Channel (Name oder ID) ein und klickst « An Channel binden ». Danach können Zuschauer !1, !2, !3 ... im Chat schreiben, um für die jeweilige Choice zu stimmen (Reihenfolge wie im Node angezeigt, plus Aliase, falls du welche in der Choice-Konfig angelegt hast). Mehrfach-Stimmen pro User werden geblockt (eine Stimme pro user_id pro Voting), Bots werden ignoriert. „Bindung aufheben" trennt den Channel wieder, ohne die Session zu beenden.

B) Party-Modus starten — der eigentliche Multiplayer-Flow

Im Bereich „🎮 Party-Modus (Multiplayer)" unterhalb des Chat-Voting-Blocks:

  1. Max-Spieler-Zahl wählen (2–8, Standard 4) und « 🎮 Party starten » klicken.
  2. Du bekommst sofort einen 6-stelligen Join-Code (z.B. 7K3M9X) und einen party_key. Die Spieler-URL ist https://chatlix.app/storyquest/party.php?code=<JOIN_CODE> — den Code kannst du groß im Stream zeigen.
  3. Spieler tragen im Join-Formular ihren Anzeigenamen ein und wählen eine Rolle: Warrior (25 HP, Tank, Verteidigungsbonus), Mage (14 HP, hoher Schaden, kann Gegner mit Brennen belegen), Rogue (18 HP, hat Initiative zuerst dran, 30% Ausweich-Chance), Healer (18 HP, heilt verletzte Mitspieler oder reinigt Statuseffekte), oder Spectator (0 HP, kämpft nicht mit, kann optional mitvoten). Rollen-Reihenfolge im Kampf ist immer Rogue → Healer → Mage → Warrior.
  4. Der Slot-Zähler im Dashboard zeigt „Spieler (n / max)". Ist die Party voll, können weitere Leute nur noch als Spectator beitreten.
  5. Overlay-URL in OBS aktualisieren, sodass &party_key= mit dabei ist.

Party-Voting statt Chat-Voting

Sobald eine Party läuft, öffnest du im Abschnitt „🗳 Party-Voting" ein Voting für die aktuelle Node (Standard-Dauer konfigurierbar, 10–600 Sekunden). Jeder aktive Spieler hat Stimmgewicht 2, Zuschauer/Spectator (falls zugelassen) Stimmgewicht 1 — Spieler-Stimmen zählen also doppelt so viel wie Zuschauer-Stimmen. Nach Ablauf oder manuellem « Schließen » wendest du den Gewinner an; bei Gleichstand oder wenn du bewusst eingreifen willst, kannst du eine Choice als „Host Override" erzwingen statt der Mehrheit zu folgen — das wird im Recap als mode: host_override vermerkt, nicht verschleiert.

Kampfrunden

Bei einer combat-Node löst du im Live-Controller eine Kampfrunde aus. Ablauf pro Runde:

  • Statuseffekte (Gift/Brennen) ticken zuerst und können HP kosten, ggf. sogar K.o. schlagen, bevor überhaupt gehandelt wird.
  • Lebende Spieler handeln in Initiative-Reihenfolge (Rogue, Healer, Mage, Warrior). Eingefrorene Spieler setzen aus, verängstigte Spieler haben 50% Chance zu verfehlen (außer Rogues).
  • Jeder würfelt W16; ab 14 ist es ein Krit (doppelter Schaden). Healer heilt mit 60% Chance einen verletzten Mitspieler oder reinigt (50/50) einen Statuseffekt, statt selbst anzugreifen.
  • Der Gegner kontert danach genau einen zufälligen lebenden Spieler. Rogues können mit 30% Chance ausweichen, Warriors haben einen Verteidigungsbonus. Manche Gegner (Mini-Bosse) können dabei einen Statuseffekt aufdrücken.
  • Ergebnis: continue (Kampf geht weiter), victory (Gegner-HP ≤ 0 — löst optional automatisches Loot aus) oder party_wipe (alle Spieler K.o.).

Das Overlay zeigt dazu passende Banner: Trefferanzeige mit fliegenden Schadenszahlen, ein großes 🏆-Banner bei Sieg, und ein goldenes Highlight-Banner bei besonders starken Treffern (≥10 Schaden + Krit gilt als „mega_crit"-Highlight).

Loot, Händler, Zufallsereignisse

Über die Panic-/Event-Controls kannst du manuell triggern: random_encounter (zufälliger Gegner), mini_boss (stärkerer Gegner mit Statuseffekt-Chance), merchant (Händler mit festen Angeboten: Heiltrank 8 Gold/heilt 10 HP, Antidot 12 Gold/entfernt Status, Scharfe Klinge 25 Gold/+1 Schaden), campfire (heilt alle um 30% ihres Max-HP und reinigt Status), rest (volle Heilung aller Spieler) und treasure (Zufalls-Loot, 8% Chance auf einen der acht Rare-Drops wie legendary_blade oder phoenix_egg). Merchant-Käufe sind gegen Race-Conditions abgesichert (atomarer UPDATE ... WHERE gold >= cost) — negatives Gold ist technisch ausgeschlossen, ein Spieler kann also die Party-Kasse nicht ins Minus kaufen.

Panic-Controls (Game-Master-Werkzeuge)

Für den Fall, dass live etwas schiefläuft, hast du als Owner:

  • ↺ Votes zurücksetzen — löscht alle Stimmen der aktuellen Node, falls ein Voting verfälscht wurde.
  • ❤ Alle beleben — setzt alle Spieler auf Rollen-Max-HP zurück und entfernt Statuseffekte.
  • ⏸ Pausieren / ▶ Fortsetzen — hält die Party im Status paused, State bleibt erhalten.
  • Party-Heal / Party-Damage — pauschaler HP-Betrag auf alle lebenden, nicht-Spectator-Spieler.
  • Status setzen/entfernen — manuell einen der fünf Effekte (poison, burn, fear, frozen, cursed) auf einen Spieler anwenden oder löschen, z.B. für skriptete Story-Events außerhalb des Kampfsystems.
  • Kick — entfernt einen Spieler-Slot (z.B. Ghost-Slot nach Verbindungsabbruch), Gold/Inventar bleiben der Party erhalten.

Recap nach der Session

Nach « Party beenden » ist die Recap-Page live unter /storyquest/recap.php?key=<party_public_key> — der Key ist der Party-Key, nicht die Session-ID. Sie zeigt Hero-Stats (Dauer, Spielerzahl, Highlights), automatisch erkannte Highlight-Momente (z.B. boss_victory, rare_loot, mega_crit, tie_vote, vote_storm, last_survivor) und den genommenen Pfad. Die Seite ist ohne weitere Auth erreichbar (wer den 32-stelligen Key hat, sieht alles) — bewusst so designed, da du die URL ohnehin mit deiner Community teilst; es stecken keine PII darin. Eine gute Zweit-Szene in OBS: die Recap-URL in einer separaten „Verabschiedung"-Szene als Browser-Source, damit Zuschauer nach dem Ende noch 60–90 Sekunden die Highlight-Karten lesen können.

Ablauf für einen 45–60-Minuten-Stream (bewährtes Muster)

Aus der internen Beta-Test-Erfahrung hat sich folgender Zeitplan bewährt:

  • T-30 bis T-15: Health-Check (/v1/health, Dashboard-Login, WS-Handshake), OBS-Overlay-Browser-Source einrichten (1920×1080, 30 FPS, „Quelle bei Inaktivität pausieren" UND „deaktivieren wenn nicht sichtbar" beide AUS, „aktualisieren wenn Szene aktiv wird" AUS — sonst Reconnect-Loop).
  • T+0: Story auswählen, „Live starten", Overlay-URL/Public-Key notieren.
  • T+2: Party starten (max_players je nach erwarteter Zuschauerzahl), Join-Code + Spieler-URL einblenden.
  • T+5–8: Spieler-Join-Welle abwarten (2-4 Spieler in 60-120s ist normal), erstes Voting öffnen.
  • T+12–18: Erster Kampf, danach Loot/Händler testen.
  • T+25: Optional ein Zufallsereignis triggern für Abwechslung.
  • T+30: Halbzeit-Check der Diagnostics-Box (siehe unten).
  • T+45–55: Story-Ende (Victory oder Wipe), Party beenden.
  • T+60: Recap zeigen.

Diagnostics-Box (Live-Dashboard)

Im Live-Controller gibt es eine ausklappbare Diagnostics-Box mit Live-Timeline (max. 80 Events sichtbar, gefiltert nach Combat/Voting/Loot/Merchant/Status/Panic/Player) sowie WS-Status, Reconnect-Zähler und Fallback-Switches (heuristisch: 10 Sekunden ohne WS-Event während die Party läuft, zählt als ein Fallback). Richtwerte für einen gesunden Stream: Stimmen/Minute 4–20, WS-Reconnects ≤ 3 pro Stunde, Fallback-Switches idealerweise 0, Wipe-Rate 5–15%, durchschnittliche Session-Dauer 30–60 Minuten, mindestens 3–8 Highlights. Deutlich abweichende Werte (z.B. >60 Stimmen/Minute = möglicher Spam, 0 Highlights = Detection könnte kaputt sein) sind ein Signal, genauer hinzuschauen.

Bekannte Beta-Limits (bewusst akzeptiert, kein Bug)

  • Die partyTimeline-API liefert maximal 500 Events pro Party (Hard-Cap). Bei sehr langen Sessions (>3h) verlieren ältere Events die Sichtbarkeit in der Diagnostics-Box — für die üblichen 45-60-Minuten-Sessions kein Problem.
  • WS-Reconnect-Backoff geht bis maximal 20 Sekunden. In diesem Fenster kann das Overlay ohne Live-Update stehen bleiben; das Dashboard-Polling (alle 5s) kompensiert für dich als Streamer, Zuschauer sehen im Worst Case einen kurzen Lag-Spike.
  • Ein nächtlicher Cleanup-Cron (04:30) markiert liegengebliebene Sessions ohne Aktivität >24h als abandoned. Solange dein Stream nicht über 04:30 hinaus läuft und die Session aktiv Log-Events erzeugt, betrifft dich das nicht.
  • Merchant-Käufe haben aktuell kein Rate-Limit (z.B. max. 1 Kauf pro 3s pro Spieler) — bei kleiner Beta-Audience kein relevanter Missbrauchsvektor, aber bei sehr aktivem Chat theoretisch spammbar.

Mehrere Sessions

Du kannst dieselbe Quest beliebig oft live spielen. Jede Session und jede Party bekommt einen eigenen Key und eigenen Recap. Es gibt keine Dashboard-Seite /dashboard/storyquests/<id>/analytics — diese Route existiert nicht. Aggregiert wird nur serverseitig über GET /v1/storyquests/<id>/stats (Finish-/Abbruch-/Wipe-Rate über alle Sessions), aber dafür gibt es aktuell (Stand Beta) keine eigene UI im Dashboard; du müsstest den Endpoint direkt abfragen.

Troubleshooting

  • Overlay zeigt nichts / weißer Bildschirm: Prüf, ob key (und bei Party party_key) korrekt und vollständig (32 Hex-Zeichen je Key) in der URL stehen — nicht der veraltete Parametername token. Browser-Console auf rote Fehler prüfen. Soft-Recover: F5 im Browser-Source-Tab, dann „Aktualisieren" in OBS.
  • Stimmen kommen nicht an (Chat-Voting): Bot-Status im Chat prüfen (ist der Chatlix-Bot im Kanal? Mod-Rechte vorhanden, falls dein Setup das verlangt?). Channel-Bindung im Live-Dashboard erneuern.
  • Party-Voting-Tally aktualisiert nicht: Ist der letzte Diagnostics-Event älter als ~30 Sekunden, ist es meist ein WS-Reconnect-Problem (siehe oben) statt ein Voting-Bug — Polling-Fallback greift trotzdem, nur verzögert. Toggle „Voting schließen" → „Voting öffnen" wirkt als Reset.
  • Party hängt fest (Node ändert sich nicht trotz beendetem Voting): „Gewinner anwenden" manuell klicken, falls vergessen. Danach ggf. „↺ Votes" + neues Voting öffnen. Als letztes Mittel: Party beenden, neue Party zur gleichen Story starten — Spieler müssen mit neuem Code rejoinen.
  • Spieler-Reconnect-Verhalten: Browser-Refresh (F5) behält Identität (voter_key liegt in localStorage) — der Spieler erscheint mit gleicher Rolle/HP wieder. Browser komplett geschlossen und neu geöffnet auf gleichem Gerät funktioniert genauso über den Join-Code. Anderes Gerät = neuer Slot; ist die Party dadurch „voll" mit Ghost-Slots, kick den alten Slot manuell.
  • Merchant-Spam / Gold verschwindet unerwartet schnell: Kein Bug — Gold ist Party-gemeinsam, jeder Spieler kann kaufen. Bei einem unkooperativen Mitspieler hilft nur „Kick", Gold bleibt der Party erhalten.
  • Galera/DB nicht erreichbar (alle StoryQuest-Calls schlagen fehl): Chatlix teilt die Datenbank-Infrastruktur mit anderen Produkten — das ist kein StoryQuest-spezifisches Problem, sondern ein Infra-Incident. Stream pausieren, Infra-Status prüfen.

Chat-Kommandos im Überblick

  • !1, !2, ... für Choices in Reihenfolge (Chat-Voting-Modus).
  • Optionale Aliase, wenn in der Choice-Konfiguration hinterlegt (z.B. !wald zusätzlich zu !1).
  • Im Party-Modus stimmen Spieler nicht per Chat-Kommando, sondern über ihre eigene Party-Seite () ab — die beiden Voting-Mechaniken sind technisch getrennt.