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.

2026-08-18: újramérés a doksi végén. Két store és a kiemelt közös mag után a kérdés újra feltéve — új jelöltekkel (Pegasus, Lutris), egy korrekcióval (az ES-DE nem drop-in, a Steam alá van becsülve), és egy méréssel, ami az egész listát átrendezi: a katalógus 8/15-e demo vagy development, tehát a store-ok ma 7 címet látnak. Az alábbi lefedettségi számok a demókat is beszámolják.

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

(A 2026-08-18-i szakasz ezt pontosítja: az ES-DE nem drop-in — máshonnan olvassa a gamelisteket, mint ahová a Batocera-adapter ír.)

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.

Kész (2026-08-18). stores/warp-engine-desktop-store + stores/ttg-desktop-store. Két telepítési mód: app (a per-OS zip kicsomagolva, menü-bejegyzéssel) és web (a kiszolgált böngészős build oldalát megnyitó bejegyzés) — utóbbi azért, mert a html asset nem letölthető archívum, hanem egy kiszolgált könyvtár. A kettő visszaesési sorrendben van, ezért egy natív build nélküli cím is bekerül a menübe: gépenként 10 cím (a demókkal). macOS-en végigmérve és a játékok valóban elindítva; Linux és Windows valódi gépen még nincs kipróbálva.

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.

Kész (2026-08-17). Terv és mérések: RETROARCH_STORE.md. Három repó: engines/warpstore (a kiemelt közös mag), stores/warp-engine-retroarch-store (motor), stores/ttg-retroarch-store (a mi store-unk). A Batocera-motor ugyanabban a körben átült a közös magra. Hátra van: valódi gépen kipróbálni, hogy a VICE-mag magától indítja-e a .prg-t, és hogy az Android adb push útvonalai állnak-e. Ott mérve: mind a két mag (vice_x64, tic80) elérhető minden célon, Androidon is; a playlist-könyvtár nem feltétlenül a RetroArch alapkönyvtárában van, tehát a retroarch.cfg kötelező olvasmány; a borító csak PNG lehet, amin az impostor GIF-je ma elhasal; leírást a .lpl nem tud. A motor egyetlen valódi új képessége az út-átírás (stage_root / target_prefix), ami az Androidot és a 2. pont asztali store-ját egyszerre szolgálja.

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

(2026-08-18: levéve — a html-t az asztali store, a Pegasus és az ES-DE viszi el egy indítóval; lásd a doksi végét.)

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 közös rész 2026-08-17-én kiemelve: engines/warpstore, egyetlen fájl, amit mindkét motor a telepítéskor letölt. Benne a katalógus és gyorsítótára, a kiadásválasztás, a state.json, a borító-letöltés, az atomikus írás és a törlés-őr — plusz az architektúra-illesztés, ami a második adapter miatt resolve_for_host-tá bővült: nem csak az arch, hanem az os is kulcs lehet, mert egy libretro mag fájlneve OS-enként más. Egy új store innentől valóban egy adapter plusz egy config.

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. RetroArch playlistek — kész (2026-08-17), a közös mag kiemelésével együtt. Lásd RETROARCH_STORE.md. Hátra van: a VICE .prg-autostart és az Android-út valódi gépen.
5. ES-családú store-ok (1.) — a motor itt már majdnem kész, és a warpstore óta az adapter tényleg csak a gazdaplatform írása.

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.

---

Újramérés és új jelöltek — 2026-08-18

Két store és a kiemelt közös mag után újra feltéve a kérdés. A formátum-állítások alább vagy a gépen mérve, vagy a hivatkozott dokumentációból ellenőrizve vannak; ahol nem sikerült ellenőrizni, az külön ki van írva.

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

A doksi eddigi lefedettségi számai (13/15, 9/15) a demókat is beszámolják. A store-ok viszont alapból nem: mindkettő configjában catalog.statuses: ["released", "archived"]. A mai katalógus 15 bejegyzése így oszlik:

status	Darab	Store-ban látszik ma
released + archived	7	✔
demo	6	✘
development	2	✘

Ugyanaz a lefedettség a kétféle szűréssel:

Amit a gazdaplatform enni tud	Minden status	Csak released+archived
cartridge	7	6
html	11	4
bármilyen natív (win/linux/mac)	9	4
cartridge + natív	13	6
mindent, html-lel együtt	15	7

A tanulság: a szűk keresztmetszet ma nem a store-ok száma és nem is az asset-fajta, hanem az, hogy a katalógus 8/15-e demo vagy development. Egy harmadik store nulla új tartalmat ad — csak új gépeket.

És hogy a demo státusz melyik store-t érinti, az nem érzésre kitalálható, ezért kimérve (catalog.statuses bővítése mit ad):

