ugrás a tartalomhoz

valós idejű játék programozása PHP-ben

ErdosJ · 2007. Szep. 19. (Sze), 17.47
sziasztok

a szabadidomben nekialltam egy jatekprogramot fejleszteni, php nyelven, mysql adatbazissal, egy kis ajax segitsegevel. gyonyoru kodot irtam, de most kezdek belegabalyodni, ezert kerem a segitsegeteket.

tehat a jatek valos ideju, minden akcional az ora elkezd ketyegni, es n masodperc mulva hajtodik vegre az akcio. elmeletileg legalabbis valahogyan igy kene mukodnie. ez reszben mar mukodik, de ahhoz, hogy bovithessem, az eddigi kodba bele kene nyulnom, es ez egyre bonyolultabb, de meg egyszer, utoljara ;-) hajlando vagyok az egeszet atirni.

per pillanat ugy mukodik, hogy jatekosonkent vegrehajt egy _admin_scriptet_, ami a legutolso futas ota eltelt idovel dolgozik, ha az eltelt ido nagyobb, mint egy ora, akkor pedig beleirja a valtozasokat az adatbazisba.

milyen technikat ajanlotok ilyen idozites kivitelezesehez szerver oldalon? lehetoleg minel minimalisabb, atlathatobb, bovithetobb kodot szeretnek irni. googlet mar volt.
nem szeretnem abbahagyni, egyre jobban erdekel a dolog. bar hobbi szinten dolgozom rajta, remelem, egyszer majd csak elkeszul.

valaszaitokat elore is koszonom
ErdosJ
 
1

google

ErdosJ · 2007. Szep. 19. (Sze), 17.49
szoval a googlet mar hasznaltam, ezt dobta ki nekem.
innen eddig a 3. megoldast hasznaltam, de erdekelne, hogy van-e mas is, illetve, hogy ti mit ajanlotok, mit erdemes, stb..
2

daemon fut a szerveren...

ErdosJ · 2007. Szep. 19. (Sze), 18.52
most jutott az eszembe egy elvetemult otlet:
mondjuk c++-ban irnam meg a program lelket, ami a szerveren megallas nelkul futna (daemon), majd peldaul egy kozos fileon keresztul parancsokat kapna egyeb php fileoktol, azokat vegrehajtana. igy az idoziteseket, adatbaziskezeleseket, miegymast kozpontilag meg lehetne oldani...
nagy hulyeseg, vagy erdemes foglalkozni vele?
valaszaitokat tovabbra is varom
ErdosJ
3

PHP?

Marcell · 2007. Szep. 19. (Sze), 18.54
Én azt nem értem, mi értelme van PHP-ban írnod egy játékot??? Mi fut a kliensnél, egy Flash? Vagy mi köze a PHP-nak ehhez?
4

miert php

ErdosJ · 2007. Szep. 19. (Sze), 19.43
ebben az otletben valahogy igy gondoltam:
FELHASZNALOI FELULET ==>ajax engine ==>php feldolgozo==>kozos file==>vegrehajto program a szerveren.
tehat a php file beleirna egy kozos fileba a parancsokat (amelyeket ugyebar ajaxos post-on kap), azt, hogy melyik felhsznalo milyen akciokat kezdemenyez, azoknak mikorra kell befejezodniuk. a program a szerveren pedig allandoan ellenorzi a filet, hogy erkeztek-e uj akciok, ha erkeztek, vegrehajtja idozitve.

lehet, hogy az elso postom nem volt egyertelmu, ezert sorry. tehat:
a jatek ajaxos, es a szerver oldal segitseget igenyli azert, hogy tobben is lehessen jatszani egyszerre, interaktiv modon.

jo, jo, hirtelen ez jutott eszembe, de azert szoljatok, hogy nagy hulyeseg-e.
5

cron

vbence · 2007. Szep. 19. (Sze), 20.40
Neked egy CRON jellegű szkript kell. Az ajax-os felületről érkező "parancsok" eltárolódnak mysql-ben, és az adott időközönként lefutó szkript végrehajtja azokat.

