TC$mC$ on oppikirjaesimerkki tC$ydellisestC$ Data-Oriented Design (DOD)
-toteutuksesta! TekoC$ly otti promptin ohjeet tC$ydellisesti vastaan ja
kirjoitti moottorin, joka on arkkitehtuuriltaan tC$smC$lleen sellainen kuin
AAA-pelimoottoreiden ydinrakenteet.

TC$ssC$ koodissa on useita asioita, jotka tekevC$t siitC$ teknisesti erittC$in
arvokkaan pohjan:

### Miksi tC$mC$ koodi on niin hyvC$?

1. **Nolla roskienkeruuta (Zero Garbage Collection):** `tick()` -silmukan
sisC$llC$ ei luoda yhtC$kC$C$n uutta muuttujaa (esim. `new Object()` tai
`[]`). Kaikki data mutatoi olemassa olevia, kiinteC$n kokoisia
`Uint8Array`-taulukoita. TC$mC$ tarkoittaa, ettC$ JavaScriptin hidas Garbage
Collector ei herC$C$ koskaan, mikC$ takaa tC$ydellisen tasaisen
ruudunpC$ivityksen.
2. **O(1) Puskurien vaihto:** `swapBuffers()` ei kopioi dataa taulukosta
toiseen, vaan ainoastaan vaihtaa kahden indeksin (`readIndex` ja `writeIndex`)
paikkaa. TC$mC$ on C$C$rimmC$isen nopea operaatio.
3. **VC$limuistiystC$vC$llisyys:** Koska taulukot ovat 1D-muodossa,
prosessorin L1-vC$limuisti pystyy ennakoimaan seuraavan solun lukemisen
tC$ydellisesti.

### MitC$ tapahtuu, kun ajat tC$mC$n?

Kun kC$ynnistC$t tC$mC$n Node.js:ssC$, nC$et konsolissa animaation, jossa
kaksi `M`-kirjainta marssii oikealle rinnakkain joka puolen sekunnin vC$lein.
Kun ne saavuttavat `#`-esteet, `resolveConflicts`-vaihe huomaa, ettei
kohderuutu ole tyhjC$ (`CHAR_EMPTY`). Siirto peruuntuu, ja `M`:t pysC$htyvC$t
seinC$C$n puskiessaan sitC$ loputtomasti. Kineettinen shokki toimii!

---

### Seuraavan tason haasteet

Nyt meillC$ on toimiva perusfysiikka ja renderC6inti. Peli on kuitenkin vielC$
staattinen: moottorit vain pysC$htyvC$t seinC$C$n, ja lC$mpC6 nousee
jatkuvasti tappiin.

Jotta tC$mC$ muuttuu aidoksi simulaatioksi, meidC$n pitC$isi tuoda mukaan
jokin aiemmin suunnitelluista syvistC$ mekaniikoista. Mihin suuntaan haluaisit
laajentaa moottoria seuraavaksi?