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
[Bearbeiten]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?
[Bearbeiten]- 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
[Bearbeiten]- 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
[Bearbeiten]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.