Files
devarea/ECOSYSTEM_PLAN.md
T
mr.zeroandClaude Opus 5 30e9a5a6e2 Close the desktop store item, and fix a check that had started lying
MORE_STORES item 2 is done: stores/warp-engine-desktop-store and
stores/ttg-desktop-store. The write-up records what the implementation changed
about the plan — chiefly that the `html` asset is not a downloadable archive but a
hosted directory, so a browser title becomes a menu entry that opens its page
rather than an offline install.

Separately: `check-repos.sh` reported `infra/wiki-pages` as STALE while the repo
was plainly there. Gitea caps a page at 50 items whatever `--limit` says, so
`tea repo list --limit 1000` had been quietly returning the first 50 — invisible
until today, when the estate reached 51 repos. The check now pages through, and
fails loudly if the server returns nothing at all rather than declaring the whole
workspace stale.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-18 10:00:41 +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.

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.