Files
devarea/ECOSYSTEM_PLAN.md
T
mr.zeroandClaude Opus 5 e8dc2d1f40 Record the store registry
A new store is a database row on the site now, not a release of the client: the
`Store` model and the public /api/stores endpoint live in the host app, and the
Electron client reads them.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-18 13:14:06 +02:00

12 KiB

TTG ökoszisztéma — mink van, mi kell még

Készült 2026-08-15-én, a 2026-08-15-i org-átszervezés utáni állapotra (lásd REPO_REFACT.md).

A cél: a TTG megoldásai együtt egy teljes játékfejlesztési ciklust fedjenek le — ötlettől a kiadáson át a kiadás utáni életig —, és minden fázisban kézzelfogható eszközt adjanak, ne csak dokumentációt.

A mérce a saját folyamatunk, a wiki PDLC oldala: Preparation → Development → Release → Post-launch. Az alábbi táblázat ezt veti össze azzal, hogy melyik fázisban van tényleg futtatható eszközünk.

PDLC fázis Fedő org Eszköz?
Preparation / Concept ✗ csak wiki-oldalak
Preparation / Admin tools (devarea) ~ részben, Redmine külső
Development / Infrastructure build, internal ✓ erős
Development / Implementation engines, demos ✓ erős
Release / Distribution services, tools ✓ web + Batocera
Release / Release party services (botok), bbs
Post-launch ✗ letöltésszámláláson túl semmi

A két véglet: a fejlesztés és a build fázis kiválóan ellátott, a ciklus két vége — a koncepció-fázis és a kiadás utáni visszacsatolás — viszont eszköz nélkül áll.


engines — a fejlesztés alapjai

Van: warp_engine (Rails engine: katalógus, publikáló API, ActiveAdmin), rubbs (Telnet BBS keretrendszer), inkwell (Go point'n'click DSL), gorpg (Ebitengine RPG motor).

Erősség: a warp_engine valódi termék — mountolható, konfigurálható, saját tárolóadapterrel és CI-hívható publikáló felülettel. A warp-engine-batocera-store szétválasztása megmutatta, hogy a köré épülő eszközök is általánosíthatók.

