[PHP]Strategia turowa Opcje

[michat34]

Witam, co to strategia turowa chyba kazdy wie Moje pytanie brzmi czy w php dało by sie zrobic internetowa strategie turowa dla dwoch graczy czy do tego potrzeba juz programow pracujacych po stronei klienta albo innego języka?

[redeemer]

PHP na serwerze, javascript po stronie klienta.

[darko]

W turówkach czas nie ma znaczenia, oddajesz turę - request do serwera i zwrotka do klienta, teoretycznie całą logikę można w całości zrobić po stronie serwera np, w php, a zmiany w widoku wyświetlać po stronie klienta. W praktyce chyba najlepiej sprawdziłby się tandem html5 + css3 + ajax (np. jquery) - json - php - zwrotka json - na końcu render zmian po stronie klienta (aktualizacja pozycji, stanów itd.). Na upartego można też zrobić wszystko po stronie klienta, jednak łatwiej będzie można oszukiwać.

[michat34]

ogolnie to czasami czas mialby znaczenie np jakis limit czqsu by sie przydał np. ze ktos ma 5 min na zrobienie ruchu. W kazdym razie w miare zaawansowana znajomosc php i javy dalaby mi mozliwosc zrobienia niewymagajacej turówki?

Ten post edytował michat34 14.08.2012, 10:40:32

[piotrooo89]

pewnie że się da, skoro nie masz konkretnego pytania programistycznego przenoszę do Hydepark.

[michat34]

wlasciwie to mozna zamknac, wiem co chcialem

[Tuminure]

javy dalaby mi mozliwosc

Javascript, a nie Java. Choć w gruncie rzeczy znając Javę, mógłbyś napisać taką grę bez znajomości PHP.

Pozwolę sobie dołączyć swoje pytanie - czy wykorzystanie do takich celów MySQLa to dobry pomysł? A także, czy Websocketsy sprawdziłyby się w takim rozwiązaniu?

Ten post edytował Tuminure 14.08.2012, 11:45:45

[hind]

WebSoket sprawdziłby się gdyby był obsługiwany przez wszystkie przeglądarki, a tak to polecam comet.
Co do MySQL, przy takim zastosowaniu nie powinno mieć znaczenia

[ShadowD]

Comet z tego co wiem też nie jest w pełni obsługiwany? - Może się mylę ogólnie mało info w sieci na ten temat. :-]

Osobiście całość ciepał bym js+php i dało by radę!

[hind]

Comet jest dobrze obsługiwany przez chyba wszystkie przeglądarki obsługujące XHR, cały myk polega na tym żeby w odpytywanym skrypcie dać jakąś pętlę i sleep.
Do póki nie pojawi się jakieś żądanie dla przeglądarki lub timeout, to przetrzymuje się żądanie. jedyne na co trzeba uważać to żeby nic nie wysłać do przeglądarki (zamknięcie połączenia XHR).
Sam planuję przesiadkę z synchronicznych requestów co 60s na long polling (z tym że w moim przypadku muszę najpierw przerzucić się na cgi. apache i mod_php blokuje mi połączenia soketowe o.O).

[rzymek01]

W wolnej chwili zamierzam się zabrać za pewną rzecz opartą o long polling,
sercem ma być usługa (np. skrypt chodzący non-stop) dający co kilka sekund odpowiedź dla max kilkudziesięciu żądań.

Jeszcze się nie zastanawiałem, czy jak pójdzie do usługi x żądań, to wystarczy, że zostanie zwrócona jedna odpowiedź (np. proste echo z nagłówkami) czy dla każdego żądania potrzebna jest odrębna odpowiedź?

[abort]

X przeglądarek z różnych stron Polski próbuje dobić się do Twojego nowego serwisu, a Ty dajesz odpowiedź tylko jednej? No wybacz.

Chyba że źle zrozumiałem Twoje pytanie...

[rzymek01]

Dla przykładu:
sytuacja #1
posiadamy statyczny zasób /img.png do którego dobija się 20 żądań,
jesli zasób jest dostępny każde z 20 żądań uzyska odpowiedź

sytuacja #2
posiadamy dynamiczny zasób /img.png do którego dobija się 20 żądań,
jeśli zasób będzie dostępny za sekundę, to też każde z 20 żądań uzyska odpowiedź

Także przenosząc tę sytuację do naszej usługi, wystarczy, że po kilku sekundach zwróci odpowiedź i 20 żądań zostanie obsłużonych.

Dobrze myślę?

[abort]

Zagwarantujesz (sobie) stałość żądań wszystkich klientów w pewnym interwale czasu?
A jak kogoś przylaguje? A jak komuś przeglądarka się wysypie i po restarcie kompa nadusi w Firefoxie "Przywróć sesję"?
Ogólnie mówiąc, to słabo to widzę. No chyba że zastosować np. logowanie i sesje z bardzo krótkim czasem życia sesji, wtedy może...

[rzymek01]

No tak, temat w kategorii gra turowa, ale mi chodzi o proste pobieranie małych danych co kilka sekund i wyświetlanie ich użytkownikowi,
jeśli jakieś żądanie się niepowiedzie, nie szkodzi, zaraz pójdzie drugie, a dla użytkownika parę sekund w tym przypadku nie robi żadnej różnicy

[ShadowD]

http://designconcept.webdev20.pl/articles/long-polling/ tutaj coś fajnego o Long polling nawet po polsku. A Tworzenie systemu który zakłada jakieś gubienie pakietów to moim zdaniem głupota - będziemy idealni i nie zakładajmy że coś się może zgubić! :-)

[rzymek01]

jesli o mnie chodzi to wiem co to jest Long polling,
tylko nie mogę sobie wyobrazić x żądań do jednego adresu, który nie jest skryptem php tylko usługą non-stop i jak wygląda tutaj zwracanie odpowiedzi

edited:
na początek niech będzie php,
czy skrypt musi się zakończyć, aby została wysłana odpowiedź do przeglądarki?



Ten post edytował rzymek01 14.08.2012, 22:15:50

[hind]

w zależności od konfiguracji, zwykle wystarczy proste echo, czasami flush. Ale ostatecznie nie ma sensu trzymać skrypt wywołany przez XHR po wyświetleniu danych (chyba że są przeprowadzane dodatkowe operacje nie widoczne dla przeglądarki), bo XHR i tak ich najpewniej nie obsłuży.

[darko]

Tutaj można byłoby wykorzystać htmlowy (5) local storage.