HyperBleKit: offline multiplayer Android és iOS között, kizárólag Bluetooth-on

Ha a játékosok egy szobában ülnek, nem kell szerver

Egy körökre osztott, többjátékos játék fejlesztésére készülünk, amelynek a játékosai fizikailag mindig együtt vannak. Emiatt teljesen elhagyhattuk az internetet és a backendet, és hagyhattuk, hogy a telefonok közvetlenül egymással beszéljenek. A lehetőségek mérlegelése után a Bluetooth Low Energy (BLE) mellett döntöttünk.

Mielőtt terméket építettünk volna erre a döntésre, kipróbáltuk. 2026. október 2–3-án egy kétnapos coworking sprinten ötfős csapattal építettünk és validáltunk egy prototípust vegyesen androidos és iOS-es készülékeken. Hét játékkal terheltük meg, a körökre osztott kártyajátékoktól a valós idejű akciójátékokig, az eredményekből pedig később egy nyílt forráskódú SDK lett, a HyperBleKit.

A host szerep miatt mindkét platformon natívan kellett dolgoznunk

Egy BLE-munkamenetben a hostoló telefonnak perifériaként (peripheral) kell működnie: ő hirdeti a játékot, és rajta fut a GATT-szerver, amelyhez a többi telefon csatlakozik. A cross-platform BLE-könyvtárak többsége akkoriban az egyik vagy mindkét platformon csak a central (kliens) szerepet támogatta, így egyetlen közös kódbázis nem tudta megbízhatóan biztosítani azt a szerepet, amelyre az architektúránk épült.

Ezért a transport réteget mindkét platformon natívan írtuk meg, Androidon Kotlinban, iOS-en Swiftben. Így teljes kontrollunk maradt a hirdetés és a GATT-szerver fölött, cserébe kétszer kellett megírnunk a protokollt. Ma mindkét platform tud hostolni és csatlakozni, és az androidos és iOS-es készülékek a gyakorlatban jól kommunikáltak egymással. A host három karakterisztikát tesz elérhetővé:

• —Játékinformáció, amelyet a kliensek olvasnak
• —Kliens–host irány, amelybe a kliensek írnak
• —Host–kliens irány, amely értesítésként érkezik

Írott specifikáció és közös tesztvektorok tartották egyformán a két kódbázist

A natív megoldás ára az volt, hogy a két implementáció eltávolodhat egymástól, márpedig egy protokoll két független megvalósítása hajlamos csendben szétcsúszni. Ráadásul az emulátorok és a szimulátorok nem támogatják a valódi BLE-rádiót, vagyis fizikai telefonok nélkül nem lehetett a protokollt elejétől a végéig ellenőrizni.

Ezért először a specifikációt írtuk meg, és azt tekintettük az egyetlen hiteles forrásnak. Közös tesztvektorokat tettünk a repóba: kanonikus JSON-üzeneteket a pontos, feldarabolt bájtkereteikkel, amelyeket mindkét platformnak bájtra pontosan elő kell állítania. Az architektúrát pedig szigorúan rétegeztük, hogy a protokoll és a játéklogika hamis, folyamaton belüli transportokon is fusson.

Mindkét platform átmegy ugyanazokon a vektorokon, ami egy laptopon, egyetlen telefon párosítása nélkül bizonyítja, hogy a két oldal ugyanazt küldi a dróton. A felderítést, a munkameneteket, a játékokat és a relay-logikát mind unit teszteltük, mielőtt valódi rádió került volna a képbe, a közös, időbélyeges debuglog-formátumnak köszönhetően pedig a valós készülékes tesztek alatt egymás mellé tehettük az androidos és az iPhone-os logokat. A megközelítést a HyperBleKit is megörökölte: a tesztjei teljes egészében Bluetooth nélkül futnak.

Az Android és az iOS a kapcsolódás szinte minden lépésénél mást csinál

Ez bizonyult a projekt legnehezebb részének. Az Android kettévágja a hirdetését, így a scan response a fő csomag után érkezik meg, nem minden androidos készülék tud hostként hirdetni, a kapcsolat állapotát és az eszközök gyorsítótárazását pedig másként kezeli a két platform. Ami egy platformon belül működött, az a kettő között nem feltétlenül.

A módszerünk az volt, hogy korán egymás ellen teszteltük az Androidot és az iOS-t, minden felfedezett furcsaságot visszavezettünk a specifikációba, a transport réteget pedig azon az oldalon javítottuk, amelyik hibázott. A specifikáció így már a valós viselkedést tükrözi: a játékkód például az Android manufacturer data mezőjében utazik, az app pedig ellenőrzi, tud-e a készülék hirdetni, mielőtt felajánlaná a hostolást.