Webes játék-tapasztalatomból egy olyan példát tudnék mondani, hogy adsz egy parancsot a karakterednek, hogy "Bányássz". Az adatbázisban az utolsó paracs található. Az újabb parancs mindig törli az előzőt. A percenként futó szkript megnézi, hogy mit csinál Ogár, látja, hogy bányászik, akkor hozzáad egy aranyat a pénzéhez. Másnap újra benézel Ogárhoz, és látod, hogy összegyűlt az 1440 arany az új bunkóra, ezért azt a parancsot adod neki, hogy menjen északnak (a közeli városba). A percenként futó szkript csekkolja Ogár státusát, és látja, hogy északra megy, ezért az Y koorinátájához hozzáad 10-et.
Az AJAX-os felület persze percenként frissül, és te látod, hogy Ogár minden percel közelebb kerül a városhoz.
Persze lehetnek azonnal futtatható parancsok, amik nem igényelnek időt. Ilyen például a vásárlás. Vagy olyan parancsok, amikhez idő kell, de csak egyszer kell őket végrehajtani (mondjuk csapdaállítás vagy építés).

Elég kevés paramétert árulál el a játék természetéről, úgyhogy lehet, hogy teljesen el vagyok tévedve. De ha már felmerült a daemon kérdése (tehát vannak épkézláb lehetőségeid a szerveren, nem egy ingyenes szolgáltató guzsbakötött szerveréről van szó). Írhatsz kvázi-démont php-ben is. A socket kezeléssel nyitvatarthatsz élő kapcsolatokat, és azonnal reagálhatsz az eseményekre. A PHP dokumentációban van egy példa CHAT alkalmazás.
6

Nem csak kvázi

janoszen · 2007. Szep. 19. (Sze), 21.01
Nem csak kvázi daemont lehet írni, főleg hogy van újfent process control, lehet több szálat is futtatni, stb.
8

nem ertem

ErdosJ · 2007. Szep. 20. (Cs), 15.38
ooo... ezt hogy erted? hol tudok ennek utanaolvasni?
10

RTFM

janoszen · 2007. Szep. 20. (Cs), 21.20
Például a PHP manualjában? A PCNTL library csinálja azt amit Te szeretnél de vastag elméleti alapok nélkül felejtsd el mert olyan gyönyörű memory leakes, bugos, versenyhelyzetes lesz a programod hogy örülsz ha darabjait össze tudod vakarni számítógép újraindítás nélkül.
7

miert nem cron

ErdosJ · 2007. Szep. 20. (Cs), 15.36
szia
nem hiszem, hogy a cron tuttijo megoldas, mivel a jatekom nem kor alapu. de vehetjuk ugy is, hogy kor alapu, csak minden kor egy mp-ig tart. igy viszont a cronnak masodpercenkent kene futtatnia, mi nem tul jo otlet.

az en jatekomban nekiallok epitkezni, es n mp mulva felepul az epitmeny. viszont a kulonbozo akciok nem egesz percenkent hajtodnanak vegre, es ez adja a nehezseget.

ez a socketezes hogyan mukodik? hogyan tudnek php-bol egy mar futo (daemon szeru) programnak parancsokat kuldeni, es visszajelzest szerezni?
11

Cron

janoszen · 2007. Szep. 20. (Cs), 21.29
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.
15

vegyes valasz

ErdosJ · 2007. Szep. 21. (P), 14.59
szia
a cronnal amugy sem vagyok kibekulve, szoba sem johetne, mivel valos ideju jatekrol van szo.
1: eddig az egyszeru modszerrel probalkoztam, gyonyoruszep objektumorientalt php programot irtam, haromszor (!) ujraterveztem, es meg mindig nem tokeletes.
2: ezt a modszert szeretnem megprobalni.

csak konyorgom, ne toljatok le ennyire!
igen, ezt hobbibol csinalom, egy darab "fejleszto" vagyok, civilben gimnazista. ez viszont a hobbim (tehat semmilyen anyagi erdekem nem fuzodik hozza, es nem a nagykozonsegnek csinalom), tudom, hogy nem egyszeru, viszont megis megoldast keresek ra. ha daemont kell irni, hat gyakorlom a c++-t, es megirom! es ehhez (is) kerek segitseget.
17

c--

vbence · 2007. Szep. 21. (P), 15.56
A c-t szerintem felejtsd el (a c++ -t meg még annál inkább), ahhoz sok gyakorlat kell, hogy ne legyenek különböző memóriaproblémák stb. A thread-ek szinkronizálása meg egy külön történet.
Inkább nézd át a PHP ilyen irányú képességeit. (Kevesebb hibalehetőség és még gyakorlatod is van benne).

