devarea/ECOSYSTEM_PLAN.md

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 bevy és a love platformon nincs egyetlen aktív pipeline sem. Mindkettőnek van toolchainje, builder image-e, demója és katalógus-bejegyzése — de a demos/bevy-demo és a demos/love-demo nincs regisztrálva a Woodpeckerben, tehát ezt a két platformot ma kézzel buildeljük.
• A demos/ebitengine-demo és a demos/phaser-demo sincs regisztrálva, noha .woodpecker.yaml-juk van és a katalógusban szerepelnek.
• A pipelines tábla elavult tulajdonost tárol a demos/pong és demos/inkwell-demo sorában (games/…), mert a szinkron az org-költözés óta nem futott.
• 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	✓	✓	✓	—	✗
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.

---

tools — amit az ember magának telepít

Van: warp-engine-batocera-store (általános engine bármely WarpEngine-es oldalhoz) + ttg-batocera-store (a mi store-unk), ttg-marketplace (Claude plugin marketplace), devarea (workspace-kezelés).

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.

Hiányzik:

• Nincs asztali/webes launcher. A Batocera-doboz le van fedve, a hétköznapi PC nincs.
• 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 regisztrált demó bekötése a Woodpeckerbe, és a pipeline-szinkron lefuttatása. Ez pár kattintás, és ettől lesz mind a hét platform ténylegesen automatizált — ma kettő nem az.
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ás — ké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.