System powtórek: nagrywać dane wejściowe lub zdarzenia?

Przeczytałem: Jak zaprojektować system powtórek Ale tak naprawdę nie odpowiada na moje pytanie.

Moja gra jest zbudowana z „widokiem” gry klienta jako oddzielnego programu od „modelu” i „kontrolera” serwera. (trochę jak MMO lub dowolna gra wieloosobowa zbudowana w ten sposób). Strona serwera jest zawsze „prawdą” gry, akceptuje tylko żądania akcji jako dane wejściowe od klientów oraz zdarzenia wyjściowe i komunikaty „bieżącego stanu”.

Model gry i zasady są w pełni deterministyczne z ustalonym cyklem aktualizacji „tykania”, więc po stronie serwera mogę rejestrować zarówno zdarzenia wysyłane do widoków klienta, jak i żądania akcji. Oba są powiązane z określonym numerem cyklu.

Pytanie brzmi: w takim przypadku, aby skonfigurować system odtwarzania, czy powinienem użyć danych wejściowych, żądań akcji użytkownika (jak tam sugerowano) lub zdarzeń?

Wydaje mi się, że oba dałyby dokładnie taką samą moc wyjściową. Jedyne różnice, które widzę to:

• Zdarzenia dają rzeczywisty wynik, podczas gdy żądania akcji muszą być przetwarzane w celu podania zdarzeń.
• Żądania akcji mogą wymagać znacznie mniej danych do zarejestrowania.

Czy są jeszcze inne rzeczy do rozważenia?

Biorąc pod uwagę system deterministyczny, są one logicznie równoważne, więc twoje podsumowanie jest prawie prawidłowe. Są jednak jeszcze 2 rzeczy, które skłoniłyby mnie do rejestrowania działań wejściowych zamiast zdarzeń wyjściowych:

1. Jeśli zapiszesz akcje, możesz ich później użyć jako danych testowych, ponieważ wykonują więcej kodu niż tylko odtwarzają zdarzenia. Może to pomóc w diagnozowaniu błędów awarii, znajdowaniu regresji behawioralnych między kompilacjami itp.
2. W przyszłości możesz zmienić zdarzenia wysyłane dla określonej akcji lub z różnych powodów możesz wysyłać różne zdarzenia do różnych klientów. W takim przypadku powtórka może stać się nieprawidłowa lub niekompletna. Ten sam problem teoretycznie może dotyczyć danych wejściowych, ale zwykle dziedzina danych wejściowych jest bardziej ograniczona niż dane wyjściowe, a zatem jest mniej prawdopodobne, że ulegnie zmianie i łatwiej będzie ją dostosować, gdy będzie to możliwe. (Dane wejściowe są ograniczone do tego, co może zrobić odtwarzacz i inne źródła danych wejściowych (np. Generator liczb losowych), podczas gdy dane wyjściowe obejmują wszystkie wyniki tych danych wejściowych oraz wszelkie inne dane wyjściowe generowane przez reguły gry, takie jak wskazówki dotyczące prezentacji, okresowe informacje o serwerze imprezy towarzyszące itp.)

Oba działają, choć należy wziąć pod uwagę kilka rzeczy.

Najpierw pamiętaj, że musisz zapisać informacje o czasie. W przypadku gier z dowolną zmienną liczbą klatek na sekundę może to być szczególnie trudne; musisz upewnić się, że dane powtórki mogą zawierać dokładnie takie same informacje o czasie, jak gra pierwotnie używana do symulacji.

Musisz także uwzględnić poprawki w zachowaniu gry. Jeśli zarejestrujesz dane wejściowe, a następnie poprawisz dowolną część sposobu, w jaki dane wejściowe są obsługiwane, jak fizyka rozwiązuje itp., Twoje nagranie staje się nieważne. Nawet jeśli nagrywasz wydarzenia z gry, a jakakolwiek część ich interpretacji zmienia się, utkniesz.

Jeśli chcesz tylko odtworzyć, dobrym rozwiązaniem jest zapisanie konkretnej listy pozycji i obrotów dla podmiotu gracza wraz z informacjami o taktowaniu. Wyłącz jak najwięcej fizyki i innej logiki rozgrywki podczas odtwarzania. To, jak łatwe lub wykonalne, zależy od liczby innych obiektów, które należy zsynchronizować.