Tervezésnél tényleg azon gondolkozz, hogy a "körök" lassíthatók legyenek, tehát esetenkéánt tarthasson már 1.5 másodpercig egy kör, ha annyi ideig tart feldolgozni a világot. Ha belaggol a játék, akkor belaggol, de ha ez nincs tudatosan kezelve, sokkal súlyosabb logikai hibák léphetnek fel.
18

miert php?

ErdosJ · 2007. Szep. 21. (P), 16.57
hmm... koszonom, megprobalom. a php-s megoldas mennyire lenne gyors?
azert valasztottam volna a c++-t, mert valahogy ugy kepzeltem el, hogy:
amikor valami akcio indul (pl socketen keresztul ertesul a dologrol), akkor elkezd visszaszamolni, es amikor nullahoz er, vegrehajt egy mysql lekerdezest, az akcio tipusatol fuggoen.
hja, erre a legszebb megoldas a javascript lenne!
19

Miért a visszazámlálás?

vbence · 2007. Szep. 21. (P), 17.09
Ha sebesség kell, akkor ott a JAVA. A visszaszámlálást nem értem, miért.
20

miert java?

ErdosJ · 2007. Szep. 21. (P), 17.14
nnah, ez lesz mar a nyolcadik nyelv, amin probalkozom, de hatha. amugy mi van akkor, ha nincs java virtualis gep a szerveren?
es hogy miert viszaszamlalas:
tehat a grafikus feluleten megnyomsz egy gombot, mire elkezd visszaszamolni az oldal, es ha nullara er, akkor frissiti a lapot. nna, ez mar mukodik kliens oldalon, most szerver oldalon szeretnem megcsinalni ugyanezt. de ha van jobb megoldas a visszaszamolasnal, akkor kivancsian varom. tenyleg.
38

érdemes lenne megnézni még

amonrpg · 2007. Szep. 23. (V), 09.50
Hát, ha nagyon ilyesmit szeretnél írni, akkor a daemonhoz jól jöhet pl. a C# & Mono páros. Könnyebb, mint a C/C++, viszont szofisztikáltabb, mint a PHP, és kicsit kisebb, mint a JAVA. Szerintem ilyen daemon feladatokra ideális választás. Olvass utána, nem is egy nagyon bonyolult nyelv.

A közös fájlt meg már megvalósították mások, adatbázisnak hívják. :D Szerintem ne kezdj el kerekeket feltalálni. :P
39

Re: érdemes lenne megnézni még

ErdosJ · 2007. Szep. 23. (V), 19.28
szia
a c#-ot mar hasznaltam, egyedul az aggaszt, hogy nem minden szervergepen van mono, es en a minden szempontbol optimalis megoldast keresem. ugyanez a bajom a javaval.
a perl mellett dontottem, a daemon mar kesz, kozos file helyett socketeket hasznal. (igen, a kozos file talan tenyleg hulyeseg..)
40

Saját szerver..

janoszen · 2007. Szep. 23. (V), 22.05
Ha komolyan gondoltad ezt a játékot, akkor úgyis saját szerverre lesz szükséged.
46

Re: Saját szerver..

ErdosJ · 2007. Szep. 24. (H), 16.51
aham... egyelore az iskolai szervert meg hasznalhatom (fel evig tartott utanajarni, hogy a mysql lehetoseg meglegyen. csak belegondolok, hogy a mono forrasbol forditasa peldaul mennyi ideig tartana ott :D).
ha iskolai szerver eleg lesz, az jo, ha nem lesz eleg, az megjobb.
13

Chat példa

vbence · 2007. Szep. 20. (Cs), 23.47
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?
14

chat szerver

janoszen · 2007. Szep. 21. (P), 08.43
Azt azért figyelembe kell venni, hogy egy chat szervernek nincsenek időzítési feladatai. Meg lehet csinálni körökre osztva időzítéssel, de akkor is figyelni kell arra, hogy ne legyen versenyhelyzet a feldolgozásnál, stb.

Szerintem, nem triviális a feladat, koránt sem. Én nem tudom kapásból azt mondani, hogy tudom rá a megoldást.
16

ez az.

ErdosJ · 2007. Szep. 21. (P), 15.01
igen, en is valami ilyesmin gondolkodom most.
az neheziti a gondot, hogy az en otletem nem tul szokvanyos.
34

