Canvas-ban tényleg lehetséges 2D-s játékot írni?

tényleg lehet.

timert felejtsd el, requestanimationframe-et használj, ugyanúgy mintha settimeout lenne.

a nehézség relatív, nekem elsőre bonyolult és nehéz volt, a végére már kitapasztaltam.

a canvasen is javascripttel jelenítesz meg.

tárolni kell mindennek a pozícióját, és minden frameben kirajzolod (játékfüggő, más megoldás is lehet)

jó ha már objektumokkal dolgozol, de meg lehet oldani nélküle is (csak áttekinthetetlen spagetti lesz)

szívesen segítek ha kell

#2: Azért a requestAnimationFrame-et illik timerből hívni, t.k. a frame rate miatt.

#3: És mire is rajzolsz, ha nem canvasra?

Egyébként a bonyolultnak kikiáltható részek pont nem a canvas/grafika járulékai, hanem inkább a fizikáé, illetve a tile engine-é.

JS-ben az objektumokkal való munka kicsit szopóbb, mint más nyelvekben, de egyáltalán nem lehetetlen, procedurális alapon meg biztosan katasztrófa lesz a kód (ahogyan azt a második válaszoló is említette).

A keypress részhez: Tulajdonképpen nyilván kell tartanod az épp lenyomva tartott billentyűket (onkeydown, onkeyup segítségével viszonylag egyszerűen megoldható) és ezeket minden frissítés alkalmával továbbítani azon komponenseknek, amelyek ezekre reagálni hivatottak. Basically.

Persze de ha ugrik, esni is fog, melyet pontosan 9,81 m/s2-el teszt.

Hogy érted hogy mire rajzolok?

#6: Úgy értem, hogy valószínűleg, ha nem canvast használsz, azért nem divekből potyogtatod ki a pixeleket. No de akkor mégis...

Kérdező: Ahogyan azt a kolléga írta előttem, ha ugrik, esni is fog. Ezen felül tud menni, szaladni, megállni, ezekhez sebesség, illetve gyorsulás értékek is tartoznak, illetve tud más objektumokkal ütközni, amelyeket detektálni kell, és az ütközési helyzetet valamiféle módon megoldani (landol, elakad valamiben, ha ellenfélre ugrik, arról elpattan, ez mind-mind fizika). Tud lőni is, a "lövedék" pedig szintén saját fizikával bír: egy bizonyos sebességgel haladva pattog, találat, vagy oldalirányú ütközés esetén megszűnik létezni. Ésatöbbiésatöbbi. Az, hogy ezek kiszámolgatása mellett egy bitmapet ki kell rajzolni a canvasra, teljesen sokadrangú, és triviális probléma (spritesheet animation).

A gravity guy zuhan (két lehetséges irányban), fut, gyorsabban fut, ezekkel összefüggésben gyorsul/lassul, ütközik, és akkor még csak a főhősről beszéltünk, ám mindebben még nincs benne semmilyen pálya, sem tárgyi akadályok, sem ellenfél. Ez mind-mind fizika.

Ha csak ugrás lenne, akkor az azt jelentené (nem számítva a grafikát, illetve az inputkezelést), hogy lóg a semmiben a főhősöd, aztán nyomsz egy ugrást, amire ő nyílegyenesen felfelé kirepül a képből. That's it. Minimum gravitáció, haladás és ütközés kell, hogy legyen.

Az ütközés kezelése gyakorlatilag további két részre bontható: Detektálás és reakció (collision detection és collision response; nem tudtam jobb magyar fordítást, sry).

Detektálni egy ilyen játék esetében még egyszerű, mert elég egy AABB, viszont a reagálással együtt úgy kialakítani/elhelyzeni, hogy a kód ne legyen vállalhatatlan, mint az sajnos a (kevésbé igényes) kollégák igen jelentős részénél lenni szokott, na az már esetint kemény dió lehet - jó fejtörő. Használhatsz persze valamilyen 2D fizikai motort, de egy ilyen játéknál az erőteljes overkill, ráadásul abból is sok a hulladék, amit a világért sem használnék, mert az API-ja nem igazán átgondolt, és ezáltal játék kódját is tönkrezúzza.

Hozzáteszem, JS-ben amúgy sem szeretek fejleszteni, mivel a prototípusos mivoltából kifolyólag elég sok borsot tud törni a fejlesztők orra alá.