// TECH //

Vom Klick zum Live-Match in Sekunden

Was der Browser lädt, wie deine Identität die Iframe-Grenze überquert, und was die Server tun, während du spielst. Jede Zahl hier wurde an der Live-Seite gemessen.

Was ein Klick auf Spielen wirklich lädt

Eine Kachel auf der Startseite bringt dich nach /play.html?game=<slug>. Diese Seite ist absichtlich klein: elf Dateien, etwa 82 KB HTML, CSS und JavaScript, rund 31 KB komprimiert, geparst und lauffähig 100 bis 150 Millisekunden, nachdem die Anfrage rausgeht.

Nichts davon ist das Spiel. Die Seite liest den Slug aus dem Query-String, holt den Katalog von games.blitzbrawl.com/catalog.json und schlägt ihn nach. Schlägt dieser Abruf fehl, wird eine in die Seite eingebaute Kopie benutzt, damit eine schlechte Minute im Netz trotzdem ein Spiel zeigt.

Der Eintrag liefert das Einzige, was zählt: eine Spiel-URL der Form games.blitzbrawl.com/<Spiel-ID>/<Versions-ID>/index.html. Die Seite erzeugt ein Iframe, zeigt es dorthin, und ist fertig.

Warum es keinen Installationsschritt gibt

Diese Versions-ID leistet echte Arbeit: Jeder Build landet auf einem neuen, unveränderlichen Pfad, also cachen Browser und CDN ihn hart, und ein Release macht nichts ungültig. Es wird nichts installiert, weil es nichts zu installieren gibt: Die Spiele sind HTML, JavaScript und ein Canvas.

Was ein erster Besuch mit leerem Cache kostet, aus dem Resource Timing des Browsers selbst:

• Blob Volley: 20 Dateien, 145 KB über die Leitung (524 KB entpackt). Das Spiel ist ein einziges 345 KB großes HTML-Dokument, das komprimiert mit 86 KB ankommt.
• Clash of Stars: 41 Dateien, etwa 620 KB, hauptsächlich Nebel-Artwork und ein Musikstück.
• Zone Command: deutlich schwerer. Seine Sprite-Atlanten kommen auf mehrere Megabyte über rund zweihundert Bilder, die noch ankommen, wenn das Menü schon benutzbar ist.

Alle drei Menüs waren an einer Desktop-Verbindung innerhalb einer Sekunde auf dem Bildschirm und klickbar. Ein Handy mit schwachem Signal braucht länger, und je schwerer die Grafik, desto mehr merkt man das.

Das Spiel läuft in einer Sandbox, auf einer eigenen Domain

Das Spiel läuft nicht auf blitzbrawl.com. Es läuft auf games.blitzbrawl.com, in einem Iframe, das mit sandbox="allow-scripts allow-same-origin allow-pointer-lock" und allow="autoplay; fullscreen" deklariert ist.

Eine andere Origin bedeutet, dass das Spiel die Seite um sich herum nicht lesen kann, weder ihr DOM noch ihren Speicher, und diese Seite nicht die des Spiels. Vollbild und Pointer Lock werden bewusst erlaubt, damit der Vollbild-Button die echte Browser-API benutzt, wo es eine gibt, und den Viewport von Hand übergibt, wo es keine gibt, wie in Safari auf dem iPhone.

Wie das Spiel erfährt, wer du bist, ohne Passwort

In diesem Stack gibt es keine Passwörter. Wenn zum ersten Mal eine Identität gebraucht wird, prägt der Kontodienst ein anonymes Gerätekonto: ein undurchsichtiges Token und eine Spieler-ID, keine E-Mail. Um es zwischen Handy und Laptop mitzunehmen, gibst du eine E-Mail-Adresse an und bestätigst einen 6-stelligen Code. Das ist die ganze Anmeldung. Die Routine, die eine bestehende Sitzung prüft, registriert nie, also kann ein wackeliges Netz ein echtes Konto nicht gegen ein frisches anonymes tauschen.

Das Token lebt in einem bb_dt-Cookie mit Geltung für .blitzbrawl.com, mit einer Kopie im Local Storage. Dieser führende Punkt ist es, der die geteilte Origin zum Laufen bringt: Ein Spiel auf games.blitzbrawl.com sitzt unter derselben Domain und sieht das Token bereits.

