devarea/MORE_STORES.md

Milyen további store-okat érdemes csinálni

Készült 2026-08-16-án, a warp-engine-batocera-store szétválasztása után. A kérdés: a batocera-store mintájára milyen más gazdaplatformra tudnánk store-t adni.

A mérés, ami átrendezi a kérdést

A katalógus legfrissebb kiadásaiban (15 szoftver) ennyi asset van (2026-08-17-i mérés):

Asset	Hány szoftvernél	Ki használja ma
html	11	senki — a publikus oldal lejátssza, de nincs könyvtár
win_x64	9	senki
linux_x64	9	senki
linux_arm64	1	a batocera-store (arch-illesztéssel)
cartridge	7	a batocera-store
win_x86	4	senki
mac_x64	3	senki
docs / source	3 / 3	a publikus oldal
mac_universal	2	senki

Platformonként:

Platform	Elérhető assetek
c64	cartridge (4)
tic80	cartridge, html, source, docs, win_x64, linux_x64, mac_x64 (3)
ebitengine	html, win_x86, win_x64, linux_x64 (3)
godot	html, win_x86, win_x64, linux_x64, mac_universal (1)
love	html, win_x64, linux_x64, mac_universal (1)
phaser	html (2)
bevy	html (1)

A tanulság: a batocera-store csak a cartridge-et fogyasztja, tehát a katalógus 7/15 részét. A legelterjedtebb asset-fajtánk, a webes build, egyetlen store-ban sem szerepel. Nem az a szűk keresztmetszet, hogy kevés store van — hanem hogy a meglévő a katalógus felét ott hagyja.

---

0. Előfeltétel mindenhez: ARM Linux buildek — kész

(2026-08-16-án megoldva; az alábbi indoklás megmaradt, mert a 3. és 4. pont erre épül.)

Akkori állapot: a build-mátrixunkban nem volt Linux ARM asset. A ReleaseAsset::KINDS ezt tartalmazza:

cartridge source html docs
win_x86 win_x64 linux_x86 linux_x64
mac_x64 mac_arm64 mac_universal

Van mac_arm64, de linux_arm64 és linux_armhf nincs — a linux_x86 pedig szerepel a listán, csak épp semmi nem gyárt bele.

Ez azért döntő, mert a Batocera nem csak x86_64-en fut: Raspberry Pi-n, Odroidon és a kézikonzolokon ARM-on megy. Egy linux_x64 bináris ezeken feltelepül, de nem indul el — ami rosszabb, mint ha nem is ajánlanánk fel. Ugyanez blokkolja az 1. pont legérdekesebb célpontjait: a muOS, ArkOS és JELOS kézikonzolok szinte mind ARM-osak.

Amiért a mai store hordozható: a cartridge architektúra-független (adat egy emulátornak), ezért mind a 7 cím megy minden Batocera gépen.

Teendő, sorrendben:

1. linux_arm64 (és ha kell, linux_armhf) felvétele a KINDS-be és a platformok ci_platforms mátrixába.
2. Cross-build a pipeline-okban. A legkönnyebb az ebitengine (Go: GOARCH=arm64), utána a bevy (Rust cross toolchain) és a godot (van ARM export template); a LÖVE a legnehezebb, ott ARM futtatókörnyezet kell.
3. A motor architektúra-felismerése (uname -m → x86_64 / aarch64 / armv7l), és csak az illeszkedő asset telepítése.

0b. linux_* → Batocera ports — kész

(2026-08-17-én megvalósítva a motorban.) A ROM-rendszerek mellett van egy második telepítési mód: install: "port" esetén a zip kicsomagolódik, és egy .sh indító kerül a Ports rendszerbe. A payload a ports/.data/<subfolder>/ alá megy — a pont rejti el az ES elől —, az indító pedig egy normál almappába, amit az ES ugyanúgy pásztáz, mint bármely más rendszerét.

Számokban, a mai assetekkel:

Gép	Lefedettség (mérve 2026-08-17)
x86_64 Batocera	13/15
ARM Batocera	9/15 — és nő, ahogy a repók újrafutnak az ARM pipeline-nal

A kimaradó kettő a phaserdemo és a trickster-tiles: mindkettő csak html-t ad, natív binárisuk nincs, tehát ezekhez böngésző kell — natív store soha nem fogja őket kiszolgálni.

Ugyanez a keret adja az interaktív ES-menüt is (ports bejegyzések gamelist-metaadattal).

---

Új store-ok, sorrendben

1. ES-családú store-ok

RetroPie, Recalbox, ES-DE, és a kézikonzolos disztrók (muOS, ArkOS, JELOS). Ugyanaz a gamelist.xml + ROM-mappa modell, amire a motor már generikus: gyakorlatilag paths.roms_root, rendszernév-leképezés és egy másik telepítő kell. A legtöbb elérés a legkevesebb munkáért. Az ES-DE Windowson és macOS-en is fut, tehát asztali elérést is ad mellékesen.

