Система відтворення: записувати входи чи події?

Я читав це: Як створити систему повторної передачі, але вона насправді не відповідає на моє запитання.

Моя гра побудована з клієнтським «поданням» на гру як окрема програма від серверів «модель» та «контролер». (трохи схожа на mmo, або будь-яку багатокористувацьку гру, побудовану таким чином). Сторона сервера - це завжди "правда" гри, вона приймає лише запити про дії як вхід від клієнтів та вихідні події та повідомлення "поточного стану".

Модель і правила гри повністю детерміновані з фіксованим циклом оновлення "галочка", тому на стороні сервера я можу записувати як події, надіслані переглядачам клієнта, так і запити на дії. Обидва пов'язані з певним номером циклу.

Питання полягає в тому, що в цьому випадку для налаштування системи повторення я повинен використовувати введення або запити на дії користувачів (як там запропоновано) або події?

Мені здається, що обидва давали б абсолютно однаковий результат. Єдині відмінності, які я бачу, це:

• Події дають реальний вихід, тоді як запити на дії повинні бути оброблені, щоб дати подіям.
• У запитах на дії може бути набагато менше даних для запису.

Чи варто враховувати інші речі?

Враховуючи детерміновану систему, вони логічно еквівалентні, тому ваше резюме є майже правильним. Однак є ще 2 речі, які б рухали мене до запису вхідних дій, а не до вихідних подій:

1. Якщо ви збережете дії, ви можете використовувати їх як тестові дані пізніше, оскільки вони виконують більше вашого коду, ніж просто відтворення подій. Це може допомогти діагностувати помилки, пов’язані з аварійними ситуаціями, виявлення поведінкових регресій між складами тощо.
2. В майбутньому ви можете змінити події, які ви надсилаєте для певної дії, або ви можете надіслати різні події різним клієнтам з якоїсь причини. У цьому випадку повтор може стати недійсним або неповним. Ця ж проблема може теоретично стосуватися вхідних даних, але, як правило, область входів обмежена, ніж виходи, і тому менша ймовірність змінитись і легше пристосуватися до зворотної сумісності, коли вона є. (Вхідні дані обмежуються тим, що може робити програвач та інші джерела введення (наприклад, генератор випадкових чисел), тоді як вихідні дані включають усі результати цих входів плюс будь-які інші результати, створені правилами гри, наприклад, підказки щодо презентації, періодичні сервери побічні події тощо)

Або працює, хоча є кілька речей.

Спочатку пам’ятайте, що вам потрібно записати інформацію про час. Для ігор з будь-яким видом змінної частоти кадрів це може бути особливо складним; вам потрібно переконатися, що ваші дані відтворення можуть містити таку саму інформацію про час, яку гра спочатку використовувала для моделювання.

Вам також потрібно врахувати зміни в поведінці гри. Якщо ви записуєте вхід, а потім налаштовуєте будь-яку частину того, як обробляється вхід, як вирішується фізика тощо, ваш запис стає недійсним. Навіть якщо ви записуєте ігрові події, якщо будь-яка частина того, як ці події трактуються зміни, ви застрягли.

Якщо ви просто хочете відтворення, хорошим підходом є записування певного списку позицій та обертів для об'єкта гравця разом із інформацією про час. Вимкніть якомога більше фізики та іншої логіки гри під час відтворення, наскільки це можливо. Наскільки це легко чи можливо, залежить від того, скільки інших об'єктів потрібно синхронізувати.