1. Nie mowie o stronie klienckiej.
2. Mowie kuwa, ze UE3 nie nada sie od strony serwera. To znaczy, ze najprawdopodobniej wytna modul sieciowy i przepisza swoj wlasny. Bo beda dwa wyjscia. Albo przysytosowac serwer pod UE3, ale jeden modul z UE3 pod serwer.
3. Przeciez kurna mowie o tym, ze maja wlasne siecowe technologie od tego, dlatego uzyja z UE3, tylko czesci odpowiedzialnej za grafike.
4. Tylko przetwarza informacje GG.
a) Serwer musi sledzic pozycje graczy
b) musi przetwarzac to co sie dzieje w okolicy (wszystkie ruchy, powiadamiac klienta, gdzie sie znajduja inni gracze, obiekty, moby etc). Oczywiscie w graniach rozsady, dlatego zazyczaj implemetuje sie jakis algorytm ktory dzieli calosc na strefy (np. wookol graczy), w zasiegu ktorych serwer bedzie ich powiadamial o zmianach, zeby nie zajechac maszyny..
c) aly szeroko pojety combat jesli liczny po stronie serwera
d) JEsli gra posiada jakas fizyke/detekcje kolicji etc, to tez jest sprawdzane po stronie serwera (i do tego musi byc synchornizowane z innymi graczami).
e) pewnie jest jeszcze kilka rzeczy o ktorych nie wiem, a ktore serwer robi, zeby ograniczyc mozliwosc cheatowania do minimum.
Nie gadaj glupot, ze klient wiecej robi. Klient interpretuje tylko nadchodzace dane.
To tak jakbys powiedzial, ze wiecej robi czesc ktora wyswietla to forum, niz baza danych + kod umozliwajacy dostep do niej..

Nie mowie ze jest debilizmem. Mowie ze debilizmem bedzie uzywanie czesci siecowej kiedy ma sie juz gotowe technologie. Oczywiscie, mozna i pewnie bedzie trzeba przystosowac protokoly tak zeby serwery mogly sie dogadywac z klientem. Z tym ze zmodyfkowanie czesci siecowej unreala engine ebdzie prostsze niz serwerowej.

Ty jeszcze lepszy. Jak kiedys sprobojesz napisac mmo, bez takiego podzialu to życzę powodzenia w zajezdzaniu serwera i ogolnie obslugi takiej gry od tej strony -;-.

Iniside ma racje, klient jedynie odbiera dane i je wyświetla, nic nie przetwarza i jest tak nie tylko w mmo, ale i na wszelkich "zamkniętych serverach", np BattleNet. Dlatego też ludzie grając w warcrafta wolą grać na LC (gra na lanie), bo wtedy informacje nie przechodzą drogą client-server-host i na odwrót, tylko bezpośrednio dzięki czemu jest mniejsze latency.

gdyby rzeczywiscie tak bylo, to przy pingu 200ms mialbys fps rowny 5... no bo wkoncu za wszystko odpowiada serwer :)


Detekcja kolicji etc, wystepuje takze po stronie klienta, gdyby wszystko musialo byc kontrolowane przez serwer to albo wszystko byloby powolne w uj, albo serwer bylby totalnie przeciazony.

Klient musi odpowiadac za spora czesc gry by odciazyc serwer. serwer ma jedynie sprawdzac klienta i informowac klienta o zmianach etc.

Czesc graficzna silnika o ktorej mowisz odpowiada jedynie za renderowanie grafiki... nic wiecej, tak wiec animacja, fizyka, i cala reszta musialby zajmowac sie serwer... to by bylo czystym debilizmem. pewnie nawet dzwieki by byly streamowane ze strony serwera ? wszelkei dane na temat modeli ? :)

dlatego dotychczas wiekszosc gier mmo ma kolizje proste jak budowa cepa a uzywanie skilli ciagle opiera sie na target lock, bo server inaczej nie wydoli. Gry MP w ktorych client sprawdza wiekszosc rzeczy to gry z dedykowanymi serverami stawianymi przez uzytkownikow, najczesciej FPSy. Gdyby client a nie server w grach mmorpg sprawdzal takie rzeczy jak to czy kula ognia trafiła przeciwnika, to mialbys mase cheaterow.

co ma fps clienta do pingu?

Nie. Moze nie zuwayzles ale gry mmo sa proste jak cep. Od usera to sa wrecz prymitywne.. Dlatego nie ma czegos takiego jak sledzenie pociskow (wszelkich), zaawansowana fizyka, ba nawet detekcja kolizji opiera sie na boxach (dlatego postacie wisza w powietrzu).

