Autor Wątek: PHP/*ServerPages vs C++/C#/Java  (Przeczytany 29787 razy)

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Maj 03, 2007, 21:18:22
Chyba nie chodzi o przerzucanie logiki, ale o pewne czasochłonne obliczenia, że np. dostajesz dane początkowe do bitwy(lub jej fragmentu) i musisz wyliczyć jej przebieg(np. jakąś 2d animację) i wynik.
dokladnie, wystarczy uzywac glownie algorytmow deterministycznych i sprawa zalatwiona.
oczywiscie do losowych elementow przesylamy seed'a z glownego serwera.
kwestia synchronizacji zdarzen pochodzacych od graczy (a te za kija nie sa deterministyczne :P) to juz niestety osobna sprawa...

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline mINA87

  • Użytkownik

# Maj 03, 2007, 22:12:56
Hmm no to sądzę że tych zdarzeń deterministycznych złożonych obliczeniowo zbyt dużo nie będzie, więc i zysk mały.
Moim zdaniem największym obciążeniem jest wielkość świata i jego aktualizacja - musi to być deterministyczne i arbitrażowe, bez błędów synchronizacji, a całość operacji jest stosunkowo tania dla małych światów (ogame itp) ale zapotrzebowanie na kluczowe zasoby zaczyna w pewnym momencie wzrastać wykładniczo. Głównym czynnikiem ograniczającym jest tu chyba pasmo.

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Maj 03, 2007, 22:19:35
Hmm no to sądzę że tych zdarzeń deterministycznych złożonych obliczeniowo zbyt dużo nie będzie, więc i zysk mały.
Moim zdaniem największym obciążeniem jest wielkość świata i jego aktualizacja - musi to być deterministyczne i arbitrażowe, bez błędów synchronizacji, a całość operacji jest stosunkowo tania dla małych światów (ogame itp) ale zapotrzebowanie na kluczowe zasoby zaczyna w pewnym momencie wzrastać wykładniczo. Głównym czynnikiem ograniczającym jest tu chyba pasmo.
tu nie zawsze chodzi o zlozonosc obliczen - to wlasnie pasmo jest oszczedzane, jesli nie musimy wysylac do serwera requesta, a zamiast tego mozna obliczenie przeprowadzic lokalnie, bo samo obliczenie gdzies trzeba powtorzyc - najlatwiej na serwerze - tak aby nie ufac klientom

Offline Goliatus

  • Użytkownik
    • Warsztat - tworzenie gier

# Maj 04, 2007, 08:46:12
Właśnie tutaj jest potrzebna sieć p2p(albo ogólnie sieć połączona ze sobą poprzez serwer gry), żeby te same obliczenia zrobić na dwóch(albo więcej) różnych klientach i dopiero wtedy przyjąć wynik za poprawny, gdy wyniki ze wszystkich się będą zgadzały.

Offline BTM

  • Użytkownik

# Maj 04, 2007, 09:23:26
Oczywiście trzeba na każdym kroku podkreślać, że wszystko co tutaj rozpisujecie zależy od typu gry ;]

Jasne - jeżeli ktoś chce zrobić grę w real-time to powodzenia itp ;]

Ale np. w przypadku tworzonej przeze mnie gry - udział może brać wielu graczy jednocześnie i nie przewiduję większych problemów.

Dla 2 graczy i komputera wygląda to tak:

1: 2 gracze wchodzą na mapę, serwer dodaje komputer
2: każdy z graczy otrzymuje komunikat, czyja teraz tura, pada na gracza 1
3: gracz 2 odpala nasłuch do serwera, pyta się co się dzieje na mapie. Serwer zapisuje timestamp zapytania ( "ping" )
4: graczowi 1 zostaje zdjęta blokada z UI, może wykonać ruch. System wysyła mu zasięg ruchu dla danej jednostki
5: gracz 2 wciąż pyta serwer, co tam słychać, serwer zapisuje timestamp zapytania i sprawdza, czy nic nie wydarzyło się od ostatniego zapytania tego gracza
6: gracz 1 wykonuje ruch, wysyła zapytanie do serwera "hej, chce się ruszyć z A4 na B7", serwer odpowiada "OK", loguje zmianę miejsca i zapisuje go do bazy
7: gracz 2 pyta serwer, co tam słychać, serwer zapisuje "ping" i sprawdza, czy coś się nie wydarzyło od poprzedniego, wyciąga info z bazy i wysyła go do gracza 2
8: gracz jeden wykonuje akcję, operacje podobne do 4-7
9: serwer odpowiada "OK, koniec twojej tury, ruszył się komputer, przemieścił się z X do Y i zaatakował zadając Z obrażeń"
10: to samo info wysyła przy kolejnym pingu od gracza 2 + informuje go, że nadeszła jego tura, przechodzimy do 4: i powtarzamy dla graczy "odwrotnie" ( znaczy, gracz 1 słucha a 2 działa )

Wszelkie sprawdzenia, czy dana akcja może zajść, wykrywanie ścieżki, obliczanie DMG czy inne arytmetyki wykonywane są po stronie serwera, klienta otrzymuje tylko w XML informację, że zaszła zmiana typu przemieszczenie, atak, jakiś inny eventl - na jakim polu się to zdarzyło, z jakiego pola na jakie przeszła jednostka i tutaj już JavaScript przejmuje kontrolę i porusza jednostkami, współczynnikami etc.

Jeżeli jakiś gracz zdejmie sobie ręcznie blokadę z UI, albo wyśle spreparowane zapytanie do serwera, otrzyma odpowiedź z informacją o błędzie i żadna akcja nie zostanie wykonana - nie ma więc potrzeby o zadbanie o synchronizację pomiędzy poszczególnymi klientami, a jedynie pomiędzy klientem a serwerem.

Offline peter

  • Użytkownik
    • BirdStorm.net browser based MMO

# Maj 04, 2007, 10:16:26
@BTM:
hmm, a taki serwer to nie za wiele musi pamietac? skoro zapisuje timestamp zapytnia to domyslam sie, ze po to, zeby wyslac do klienta tylko te zmiany ktore zdarzyly sie w miedzyczasie, a to prawdopodobnie oznacza, ze musi pamietac ogolnie wszystkie (a przynajmniej wszystkie niewyslane) zmiany wraz z timestampami - tego troche moze byc przy wiekszej ilosci graczy... no ale jak sam powiedziales wszystko zalezy od typu gry..

BTW zdaje sie ze obiecales jakies obrazki ze swojego dziela ;)

Offline BTM

  • Użytkownik

# Maj 04, 2007, 10:44:29
Timestamp jest dokładnie po to, by wysłać informacje o wydarzeniach po danej dacie. W moim systemie, walki odbywają się na planszach - nazwijmy je instancjami danej mapy - system tworzy instancję w miarę potrzeb, wysyła do graczy obecnych na danej instancji informacje o zdarzeniach i kiedy wszyscy wyjdą z mapy ( np. zakończono bitwę ) i instancja jest usuwana usuwa też log - nie powinno to marnować przestrzeni. Poza tym, to tylko tekst ( XML ) więc serwery nie takie rzeczy obsłużą ( jeden monster u mnie w pracy, przeze mnie pisany ma aktualnie ~700mbdanych i 13 milionów rekordów ;-) )

Zdjęć nie będę wrzucał, bo to trochę bez sensu, ale filmik się właśnie konwertuje do SWF to wrzucę na stronę do obejrzenia.

Na filmiku jest widok dla 2 graczy w jednym oknie przeglądarki - na screenie pokazane jak to wygląda w całości w chwili obecnej.

http://anfo.pl/world/screen.png

Po prawej menu ze statsami i przedmiotami / akcjami.

http://anfo.pl/world/ - tu filmik

Nie widać tego, bo program przekodował 120mb do 1.2 wycinając klatki :( ale ruchy odbywają się płynnie po 1 px w odpowiednich kierunkach. Po każdej turze muszę wcisnąć turn.end() bo normalnie jest wtedy czas na wykonanie akcji ( atak / przedmiot ) ale niestety nie jest to jeszcze do końca zaimplementowane.

Avatar "rycerza" jest sterowany przez AI i podąża za jednym z graczy ( aktualnie, za tym po lewo ;) ).

Na koniec zaglądamy jeszcze do przesyłanego XML'u.

Offline nameczanin

  • Użytkownik
    • devlog

# Maj 04, 2007, 13:04:20
BTM: polecalbym uzywac XML-a w paczkach naprawde tylko wtedy kiedy jego mozliwosci sa potrzebne... Mowie tutaj o tej hierarchicznej strukturze danych. Strukturze, ktora nie jest do konca do przewidzenia [drzewa danych]. Filmiku obejrzalem kawalek i z tego co widzialem byly tam roznawe parametry postaci, ruch, identyfikacja ruchow ["succes"] itp. Dla bandwidthu bardziej oplacalo by sie napisac swoj interpreter [zamiast uzywania wbudowanego responseXML] i wpakowywac dane bez tych wszystkich klamer itd. ^^ Enkapsulacja danych w tym momencie. Ale to tylko taka moja mala sugestia co do pingow i transferow. Bardzo ciekawe poza tym. Pozdrawiam :)

Offline BTM

  • Użytkownik

# Maj 04, 2007, 13:32:25
Wstępnie używałem własnej "enkapsulacji" danych, ale wraz z rozrostem aplikacji i ilości przekazywanych danych pojawiło się coraz więcej if'ów, whilów i innych takich w kodzie.
Jeżeli chodzi o parser, to używam XML for Script ( http://xmljs.sourceforge.net/ ) żeby działało w miarę bezproblemowo na większości przeglądarek :)

Offline nameczanin

  • Użytkownik
    • devlog

# Maj 04, 2007, 17:30:59
O parser XML sie nie martwie, tylko o transfer :-) Moglbys wrocic do tej enkapsulacji, o ile zaprojektujesz kod tak, zeby nie trzeba bylo duzo zmieniac w jakims tam API samym, ale dosyc wewnetrznie. No chyba, ze az tak wzorcowego kodu nie masz :( Moim zdaniem warto w odpowiednie miejsce powrzucac tej masy if'ow i while'ow w drodze optymalizacji.

BTW dzieki za tak smakowitego linka ^^

Offline BTM

  • Użytkownik

# Maj 05, 2007, 11:58:58
Nie wydaje mi się, żeby byl to aż taki problem - z tego co kojarzę, to zapytania AJAX to "ukryte" wywołanie requestu przeglądarki, więc powinny bez problemu obsługiwać kompresje gzip przesyłanych danych.

Poza tym, "enkapsulacja" we własne formaty mogła by spowodować problemy podczas portowania UI na inne technologie ( tj. flash etc ) - dużo łatwiej posługiwać się jednak XML'em - zawsze można go jeszcze trochę pokastrować i zamiast przekazywać nazwy parametrów przekazywać wartości numeryczne i "resolvować" je po stronie klienta.

// Pozdrowienia z "Metod numeryczych", blah ;-)

Offline peewee

  • Użytkownik

# Marzec 17, 2009, 00:43:32
http://json.org/

W wielu przypadkach lepsza alternatywa XML'a. w Javascripcie (i Actionscripcie) nie trzeba ręcznie parsować, bo się po prostu eval'uje. A po stronie serwera większość rozwiązań (php, python...) ma moduły do serializacji danych w postaci json'a.

Offline Mattrick

  • Użytkownik

# Kwiecień 21, 2009, 23:51:21
Ładnego kotleta żeś odgrzał, nie ma co. :P