Weblabor

A cron nem tud másodpercenként futni, csak percenként ha jól olvastam. A socketelés megint egy olyan dolog, mint a fent említett PCNTL: elméleti alapok is kellenek.

A probléma koránt sem triviális sajnos, mivel nagyon sok részfeladata van és nagyon sok időzítés van. Két fajta megközelítést tudok ajánlani:

1. az egyszerűbbik módszer. Valaki elindítja egy mézessüti építését, akkor az bekerül egy adatbázis táblába. Legközelebb amikor valaki csinál valaki valami mézessütitől függő dolgot, akkor az a programrészlet megcsinálja a már elkészült mézessütik átállítását...

Ezzel az a probléma, hogy könnyebben törhető a játék és egy idő után nagyon lassúak lesznek a lekérések.

2. a bonyolultabb módszer. Kell egy daemon, amelyik az időzítést ellátja. Több szál, az egyik szál csak a mézessütikkel foglalkozik, nézegeti mi mikor készül el, megszakítások, stb.

Ezzel meg az a probléma hogy nem érzem reálisnak azt, hogy egy ilyet belátható időn belül megírj. Ehhez kell a Unix rendszerprogramozástól kezdve a PHP elég mély ismeretéig minden.

Van még egy köztes módszer is, amiből valószínűleg mind a kettő árnyoldalait fogod ki, méghozzá hogy írsz egy daemont ami az alapvetően időzítendő feladatokat ellátja, a többi meg valós időben történik...

Összegezve, nem érzem reálisnak azt, hogy Te egy ilyen szoftvert megírj. Ha százalékot kellene mondanom, itthon a webfejlesztő cégek 80-90%-a nincs fölkészülve egy ilyen feladatra. Próbálkozni persze lehet, csak kezdd kicsivel és számíts rá, hogy nagyon, nagyon, nagyon sokszor fogod újratervezni az egészet.

A PHP mauálban van egy chat szerver, mint példa. Ez nem multithread-es megvalósítás, szóval nem kell nagyon komoly dolgokkal (szinkronizálás stb) foglalkoznod.

Én így csinálnám: Egy szkript (átlagos PHP) megkapja az AJAX hívást. A klienstől kapott parancsot egy timestamp-el ellátva bepakolja az adatbázisba. Egy állandóan futó PHP szkript feldolgozza a beérkezett parancsokat (az adatbázisból) a timestamp sorrendjében. Persze figyelve, hogy az egy másodpercben kiadott parancsok egy körre vonatkoznak, például, ha két játékos támajda egymást, akkor nem csak az első támadást kell végrehajtani, és nullára csökkenteni a másik életerejét, hanem a másik támadása is végrehajtódik, mert csak a következő kör elején hal meg az ellenfél.

És itt jön a probléma a másodperces körökkel. Mi van, ha több ideig tart a szervernek a kör feldolgozása, mint 1mp?

Ez is fontos terület valóban. Sajnos a csalásokat nehéz kiszűrni. Ha a kliens vékony és csak utasításokat küld, azt is lehet scriptelni. Okos emberkék megnézik milyen műveletre milyen utasítás megy ki, erre írhatnak mindenféle scripteket amik gyorsítják a műveleteiket (nem kell hozzá semmi extra egy firefox+firebug+live http headers+grease monkey combóval már neki lehet látni :)
Persze ez nem igazi csalás, csak spórolhat valaki a klikkelésen és tonnaszám gyárthat majd egységeket, ha van elég erőforrása, nem kell keresgélni a "gyárat" kattintgatni rajta stb. Ezzel is előnybe tud kerülni a becsülettel játszókkal szemben.
Erre csak olyan megoldást látok, hogy a saját protokoll-t titkosítani kell, hogy ne lehessen könnyen visszafejteni. Esetleg korlátozni az egységnyi idő alatt küldhető parancsok számát vagy valami ilyesmi... Ezzel szívtunk annó, igaz a mi játékunk nem real-time volt, hanem körökre osztott stratégia.

ez a comet eddig elkerulte a figyelmemet, de mar rajta vagyok.
de amit eddig felfogtam belole az alapjan, lehet jobb valasztas (hosszabb tavra gondolvan), egy java kliens erre a celra, vagy a szerver oldalon kell nagyon ugyesnek lenni. :P

Passz, nem tudom a Perl tud-e több szálat kezelni de ha daemont írsz akkor értemesen nem tudod megkerülni a dolgot, úgyhogy olyan nyelvet kell választani ami tud ilyet.

Egyébként zárójelesen megjegyzem, nem hiszem hogy a Perl (ami alacsonyabb szintű mint a PHP) ne tudja ezt, amikor a PHP már tudja.