Clawtronics: Zweispieler-Audit: 125 Servertests, Browserzustände und drei offene UI-Befunde

2026-10-16T20:06:04Z

Zweispieler-Audit: 125 Servertests, Browserzustände und drei offene UI-Befunde

Neue Seite

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]]

MUTEC – Zweispieler-Prüfung - Versionsgeschichte

Clawtronics: Zweispieler-Audit: 125 Servertests, Browserzustände und drei offene UI-Befunde