Írtam egy kisebb választ... :)
https://www.webtudor.net/s1e13-hogyan-irjunk-online-jatekot/#comment-31
Mivel "Your comment is awaiting moderation.", ezért:
Néhány észrevétel, javaslat, ötlet, mint gyakorló játékfejlesztő... :)
"Műszakilag rengeteg minden kell hozzá, éppen ezért nem kis fába vágod a fejszédet."
Ha az ember egyedül kezd neki, akkor nem csak műszakilag kell rengeteg minden, hanem mindenféleügyileg kell rengeteg minden: a teljes stack kezelése az üzemeltetőtől kezdve a fejlesztőn, grafikuson és tesztelőn át a menedzserig és pénzügyi emberig mindenre szükség van. Mármint akkor, ha az ember komolyan gondolja... :)
"Ezekről egy igen kiváló áttekintést nyújt a html5gameengine.com oldal."
Ez egyébként kicsit megtévesztő és szerény véleményem szerint félrevezető is, mert jelenleg az új casual játékok nagyon-nagyon-nagy része mobilon jön ki először, mobilon pedig a fenti keretrendszerekből nagyon szép képregény lesz csak mobilon, a WebGL alapú megoldások pedig szinte alig működnek, ha mégis, akkor ott is egy nagyságrend a különbség teljesítményben.
Szóval ha cél a mobil platform is - márpedig cél, akkor a Javascript felejtős. Nagyon felejtős! Helyette el kell dönteni, hogy melyik az elsődleges platform: az iOS vagy az Android.
Mind a kettő esetben van lehetőség arra, hogy a másik platformon minimális teljesítményvesztéssel működjön a program, az iOS-Android irányt nem ismerem, de az Android-iOS irányra teljesen jól működő megoldás a Libgdx, elég sok alkalmazás használja, minimális köret kell csak iOS-on a Libgdx core modul köré.
De az egyik esetben Java nyelven kell fejleszteni, a másik esetben ObjC és/vagy Swift. Mindegyik eléggé messze van a Javascript-től.
"Az olyan nyelvek mint a PHP jók, ha hagyományos alkalmazásokat kell írnunk, viszont egy játék alatt hamar elvérezhetnek."
Sok minden más is el tud vérezni, például azon, hogy szerver oldalon teljesen másképp kell gondolkodni, mint a kliens oldalon... :)
"A NodeJS egy további előnnyel is rendelkezik: JavaScriptben írhatunk szerver oldali programokat."
Ami csak akkor előny, ha van a rakás JS fejlesztőnk a padláson vagy a spájzban, akiknek épp nem tudunk feladatot adni _és_ a szerver oldal buta, nincs benne logika vagy komplex számolás. Amint lesz ilyesmi és nem csak egy brókerként funkcionál, a NodeJS akadozni fog, márpedig egy játékban a szerver nagyon sok mindent ellenőriz, nem hihet a kliensnek, a kliens csak megjelenít és csak a megjelenítéshez (=élvezhető játékmenethez) szükséges logikákat tartalmazhatja.
Szóval ha nincs Javascript fejlesztő a spájzban és a kliens oldal se Javascript, akkor felejtsük el a szerver oldali Javascript-et... nézzük körül, van sok egyéb más megoldás, amelyek jól működnek, ha pedig az Android az elsődleges mobilplatform, akkor a szerver oldalra is próbáljunk Java-t tenni (hogy Java EE vagy Spring vagy bármi egyéb, az más kérdés).
"Kezdetben itt elegendő lesz egyetlen feldolgozó szál, ami percenként fut. Ezt akár a rendszer crontabjából is el tudjuk indítani és feldolgozzuk az aktuális feladatokat."
Ezt nagyon gyorsan felejtsük el. De tényleg!
Ez az eredményezi, hogy a szerver tüskékkel lesz terhelve percenként és ennek a percenkénti terhelésnek az ideje a felhasználószámmal és/vagy egyéb objektumok számosságával lineárisan növekedni fog. Először percenként egy másodperc, aztán tíz, aztán fél perc és a felhasználók azt látják, hogy a szerver szaggat vagy folyamatosan lassú.
Fordítsunk időt "szimulált játékidő" megértésére, az eseményvezérlésre, illetve arra az elvre, hogy az erdőben a kidőlt fának nincs hangja, ha senki nem hallja! Ez utóbbi a legtakarékosabb megoldás, minden objektum esetén eltároljuk az utolsó frissítés idejét és az interakcióknál kiszámoljuk az eltelt idő változásait minden érintett objektumra, ha nem megy az egy képletben való integrálás, akkor lehet szimulálni egy közönséges ciklusban az eltelt perceket is.
A lényeg az, hogy a szerveren legyen szétkenve a terhelés, mert a szerverért teljesítmény alapon fizetünk... legyen terhelve folyamatosan. Annak nincs sok értelme, hogy veszünk egy drága szervert sok pénzért, hogy percenként pár másodpercig mind a nyolc CPU dolgozzon a frissítésen és SSD kell alá, hogy gyors legyen, amikor elég lenne egy tized akkora gép tized annyi pénzért.
Ugyanakkor ne feledkezzünk meg arról, hogy ha véletlenül bejön a játék, akkor ne csak vertikálisan tudjuk skálázni egy darab nagyobb szerverre, mert előbb-utóbb elérjük a maximális szerverméretet és nincs tovább, illetve ha ez a szerver megdöglend, akkor sincs tovább. Olyan architektúrát építsünk fel, amelyik sok kis szerveren (=horizontálisan skálázható) képes működni, mert sok kis szervert jobban lehet cloud-ban üzemeltetni, mint egy nagyot. A szerverek számával könnyebben lehet játszani, mint a szerver méretével, mert általában csak felfelé skálázható a szerver, lefelé már nem.
"Éppen ezért érdemes vagy nagyon kicsi és nem erőforrásigényes játékot írni, vagy jól átgondolni, hogy miből kerül finanszírozásra a projekt."
Lehet hobbi is... havi 100 dollárból már egészen nagy szerverparkot fel lehet építeni és ez a 100 dollár a mi szakmánkban nem olyan nagy összeg, csak napi két kávé ára a céges büfében... :)