Nme mindig 1sec az 1sec

inf · 2007. Szep. 22. (Szo), 19.23
Szerintem lehet a játéknak külön órát csinálni ilyen célra, és akkor nincs probléma.
9

socket

ErdosJ · 2007. Szep. 20. (Cs), 18.20
beleneztem a socketekbe php alatt, erdekes. de mennyire gyors egy socketes-adatbazisos allandoan futo, php-ben irt script? es mennyire terheli le a szervert?
az megoldhato, hogy socketeket keresztul kommunikaljanak a scriptek a daemonnal (amit c++-ban szeretnek megirni ugyebar)?

hu, bonyolodik.
12

Gyors az

janoszen · 2007. Szep. 20. (Cs), 21.29
Annyira gyors, hogy a PHP is socketen szeret kommunikálni a MySQL-lel például. De ugye mihez képest. Egyébként ha már nagy léptékű rendszer tervezel, akkor inkább beszélgess szappannal (SOAP), mert az legalább szétdobálható több szerverre.
21

Application server

janoszen · 2007. Szep. 21. (P), 19.28
Namost, egy kicsit absztraktabbul nézve a feladatot, neked több szerverre kell tervezned ha jót akarsz magadnak. Szóval Neked az kell, hogy ha a webszerveredet (PHP-det) megkérdezik valamiről, akkor neki meg kell kérdezni az application szervert (ami akár futhat azonos gépen is), hogy az mi a történés. Ergó, el kell fedni a belső működését.

A szerveren belül meg meg kell oldanod, hogy a belső működés jó legyen. Én nem javaslom a körökre osztást, bár lehet hogy nem tudod elkerülni.

Szerintem, ha az elsőt kifogástalanul meg tudod csinálni, az már nagy előrelépés. Aztán írhatod meg a játék enginet. :D
22

tippek

gonoszcsiga · 2007. Szep. 22. (Szo), 00.26
szerintem felesleges tulbonyolitani (lasd 1-2):
1.egy tablaba eltarolod, hogy milyen parancs, mikor, fusson le. aztan irsz egy scriptet, ami annyit csinal, hogy kiolvassa ezt a tablat, az idoket veve alapul, es amelyik parancsnak "lejart" az ideje, azt futattja. aztan ezt a scriptet, minden lapletoltodesnel futtatod.
nyilvan valamilyen zarolast is kell hasznalnod, illetve egy kis cron segitseget is igenybevehetsz, arra az idore, ha senki se kattintana hosszu ideig, bar ha senki se kattint, akkor lehet nincs is mit szamolni. :)
persze ez igy fake, de legalabb egyszeru.

2. irhatsz demon-t is, ott tulkepp a demon-nak odaadod a parancsot, ami indit egy timer-t, es ha lejar lefutattja, en python-ba irnam. ;)

de ha bonyolitani akarod:
3. ha mar visszajelzest is akarsz lehetoleg real-time-ban, akkor szinten demon-t kell irnod, de akkor mar valamilyen kezdetleges protokolra is szukseged lesz, kliens oldalra javaslok egy java socket gateway-t(google-ba megtalalod) ez csatlakozik a demon-hoz, es fenntartja a kapcsolatot. aztan evvel a java progival kell kommunikalnod js segitsegevel, ez viszonylag egyszeru pl. firefox-nal, ie-nel mar nem. annyi kulonbseg, hogy a java-ban levo fuggvenyeket mindket esetben tudod futtatni js-bol, mig a java-bol, csak firefox-al tudsz js fuggveny-t futtatni.
valoszinu tobb problemad is lesz meg. :)

4. a demon tulkepp marad, de a kliens oldalt, pl. tisztan java-ba, vagy flash-ben irod meg.

u.i.:egyebkent leirhatnad szajbaragosabban is a jatekot, mert szamomra meg mindig zavaros. :)
23

Re: tippek

ErdosJ · 2007. Szep. 22. (Szo), 07.29
szia
koszonom a valaszodat.
1) eddig ez volt. gyonyoruen mukodott, de a kod gyakorlatilag bovithetetlen. az a problema, hogy bizyonyos akciok fedik egymast, egyiknek szuksege van egy masikra, stb.
2) iggen, most ezen dolgozom. en perlben irom. (es most a socketkezelessel szivok.)
3),4) flash sajna szoba sem johet, a java-t pedig sajna nem ismerem tulsagosan (egy hellovilag meg elmegy.)
ha meg mindig nem vilagos, akkor sorry, megprobalom az elso postot szerkeszteni.
24

