Na pont ez a kényes dolog, amit a Nintendo belső fejlesztői köre maximálisan megértett már akkor is, amikor én még csak készültem.
81-es Donkey Kong óta minden platformjátékukban a legfontosabb a fix, következetes, pontos, és szabályok szerint viselkedő irányítás. Ha te nekifutsz 500x egy pályának, begyakorlod, izommemóriába vésed, és megjegyzed a gombok ritmusát, akkor csukott szemmel is képes leszel reprodukálni végtelenszer ugyanazt az eredményt. Egy időben ez PC-n is jól működött, pl Doom speedrun korszak, de még a fizikai motorokat nélkülöző későbbi 3D shooterek is, mint a Quake/Unreal első pár része.

Aztán elszabadult a pokol. A játék szinten direktben implementált mozgás helyett jöttek a komplex, interaktív világ építésre alkalmasabb fizikai motorok. Mostanában épp általában Havok, de mindegy, hogy Physics, Box2D, vagy más, alapjaiban hasonlók lesznek. Lényeg, hogy egy-egy frame között sok iterációban futtat le rengeteg kölcsönhatást, és kapsz belőle egy közelítőleg elfogadott következtetést. Ezzel az a probléma, hogy ha épp egy párkányra ugrásnál ez a következtetés nem lesz szélsőséges esetben minden pillanatban azonos, akkor már egy húzósabb átugrásnál a precizitás mellé a szerencse is odakerül.

Mellé bejön az, amiben a Nintendo jól csinálja, a többi meg nem igazán, a hardware kereteiben élés. Tudod jól, hogy mi a számítási kapacitás, mi fér bele, mi nem, így tervezetten annyit rajzolsz oda olyan minőségben, ami mellé belefér minden, ami fizikai modellezés fix framerate tartásához kell. Ez azért fontos, mert ha fix pl 60FPS sebességgel modellezed a világot a rajzolási sebességtől függetlenül, és nincs frameidő ugrálás, akkor a solverek ugyanakkora iterációkat fognak ugrani, nem kell változó időközöket áthidalniuk, egységes lépcsőfokokon lineárisan halad. Ha sebességfüggően néha többet, néha kevesebbet kell extrapolálni, akkor máris jönnek a túlcsordult, túlkompenzált hibák. Lásd pl GTA4, ahol a hintákkal fellőhetted az autót a felhők közé simán, vagy bármi hasonló, szarabbul implementált cucc, ahol komolyabb beakadásnál akár áteshettél a talajon lefelé, mert a solver a gravitációval együtt már lefelé kerekítette a kerék pozícióját az út alá.

Nagyon nem mélyedek bele, mert hosszú, legtöbb esetben lényegtelen, a lényeg, hogy egy modern jó játékban a fizikai motornál nem szabad túl sok kompromisszumot kötni a sebességre, és néhány kulcsfontosságú dolgot ki kell benne erőltetni ahelyett, hogy simán ráhagynánk a világra a mozgatást, akkor nagy baj nem lesz belőle. Viszont ha jön a marketing követelése a 16k HDR igényről budget telefonprocesszorra, akkor kell egy Clint Eastwood szinten tökös manager, aki rendíthetetlen szigorral, a fejlesztők véleményét megtámogatva, ellentmondást nem tűrve közli, hogy NEM. Ha ez hiányzik, akkor jönnek a hasonló, majdnem kifogástalan szuperprodukciók, ahol iszonyatos crunchperioddal kiszenved egy csomó túlhajszolt koffeinfüggő bevérzett szemű fejlesztő valami még használható kompromisszumot. Senkinek sem jó, csak valami excel grafikonban tűnik ez a legjobb útnak, úgyhogy ezt kapjuk. Grr.