Techniki, algorytmy i zasoby MMO do utrzymywania niskiej przepustowości?


9

Czy są jakieś zasoby i dokumentacja na temat tego, jak obecne MMO przetwarzają dane akcji i ruchu od kompresji do obsługi na kliencie? Jakieś zasoby na algorytmy przewidywania ruchu?

Szczególnie interesują mnie te, które mają ruch wsad i skupiają się na utrzymywaniu niskiego opóźnienia. Jaka jest także szybkość i rozmiar pakietu dla różnych typów MMO (pod względem sieci)?

Czy istnieje sposób na skalowanie szybkości pakietów lub całkowite wyłączenie niektórych pakietów, jeśli gracz nie może ich dosięgnąć lub w późniejszym przypadku je zobaczyć?

Odpowiedzi:


9

Cóż, jest ta książka - która jest już trochę stara i nigdy tak naprawdę jej nie czytałem, ale pochodzi od renomowanego wydawcy. Znalazłem też ten , który jest nowszy, ale nigdy wcześniej o nim nie słyszałem. Oba twierdzą, że obejmują kwestie związane z tworzeniem gier MMO (lub przynajmniej online); to powiedziawszy, przewidywania po stronie klienta są mniej więcej takie same, niezależnie od skali Twojej bazy współbieżnych graczy, a Google ma wiele informacji na ten temat .

Ważne jest, aby zdać sobie sprawę, że z praktycznego punktu widzenia deweloperowi niezależnemu / hobbystycznemu trudno jest stworzyć grę, która będzie na tyle popularna, że ​​nawet zdobędzie wystarczającą liczbę graczy, aby osiągnąć teoretyczną szczytową współbieżność na tyle wysoką, że można ją uznać za „masywną”. Ale techniki te mogą nadal być edukacyjne do badań.

Istnieją dwie główne klasyfikacje rzeczy, które możesz zrobić:

  • Bądź agresywny, wysyłając tylko minimalną ilość danych do minimalnego zestawu klientów, którzy ich potrzebują.
  • Zaprojektuj grę, która nie zachęca graczy do nadmiernego gromadzenia się, pomagając w utrzymaniu niewielkiej liczby „klientów, którzy potrzebują” rzeczy.

Drugi to tak naprawdę problem z projektowaniem gier i manipulacjami społecznościowymi - jest to szczególnie trudne, ponieważ gry wieloosobowe są naturalnie społecznościowe, to część ich atrakcyjności, więc nie chcesz zbytnio zniechęcać grup graczy. Z drugiej strony, gra, w której wszyscy na świecie odradzają się jako ten, który upuści najlepsze łupy w grze, będzie trudna do skalowania.

W przypadku pierwszej opcji możesz rozważyć wielopoziomowe przesyłanie wiadomości - o innych graczach zawsze warto wiedzieć, na przykład pozycje. Ale inne rzeczy, takie jak zdrowie, mogą nie być tak ważne dla obiektów, których aktualny gracz jeszcze nie widzi, więc zamykasz to, co wysyłasz do tego gracza, na podstawie względnej odległości wszystkich innych istot w jego pobliżu - jest to zasadniczo dławienie dane, które wysyłasz, jak wspomniałeś w ostatnim fragmencie pytania, a także ich filtrowanie.

Bardzo duże architektury dla wielu graczy będą również buforować raporty, które nie muszą być natychmiast podejmowane. Wiadomości zapisywania znaków wysyłane na serwer można wykonywać w delcie, z pełnymi aktualizacjami tylko w krytycznych punktach, a te aktualizacje można buforować na serwerze dławiącym, aby były wysyłane do serwera, który faktycznie przechowuje dane postaci, okresowa moda - w miarę skalowania bazy odtwarzacza musisz się martwić o optymalizację IO dysku oraz ruch sieciowy. Nie chcesz powodować, że baza danych postaci zostanie zniszczona.

Szybkość i rozmiar pakietów różni się znacznie w zależności od gry, podobnie jak w przypadku gier innych niż MMO. To jest naprawdę bardzo specyficzne dla wymagań i nie ma uogólnionych standardów.


1
Jest też kontynuacja pierwszej książki (Massively Multiplayer Game Development 2). Moim zdaniem nie jest to wyjątkowo przydatna seria książek (zdecydowanie nie jest to książka typu „od początku do końca”, jak w większości książek dla twórców gier), ale omawia niektóre teoretyczne problemy zadane w tym pytaniu. A może bardziej przydałby się komuś, kto już częściowo opracował MMO.
Ricket

5

Oprócz powyższej odpowiedzi przeczytaj w TCP_NODELAY i o tym, jak działa skalowanie okien. Zrozumienie szczegółów TCP (i tak, chcesz używać TCP, a nie UDP, chyba że perspektywa obsługi różnicowych aktualizacji przychodzących poza kolejnością brzmi zabawnie) i retransmisja jest krytyczna dla kontroli opóźnień.


4
Powtórzę, że jeśli używasz aktualizacji różnicowych (zwykle binarnych różnic struktur w grze) i używasz czegokolwiek z dostawą poza kolejnością (niezawodne lub nie), będziesz tego żałować. Ludzie, którzy nie lubią TCP w grach, po prostu nie wiedzą wystarczająco dużo o tym (na przykład wiedzą, co robi NODELAY). UDP ma sens w przypadku takich danych, jak dane głosowe, w których pakiety poza kolejnością można po prostu upuścić, co rzadko zdarza się w grze.
coderanger

1
„rzadko ma to miejsce w grze”? Pod warunkiem, że serwer podaje mi autorytatywne stany gry w każdej klatce, nie dbam o to, co się działo w przeszłości. Prosta monotonicznie rosnąca liczba ramek z pakietów UDP jest do tego idealna. Ile danych naprawdę potrzebujesz do niezawodnego przesyłania?
ChrisE

2
„Pod warunkiem, że serwer podaje mi autorytatywne stany gry w każdej klatce” Jasne, jeśli traktujesz to jako pewnik. Zauważ, że powiedziałem „jeśli używasz aktualizacji różnicowych”, co byłoby przeciwieństwem strobowania pełnego stanu każdej klatki. W MMO o dowolnym poziomie złożoności dla świata szybko stanie się niemożliwym częste wysyłanie pełnych aktualizacji.
coderanger

1
Nawet jeśli wyślesz pełny stan rzeczy, które się zmieniają, możesz mieć problemy z dostawą poza kolejnością, w której scalanie rzeczy może być niemożliwe. Pomyśl o aktualizacjach „x = 1, y = 2”, a następnie „y = 1, z = 2”. Jeśli przychodzą one do tyłu, musisz upuścić „pierwszy”, aby wartość y była poprawna, ale wtedy tracisz zmianę na x.
coderanger

1
@Adam Dlatego powiedziałem, że powinieneś przeczytać specyfikację TCP i zrozumieć, jak działa skalowanie okien i jak współdziała z retransmisją ;-) Przepisywanie TCP jest w zasadzie zawsze złe, szanse na zepsucie go wynoszą prawie 100%. Jeśli chcesz mieć niezawodną dostawę w porządku, nie powinieneś używać UDP.
coderanger
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.