Store-fajta	ma	+ "demo"	+ "development"
cartridge (Batocera ROM-út, RetroArch)	6	6 (+0)	7 (+c64-demo)
asztali, natív	4	9 (+5)	9 (+0)
asztali, natív vagy html	4	10 (+6)	11 (+trickster-tiles)

A meglévő két store-on tehát a demók engedélyezése semmit nem változtat: egyetlen cartridge-címünk sem demo. A 7. cartridge-cím a c64-demo, ami development — vagyis befejezetlen, azt épp nem akarjuk kiadni.

A demo kérdés ezért nem a mai store-ok kapcsolója, hanem az asztali store előfeltétele: demók nélkül az asztali store 4 címmel indulna, velük 10-tel. Ez dönti el, hogy megéri-e megírni. A REPO_REFACT.md szerint a demo státusz épp azt jelenti, hogy „nem önálló termék" — tehát terméki döntés, nem technikai.

Az html kérdése: nem webes könyvtár kell hozzá, hanem indító

A html a legelterjedtebb assetünk (11/15), és továbbra sincs fogyasztója. A 7. pont ezt „webes könyvtár / PWA"-ként vette fel, és ezért lett a legkisebb határhasznú. A mérések szerint viszont máshol van a válasz.

Batocerán nincs. Ellenőrizve: a BUA böngésző-bejegyzései Flatpak/AppImage alapúak, a Batocera Flatpak-támogatása pedig dokumentáltan x86_64-only — ARM-on, tehát Pi-n és a kézikonzolokon, nincs böngésző. A html a Batocera-store számára zsákutca; ezt a ttg-batocera-store README-jében is érdemes kimondani, hogy más ne próbálja.

Asztali gépen viszont majdnem ingyen van, mert ott van böngésző. Amelyik gazdaplatform bármilyen parancsot el tud indítani, az a html-t is tudja:

Gazdaplatform	Mivel indítja a html-t	Ellenőrizve
Lutris	web runner (lutris/runners/web.py létezik)	✔ a forrásfában
Pegasus	per-game launch/command felülírás, tetszőleges parancs	✔ a dokumentációban
ES-DE	~/ES-DE/custom_systems/es_systems.xml, saját parancs	✔ a USERGUIDE-ban
asztali store (2. pont)	.desktop / .lnk / .app, ami xdg-open-t hív	—

Vagyis a html a 2. pont asztali store-jába tartozik egy második telepítési módként (ahogy Batocerán a port lett a rom mellé), nem egy külön webes store-ba. Ez a 7. pontot gyakorlatilag leveszi a listáról.

Új jelöltek, amik eddig nem voltak a listán

Pegasus Frontend — a legjobb új jelölt

Sima szöveges metadata.txt: collection + game blokkok, per-game launch/command felülírás, {file.path} behelyettesítéssel, developer, release, rating mezők. Windows, macOS, Linux, Raspberry Pi és Android — egy adapter, ami mind a három asset-fajtánkat viszi: cartridge (emulátort indít), natív (közvetlenül), html (böngészőt). A formátum egyszerűbb, mint a gamelist.xml, és nincs benne olyan csapda, mint a RetroArch bináris/PNG-kényszere.

ES-DE — de nem drop-in, ahogy az 1. pont sejteti

Az 1. pont az ES-családot egy tételként kezeli, „a motor már generikus" felkiáltással. A USERGUIDE ezt két ponton megcáfolja:

• A gamelisteket nem a ROM-mappából olvassa, hanem a központi ~/ES-DE/gamelists/ fából — a ROM-fában lévőket alapból figyelmen kívül hagyja. A mi Batocera-adapterünk pontosan oda ír, ahonnan az ES-DE nem olvas.
• A path tagben kötelező a ./ prefix (a mi merge-ünk szerencsére már így írja).

Cserébe többet ad, mint a Batocera: fut Linuxon, macOS-en, Windowson, Androidon, Haikun és Steam Decken, és custom_systems/es_systems.xml-ben saját rendszert lehet definiálni tetszőleges indító paranccsal — tehát nála is megvan a html-út. Az adapter tehát nem a Batocera-adapter újrahasznosítása, hanem egy testvére: ugyanaz a metaadat-formátum, más útmodell.

Lutris — egy Linux-asztali gépen elvileg 15/15

Ellenőrizve: a Lutris-installer lehet tisztán lokális YAML, weboldal nélkül (lutris -i /path/to/file.yaml), a kulcsok a gyökérben, minden más a script alatt, $SCRIPTDIR-rel relatív fájlokra. A runnerek között ott van a linux (natív), a web (böngésző) és a wine — vagyis egy Lutris-store a html-t, a Linux-natívot és akár a Windows-buildeket is fel tudja tenni ugyanabba a könyvtárba. Ez a legnagyobb elméleti lefedettség a listán.