Egy platformok közötti interop review után megerősítettük az androidos transport eszköz-gyorsítótárazását és kapcsolatkezelését. A vegyes platformú munkamenetek ezután megbízhatóan felépültek, és stabilan meg is maradtak.

Az üzenetméret tervezési korlát, nem részletkérdés

A BLE-t kis csomagokra tervezték, egy játéknak viszont strukturált üzeneteket kell cserélnie, amelyek jóval nagyobbak lehetnek egyetlen csomagnál, különösen gazdagabb tartalomnál, például kártyagrafikánál vagy valós idejű frissítéseknél. Ezt egy protokollréteggel hidaltuk át, a valós idejű játékoknak pedig külön, a megbízható üzenetfolyamtól elválasztott valós idejű sávot építettünk.

Kis JSON-üzenetekkel és mérsékelt számú csatlakoztatott eszközzel az átviteli sebesség nemcsak körökre osztott, hanem egyszerűbb valós idejű játékokhoz is elég volt. A teljesítmény romlik, ahogy nőnek az üzenetek, és ahogy egyre több eszköz osztozik a host kapcsolatán, ezért az erre épülő játékoknál az üzenetméretet tervezési korlátként kell kezelni.

• —MTU-egyeztetés, darabolás és újraösszeállítás
• —Sorszámok és nyugtázás
• —Újraküldés és duplikátumszűrés
• —Külön valós idejű sáv a megbízható üzenetfolyam mellett

A játékosszám feljebb tolható, de a hardver szab neki határt

Csillag topológiában minden játékos a hosthoz kapcsolódik, egyetlen, GATT-szerverként működő telefon viszont csak korlátozott számú egyidejű kapcsolatot bír el. Ez a korlát a készülék Bluetooth-chipkészletétől függ, és ez a valódi akadály egy kis társaság és egy nagyobb csoport között.

Először a host BLE-kezelésének kapacitásán javítottunk, aztán szándékosan emeltük a játékoslimitet 5-ről 10-re, majd 16-ra, hogy megtaláljuk a töréspontot. Végül túlléptünk a csillagon egy relay-fával, amelyben a közbenső telefonok továbbítják a forgalmat a host helyett, így a hálózat tovább ágazhat, mint amennyit egyetlen rádió elbír.

A plafont valamennyire sikerült megemelni, de kemény felső határ így is maradt, és készülékenként más. A relay-fát Androidon megépítettük és hamis transportos tesztekkel teszteltük, majd iOS-re is portoltuk, de az iOS-es portot a sprint alatt nem buildeltük és nem ellenőriztük. Az SDK jelenleg legfeljebb 10 játékost ad meg korlátként.

Az újracsatlakozást és a hostváltást egy stabil eszközazonosító teszi lehetővé

A telefonok kiesnek a BLE-munkamenetekből. A kiesett játékosnak ugyanarra a helyre kell visszakerülnie, a munkamenetnek pedig túl kell élnie, ha a host kilép vagy eltűnik, ami azt is jelenti, hogy a többi telefonnak meg kell találnia az új hostot. Tovább bonyolítja a helyzetet, hogy az iOS rotálja a készülék Bluetooth-címét, vagyis az eszközöket nem lehet a címük alapján felismerni.

Az újracsatlakozást és a hostmigrációt előbb a README-ben specifikáltuk, és csak utána implementáltuk, a két platformon szinkronban. Minden játékost egy stabil, véletlenszerűen generált eszközazonosító azonosít, az újracsatlakozás pedig játékkóddal történik. Ez az azonosító tette lehetővé, hogy a játékos visszakerüljön a helyére, és hogy a munkamenetet egy másik telefon vegye át. Mindkét képesség a HyperBleKit alapfunkciója lett.

Mit bizonyított a sprint, és mit nem

A sprint megválaszolta azt a kérdést, amelyre terveztük: megvalósítható az offline multiplayer Android és iOS között, kizárólag BLE-n. A platformok közötti kommunikáció működik, az átviteli sebesség pedig körökre osztott és egyszerűbb valós idejű játékokhoz elég, amíg az üzenetek tömörek maradnak. A fő korlát az egyszerre csatlakoztatott eszközök száma, amely feljebb tolható, de nem szüntethető meg.

A munkát a HyperBleKitben összegeztük: ez egy nyílt forráskódú SDK Androidra és iOS-re, amely elválasztja a BLE-hálózatkezelést az alkalmazáslogikától. Jelenleg a 0.1.0-s verziónál tart: mindkét platformon unit tesztekkel lefedett, de csomagolt formájában valódi telefonokon még nem teszteltük.