a jatekrol konkretan.

ErdosJ · 2007. Szep. 22. (Szo), 07.38
mivel tobben irtak, hogy nem ertik a jatek lenyeget, es azt, hogy mit bonyolitok, leirom a konkret peldat:

minden jatekos egy fold meretu ;-) bolygoval kezd. ezen a bolygon tud epitkezni, fejleszteni. egy epitkezes, fejlesztes ugy mukodik, hogy amikor megnyomtam a gombot, visszaszamol az oldal (meg van hatarozva, hogy egy epitkezes/fejlesztes milyen hosszu ideig tart.), majd amikor nullahoz er, az epitkezes/fejlesztes befejezodik.

tehat valos ideju. idaig tokeletesen mukodik, de a kovetkezoket mar nem tudtam belezsufolni a kodba:

nem csak epitkezni/fejleszteni lehet, hanem (az epuletek szintjetol fuggoen) bizonyos egysegeket gyartani, tamadni, vedekezni, kereskedni (a flotta is meghatarozott ido alatt jut el a jatekoshoz).
25

nem értem

zila · 2007. Szep. 22. (Szo), 09.04
Nem látok lényeges különbséget az építkezés és a gyártás, fejlesztés, mozgás között...

Mindegyikhez kell idő. Ugyanúgy kell kezelni mint az építkezést. X mp + Y nyersanyag = level 2-es épület, X mp + Y lakóhely + Z nyersanyag = katona, egységtől függő X mp = 1 egység megtétele a térképen...

Én ezeket kliens oldalon csinálnám meg, és csak adminisztrálnék szerver oldalon. Csak azt kell megoldanod, hogy a játékosok mozgását is meg tudd jeleníteni mindenkinél (közeledik az ellen, támad stb.) A problémát ez jelenti, hiszen ehhez valamilyen server-push megoldás fog kelleni neked, amit lehet COMET-tel, bár ezt még sosem próbáltam... Használhatsz flash-t. Ez a játék felületét is látványossá teheti, valamint tud socket-eket kezelni, így a játékszervered nem egy webszerverben futó php script lehet, hanem egy rendes alkalmazás, rendes tcp/ip kapcsolatokkal, kétirányú kommunikációval. Írhatod amiben tetszik, én biztos nem php-ban írnám...
26

Re: nem ertem

ErdosJ · 2007. Szep. 22. (Szo), 09.16
hmm. kulonbseg talan annyi, hogy amikor tamadok, akkor frissitesenkent mar nem csak a sajat bolygomat, hanem a megtamadottet is frissiteni kell, ha o tamad valakit, akkor azt is, es igy gyonyoru rekurzioba kerultem. erre meg jon az is, hogy a mozgasok meghjelenitese mindenkinel, ha valaki visszavonja a tamadast, akkor is... egyszeruen macera az egesz.
most mar egeszen jol haladok, perlben nekialltam a daemont megirni, socketkezeles mar kesz,adatbaziskezeles meg hatra van.
az, hogy php/java/flash... en a javahoz nem ertek olyan szinten, hogy socketezes, adatbazisozas, minden menjen. flash-hoz meg anynira sem. igy maradt a php+valami mas paros. igy is, amit csak lehet, kliens oldalon oldok meg, ajax segitsegevel.
27

ezért nem jó a php

zila · 2007. Szep. 22. (Szo), 09.55
Ezért mondtam, hogy neked egy saját szervert kell írnod - nem felétlenül php-ban - annak pont ennyi a dolga, hogy minden játékos interakcióját adminisztrálja, az aktuális helyzetet pedig leküldje a klienseknek. Erre meg a http protokoll nem igazán alkalmas, amire a flash socketet javasoltam példának. A szervered annyi szálat kell futasson ahány játékos csatlakozik, mindegyik a saját socket-én lóg, azon keresztül beszélget a kliens és a szerver. Így ha az egyik játkos lép alamit, akkor ezt a lépést leküldöd az összes többinek. persze csak akkor érdemes leküldeni, ha az adott interakció látható egy adott játékosnál (pl, van neki valami long range sensor kütyüje, vagy látótávolságban vannak az egységek...)
28

