Clawtronics: Pong: Gastberechtigungen, Spielprotokoll und Inbetriebnahme dokumentiert

2026-10-10T12:16:20Z

Pong: Gastberechtigungen, Spielprotokoll und Inbetriebnahme dokumentiert

Neue Seite

= MUTEC · Pong — Stand 10.10.2026 =

== Aktivieren ==

Das Frontend wird unter https://www.tinetronics.de/mutec/pong/ veröffentlicht. Der Electron-Reiter pong auf PC 166 verwendet display.html und den bestehenden DISPLAY_KEY. Den Schlüssel nicht weitergeben; er ist nie im Gast-QR-Code enthalten.

# Eine laufende MUTEC-Anwendung mit „Zur Auswahl“ verlassen.
# Auf dem VPS als root ausführen:
<code>bash /home/clawtronics/mutec-pong-update/apply-pong-update.sh</code>
# Die abschließende Statusmeldung muss pong:true, flight:true und returnToTrailer:true enthalten.
# Electron neu starten und das MUTEC-Menü am Smartphone neu laden. Pong wird sichtbar, sobald /mutec-control-api/capabilities pong:true meldet.
# Spieler 1 meldet sich mit einem MegBes-Ticket an und wählt Pong. Finger auf der großen Touch-Fläche hoch/runter bewegen.
# Spieler 2 scannt den QR-Code auf dem Bildschirm und drückt „Rechten Schläger übernehmen“. Er braucht kein MegBes-Ticket.

Kein neuer nginx-Pfad, API-Schlüssel oder MegBes-Backend nötig. Der separate Relay erhält access.js, protocol.js, server.js, pong-guests.js und test/relay.test.js. Update mit Sicherung, Prüfung und Rücksetzen bei Fehlern. Umgebungsdatei, DISPLAY_KEY, Abhängigkeiten und systemd-Konfiguration bleiben erhalten. Die existierende Karten-, Aqua-, Medien- und Papierflug-Steuerung bleibt verfügbar.

== Spiel ==

Das Spiel startet gegen den Computer. Spieler 1 steuert links; ein Gast ersetzt den Computer rechts. Wer zuerst sieben Punkte erzielt, gewinnt. Spieler 1 darf das Spiel neu starten; der Gast kann nur rechts steuern oder seinen eigenen Gastzugang verlassen. Bei Gast-Trennung oder inaktivem rechten Browser übernimmt die KI. Fehlen aktive Eingaben von Spieler 1 länger als 1,2 Sekunden, wird pausiert. Der Spielstand wird auf beide Smartphones zurückgemeldet.

„Zur Auswahl“ beendet die Pong-Sitzung, schickt 50-Trailer und gibt Station 50 frei. Alle Gastberechtigungen dieser Sitzung verfallen dabei. Auch Ticket-Widerruf, Station-IDLE und Sitzungsablauf beenden den Gastzugang über dieselbe bestehende Überprüfung. Der Gast kann die Station nicht reservieren oder deren Ticket-Sitzung verlängern.

Auswahl: Feature pong, UDP 166-pong und 50-maps. 50-maps ist der vorhandene HDMI-Umschaltbefehl. Electron views.json erhält id/udpSignal pong; URL https://www.tinetronics.de/mutec/pong/display.html#displayKey=BESTEHENDER_DISPLAY_KEY.

== QR-Code und Gastberechtigung ==

Eine angemeldete Pong-Anzeige fordert über WebSocket eine Einladung für die aktive, durch ein Ticket reservierte Pong-Sitzung an. Eine Einladung ist 90 Sekunden gültig und wird danach automatisch ersetzt. Sie enthält einen kryptografischen Zufallswert mit 256 Bit. Dieser Wert steht im URL-Fragment von guest.html, wird vom Browser aus der Adresszeile entfernt und nicht als HTTP-Abfrageparameter, Referrer oder an einen externen QR-Dienst weitergegeben. Der QR-Code wird lokal mit qrcode-generator 1.4.4 (MIT-Lizenz beigelegt) erzeugt.