Detekcja kolizji jest po stronie serwera. Glownie dlatego zeby nieodchodzily takie bajki jak kogos gonisz on sie zapda w ziemie, bo sobie klienta zmodyfikowal..

Animacja, jest renderowana przes silnik. Fizyka tylko czesciowo.

Pyanie. Czys ty kiedys projektowal gre, czy tak sobie poczytales propagadne tworcow unreal engine ? .

Pytanie, czy ty kiedys napisales cos poza kalkulatorem w jakims visualu? Obstawiam studenta informatyki, ktory niewiele sam napisal ale naczytal sie duzo i wszystko mu sie wydaje proste. Programista teoretyk.

No... macie racje grafa w tej grze jest calkiem fajna

nie wiem jak on, ale ja owszem i wygląda to dokładnie tak jak on napisał

W sumie programowanie to w duzej mierze teoreyzowanie, bo same jezyki to tylko narzedzie od implemetacji.
Pozatym nie mowilem ze pisalem. Robilem tylko projekt gry . Na pisanie mi juz nie starczylo checi :<.
Po drugie nie mowie ze jest proste. Bo nie jest. Problem w tym, ze ktos juz wczesniej wypracowal odpowiednie rozwiazania, wpadl tu taki Razoth ktory naczytal sie propagadny Epic i mysli, ze Unreal Engine 3 potrafi kawe zrobic..

a widziales ty kiedys w zyciu Planetside ? :)


co do fpsa, biorac pod uwage to co mowi inside, czyli to ze klient jest czystym silnikiem graficznym, to nawet gdyby renderowalo ci 100fps, to w rzeczywistosci bys widzial jedynie 5 fps, bo wkoncu silnik by dostawal informacje co renderowac tylko 5 razy w ciagu sekundy.


Kolejna sprawa: dajmy na to ze idziesz postacia, biorac pod uwage ze za wszystko odpowiada serwer i masz laga, to przechodzisz przez mury, obijasz sie o sciany, do tego postacie skacza z miejsca na miejsce...

bo wkoncu niema wykrywania kolizji po stronie klienta, niema przewidywania zdarzen, klient jedynie wyswietla informacje ktore przesle mu serwer.


Edit: inside, chetnie zobacze gre ktora zaprojektowales :) mozesz podac namiary ? :)

No to juz wiem skad twoja pewnosc siebie. Kazdy problem mozna rozwiazac na wiele sposobow, wlasnie teoretycznie zazwyczaj wszystko wydaje sie latwe. Implementacja i debugowanie jest prawdziwym problemem. Programowanie to zdecydowanie praktyczna dyscyplina. Przeczytanie dowolnej ilosci ksiazek nie da ci tyle co napisanie samodzielnie kawalka kodu. Zachecam, zebys sprobowal jednak cos napisac.

Nie zobaczysz bo napisalem, ze skonczylo sie na projekcie .

Nie mowilem ze jest czystym silnikiem graficznym . Czysty silnik graficzny to co najwyzej moze ci model w bluebox renderowac i obrcac .
Napisalem, ze OGROM informacji jest przetwarzany bezposrednio na sewrerze i dopiero potem przekazywany do klienta. Co zreszta widac. Kiedy w grze dostajesz laga to nagle stoisz wmiejscu albo sie teleportujesz z mniejsca na miejsce...

Ale kiedy wszystko jest normalnie co kilka sekund klient wysyla informacje do serwera o polozeniu (oczywiscie najlepiej byloby to robic jak najczesciej, ale w tedy zbyt latwo przeciazyc strone kliencka), dlatego np. synchornizacja polozenia nastepuja co kilka sekund (powiedzmy co 2). Zalezy jak to jest rozwiazane (np. w miejscu gdzie jest duzo poruszajacych sie obiektow moze byc czestsza zeby zachowac wrazenie plynnosci), a w przypadku np. mobow/npc mozna zastosowac jakis algorytm predykcji ktory z wyprzedzeniem wysle przewidywane polozenie npc.

Co ma alg do przechodzenia przez sciany ? Jak masz zalga to zazwyczaj cie freezuje w jednym miejscu, a nie magicznie zaczynasz przenikac przez wszystko. Aktualny stan twojej postaci jest zazwyczaj cachowany do jakiegos podrecznego binarnego formatu i trzymany w ramie, i co X czasu zapisywany do bazy danych. Jak bedziesz mial laga, to poprostu zawartosc cachce sie nie zmieni i juz.