Kliens

janoszen · 2007. Szep. 22. (Szo), 10.38
Kezd kialakulni a koncepció. Én annyit tennék hozzá, hogy a kliensek (ha a felhasználók gépén futnak) akkor legyenek vékony kliensek, mert ha alkalmazás logikát viszel a felhasználóidhoz, akkor törni fogják amit csak lehet. Ezzel ellenben ha a kliens csak parancsokat küld a szervernek és visszajelzéseket kap a végrehajtásról, nem kell külön foglalkoznod azzal, hogy a felhasználótól kapott adatok vajon valósak-e, hanem mondhatod azt, hogy a kapott utasítést (ha lehetséges) végrehajtod.
29

törés, csalás

zila · 2007. Szep. 22. (Szo), 11.26
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.
33

Rossz megközelítés

vbence · 2007. Szep. 22. (Szo), 19.22
Ha a sok kattintás (és ezek megspórolása) különbséget jelent két játékos között, akkor a játék egyszerűen rossz :) Nem kötelezheted az embereket fölösleges kattingatásra. Például: ha van erőforrása ezer egységhez, akkor ne kellessen már 1000szer megnyomnia a gombot, és az a játékos lesz erősebb, aki később unja meg a nyomogatást (mert ez következik a fenit írott példából).

Én még bátorítanám is a szkriptelést. Valakinek érdekesebb lehet botot írnia, mint maga a játék. A szabályoknak kell kivédeni, hogy a valódi játékosok ne kerüljenek hátrányba a szkriptekkel szemben. Ha kiküszöbölsz a játékból mindent, amiben jobb egy gép, akkor a logika, stratégia lesz ami jóvá tesz egy játékost, nem pedig az, hányszor tud kattintani, ez érdekesebbé teszi a játékodat emberi lények számára.

Más: egy netes játékban nincs csalás! Mindaddig, amég nem törik fel a szereredetcsak a Te általad adott lehetőségekkel élnek. (Esetleg felfedezik a tervezési, logikai hbáidat).
30

real -time

gonoszcsiga · 2007. Szep. 22. (Szo), 16.40
neked meg zavaros kicsit szerintem, tehat, ha azt akarod, hogy mindenki azonnal ertesuljon arrol, hogy valami tortent az akarmijevel, akkor mindenkepp szukseged lesz kliens oldalon valamilyen socket kezelesre, az ajax nem eleg.
abban az esetben eleg az ajax, ha belefer egy pl. 30mp-kenti frissites, de abbol amit leirtal, nekem az jott le, hogy nem fer bele.
32

COMET

Hodicska Gergely · 2007. Szep. 22. (Szo), 17.54
Dehogynem, említették is már a COMET-et, azzal simán meg tudod csinálni.


Üdv,
Felhő
36

jo, hogy mondod

gonoszcsiga · 2007. Szep. 22. (Szo), 19.27
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
41

Comet

inf · 2007. Szep. 24. (H), 07.55
Hát a Cometnek én is utánajártam, de nem a legjobb technológia, mármint az alap Comet nem nyerő, viszont a Smart Polling az nagyon megtetszett, és minél előbb ki szeretném próbálni. Az elgondolás már megvolt fejben, csak a nevét nem tudtam. :P
42

Comet hááát

vbence · 2007. Szep. 24. (H), 09.33
Nekem sose volt szimpatikus a comet. Én ilyen helyzetben inkább UDP kommunikációban gondolkodnék - nem eszik socketet a szerveren, és nem kell lefusson a HTTP logika az eseménykezelő rétegben.
44

böngészőből?

Hodicska Gergely · 2007. Szep. 24. (H), 11.05
Böngészőből hogyan szeretnél ilyet használi? Egy játéknál, vagy egy valós idejű adminnál meg szükség van ilyen funkcionalitásra, és teljesen jól is működik.


Üdv,
Felhő
45

applet

vbence · 2007. Szep. 24. (H), 11.09
Egy minimális JAVA Appletre gondolok. Tudom, a JAVA nem Web2.0 kompatibilis, de kit érdekel :) A szerveroldalon meg akár PHP is hallgatózhat.
43

ez is comet

Hodicska Gergely · 2007. Szep. 24. (H), 11.03
Lényegét tekintve ez is COMET, nagyjából annak a böngészők és a környezet által felállított problémák miatti kényszerű megvalósítása.