POST /mutec-control-api/pong/guest mit dem Einladungstoken im Authorization-Header tauscht eine Einladung einmalig gegen einen separaten Gasttoken. Parallele Beitrittsversuche werden in der bestehenden Relay-Warteschlange nacheinander geprüft; genau einer gewinnt. Gasttoken gilt maximal 15 Minuten und ausschließlich während seiner Elternsitzung. Ein Platz ist nach dem Einlösen bis zur WebSocket-Verbindung 15 Sekunden reserviert. Es kann nur eine Gast-WebSocket-Verbindung zugleich bestehen. Bei Trennung ist Wiederverbindung mit dem bisherigen Token möglich; wenn ein neuer Gast den Platz übernimmt, verliert der alte Token seine Gültigkeit.

Gäste haben Rolle guest und Feature pong. Ihre Token werden von den APIs für Ticket-Steuerung, Stationserneuerung und UDP nicht akzeptiert. Gast-Nachrichten werden ausschließlich als Position des rechten Schlägers weitergeleitet. Eine selbst gewählte Seite wird verworfen. Gäste dürfen keine Spielaktionen, Kartenereignisse oder Spielstände senden. POST /pong/guest/leave widerruft nur den eigenen Gastzugang.

Der Gast verwendet weder /enter-system noch die MegBes-Ticket-Anmeldung. Eltern-Ticket und DISPLAY_KEY werden nicht im Gast-Frontend oder QR-Code offengelegt.

== WebSocket-Protokoll und Module ==

Join v1 mit feature:pong und role:controller|display|guest. Der bestehende ControlClient unterstützt die neue Rolle und Pong-Einladungen. Karten- und Papierflug-Nachrichten bleiben vom Pong-Kanal getrennt.

* pong.paddle, Smartphone → Relay: {y:0..1, active:boolean}, ca. 25/s. Relay ergänzt side:left|right anhand der authentifizierten Rolle.
* pong.action, nur Ticket-Controller → Anzeige: {action:restart, id:UUID}.
* pong.status, nur Anzeige → beide Spieler: {left:0..7, right:0..7, phase:waiting|playing|paused|finished, opponent:computer|guest, gameId:UUID}, ca. 6/s.
* pong.invite, nur angemeldete Anzeige: Anfrage v1/type:pong.invite; Antwort enthält entweder einen Gast-Einladungstoken mit Ablauf und gameId oder null.
* presence enthält für Pong zusätzlich guest:boolean und gameId. Keine Token in Presence.

Die Anzeige berechnet Ballphysik, KI und Punkte. simulation.js ist unabhängig von DOM und Netzwerk; paddle.js enthält die gemeinsame Touch-Bedienung für links/rechts; guest.js verwaltet ausschließlich den Gastbeitritt; pong-guests.js kapselt das Berechtigungsmodell des Relay. Neue Eingaben werden fortlaufend übertragen; alte Pong-Impulse werden nicht nach einer Wiederverbindung abgespielt. Neuladen der Anzeige setzt den Spielstand zurück. Keine dauerhafte Bestenliste.

Probespiel am PC ohne Ticket oder Stationssteuerung: https://www.tinetronics.de/mutec/pong/display.html?preview=1 (Pfeiltasten/W/S). Der Probemodus erstellt keinen echten Gastzugang.

== Prüfung und ausstehende Abnahme ==

36 automatische Prüfungen: 17 Relay-Prüfungen (einschließlich einmaliger QR-Nutzung, gleichzeitiger Beitritte, Gast-Timeout, Rechtebegrenzung, Seitenzuordnung, Ticket-Widerruf und Gast-Ende beim Verlassen), zehn Ticket-Prüfungen, vier Papierflug-Prüfungen und fünf Pong-Physikprüfungen. Browserprobe mit drei Ansichten: Computergegner, QR-Beitritt, rechter Schläger, Spielstand-Rückkanal, Besitzer-Neustart und Rückkehr zur KI beim Gast-Aussteigen. Keine echten Hardware-Befehle in diesen Prüfungen.

Noch erforderlich: root-Installation auf dem VPS und Test mit zwei echten Smartphones sowie Electron/Station 50. Der QR-Code in den Prüfbildern stammt aus dem isolierten lokalen Test-Relay und ist kein Zugang zum Live-System.

Quellen: https://github.com/kazuhikoarase/qrcode-generator und https://developer.mozilla.org/en-US/docs/Web/API/Pointer_events

Siehe auch [[MUTEC – WebSocket-Steuerung]], [[MUTEC – Papierflug]].
[[Kategorie:MegBes]]
[[Kategorie:Frontend]]

MUTEC – Pong - Versionsgeschichte

Clawtronics: Pong: Gastberechtigungen, Spielprotokoll und Inbetriebnahme dokumentiert