Szukam dowolnego materiału na bezproblemowych serwerach MMO! Mam kilka artykułów w książkach „Massively Multiplayer Game Development” i „Game Programming Gems 5.” Czy ktoś ma doświadczenie na ten temat lub zna artykuły na ten temat?
Interesują mnie „widoki wysokiego poziomu”, a także implementacje. To może stać się tematem mojej pracy magisterskiej i chciałbym dowiedzieć się, jak ciężko jest napisać taki system, zanim zacznę pracę magisterską. W tej chwili nie zdecydowałem, którego języka użyć, myślę o Javie lub Scali. Erlang może być wyborem, ale nigdy nad tym nie pracowałem.
Uwaga: Podstawowym wymaganiem byłby ruch. Wszelkie inne systemy gier są opcjonalne i dają „kredyt premiowy”.
Teraz, co mam na myśli przez „bezproblemowy serwer”: Chcę tak skonfigurować klaster serwerów, w którym każdy węzeł kontroluje pewną część świata gry ze statycznymi granicami. Gracze mogą teraz przenosić się z jednego krańca świata na drugi bez zmiany instancji lub trafienia w jakiś „teleporter”. Myślę, że WoW to robi. Jednak w moim back-endie odtwarzacz przechodzi z jednego serwera na drugi.
źródło
Odpowiedzi:
Podstawowa złożoność zarządzania takim systemem wynika z tego, jak płynnie potrzebujesz. Jak powiedział Josh, kluczowym elementem pakietu jest rozwiązanie problemu przekazywania jednostki z jednego serwera na drugi.
Nie jest to jednak jedyny problem - jeśli podmioty na wielu serwerach muszą wchodzić w interakcje w ramach jednej operacji, masz teraz problem z synchronizacją, w którym każdy system potrzebuje danych z drugiej strony, aby kontynuować, ale zanim te dane dotrą, może już jest nieprawidłowy. Możesz spróbować rozwiązać ten problem, dzieląc operację na wiele wiadomości z możliwością cofnięcia, jeśli jedna strona się wycofuje, ale jak widzieliśmy w rozdziale 3.1 w „Rozwój gry wieloosobowej”, znacznie komplikuje to logikę gry, którą musisz zrób to z. Scala i Erlang pomagają prawidłowo skonfigurować system przesyłania wiadomości - nie pomagają w rozkładzie funkcji 10-liniowej na wiele różnych komunikatów i stanów, które należy teraz śledzić.
Oczywiście ten problem nie jest całkiem nowy, a relacyjne bazy danych obsługują ten problem, przechowując wszystkie dane centralnie i umożliwiając wielu klientom wysyłanie zapytań i modyfikowanie go w razie potrzeby, wycofując transakcje w razie potrzeby. Daje to większość wymagań dotyczących poprawności, ale niestety narzuca niepraktyczne problemy z wydajnością, a także sprawia, że implementacja logiki gry jest niewygodna (ponieważ duża część logiki jest teraz zapisana w procedurach przechowywanych w bazie danych). Dobrym rozwiązaniem może być inny rodzaj bazy danych, zwłaszcza jeśli chcesz odrzucić wymagania dotyczące niezawodności, które zapewnia większość RDBMS.
Większość profesjonalnych gier rozwiązuje ten problem, nawet go nie próbując, utrzymując rozmiar odłamka na tyle mały, aby umieścić wszystkich graczy na jednym serwerze, dzieląc świat na części, które tak naprawdę nie wchodzą w interakcje (patrz przykład WoW w komentarzach powyżej) lub poprzez dystrybucję gry między serwerami w oparciu o funkcję, a nie położenie geograficzne (np. cała walka odbywa się na jednym serwerze, wszystkie czatują na innym), aby nie było żadnych „szwów” do walki.
źródło
Wdrożenia są na ogół dość głęboko zaangażowane i prawdopodobnie nie będziesz tutaj dużo o nich mówić. Oprogramowanie StackExchange nie nadaje się do tego rodzaju zaangażowanych dyskusji, nie wspominając o tym, że wymagałoby to znacznej inwestycji czyjegoś czasu.
Nie mniej lub bardziej trudny niż jakikolwiek inny system: będzie zależeć od twoich wymagań i funkcji, które zamierzasz prowadzić. Możesz pisać trywialne implementacje w trywialny sposób, ale nietrywialne rzeczy będą oczywiście znacznie trudniejsze. Jednym z większych problemów jest to, że prawdopodobnie nie będziesz mieć wystarczającej liczby prawdziwych klientów, aby stwierdzić, czy Twój system rzeczywiście skaluje się do „ogromnego” poziomu, na którym działają WoW i inne gry.
MMO nie są magiczne. Większość ich technologii nie jest niczym specjalnym, gdy jest rozpatrywana w oderwaniu, po prostu wiele mniejszych, prostszych kawałków technologii łączy się bardzo inteligentnie, aby umożliwić połączone równolegle symulacje na większą skalę dla pewnego wspólnego stanu świata.
Zasadniczo chodzi o przekazanie symulacji. Można to zrobić po prostu i niekoniecznie jest to technologia specyficzna dla MMO (gry peer-to-peer obsługują wszystkie te same podstawowe mechanizmy implementacji migracji hosta). Podstawowym założeniem jest, aby każdy serwer rozumiał topologię serwerów „wokół niego” (w szczególności serwer dla węzła światowego A musi wiedzieć o serwerach dla sąsiadujących z nim symulacji węzłów światowych), a także zdefiniować bufor, wokół którego uważasz, że konkretny symulowany obiekt „blisko” sąsiedniego serwera.
Gdy jednostka wejdzie do bufora „zamykania”, zaczniesz raportować go również na sąsiednim serwerze. Gdy jednostka przekroczy rzeczywisty próg, wysyłasz komunikat do sąsiedniego serwera z pełnym stanem jednostki oraz komunikat wskazujący, że sąsiedni serwer powinien przejąć jednostkę. Oczywiście chcesz, aby była to jak najbardziej niezawodna.
źródło