Kiadva (2026-08-16):

  • inkwell v0.1.0 — modulnév git.teletypegames.org/engines/inkwell, go get-tel lehívható. A demos/inkwell-demo már a kiadott verziót használja, replace direktíva nélkül; ez javította a demó CI-jét is, ami a testvérkönyvtárat váró replace miatt bukott.

  • gorpg v0.1.0 — a modulneve module game volt, vagyis semmilyen néven nem lehetett rá hivatkozni; most git.teletypegames.org/engines/gorpg.

  • warp_engine 0.2.0 gem — fent van az engines rubygems registryben (https://git.teletypegames.org/api/packages/engines/rubygems), Bundlerrel feloldható. A publikáló pipeline megvolt a monorepóban, csak sosem futott le; három elavult org-hivatkozást és egy hitelesítési hibát kellett javítani benne.

Hiányzik:

  • Nincs audio- és bemenetkezelő könyvtár. A grafikai/narratív oldal le van fedve, a hang és a gamepad-absztrakció minden játékban újraíródik.

build — a CI gerinc

Van: hét toolchain repo (bevy-, c64-, ebitengine-, godot-, love-, phaser-, tic80-tools), mind közös Makefile-mintára; hozzájuk hét builder image az internal registryben; a pipeline-t a warp_engine config-extension szolgáltatása szolgálja ki központilag, tehát egy image-bump egy sor a services/teletypegames inicializálójában.

Erősség: ez a legérettebb részünk. Hét platform, egységes minta, központi konfiguráció — egy új játék .woodpecker.yaml-ja egyetlen sor (platform: ebitengine).

Hiányzik:

  • A WarpEngine pipelines táblája hiányos. A Woodpecker 19 repót ismer és mind aktív, a /api/ci/pipelines viszont csak 10-et mutat, elavult tulajdonossal. A tábla a felület, amin a CI állapotát nézzük, tehát félrevezet — a valóság a woodpecker-cli repo ls.
  • Négy build nem zöld (2026-08-16): a bevy-demo a bevy-builder image miatt (a Dockerfile-ban ott a pkg-config, a publikált image-ben nincs — újra kell építeni), a bombexpert az ldoc miatt (a Lua forrás dokumentációs kommentjei nem értelmezhetők), a trickster-tiles pedig azért, mert a phaser pipeline src/*.js-t ellenőriz egy TypeScript projektben (javítva a sablonban, deploy után él).
  • Kétféle fájlnév él egymás mellett: .woodpecker.yaml és .woodpecker.yml (impostor, mranderson). Apróság, de a keresést és a sablonozást megnehezíti.
  • Nincs kiadás-előtti ellenőrzés. A pipeline buildel és publikál, de nem futtat tesztet, lintet vagy méretkorlát-ellenőrzést.

games és demos — a tartalom

Van: 11 játék és 6 platformdemó. A katalógusban 15 bejegyzés: 5 released, 2 archived, 2 development, 6 demo.

Platform-lefedettség:

Platform Toolchain Builder image Demó Kiadott játék Aktív CI
c64 ✓ (c64-demo) 3
tic80 2 (+2 archivált)
ebitengine ✓✓ 1
godot ✓ (pong)
phaser — (1 fejlesztés alatt)
bevy ⚠ builder image elavult
love

Hiányzik:

  • Négy platformon nincs kiadott játék (godot, phaser, bevy, love). A teljes eszközlánc kiépült alattuk, de nem bizonyítja semmi.
  • A demók nem sablonok. Mindegyik önálló repo, de nincs belőlük create-from-template mintarepo, se scaffolding parancs. Új játék indítása ma másolás-beillesztés.
  • nyuller, realworld, c64-demo-cpp: se CI, se katalógus, se wiki-oldal. Elakadt vagy félbehagyott munkák — érdemes eldönteni, hogy élnek-e.
  • Névütközés: a katalógus szoftvernevei és a repo-nevek eltérnek (bevydemo/bevy-demo, love2ddemo/love-demo), és két külön c64 demó fut hasonló néven (c64demo és c64-demo).

services — ami a szervereinken fut

Van: teletypegames (a publikus oldal monorepója: Rails katalógus-API + Vue SPA), statusbot és updater (Discord), social-updater (YouTube → Facebook/LinkedIn), blog-writer (wiki → Gemini → blog), redmine-tree.

Erősség: a kiadás utáni kommunikáció automatizált — új build, közösségi poszt, blogbejegyzés mind gépi úton megy.

Hiányzik:

  • Nincs visszacsatolás a játékostól. A warp_engine letöltést számol, de nincs értékelés, komment, hibabejelentő vagy telemetria. A PDLC „Post-launch" fázisa gyakorlatilag eszköztelen.
  • Nincs hírlevél vagy követés. Aki egyszer letöltött egy játékot, nem értesül a következő kiadásról.
  • A statusbot Pascalban, a többi Go/Python/Ruby — négy nyelv négy bothoz, közös keretrendszer nélkül.

stores — a katalógus a gazdaplatform könyvtárformátumában

Van: warpstore (a közös mag, az engines alatt) + három motor és a rájuk épülő három store-unk: warp-engine-batocera-store / ttg-batocera-store (EmulationStation, ROM-mappák, gamelist.xml), warp-engine-retroarch-store / ttg-retroarch-store (RetroArch .lpl playlistek, borítóképek) és warp-engine-desktop-store / ttg-desktop-store (az OS saját alkalmazás-menüje: .desktop, .app, Start menü). 2026-08-18-ig a tools orgban voltak.

Erősség: a Batocera store a mintapélda arra, hogyan válik egy belső eszközből általánosan használható termék — bárki felhúzhat saját store-t a saját katalógusára. A második motor ezt igazolta: a közös rész kiemelése után egy új gazdaplatform egy adapter plusz egy konfiguráció, nem új program.

Grafikus kliens és store-registry (2026-08-18): stores/warp-engine-desktop-gui Electron-ablak a desktop store CLI fölé, és hozzá a services/teletypegames-ben egy Store modell + publikus GET /api/stores végpont ActiveAdminnel. A kliens innen kérdezi, milyen store-ok vannak — tehát egy új store egy adatbázissor, nem egy app-kiadás. Szándékosan a host appban van, nem a WarpEngine-ben: a motor egy katalógust szolgál ki, és nem tudja, ki ad rá store-t.

Hiányzik:

  • A html csak online megy. Az asztali store menü-bejegyzést ad hozzá, de az a kiszolgált oldalt nyitja meg, mert a html asset nem letölthető archívum. Offline webes játékhoz a warp_engine-nek zip-ben is publikálnia kellene.
  • Windowson és Linuxon senki nem próbálta még az asztali store-t valódi gépen.
  • A demók nélkül az asztali store négy címet vinne, ezért ott be vannak kapcsolva; a cartridge-store-okon ez a döntés semmit nem változtat (nincs demo státuszú cartridge).

tools — amit az ember magának telepít

Van: ttg-marketplace (Claude plugin marketplace), devarea (workspace-kezelés), tic80-draw-image (vendorolt).

Hiányzik:

  • Nincs projekt-scaffolder. A devarea a workspace-t kezeli, de nincs ttg new game --platform godot jellegű parancs, ami a demót, a Makefile-t, a .woodpecker.yaml-t és a Redmine-projektet együtt felhúzza. Ez az egyetlen eszköz, ami a build és a games közti szakadékot áthidalná.
  • Nincs helyi fejlesztői környezet dobozolva. A builder image-ek CI-re valók; lokálisan mindenki maga rakja össze a toolchaint.

bbs — a közösségi felület

Van: bbs-server (a rubbs-ra épülő Telnet BBS), sermo-bbs (SERMO-DOS showcase), impostor-bbs (a Neumatronic Universe 1.5-ös „játéka").

Erősség: ez a márkánk egyedi arca — retró csatorna, ami egyben a rubbs referenciamegvalósítása és NU-tartalom is.

Hiányzik:

  • A BBS nincs összekötve a katalógussal. Nem lehet rajta böngészni vagy letölteni a játékainkat, pedig a warp_engine API pont ezt adná — a warp-engine-batocera-store mintájára egy „BBS store" modul kézenfekvő lenne.

infra — az üzemeltetés

Van: nginx-conf, backup-scripts, wiki-pages (Grav wiki + fetcher + BBS front-end).

Hiányzik:

  • Nincs verziózott deploy. A nginx-conf és a backup szkriptek megvannak, de nincs infrastruktúra-leíró (Ansible/Terraform/Compose-gyűjtemény), amiből a teljes kiszolgáló újraépíthető.
  • Nincs a repóban monitorozás. Az Uptime Kuma külső szolgáltatás, a konfigurációja nincs verziózva.
  • Az internal org megmaradt a builder image-ek névtereként; a csomagok nem költöztek a repókkal. Amíg nincsenek újrapublikálva a build alá, ez a névtér nem szűnhet meg.

Ami a ciklusból teljesen hiányzik

Ez a három nem illeszthető egyetlen meglévő orgba sem — új org vagy új repo kellene hozzájuk.

1. Asset-készítés (assets). A wiki dokumentálja a LibreSprite-ot és a Pixeloramát, a tic80-draw-image vendorolt harmadik féltől — de saját asset-eszközünk nincs. Nincs paletta-készlet, sprite-konverter, tilemap-exportáló, hangkonverter. Minden platformnak más a formátuma, és ezt ma kézzel hidalja át mindenki. Ez a legnagyobb egybefüggő hiány a láncban.

2. Koncepció-fázis (design). A PDLC szerint itt dől el a sztori, a műfaj és a technológia. Van hozzá wiki (Neumatronic Universe, paper-sketch), de nulla eszköz: nincs game design dokumentum-sablon, nincs a technológiaválasztást segítő döntési segédlet (pedig hét platformunk van, és a választás következményeit a /builds mátrix már ismeri).

3. Post-launch. Nincs analitika, visszajelzés-gyűjtés, patch-folyamat vagy játékos-kommunikáció. A warp_engine letöltés-statisztikája az egyetlen adatunk arról, mi történik a kiadás után.


Javasolt sorrend

Hatás szerint, nem nehézség szerint.

  1. A négy nem zöld build rendbetétele, és a WarpEngine pipeline-szinkron lefuttatása, hogy a /api/ci/pipelines a valóságot mutassa. A demók bekötve vannak — a korábbi feltevés, hogy hiányoznak, a hiányos táblából jött.
  2. Projekt-scaffolder a tools orgba. A build és a games közti kézi lépéseket szünteti meg, és a demókat sablonná lépteti elő.
  3. assets org és az első konverter. A leghosszabb út, de a legnagyobb napi megtakarítás.
  4. Csomagpublikáláskész (2026-08-16): inkwell v0.1.0, gorpg v0.1.0 és a warp_engine 0.2.0 gem kiadva, mindhárom külső projektből ellenőrizve.
  5. Kiadott játék a godot / phaser / bevy / love platformra. Négy kiépített lánc várja, hogy bizonyítson.
  6. Post-launch visszacsatolás — értékelés vagy hibabejelentés a katalógusban, warp_engine bővítésként, hogy minden WarpEngine-es oldal megkapja.