Der sauberere Weg ist ein Handshake über die Iframe-Grenze. Das SDK des Spiels schickt ein hello mit seiner Protokollversion; die Seite antwortet mit ready, der Spiel-ID und dem aktuellen Spieler. Beide Seiten bleiben misstrauisch: Die Seite ignoriert alles, was nicht von der exakten Spiele-Origin und dem exakten Iframe kommt, das sie eingehängt hat, und das Spiel rastet beim ready auf die Eltern-Origin ein. Vor dieser Sperre bewegen sich keine Spielerdaten, und ein fehlgeschlagener Handshake fällt auf das Cookie zurück. Meldest du dich mitten im Spiel an oder ab, fährt ein playerChange-Ereignis über denselben Kanal, sodass der Multiplayer ohne Neuladen aufleuchtet.

Wie du in einem Match mit einem echten Menschen landest

Zwei der drei Spiele teilen sich einen serverseitigen Matchmaker, und der probiert zuerst die langweilige Option: Wartet eine öffentliche Lobby mit einem freien Platz und einem lebendigen Host, wirst du dort bereits als bereit hineingesetzt. Die Wertung wird dabei ignoriert: In einem laufenden Spiel zu landen, schlägt eine faire Paarung, wenn niemand in der Warteschlange steht.

Gibt es keine Lobby zum Beitreten, kommst du in eine Warteschlange, die sich weitet, während du wartest. Der akzeptable Wertungsabstand beginnt bei 150 Punkten und wächst um 100 pro fünf gewartete Sekunden, und die Fenster beider Spieler müssen den Abstand überspannen, bevor sie gepaart werden, sodass ein langer Wartender nie einen unpassenden Neuankömmling vorgesetzt bekommt. Es gibt keine serverseitigen Timer: Dein Client schickt seine Anfrage alle fünf Sekunden neu, und zwei kompatible Suchende werden sofort gepaart. Das Match beginnt 800 Millisekunden später, auf einer Uhr, auf die sich beide Clients einigen.

Blob Volley fährt eine gröbere Version derselben Idee und stuft den Abstand über 200, 500 und 1000 Wertungspunkte bis hin zu jedem, fünf Sekunden pro Stufe.

Matchmaking dauert Sekunden, wenn gerade noch jemand sucht. Wenn nicht, ist es ein Warten, und das repariert keine Technik, weshalb alle drei Spiele auch einen vierstelligen Lobby-Code ausgeben, den du einem Freund schicken kannst.

Was das Match am Laufen hält

Jedes Online-Match läuft über einen WebSocket zu einem regionalen Endpunkt. Clash of Stars rät die Region aus deiner Zeitzone (Frankfurt, Virginia oder Singapur) und lässt dich das in den Optionen überschreiben. Blob Volley öffnet alle drei und behält den, der zuerst antwortet. Zone Command läuft heute in einer Region, Frankfurt.

Dieser Socket ist ein Relay, und das Relay ist der Boden, nicht die Decke. Jedes Spiel handelt zusätzlich einen direkten WebRTC-Datenkanal aus, ungeordnet und ohne Wiederholungen, weil eine verspätete Eingabe nichts wert ist. Solange beide Routen existieren, gehen Pakete über beide raus, sodass die direkte Route die Latenz nur senken und ein Match nie zu Fall bringen kann. Blob Volley dreht die Reihenfolge um: Es bevorzugt den direkten Kanal und fällt nach 15 Sekunden auf das Relay zurück.

Was über die Leitung geht, ist kein Spielzustand. Alle drei schicken Eingaben und Befehle und berechnen die Folgen lokal, weshalb der Verkehr winzig ist:

• Clash of Stars fährt eine deterministische Simulation mit 20 Ticks pro Sekunde. Befehle werden fünf Ticks (250 ms) voraus gestempelt, damit sie überall rechtzeitig ankommen, und jeder Client hasht seinen Zustand alle 40 Ticks, um eine Abweichung zu erwischen.
• Zone Command benutzt dieselbe Engine-Familie mit einer engeren Befehlsverzögerung von zwei Ticks (100 ms) und einem Hash alle 30 Ticks.
• Blob Volley ist ein Rollback-Spiel mit 60 Frames pro Sekunde. Ein Eingabepaket hat 8 Bytes: eine 24-Bit-Framenummer plus vier Eingabebytes, den aktuellen Frame und die drei davor, sodass ein verlorenes Paket sich selbst repariert. Eine verspätete Eingabe spult zurück und spielt bis zu 20 Frames nach.

Wo die Sekunden wirklich bleiben

Zusammengezählt für einen kalten ersten Besuch an einer Desktop-Verbindung: etwa 150 Millisekunden für die Seite um das Spiel herum, unter einer Sekunde, bis das leichteste Spiel ein klickbares Menü zeigt, zwei Taps bis zur Schnellsuche, und dann die eine Zutat, die keine Technik liefern kann, ein anderer Mensch.