Jak zaprojektować system nagrywania / odtwarzania dla często zmieniającej się gry?


10

Pracuję w darmowej MMORPG i mam problem.

Wraz z innymi ludźmi opracowuję system nagrywania wideo do gry. Pomysł jest w gruncie rzeczy: rejestrujemy wszystkie paczki wysłane i otrzymane ze znacznikami czasu oraz niektóre lokalne dane od klienta, a następnie zrzucamy je do pliku. Aby odtworzyć wideo, po prostu emulujemy wszystko, co znajduje się w pliku. Mamy również opcję eksportu wideo do avi za pomocą ffmpeg.

Problem polega na tym: kiedy zmieniamy wersje gry, trudno jest zachować zgodność wsteczną dla wideo (polecenia dodane / usunięte, zmiany funkcji itp.). Czy istnieje dobry sposób na poradzenie sobie z tym problemem? zamiast mieć kilka różnych odtwarzaczy i wybrać odpowiedni dla każdej wersji pliku wideo?

Przydałoby się wiedzieć, jak inne gry radzą sobie z tą sytuacją.

Dzięki za pomoc, przepraszam za mój angielski.


Podobnie jak trochę więcej jedzenia dla googlingu / badań: sposób, w jaki to robisz, jest dokładnie tak, jak Quake Games id nagrywało dema, przechwytując pakiety serwerów. O ile mi wiadomo, po prostu nigdy nie rozwiązali problemów ze zgodnością.
Michael Stum

Zmieniłem tytuł tego pytania - tak naprawdę nie chodzi o MMO, z wyjątkiem tego, że MMO to najczęściej zmieniające się gry.

Odpowiedzi:


8

Naszą podstawową zasadą jest, aby nigdy nie zmieniać istniejącego typu pakietu. Wszystko jest dodawane na końcu istniejącego lub nowego polecenia. To sprawia, że ​​znacznie mniej prawdopodobne jest, aby dwie osoby zaczęły się nawzajem męczyć.


W tej grze to się zdarza. Pakiety są dodawane, usuwane, przenoszone (na przykład jakiś czas temu postanowiliśmy przenieść wszystkie pakiety związane z poleceniami GM do „pakietu rozszerzonego”, prawdopodobnie powtórzy się to, gdy przepiszemy system gildii .. Edycja poleceń / funkcji (zmiana jego funkcjonalności) jest mniej prawdopodobna, ale nie o to chodzi. Mówisz, że odtąd nie powinniśmy usuwać żadnego pakietu, usuwać polecenia po prostu pozwolić im na nieosiągalną stronę serwera? Dzięki za odpowiedź!
Marco

1
Tak, przestarzałe i zostaw je tam. Ostatecznie stare rzeczy można usunąć, ale zwykle dzieje się to po roku lub dwóch.
coderanger

1
Pomocne byłoby także dodatkowe planowanie. Im lepiej zaplanujesz teraz swoje pakiety, tym mniej zmian będziesz musiał wprowadzić w przyszłości.
Kylotan,

Problem polega na tym, że gra ciągle się zmienia. Dodajemy nowy pakiet prawie co miesiąc (dodajemy nowe funkcje). A jednak musimy wprowadzić wiele zmian w starych funkcjach przepisywania pakietów i tak dalej ... Ale sądzę, że możemy zostawić metody tam i poczekać rok, aby je usunąć.
Marco

3
Użycie bardziej ogólnych typów pakietów bardzo by Ci w tym pomogło. Nie musisz dodawać nowych wiadomości do każdej nowej implementowanej funkcji.
Kylotan,

5

Nie jest niepojęte, szczególnie na PC, że po prostu zmieniają kod gry i podbijają wersję, gdy wprowadzają zmiany wpływające na system powtórek. Jeśli plik powtórki jest oznaczony wersją kodu gry, z którym został utworzony, a klient nadal ma dostęp do tej wersji, która powinna działać poprawnie.


Tak widziałem to w praktyce, przechowuj numer wersji z logiem gry. Następnie oczywiście musisz zachować poprzednie wersje oprogramowania, aby odtworzyć poprzednie dzienniki, np. W repozytorium kodu źródłowego, ale prawdopodobnie i tak powinieneś to zrobić.
Ian Schreiber,

Dzięki za odpowiedź, gra jest darmowa (licencja GPL), więc każdy może uzyskać dostęp do starych wersji gry, a nawet skompilować klienta, aby nie było problemu z posiadaniem różnych wersji. Jest to bardzo używane, nie wszystkie alternatywne serwery używają najnowszych wersji, istnieją serwery, które działają w wersjach od 2004 r.
Marco

@Marco: Podejrzewam, że działa SC2, ponieważ umieszcza prawie cały kod w bibliotece DLL. Gdy ładuje powtórkę, sprawdza wersję, ładuje bibliotekę DLL dla tej wersji i uruchamia się. Jest to nieco bardziej skomplikowane, ale użytkownik potrzebuje tylko jednej instalacji, a jeden exe może uruchomić wszystkie stare powtórki.
Mooing Duck

1

Jednym ze sposobów rozwiązania tego problemu jest gra „Heroes of Newerth”. (który zmienia się co +/- 2 tygodnie) Z tego, co mogę powiedzieć:

  1. Użyj łatki różnicowej do gry i powtórek.
  2. Wszystkie powtórki są przechowywane w chmurze. W końcu wygasają.
  3. Jeśli użytkownik chce obejrzeć starą pobraną powtórkę, musi najpierw użyć przycisku „Kompatuj”.
  4. Wygląda na to, że albo zdalne różnice do najnowszej wersji; lub w przypadku, gdy powtórka nie jest już przechowywana, przesyła ją, a następnie wykonuje zdalne różnicowanie.

Ponieważ nie pracuję w S2, nie mogę powiedzieć, że tak właśnie działa. Zauważyłem jednak wyraźny trend wielkości pobierania związany z wiekiem powtórki.

Albo to, albo dodają łatki bytu do powtórki (np. Zaklęcie X ma efekt Y zamiast efektu Z). Jeśli informacje związane z pakietami są również przechowywane w konfiguracji encji, ta poprawka encji na gorąco pozwoli również zrozumieć starsze pakiety.

Zdecydowanie nie zapisałbym historycznych zachowań na kliencie, ponieważ może to bardzo szybko stać się ogromne. Zwłaszcza, gdy klient aktualizuje z np. 10.1.0 do 10.2.0 (ponieważ musi pobrać każdą łatkę między dwiema wersjami zamiast ostatniej poprawki).

Google Protobuf jest dobrym pomysłem jako warstwa serializacji, ponieważ obsługuje takie rzeczy z założenia.

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.