lab-core — jeden engine labowy, wiele języków

Prototyp: bazowa konsola + canvas jako wspólny rdzeń, a języki jako wymienne nakładki ("overlays") wpięte przez Lab Runtime Protocol (LRP) plus World Registry — wspólny świat GameObject/Component, który umożliwia interop między językami na poziomie publicznych pól i metod.

Wzorzec wzięty z java-lab (shared/lab-game-v2/contract.json) — tu protokół jest formalnie wydzielony i niezależny od języka.

cd C:\Nauka\lab-core
npm install
npm run dev        # http://127.0.0.1:5191

Warstwy

UI (main.ts)           — edytor, konsola, canvas, wybór języka
LabHost (core/host.ts)  — stdout/stderr, draw(), input, stdin, pętla gry
LRP (core/protocol.ts)  — DrawCmd, RunRequest, LabHost, LabRuntime
WorldRegistry           — handle GameObject/Component + get/set/invoke
  (core/world.ts)         marshalowane przez host (hub-and-spoke)
Renderer (core/engine.ts) — canvas 2D + InputTracker
Nakładki (src/runtimes/*) — po jednej na język

Nakładka nie dotyka DOM. Dostaje LabHost, tłumaczy natywne wywołania (print, lab.drawRect, cin >>…) na LRP i zwraca RunResult. Renderer/konsola/wejście/świat są współdzielone.

Kontrakt dla kodu ucznia (identyczny we wszystkich językach)

• print(...) → konsola; stdin czytane lab.input() / input().
• Gra: skrypt definiuje init() i/lub update(dt) — host odpala pętlę rAF, dt w sekundach z clamp 0.1 s (jak java-lab).
• Fasada lab.*: drawRect/Circle/Line/Text, clear, isKeyDown(code), isKeyPressed(code), width(), height().
• Interop: lab.spawn(name?), lab.attachComponent(obj, kind, impl), lab.getComponent(obj, kind), lab.findComponent(kind), lab.getProp(id, k), lab.setProp(id, k, v), lab.call(id, m, ...), lab.worldInfo(). Host tickuje update(dt) każdego komponentu co klatkę — niezależnie od języka, w którym został napisany.
• Most do silnika GameLab (engine/bridge.ts): przy żywym silniku spawn/attachComponent materializują się jako prawdziwe GameObject/Component — silnik tickuje ich update(dt) w fazie WORLD jak natywnych. lab.attachRenderer(obj, spec) dokłada Sprite/ShapeRenderer/TextRenderer i w razie potrzeby bootuje silnik (attachRenderer z Lua/Pythona samo odpala LAB·BOY). lab.setPosition/setTransform/getPosition sterują transformem. Konwencja: publiczne pola x/y komponentu napędzają transform GameObjectu automatycznie. spec: {type:'sprite'|'rect'|'circle'| 'text', texture,width,height,color,text,fontSize,layer,order,space}.
• Hierarchia (panel pod podglądem, jak Unity Hierarchy + Inspector): GameObject → komponenty → publiczne pola z wartościami na żywo i metody; węzły zwijane, badge pokazuje język komponentu.
• Project (lewy panel, jak Unity Project): pliki projektu pogrupowane w foldery (assets/… → sekcja Assets), foldery puste, nowy/usuń/zmień nazwę/★ plik startowy; sekcja "Assets silnika" z wbudowanymi assetami — klik wstawia lab.asset("klucz") do edytora.
• Edytor: Monaco (syntax highlight per-rozszerzenie, Ctrl+Enter=RUN, model per-plik z undo). Pliki specjalne mają własne edytory w centrum: .png → edytor pikseli (paleta, gumka, zapis = dataURL PNG + tekstura Sprite("nazwa.png") od razu w silniku), .sfx → synth SFX z suwakami (presety: Wybuch/Deszcz/Laser/Skok/Moneta/Uderzenie/Powerup/Alarm/ Wiatr/Splash), .song → sekwencer krokowy (siatka nut × kroki, BPM, akordy = kilka nut w kroku, loop).
• Dźwięk (this.sound.* w grze): playNote("C5"), playSong, playSfx(spec), playSeq(seq), playSound(nazwa) — nazwa rozwiązuje kolejno: plik projektu .sfx/.song (spec JSON) → uploadowany audio → fallback nuta.
• Playground: projekt = wiele plików. W JS/TS pliki nie-startowe doklejane są przed startowy (helpers → main), więc funkcje/klasy pomocnicze są widoczne w entry. lab.readFile(name) czyta pliki projektu (np. assets/palette.json), lab.asset/drawSprite używają wbudowanych tekstur z palety labów (player, coin…).
• Konsola (API jak RuntimeConsole z labów): linie > /⚠ /Błąd: , pill Czeka/Ładuję/Działa/Gotowe/Błąd; przyciski: kopiuj wynik (wzorzec CopyCodeButton), "Pokaż białe znaki" (· ⇥ ↵ jak ConsoleOutput z java-lab), wyczyść, zwijanie. console.log/info/ warn/error mapowane jak w labach — kod skopiowany z web-lab wypisuje się identycznie.

Interop w praktyce (zweryfikowane)

1. Wybierz Lua → "Interop: komponent Chaser" → RUN (rejestruje komponent z tabeli Lua: publiczne x, y, speed + metody setTarget, update).
2. Wybierz Python → "Interop: komponent Wanderer" → RUN.
3. Wybierz JavaScript → "Gra: interop" → RUN: kod JS iteruje lab.worldInfo(), czyta publiczne pola, woła metody — a host tickuje update(dt) napisane w Lua/Pythonie co klatkę. "Wyczyść świat" resetuje rejestr.

Wywołania są synchroniczne, bo JS/TS/Lua/Python żyją w jednym wątku. Dla WASM-runów (C++/Java) ta sama ścieżka działa przez eksport WASM lub jako async marshaling — interfejs ComponentBridge już toleruje Promise w invoke.

Status nakładek

Język	Runtime	Pobieranie	Stan
JavaScript	natywny (new Function)	0	działa: konsola + gra + interop
TypeScript	sucrase (strip types)	~1 MB	działa: gra
Lua	wasmoon (Lua 5.4→WASM)	~0.5 MB	działa: konsola + gra + interop
Luau (Roblox)	@luau-rs/luau (Luau 0.739→WASM)	~2 MB	działa: konsola + interop (sync)
Python	Pyodide (CPython→WASM, lazy CDN)	~10–30 MB	działa: konsola + gra + interop
C++	JSCPP (interpreter podzbioru)	~0.5 MB	działa: konsola + interop (lab.h, sync)
C#	@wasmsharp/core (.NET WASM + Roslyn)	~41 MB lazy	działa: konsola + interop (LabBridge.dll, sync)
Java	TeaVM 0.16 (javac+backend WASM w workerze)	~10 MB lazy	działa: konsola + gra + interop (sync)

여기까지가 README 앞부분입니다. 나머지는 원문에서 읽을 수 있습니다. README 전문 보기 ↗