Система воспроизведения: запись входов или событий?

Я прочитал это: Как спроектировать систему воспроизведения, но она не отвечает на мой вопрос.

Моя игра построена с клиентом «просмотр» игры как отдельная программа от сервера «модель» и «контроллер». (немного похоже на mmo или любую многопользовательскую игру, созданную таким образом). Серверная сторона всегда является «правдой» игры, она принимает только запросы действий в качестве входных данных от клиентов и выходные события и сообщения «текущего состояния».

Модель и правила игры полностью детерминированы с фиксированным циклом обновления «тиков», поэтому на стороне сервера я могу записывать как события, отправленные клиентским представлениям, так и запросы действий. Оба связаны с определенным номером цикла.

Вопрос заключается в следующем: в этом случае, чтобы настроить систему воспроизведения, я должен использовать ввод, или запросы действий пользователя (как там предлагается) или события?

Мне кажется, что оба дадут одинаковый результат. Единственные различия, которые я вижу:

• События дают реальный результат, в то время как запросы действий должны быть обработаны, чтобы дать события.
• Запросы действий могут быть гораздо меньше данных для записи.

Есть ли другие вещи, чтобы рассмотреть?

При наличии детерминированной системы они логически эквивалентны, поэтому ваше резюме в значительной степени верно. Однако есть еще две вещи, которые побудили бы меня к записи действий ввода, а не событий вывода:

1. Если вы сохраните действия, вы сможете позже использовать их в качестве тестовых данных, так как они используют больше вашего кода, чем просто воспроизведение событий. Это может помочь в диагностике ошибок, обнаружении поведенческих регрессий между сборками и т. Д.
2. В будущем вы можете изменить события, которые вы отправляете для определенного действия, или вы можете отправлять разные события разным клиентам по какой-то причине. В этом случае воспроизведение может стать недействительным или неполным. Те же проблемы могут теоретически применяться к входным данным, но обычно область входных данных более ограничена, чем выходные, и поэтому с меньшей вероятностью изменится и будет легче приспособиться к обратной совместимости, когда это произойдет. (Входные данные ограничены тем, что может делать игрок и другие входные источники (например, генератор случайных чисел), тогда как выходные данные включают в себя все результаты этих входных данных плюс любые другие выходные данные, сгенерированные правилами игры, такие как подсказки представления, периодические серверные параллельные мероприятия и т. д.)

Либо работает, хотя есть несколько вещей, которые следует учитывать.

Во-первых, помните, что вам нужно записывать информацию о времени. Для игр с любым типом переменной частоты кадров это может быть особенно сложно; Вы должны убедиться, что ваши данные воспроизведения могут предоставить ту же самую информацию о времени, которую игра изначально использовала для симуляции.

Вам также необходимо учитывать твики к поведению игры. Если вы записываете ввод, а затем настраиваете любую часть того, как обрабатывается ввод, как физика разрешается и т. Д., Ваша запись становится недействительной. Даже если вы записываете игровые события, если какая-то часть того, как эти события получают интерпретируемые изменения, застревает.

Если вы просто хотите воспроизведения, хорошим подходом является запись определенного списка позиций и поворотов для объекта игрока вместе с информацией о синхронизации. Отключите как можно больше физики и другой логики игрового процесса во время воспроизведения. Насколько это легко или выполнимо, зависит от того, сколько других объектов вам нужно синхронизировать.