TC$mC$ on loistava loikka pelillistC$miseen ja kilpailullisen ohjelmoinnin
(kuten *Core War* tai robottiohjelmointikisat) suuntaan! Kun simulaation
moottori voidaan toteuttaa millC$ tahansa kielellC$ (kunhan se kC$C$ntyy tai
toimii Node.js- tai selainympC$ristC6ssC$ WebAssemblyllC$ tai
JavaScriptillC$), luomme samalla alustan erC$C$nlaiselle "metakielelliselle"
optimointikilpailulle.

TC$mC$ ratkaisee yhden simulaatiopelien suurimmista haasteista: laskennan
raskauden. Jos joku kirjoittaa moottorinsa raa'alla WebAssemblyllC$ (C/C++ tai
Rust kautta) ja toinen optimoidulla JavaScriptillC$, he kilpailevat siitC$,
kenen virtuaalimaailma pyC6rii sulavimmin.

ViedC$C$n tC$tC$ ajatusta eteenpC$in pelisC$C$nnC6iksi ja arkkitehtuuriksi.
MiltC$ tC$llainen "Open Engine / Strict Code" -kilpailumuoto voisi nC$yttC$C$
kC$ytC$nnC6ssC$?

### 1. Kilpailun sC$C$nnC6t: Sandbox & Open Engine

* **Avoimen moottorin sC$C$ntC6 (The Engine Rule):**
* Kilpailijat (tai pelaajat) saavat vapaasti toteuttaa pelimoottorin
(fysiikka, lC$mpC6, sC$teily, tC6rmC$ykset) millC$ tahansa ohjelmoinnin
kielellC$, kunhan se paketoituna pyC6rii Node.js-taustapalvelimella tai
selaimessa (esim. JS-moduulina tai WASM-binC$C$rinC$).
* Moottorin tehtC$vC$nC$ on vain lukea standardoitu YAML/JSON-kenttC$,
pyC6rittC$C$ simulaatiota mC$C$ritetyn vuoromC$C$rC$n (tick) mukaan ja
palauttaa lopputulos tai animaatio.


* **Tiukka tavurajoitus (The Payload Rule):**
* Vaikka moottorin saisi kirjoittaa millC$ tahansa tyC6kaluilla, varsinainen
pelikentC$lle pudotettavan organismin tai solukon koodi on ankaraa
"koodigolfia". Esimerkiksi jokaisen solun ohjelmakoodi on maksimissaan se **10
tavua/merkki**, tai koko organismin YAML-malli saa viedC$ vain tietyn pienen
maksimitavumC$C$rC$n (esim. 256 tavua).
* TC$mC$ pakottaa C$C$rimmC$iseen optimointiin ja esoteeristen komentojen
kC$yttC6C6n.



### 2. Miten eri kielimoottorit voisivat kohdata toisensa? (Standardi
rajapinta)

Jotta eri kielellC$ toteutetut moottorit voisivat kisata keskenC$C$n,
tarvitaan yhteinen rajapinta (API). Node/selainympC$ristC6ssC$ tC$mC$ on
helppo ratkaista JSON- tai Buffer-pohjaisilla sopimuksilla:

1. **Alustus (`init`):** Moottori ottaa sisC$C$n kentC$n koon, tC$hden
sijainnin ja YAML/JSON-tiedoston, joka sisC$ltC$C$ symbolien sC$C$nnC6t ja
aloituskuviot.
2. **Askel (`tick`):** Yksi pelikierros laskee valon sC$teilyn, lC$mmC6n
siirtymisen johtavuuden kautta, kineettisen paineen ja solujen 10 merkin
koodin suorituksen.
3. **Tila (`getState`):** Moottori palauttaa ruudukon tilan (ASCII-merkit, 8.
bitin elossa/kuollut -tilat, lC$mpC6kartat ja sC$teilytasot) renderC6ijC$lle.

### 3. Ekosysteemin metatasot: MitC$ tC$stC$ seuraisi?

TC$llainen konsepti synnyttC$isi uskomattoman kiehtovia yhteisC6llisiC$
ilmiC6itC$:

* **Optimaalisten moottorien meta:** Pelaajat eivC$t optimoisi vain
organismejaan, vaan myC6s simulaatiomoottoriaan. Syntyisi "turbo-moottoreita",
jotka hyC6dyntC$vC$t rinnakkaislaskentaa (esim. Web Workers tai
monisC$ikeisyys Node.js:ssC$), jotta simulaatio voidaan ajaa miljoona sykliC$
sekunnissa.
* **Kielen valinnan taktiikka:** Joku voisi kokeilla tekoC$lypohjaista
moottoria, toinen puhtaan funktionaalista lC$hestymistapaa, ja nC$hdC$,
millainen digitaalinen ekos#2stemi kyseisellC$ fysiikan tulkinnalla syntyy
(koska eri kielten pyC6ristysvirheet tai laskentatarkkuudet saattaisivat
johtua pienistC$ eroista deterministisessC$ kaaoksessa!).

Haluatko, ettC$ hahmotellaan tC$lle arkkitehtuurille simppeli rajapinta (esim.
miltC$ moottorin JavaScript/TypeScript-kontrakti nC$yttC$isi), vai haluatko
miettiC$ lisC$C$ itse kilpailumuotoa tai turnaussC$C$ntC6jC$?