Üdv,
Felhő
31

tobbnyire kesz.

ErdosJ · 2007. Szep. 22. (Szo), 16.53
sziasztok
most keszultem el a daemon elso valtozataval.
mar mukodokepes, van benne socketkezeles, adatbaziskezeles, tokeletesen mukodik a php filejaimmal.
az egeszet PERL-ben irtam meg, tomboket hasznal meg ciklusokat, es eleg gyors (kicsi gepemen nehany ms-t eszik.)
mivel a PERL nem az erossegem, esetleg arra tudnatok nehany bolcs tanacsot mondani, hogy hogyan tehetnek egy ilyen jellegu kodot meg gyorsabba, hatekonyabba, biztonsagosabba?
minden eddigi hozzaszolast nagyon koszonok, sokat segitettetek.
35

PERL

vbence · 2007. Szep. 22. (Szo), 19.25
Szerintem a PERL hosszú távon zsákutca lesz, de ne legyen igazam. (Mellesleg mit tud, amit a PHP nem?)
37

Re: PERL

ErdosJ · 2007. Szep. 22. (Szo), 23.47
hmm... perlben meg nincsen tul sok tapasztalatom, de majd meglatjuk. (kizarasos alapon jutottam ehhez a nyelvhez.) addig is megprobalom a programot minel egyszerubben es atlathatobban tartani.
neked mar vannak ezzel kapcsolatban rossz tapasztalataid?
47

a projekt ma.

ErdosJ · 2007. Okt. 15. (H), 19.09
sziasztok

