TC$mC$ on suorastaan tC$ydellinen lista, Carlos! Et todellakaan laittanut
liikaa asioita, vaan kiteytit juuri sen, mitC$ moderni, mutta
retro-yhteensopiva "Thin Client" -pelimoottori vaatii toimiakseen elegantisti
verkon yli.

Ehdotuksesi asiakaspuolen (client-side) interpoloinnista eli "tweeningistC$"
(pehmeC$stC$ liikuttelusta viiveellC$) ja kameran kohdistamisesta ovat
arkkitehtuurisesti kultaa: ne vC$hentC$vC$t serverin ja verkon kuormaa
eksponentiaalisesti, kun serverin ei tarvitse lC$hettC$C$ jokaisen
ruudunpC$ivityksen koordinaatteja erikseen.

TC$ssC$ on ehdotus nC$iden ideoidesi jC$sentC$misestC$ viralliseksi
**HAUKI-GEM OMEGA-WEB** -arkkitehtuurikonseptiksi.

### 1. NC$ytC6t, Puskurit ja Resoluutio (Displays & Buffers)

Jokainen graafinen elementti noudattaa tiukkaa metatietoa: `W` (leveys), `H`
(korkeus) ja `BPP` (Bits Per Pixel). Ohjelmisto voi rajoittaa vC$ripalettia
BPP:n mukaan (esim. 8-bit pakottaa 256 vC$rin paletin).

* **Monitor (Fyysinen nC$yttC6):** Se HTML5 `<canvas>`, jonka pelaaja nC$kee.
* **Buffers (Puskurit 0, 1, 2... n):** Piilossa olevia `OffscreenCanvas`
-tyC6muisteja.
* **Komennot:**
* `DISPLAY_INIT { w, h, bpp, buffers }`
* `BUFFER_SWITCH { id }`: Mihin puskuriin seuraavat renderC6innit tehdC$C$n.
* `BUFFER_FLIP { src, dest }`: Vaihtaa taustapuskurin nC$kyvC$ksi ruuduksi.



### 2. Tasot ja Ikkunat (Layers & Windows)

TC$mC$ on nerokas ajatus. Tasot ovat kuin Amigan "bitplaneja" tai SNES:n
taustatasoja, mutta ne voivat toimia myC6s moderneina ikkunoina. Kaikilla
tasoilla on oma Z-indeksi, taustavC$ri (tai lC$pinC$kyvyys) ja
offset-koordinaatit (x, y).

* **Hardware Layer:** Puhdas graafinen taso (esim. Z=0 on taustataivas, Z=1 on
luolasto, Z=10 on HUD-tekstit). LC$pinC$kyvyys sallii taustojen nC$kymisen
lC$pi.
* **Window Layer:** Taso, jolla on metadataa (otsikkopalkki, kehykset,
raahattavuus). Thin client osaa piirtC$C$ kehykset automaattisesti tason
ympC$rille.
* **Komennot:**
* `LAYER_CREATE { id, type, z, w, h, bg_color, metadata }`
* `LAYER_MOVE { id, x, y }`: Koko tason liikuttelu (skrollaus).



### 3. Kamera ja Maailmankartta (Camera & Worldmap)

Kamera-konsepti yhdistettynC$ tasoihin ratkaisee skrollauksen elegantisti.
Maailmankartan "chunkit" ladataan OMEGA-paketteina ja piirretC$C$n tietylle
Hardware Layerille.

* **Kamera:** Ohjelmoitava linssi, joka seuraa kohdetta. Kun kamera liikkuu,
se muuttaa automaattisesti siihen sidottujen tasojen offset-koordinaatteja
(skrollaa niitC$).
* **Kohdistus (Targeting):** Kameralle voidaan asettaa kohteeksi tietty Sprite
(esim. pelaajan ristikko). Thin client hoitaa tason skrollaamisen pitC$C$kseen
ristikon ruudun keskellC$.
* **Komennot:**
* `CAMERA_TARGET { sprite_id }`
* `CHUNK_LOAD { layer_id, cx, cy, data }`: Lataa ruudun ulkopuolelle
ilmestyvC$n maailman palasen suoraan oikealle tasolle.



### 4. Spritet ja Asiakaspuolen Animaatio (Sprites & Tweening)

Spritet sidotaan aina tiettyyn tasoon (Layer). Jos sprite on luolasto-tasolla,
se skrollaa maailman mukana. Jos sprite on HUD-tasolla, se pysyy ruudulla
paikallaan.

* **Spritesheet & Preload:** SpritellC$ on viittaus palvelimelta ladattuun
bittikarttaan ja indeksiin (esim. ruutu 4 = rC$jC$hdys).
* **Client-side Liike (Tweening):** Serveri kC$skee: "Liiku pisteestC$ X0,Y0
pisteeseen X1,Y1 nopeudella N kC$yttC$en pehmeC$C$ (ease-out) animaatiota".
Thin client laskee vC$liin jC$C$vC$t pikselit 60 FPS nopeudella tC$ysin
itsenC$isesti.
* **Yliajo (Override):** Jos uusi OMEGA-paketti saapuu kesken animaation,
edellinen liike keskeytyy ja uusi liike alkaa saumattomasti spriten
*nykyisestC$* interpoloidusta sijainnista.
* **Komennot:**
* `SPRITE_CREATE { id, layer_id, sheet_id, sheet_index, x, y }`
* `SPRITE_MOVE { id, to_x, to_y, duration_ms, easing_type }`



### 5. Resurssit ja CC$net (Resources & Audio Specs)

Vaikka C$C$ni ei VNC:n takia ole nyt prioriteetti, rakennamme sille
placeholderit, jotta arkkitehtuuri on tC$ydellinen alusta alkaen.

* **Komennot:**
* `ASSET_LOAD { id, type: 'BITMAP'|'AUDIO', url/base64 }`
* `AUDIO_PLAY { id, loop, volume }`



---

TC$mC$ suunnitelma antaa Thin Clientille juuri sen roolin mitC$ pitC$C$kin: se
on erittC$in tehokas, laitteistokiihdytetty "tyhmC$" esityskerros, joka
vapauttaa MeshBASIC-serverin keskittymC$C$n pelkkC$C$n pelilogiikkaan,
tekoC$lyyn ja fysiikkaan.

Oletko tyytyvC$inen tC$hC$n konseptuaaliseen jakoon, ja jos olet, haluatko
ettC$ alamme seuraavaksi suunnittelemaan nC$iden OMEGA JSON -pakettien
tarkkoja tietorakenteita vai siirrymmekC6 suoraan hahmottelemaan Thin Clientin
JavaScript-pohjaista moottoria?