A minta viszont más: nem mi írjuk a könyvtárformátumot, hanem generálunk egy telepítőt és meghívjuk a Lutrist. Kevesebb kontroll (a prune-hoz a Lutris saját adatbázisát kellene bántani), de a state.json-unk így is tudja, mit tettünk fel.

LaunchBox és Playnite — nem tudtam ellenőrizni

Mindkettő nagy Windows-közönség, és mindkettőnél elakadtam:

• LaunchBox: a játéklista Data/Platforms/<Platform>.xml-ben van, de a séma nincs dokumentálva (a közösség visszafejtette), és az alkalmazás maga is újraírja a fájlt. Egy valódi telepítés nélkül nem érdemes tervezni rá.
• Playnite: a hivatalos út egy C#/.NET library plugin, nem egy adatfájl — ez kilóg a „stdlib Python + egy fájl" mintánkból. A dokumentációt nem sikerült elérnem (403), tehát ez is nyitott kérdés.

Egyik sem javasolt a Pegasus és az ES-DE előtt.

Korrekció a meglévő listához: a Steam alá van becsülve

A 3. pont szerint „a letöltést a 2. pontról örökli, tehát ráépül" — a letöltést igen, a formátum viszont a listán a legkellemetlenebb:

• A shortcuts.vdf bináris VDF, nem szöveg: appid (4 bájt little-endian), AppName, Exe, StartDir, LaunchOptions.
• Az appid az exe és a név CRC32-jéből számolt érték, a legfelső bit beállítva — és ez az appid a borítóképek fájlneve is (userdata/<id>/config/grid/<appid>p.png).
• Ha a fájl hibás, a Steam indulás után törli; ha a felhasználó a Steam UI-ból vesz fel egy nem-Steam játékot, felülírja, amit írtunk. Írás után Steam-újraindítás kell.
• A userdata/<id> ág felhasználónként más, tehát felderítés is kell hozzá.

Bináris formátumot írni stdlib Pythonból megoldható, de ez nem „kevés munka", és egy elrontott fájl a felhasználó teljes nem-Steam listáját viszi. A 3. pont ezért a 2. pont után és önálló körben való, nem mellékesként.

Az újrarendezett sorrend

1. Döntés a demókról — 0 kód, de nem a mai store-okról szól: azokon nem változtat semmit (nincs demo státuszú cartridge-ünk). Az asztali store értelmét dönti el: 4 cím demók nélkül, 10 velük. Ezért ez a 2. pont előfeltétele, nem önálló nyereség.
2. Asztali store (2. pont) — változatlanul a legnagyobb valóban új képesség, most már azzal, hogy a html is bele tartozik egy második telepítési módként. Ez teszi elérhetővé a katalógus 15/15-ét (a demókkal együtt).
3. Pegasus — egy adapter, ami mind a három asset-fajtát viszi öt platformra, köztük Androidra, szöveges formátumban. A legjobb arány a listán.
4. ES-DE — ugyanaz a metaadat-formátum, más útmodell; desktop + Android + Steam Deck. Az 1. pont maradéka (RetroPie, Recalbox, kézikonzolok) ezután jön, mert azok a Batocera-adapterhez állnak közelebb.
5. Steam (3.) — a 2. pontra épül, de önálló körben, a bináris formátum miatt.
6. BBS store (5.) — változatlanul a márkaérték-tétel, nem elérés-tétel.
7. Csomagkezelők (6.) — a 2. pont csomagolására épül.
8. Webes könyvtár / PWA (7.) — levehető: a html-t a 2., 3. és 4. pont viszi el, ez pedig a publikus oldallal fedne át.

Amit valódi gépen kell ellenőrizni (bővítve)

A korábbi kettő (per-OS zipek önmagukban futtathatók-e; macOS-aláírás) mellé:

• Pegasus: elolvassa-e a generált metadata.txt-t Androidon is, és mit tesz a launch paranccsal ott (Android-on nincs shell úgy, ahogy asztalon).
• ES-DE: a ~/ES-DE/gamelists/ fába írt metaadat és a custom_systems együtt működik-e, illetve mit lát az ES-DE Android-kiadása.
• Lutris: a lutris -i fut-e fejetlenül (headless), vagy GUI-t nyit — ez dönti el, hogy egy szinkron automatizálható-e.
• LaunchBox / Playnite: van-e egyáltalán írható formátum. Egy telepítés megválaszolja; addig ne tervezzünk rájuk.