gondoltam, kozzeteszem, hogy a projetk most hogy all, de iskola mellett nincsen tul sok idom ra :(
a daemon eleg jo, json adatokat kuld a szervernek, ami pedig a klienssel kommunikal. azota egyszer mar ujrairtam.

most azon dolgozom, hogy legyen benne utemezes is.
erre celszeru megoldas lenne a cron hasznalata, de felmerult az a problemam, hogy mar igy is tul sok reszbol all a program, es attol tartok, hogy mar tenyleg nagyon atlathatatlan lesz.
arra gondoltam, hogy erdemes lenne-e az utemezest is a (perl) daemonomba beepiteni? vagy a cron gyorsabb/biztonsagosabb/hatekonyabb/jobb?
perlben daemon irasakor jo vegtelen ciklust hasznalni, vagy van hatekonyabb megoldas is?
valaszaitokat varom
ErdosJ
48

Daemon...

janoszen · 2007. Okt. 15. (H), 19.16
Sztem érdemes beépíteni de mivel soha nem csináltam ilyet, ezért fogalmam sincs, hogyan. Talán úgy csinálnám meg hogy a háttérben futtatnék egy ütemező szálat, ami a következő eseményig alszik. Ha változás van, egy interrupt megszakítja az alvást.
49

Re: Daemon...

ErdosJ · 2007. Okt. 15. (H), 19.18
en kicsit egyszerubben kepzeltem: egy vegtelen ciklusban vizsgalja, hogy az ora meguti-e az egeszet. ha igen, vegrehajtas, ha nem, mindegy.
a vegtelen ciklus mennyire szerverbarat?
50

semennyire

vbence · 2007. Okt. 16. (K), 00.00
Ki kell találnod valamit a munka minimalizálására (mondjuk miliszekundum alapú sleep-et). Ha másodpercenként párszázezerszer ellenőrzöd, hogy váltott-e a másodperc a rendszeridőben az eléggé pazarlásnak tűnik az erőforrásokkal.
53

Re: semennyire

ErdosJ · 2007. Okt. 16. (K), 17.34
hmm... lehet, hogy tenyleg a tobbszalusag lesz celravezeto..
51

Aktív várakozás

janoszen · 2007. Okt. 16. (K), 07.17
Az egyk (kisebbik) baj ezzel az, hogy aktívan várakozol, azaz fölöslegesen zabálod a rendszereröforrásokat.

A nagyobbik baj, hogy ha egyszerre sok feladat szakad a szerverre, be fog lassulni a játék, mert a feladatok egymás után hajtódnak végre, nem pedig több szálon, ahol az ütemezö futhatna egy önálló szálon.
52

Re: Aktív várakozás

ErdosJ · 2007. Okt. 16. (K), 17.32
mit javasolsz (perlben) a problema megoldasara? a leirasokban eddig mindenhol a vegtelen ciklusos megoldasokrol olvashattam.
perlben van mod tobbszalusagra?
nnah, megyek, utanaolvasok.
54

Passz

janoszen · 2007. Okt. 16. (K), 18.21
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.
55

Re: Passz

ErdosJ · 2007. Okt. 21. (V), 10.11
utananeztem, a perl tud tobb szalat kezelni.
tehat lehet, hogy erdemes lenne ket fo szalra bontani a scriptet, az egyik a lekereseket kezelne, a masik pedig aludna vegtelen ciklusban? akkor pedig mar nem eszerubb ket kulon script filet kezelni? innen pedig mar tenyleg egy lepesre van a cron hasznalata..
azert nem szeretnem a 'lekerdezesek kezeleset' is tobb szalra bontani, mert a 'lekerdezes' tulajdonkeppen abbol all, hogy egy sokdimenzios tombon muveleteket hajt vegre. es mi van akkor, ha a ket szal egyszerre akar muveleteket vegrehajtani a tombon, vagy bejarni a tombot? nem fognak osszekavarodni a szalak?
56

event queue

vbence · 2007. Okt. 21. (V), 12.06
Használj valami sorbaállítást (esetleg többet) az eseményeknek.. az mindig jó ötlet.
57

Re: event queue

ErdosJ · 2007. Okt. 21. (V), 12.17
jelenleg tomboket hasznalok.
ha jol ertem a sorbaallitas lenyeget.. akkor azzal fogok szivni, hogy nem minden esemeny tart ugyanannyi ideig. ergo mindig meg kell vizsgalnom, hogy a sorban hova szurjam be az esemenyt. itt viszont visszaterek a tombok hasznalatahoz.
kifejtened bovebben? es hogyan hasznalhatnek tobb sorbaallitast?
58

Strukturálás

vbence · 2007. Okt. 21. (V), 13.40
Nem ismerem a feldolgozásod menetét. A több sort úgy gondoltam, hogy az adott sorba bedobja az egyik thread, a másik pedig kiveszi onnan. Például, amikor a socketen figyelő thread elfogad egy parancsot a klienstől, akkor azon az égvilágon semmit sem tesz, csak úgy ahogy van beszúrja egy sorba. Innen egy másik thread szedi ki, és dolgozza fel.
Másik lehetőség ha például vannak azonnal végrehajtandó parancsok, ezek mennének az egyik queue-ba és vannak amik az aktuális állapotokat egyáltalán nem változtatják (időzített dolgok?) ezek pedig egy másikba. A magasabb prioritással futó szál kezeli az első sort, a másodiknak pedig elég egy kisebb prioritás stb stb...
Ha nagyon sok queue-t használsz az persze lassít a dolgon, de egy ilyen méretű projektnél 5-6 különböző sorbaáállítást símán el tudnék képzelni. Maga a parancs feldolgozása sem kell hogy egytlen logikai lépés legyen. Gondolkodhatsz itt is abban, hogy különböző parancsokra más-más thread-ek működnek.
59

Queue

janoszen · 2007. Okt. 21. (V), 13.48
Nem kell több queue, max pioritásonként bontva, elég ha a sorból az első időben esedékes feladatot kiveszed.
60

Re: Queue

ErdosJ · 2007. Okt. 21. (V), 14.46
most -azt hiszem- ez van. tombokkel. ciklussal vegigjarja a tombot, es amikor talal egy idoben esedekes elemet, a hozza tartozo parancsot vegrehajtja, majd torni.
61

Nem jó annyira

janoszen · 2007. Okt. 21. (V), 15.17
Nem jó a megoldás annyira. Sokkal inkább azt kéne csinálni, hogy ha talál egy végrehajtandó eseményt, elindít egy új szálat és a főszál tovább nézi a queue-t.
62

Re: Nem jó annyira

ErdosJ · 2007. Okt. 21. (V), 16.51
hmm.. ez tetszik.
koszonom, neki is allok megcsinalni.
63

Wait

janoszen · 2007. Okt. 21. (V), 18.06
Arra figyelj, hogy ha indítasz egy új szálat, akkor a szál befejezése után wait()-elj majd egyet a főszálban, különben tele leszel zombi-processzekkel.