Zreszta. Chodzi o to ze czesc sieciowa UNreal Engine 3 nie nadaje sie na mmo i koniec. NCSoft ma wlasne technologie, ktore sa juz pod tym wzgledem przetestowane. A algorytmy sieciowe to nie sa algorytmy fizyki/grafiki ze dla kazdej platformy trzeba zaczynac od zera, zeby to bylo strawne.


Implementacja == wymyslenie algorytmu.
Wymyslanie algorytmu == malowanie na papierze/scianie/czym chcesz roznych smiesznych rzeczy (ja do prywatnego uzytku preferuje kolka, kreski i cyferki).
Ty chyba przez programowanie rozumiesz wykucie na pamiec jakis ~70 polecen wbudowanych w jezyk (o jakis biblitekach nie mowie, bo tego nikt normalny sie na pamiec nie uczy).
Zachecac nie musisz, Dziekuje.
Bede obstawial przy swoim, do czasu az ktos mi tu zaproponuje rozwianie inne niz podalem a nie bedzie mowil ze modul sieciowy UE3 nadaje sie do gry mmo.

i dokładnie tak jest, w csie jak masz laga to masz freeza, w grach na silniku Quake 3 postaci rzeczywiście przechodzą przez ściany, ale to dlatego, że tam nie jest przesyłane tylko x,y,z co jakąś dziesiątą sekundy, ale również wektor prędkości dzięki czemu gra jest bardziej płynniejsza i można rzadziej aktualizować pozycje.


Wytłumacze Ci jak działa silnik sieciowy. Wciskasz klawisz ruchu, do servera jest przysyłana informacja np x+=3 y+=0, czyli zmiana pozycji, server sprawdza czy na nowej pozycji nie ma kolizji, jeśli jest to pozostaje stara pozycja, jeśli nie ma to wysyła Tobie i innym graczom (w MMMORPG tylko tym którzy są w pobliżu) Twoją nową pozycje i w tym momencie trzeba dodać, że gra u Ciebie nie staje w miejscu, tzn ona cały chodzi z jakąś tam swoją prędkością przetwarzania informacji (dla różnych gier jest to różna wartość, potocznie zwana stepami).
teraz zakładając, że server przesyła Ci nowe położenie 5 razy w ciągu sekundy oznacza tylko tyle, że Twoja pozycja będzie aktualizowana 5 razy na sekundy, natomiast na fpsy nie pływa to w praktycznie żadnym stopniu. Sytuacja o jakiej Ty mówisz wystąpiłaby jeśli klient nie miał by nawet silnika graficznego, jedynie zasoby, a informacje o tym kiedy i gdzie ma być narysowany sprite/polygon, whatever, przesyłałby server.
samo przeczytanie książek na pewno nie da umiejetnosci pisania gry, ale ZNACZNIE pomoże. Gdybym najpierw troche poczytal przed zabieraniem sie za pisanie silnika sieciowego, to może nie musiałbym odkrywać koła na nowo, a tak zrobiłem zasadniczy błąd, czyli praktycznie nie rozniacego sie klienta od servera. Klient sprawdzal swoje kolizje, server swoje i praktycznie mial nazwe server tylko dlatego, ze on "tworzył gre w sieci" do ktorej klient pozniej mogl dołaczyć. Skutek tego był taki, że jak ktos mial nawet niewielkie doswiadczenie w pisaniu gier, mogl w pare minut napisac hacka zmieniajacego wszystkie statystyki postaci na Twoje widzimisie.
Dla przykładu CS jest tak napisany, że informacja gdzie gracz trafił pociskiem musi być przetwarzana na kliencie i stąd się biorą aimboty, na szczęście są jeszcze anti-hacki, ale one działają dopóki ktoś ich nie obejdzie. Sprawdzania wszystkiego na serverze nikt nie obejdzie, bo musiałby mieć dostęp do servera.

*gleba*


poddaje sie :)


@ inside: nikt nie mowi ze netcode z unreal engine ma sie nadawac do mmo, wlasnie mowimy o tym ze tylko netcode z silnika zostanie zmieniony, tymczasem ty piszesz ze wszystko poza silnikiem graficznym bedzie zmienione :)

