Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP][AJAX][inne]pytanie
Forum PHP.pl > Forum > Przedszkole
tsdarky
Witam mam prosbe o rozwiazanie mojego malego problemu. Otoz tworze gre MMORPG via www. Gra toczy sie w czasie rzeczywistym gdzie akcje graczy i botow sa widoczne dla kazdego gracza np. gracz A ruszyl sie na pole XY i gracz B widzi ten ruch bez odswiezania strony. I tu pojawia sie problem a w zasadzie to dylemat jakiej technologii uzyc aby bez odswiezania strony gracz B widzial ruch gracza A.
Do wyboru mam AJAX, AS lub JAVA ktory z tych jezykow najlepiej pasowal by do gry oraz nie zarzynal przegladarki i serwera?


ps. gra przewidziana jest na 200-500 graczy online
Spawnm
Nadaj sensowny tytuł.
vokiel
AJAX to nie jest język programowania tak jak JAVA.

W tym przypadku użycie ajaxa jest jak najbardziej na miejscu.
tsdarky
Wybaczcie brak ladu w poprzednim poscie ale pisalem go w nocy smile.gif moje pytanie mialo brzmiec nastepujaco: ktora z ponizszych technologii najlepiej nadaje sie do stworzenia interaktywnej mapy gdzie gracze obserwuja poczynania innych graczy w czasie rzeczywistym bez koniecznosci przeladowania strony.

Osobiscie chcialem wykozystac AJAX ale przeczytalem gdzies na tym forum, ze przy duzej ilosci obiektow z interwalem co sekunde zarzne urzytkownikowi przegladarke.

Dlatego prosze o szersze i bardziej szczegolowe odpowiedzi:
- dlaczego ta technologia a nie inna
- plusy i minusy wykozystania jej w mojej grze


Z gory dziekuje i pozdrawiam
erix
Przy takim obciążeniu dobrze byłoby napisać natywną aplikację kliencką. ;]

Cytat
Osobiscie chcialem wykozystac AJAX ale przeczytalem gdzies na tym forum, ze przy duzej ilosci obiektow z interwalem co sekunde zarzne urzytkownikowi przegladarke.

Órzydkownigowi nitz bendzie. Fajnie się czyta? To nie kalecz naszych oczu.

Grupuj żądania po kilka i wysyłaj parę operacji w jednym. Jeśli zależy Ci na nie wykorzystywaniu zewnętrznych wtyczek, zostaje właściwie tylko i wyłącznie AJAX. Musisz porobić testy, gdyż po pierwsze: nie wiemy, co konkretnie będziesz przesyłał, po drugie: jak często i w jakich ilościach.
tsdarky
Cytat
Przy takim obciążeniu dobrze byłoby napisać natywną aplikację kliencką. ;]

Za wysokie progi jak na moje nogi smile.gif

Cytat
Órzydkownigowi nitz bendzie. Fajnie się czyta? To nie kalecz naszych oczu.

Ty natomiast nie kalecz sobie palcow na wypisywanie takich komentarzy. Kazdemu moze sie przytrafic blad.

O jakich zewnetrznych wtyczkach mowisz?

Przesylanie danych odbywac sie bedzie co sekunde:
- polozenie gracza na mapie
- atrybuty gracza: wyglad, nick, klasa postaci itp.
- akcje gracza: stoi, rozmawia, walczy itp.
- teksty wypisywane w shoutboxie
- polozenie potworow na mapie
- akcje potworow: stoi, walczy itp.

Ostatnio przegladalem pare gier via www w poszukiwaniu odpowiedniej technologi i jedna z nich napisana jest w pelni w AS i przy obciazeniu 200-300 graczy dziala bez zadnych problemow([LINK] ) i tu pojawiaja sie moje watpliwosci czy napewno AJAX to jest to czego potrzebuje smile.gif
erix
Cytat
Ty natomiast nie kalecz sobie palcow na wypisywanie takich komentarzy. Kazdemu moze sie przytrafic blad.

To się go poprawia albo korzysta ze sprawdzania pisowni. Jesteśmy w Polsce i piszemy po polsku. Temat: Ortografia w postach

Cytat
Przesylanie danych odbywac sie bedzie co sekunde:

Co sekundę? A na co taka rozdzielczość? Na np. shoutbox wystarczy w zupełności co 10 sekund, zawsze można wysyłać nagłówki, czy coś się zmieniło, czy nie - jeśli tak, to wymuszasz zestawienie dodatkowego połączenia XHR, na żądanie, żeby tylu danych nie przesyłać.

Ogólnie rzecz biorąc, AJAX będzie tu dość wąskim gardłem, a to z tej racji, iż będzie wymagał każdorazowego zestawiania połączenia HTTP (TCP), co już samo w sobie jest i zasobożerne, i czasochłonne. Nie wiem, czy można by było tu wykorzystać flasha, który trzymałby połączenie keep-alive i komunikował się tak, jak komunikatory. Ciężko mi się w tej sprawie wypowiedzieć, gdyż moja znajomość ActionScript jest na poziomie dość podstawowym. ;]
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.