Fontos megkötés: a kézikonzolok jóformán mind ARM-osak, és a RetroPie is Pi-n fut. Cartridge-dzsel ezek azonnal kiszolgálhatók, natív játékkal viszont csak a 0. pont ARM buildjei után.

2. Asztali store — warp-engine-desktop-store

A per-OS zipeket telepíti egy helyi könyvtárba, és indítót csinál hozzá (.desktop, Start menü bejegyzés, .app). Ma 8 szoftvert szolgálna ki, és a CI-lefedettséggel nő. Ez a legnagyobb valóban új képesség: asztali gépre ma semmilyen utunk nincs.

3. Steam-könyvtár

A shortcuts.vdf-be írva a játékaink megjelennek a Steam könyvtárban borítóval — és ezzel a Steam Decken is. A letöltést a 2. pontról örökli, tehát ráépül, nem mellé megy. Bevált technika, a Heroic és a Lutris is ezt teszi.

4. RetroArch playlistek

.lpl JSON playlist platformonként. A cartridge-eket sokkal nagyobb közönségnek adja, mint a Batocera: Android, asztali gépek, konzolok. Kis formátum, kevés munka.

5. BBS store

A bbs/bbs-server-be, a saját rubbs-unkra épülve. Bármelyik asset-fajtát tudja adni letöltésként, és ez az egyetlen a listán, amit rajtunk kívül senki nem tudna lemásolni — márkaérték, nem csak elérés.

6. Csomagkezelők

Homebrew tap és Scoop bucket: brew install ttg/tap/rabbitroller. Kevés munka, és nem kell hozzá launchert írni; a 2. pont csomagolására épül.

7. Webes könyvtár / PWA

A html assetek megvannak, de ez van a legnagyobb átfedésben a mostani publikus oldallal, ezért a legkisebb határhasznú — annak ellenére, hogy ez a legelterjedtebb assetünk.

---

Amit nem javaslok

• itch.io — az az ő katalógusuk, nem a miénk; nem store-t adnánk, hanem feltöltenénk.
• Flatpak / Snap — nehéz átvezetés és felülvizsgálat kevés extra elérésért.
• Önálló Android APK — nagy munka; a RetroArch úton (4. pont) az android elérés majdnem ingyen megvan.

---

A minta

Mind ugyanaz a forma: olvasd a WarpEngine katalógust → írd a gazdaplatform saját könyvtárformátumát. A warp-engine-batocera-store szétválasztásával ezt már megalapoztuk. Ha a közös rész — katalógus-lekérés és gyorsítótár, kiadásválasztás (dev- kihagyás, asset-egyeztetés), state.json, borítókép, prune-védelem saját almappával — egy helyen marad, akkor egy új store valóban csak egy adapter plusz egy config.

Egy dolog viszont nem tartozik az adapterbe, hanem a közös részbe: az architektúra-illesztés. A gazdaplatform megmondja, milyen gépen fut (uname -m, Windows/macOS esetén a megfelelő megfelelője), és a motornak ehhez kell asset-fajtát választania. Ez a 0., 1. és 2. pontnak egyaránt kell, tehát egyszer, jó helyen érdemes megírni.

A javasolt sorrend

1. linux_arm64 a build-mátrixba — kész (2026-08-16). Az ebitengine és a bevy gyártja; a godot-hoz a játék repójában kell ARM export preset, a LÖVE-hoz nincs upstream ARM AppImage, a TIC-80 export parancsának meg nincs ARM célja. A bevydemo 1.0.0 már linux_arm64-et is ad.
2. Architektúra-illesztés a motorba — kész (2026-08-17). A kind és az ext lehet architektúra-leképezés * tartalékkal; a felismert arch látszik a list és a config kimenetében. aarch64-en végigpróbálva: az ARM csomagot tölti le, és a benne lévő bináris valóban AArch64.
3. linux_* → Batocera ports — kész (2026-08-17). install: "port"; aarch64-en végigpróbálva: telepítés, idempotens újraszinkron, eltávolítás a 106 MB-os payloaddal, és a névtér-védés is (idegen .data útra mutató bejegyzést elutasít). Hátra van: bekapcsolni a ttg-batocera-store configjában, és valódi gépen kipróbálni, hogy a natív játékok tényleg elindulnak-e.
4. ES-családú store-ok (1.) — a motor itt már majdnem kész.

Amit valódi gépen kell ellenőrizni

A 2. és 3. pont azon áll vagy bukik, hogy a per-OS zipjeink önmagukban futtathatók-e: van-e hiányzó függőség Linuxon, és mit szól hozzá a macOS aláírás-ellenőrzése egy nem jegyzett binárishoz. Erről a katalógus nem árulkodik, csak egy próba.