MUTEC – Zweispieler-Prüfung

Stand: 16.10.2026. Logische Prüfung des lokalen MUTEC-Projektstands; keine Änderung der produktiven Seiten, des Relay oder von Bestenlisten.

Ergebnis

125 automatisierte Servertests bestanden: 61 bestehende und 64 neue Vertragsprüfungen (16 Szenarien je Pong, Pöng, Flight und Ortssuche). Zusätzlich drei getrennte Browserkontexte für Gastgeber, Gast und Anzeige; 36 Zustandspaare mit tatsächlich sichtbaren Optionen/Meldungen erfasst. Standardablauf einschließlich gemeinsamer Startbereitschaft, Ergebnis/Highscore, Revanche und Gastausstieg bestanden. Drei bestätigte Oberflächenfehler bleiben offen; dies ist keine uneingeschränkte Freigabe.

Wer bekommt wann welche Optionen?

QR nur auf Smartphone von Spieler 1. Das Anzeigen unterbricht ein laufendes Einzelspiel nicht; erst der Scan akzeptiert den Gast und bereitet eine gemeinsame neue Runde vor. Spieler 2 erhält eigene Infokarten.
Eine Beitrittsanfrage mit eigenem Ticket bleibt dagegen offen, bis Spieler 1 annimmt. Spieler 1 sieht Annehmen/Ablehnen; bis dahin läuft das Einzelspiel weiter. Gast wartet nach den Karten auf Annahme.
Gemeinsamer Countdown dauert drei Sekunden und erfordert Bereitschaft beider Teilnehmer sowie ihre Verbindungen und die Anzeige.
Spieler 1 steuert links/eigenen Flieger/eigene Karte; er darf Neustart bzw. neue Suche anfordern und zur Auswahl zurückkehren. Bei Pong/Pöng auch Spiel beenden.
Spieler 2 steuert nur rechts bzw. seinen Flieger/seine Karte. Er darf Bereitschaft erklären und selbst aussteigen. Er darf weder Stationen steuern/freigeben noch eine gemeinsame Runde erzwingen.
Ergebnis und qualifizierte Namenseingabe gehören jeweils dem richtigen Teilnehmer. Bei Ortssuche kann ein fertiger Teilnehmer warten, während der andere weiter sucht. Bestenlisten nur auf der Anzeige.
Revanche wartet erneut auf beide. Bei Pong/Pöng/Flight kann Gastbereitschaft nach dem Ende vor oder nach der Gastgeberanforderung eintreffen. Bei Ortssuche erhält der Gast nach der neuen Suchanforderung den Bereitschaftsbutton.
Gastverbindung: kurze Unterbrechung pausiert; erneut bereit werden. Platz zunächst 15 Sekunden reserviert. Gast geht: Besitzer behält Station; Rückkehr zum Einzelspiel mit Countdown.
Gastgeberverlust: Gast nach 15 Sekunden höflich verabschieden, keine Übernahme von Stationsrechten. Zusätzlicher Gast oder zweiter aktiver Gast-Tab wird abgewiesen.

Offene reproduzierte Fehler

UI-01 – Einladung während des Ladens abbrechen

Antwort des Einladungsabrufs verzögern, Zurück zum Spiel drücken, Antwort zulassen. Nur POST, kein Widerruf; geschlossener Dialog erhält trotzdem QR-Link und spätere Gastmeldung löst den Einladungserfolg aus. Gemeinsames Einladungsmodul aller vier Spiele. Eine Korrektur muss verspätete Antworten, Widerruf und Wiederöffnen gemeinsam behandeln.

UI-02 – Gast wartet laut Hinweis auf sich selbst

Pong/Pöng zeigen auch dem Gast „Warte auf Spieler 2“, wenn seine eigene Bereitschaft fehlt. Rollenabhängigen Hinweis vorsehen.

UI-03 – Bereitschaft ohne Verbindung aktiv

Pong/Pöng lassen „Ich bin bereit“ beim Wiederverbinden aktiv; Klick kann in dieser Phase nicht gesendet werden. Während Trennung deaktivieren und Bestätigung klar anzeigen. Einige Pong/Pöng-Texte in control/paddle-flow.js enthalten zusätzlich fehlerhaft kodierte Zeichen. Keine dieser Korrekturen wurde im Rahmen der Prüfung veröffentlicht.

Testumfang und Grenzen

Neue Tests: realtime/test/two-player-contract.test.js. Prüfung fehlender Bereitschaft/Anzeige; QR-Anzeige und Scan; Ticketanfrage/Annahme/Ablehnung/Rückzug; gleichzeitige Scans; alte/abgelaufene/widerrufene QR-Codes; dritte Person; verbotene Gastaktionen; Neustart/Revanche in beiden Reihenfolgen; Gast-/Displayverlust; Gasttimeout/Ticketwiderruf; Gastgeberverlust bei 14/16 Sekunden; doppelte Gastverbindung.

Echte Serverlogik und WebSocket-Weg lokal, MegBes-Upstream simuliert. Browser mit echten HTML-/CSS-/Steuerungsmodulen; Google Maps und Flight-3D-Ansicht als Attrappen, Rundenenden für reproduzierbare Ergebnisprüfung gezielt herbeigeführt. Kein physischer LED-, Neigungssensor-, Mobilfunk-, iOS-Hintergrund- oder Dauertest. Produktiver Relay unverändert.

Lokaler Nachweis: outputs/MUTEC-Zweispieler-Prüfbericht.md, MUTEC-Zweispieler-Optionen.md, MUTEC-Zweispieler-Browserzustände.json und MUTEC-Zweispieler-Grenzfälle.json im Codex-Arbeitsordner dieser Unterhaltung.

MUTEC – Spielablauf · MUTEC – Einheitliche Spiele