@quasi: wyobraz sobie taka sytuacje, ze klient i serwer zarowno sprawdzaja kolizje... dzieki temu gracze nie wchodza w sciany, a cheaterzy nie zapadaja sie pod ziemie :) wiem ze dla ciebie to skomplikowane w uj, wkoncu jak to mozliwe by serwer i klient wykrywal kolizje... przeciez cheaterzy moga zmodyfikowac kod i wchodzic pod ziemie... ale wtedy serwer informuje ze jest to niemozliwe, i wysyla do klienta o tym informacje, jezeli gra jest shackowana i olewa takie informacje to owy osobnik stoi sobie pod ziemia i nic nie widzi, tymczasem wszyscy inni widza go jakby stal w miejscu _na_ziemi_ no ale rozumiem ze to zbyt skomplikowane dla twojej wyobrazni...

pieprzysz mi o cs i quaku ale widac nigdy nie grales na silniku unreala gdzie jest przewidywanie zdarzen :)


no ale juz eot z mojej strony, poddaje sie :)

Chodzi oto ze dodatkowa synchornizacja, bedzie spowalaniac calosc a to jest niedopuszczalne w MMO, gdzie na serwerze robi sie jeszcze dziesiatki innych rzeczy.
Wezmy wowa. Niby banalnie prosta gra (i tak w sumie jest). Ale jeden Realm to tak naprawde klaster serwerow (afair 3 albo 4)..
Widzisz problem w tym, ze nie trzeba implementowac dwa razy tej samej funckjonalnosci. wystarczy jeden raz 0o.

Ashton, Razoth. What the difference. ;)

No wlasnie nie. Implementacja to zakodowanie algorytmu w konkretnym jezyku programowania.

Straszenie dziwne wnioski wyciagasz. Oczywiscie, ze uczysz sie podejscia do programowania, technik, algorytmow etc. Z tym, ze cala ta wiedza niepoparta praktyka w dowolnym jezyku jest NIC nie warta.
@Quetzacotl Ja nie neguje wagi etapu projektowania, z tym ze powoli mieszane sa tutaj dwie fazy: projektowania i developerki, ktora wykonuja odrebni ludzie.

Right, no big deal anyway .


E, dla mnie najgorsze jest wymyslenie.
Zaprogramowanie to juz pikus umiesz jeden jezyk, umiesz wszystkie, bo logika w kazdym jest taka sama.
No tam takich cudow, jak COBOL, Lisp, smalltalk nie licze. (ok Delphi to tez dla mnie sie tam zalicza).

W malych zespolach za projektowanie i programowanie odpowiadaja ci sami ludzie.
Zreszta, to ostatnio popularne podejscie, bo kto lepiej zrozumie projekt niz osoba(by), ktore go zrobily ?

Miedzy jezykami proceduralnymi a obiektowymi, asemblerami, skryptowymi etc. tez nie ma roznicy? Przeciez w kazdym pisze sie zupelnie inaczej. Na dodatek przy duzych projektach, rzadko caly system powstawje w jednym jezyku. Chociazby z przyczyn optymalizacyjnych uzywa sie kilku. Patrz chocby eve, gdzie czesc kodu powstala w javie, a czesc z tego co pamietam w c.

Nie pracuje w branzy gier, ale przy duzych projektach tworzenia oprogramowania biznesowego dla firm ten proces jest rodzielony. Maly team moze conajwyzej girki w javie na komorke robic.

Nie zalapales o co mi chodzilo .
Roznica pomiedzy C/C++C#/Java przy pisaniu algorytmow sa kosmetyczne. Dopiero przy wiekszy projektach wychodza rozne rzeczy (jak obiektowosc).
O roznych takich pisalem, moj blad ze nie umiescilem tam assemblera .
EVE jest akuart pisane w Pythonie (nie pamietam jaka nazwe ma ta odmiana). Klient jest w 100% w Pythonie (mam chyba jeszcze calosc kodu ktory swego czasu wyciekl), a serwer w sumie tez, tylko niektore wstawi sa zrobione w C++.
Oczywiscie ta odmiana kompliuje sie do kodu binarnego (tzn. ... bardzo latwo sie to dekompiluje jak sie poogoluje za odpowiednimi narzdziami).
W CCP prauja chyba jacys nienawracalni fanatycy Pythona, gdzie oni tam Jave ;o.
Programistow przy grach w zasadzie nie ma za wielu. (oczywiscie zalezy od firmy), ale ogrom czesci tzw. "dev-team" zajmuja graficy, scenarzysci, dzwiekowcy, etc.

Gierki w javie to samemu mozna pisac .