Sistema de reproducción: ¿entradas de registro o eventos?

Leí esto: Cómo diseñar un sistema de repetición Pero en realidad no responde a mi pregunta.

Mi juego está construido con el cliente "vista" del juego como un programa separado del servidor "modelo" y "controlador". (un poco como un mmo, o cualquier juego multijugador construido de esta manera). El lado del servidor es siempre la "verdad" del juego, solo acepta solicitudes de acción como entrada de los clientes y eventos de salida y mensajes de "estado actual".

El modelo y las reglas del juego son totalmente deterministas con un ciclo fijo de actualización "tick", por lo que en el lado del servidor puedo registrar tanto los eventos enviados a las vistas del cliente como las solicitudes de acción. Ambos están asociados a un número de ciclo específico.

La pregunta es: en este caso, para configurar un sistema de reproducción, ¿debo usar la entrada o las solicitudes de acción del usuario (como se sugiere allí) o los eventos?

Me parece que ambos darían exactamente el mismo resultado. Las únicas diferencias que puedo ver son:

• Los eventos proporcionan la salida real, mientras que las solicitudes de acción deben procesarse para proporcionar eventos.
• Las solicitudes de acción pueden tener muchos menos datos para registrar.

¿Hay otras cosas a considerar?

Dado un sistema determinista, son lógicamente equivalentes, por lo que su resumen es bastante correcto. Sin embargo, hay 2 cosas más que me influirán para registrar acciones de entrada en lugar de eventos de salida:

1. Si guarda las acciones, puede usarlas como datos de prueba más adelante, ya que ejercitan más de su código que la reproducción de eventos. Esto puede ayudar a diagnosticar errores de bloqueo, encontrar regresiones de comportamiento entre compilaciones, etc.
2. En el futuro, puede cambiar los eventos que envía para una determinada acción, o puede enviar diferentes eventos a diferentes clientes por algún motivo. En este caso, la reproducción podría volverse inválida o incompleta. En teoría, el mismo problema podría aplicarse a las entradas, pero por lo general el dominio de las entradas está más restringido que las salidas y, por lo tanto, es menos probable que cambie y sea más fácil adaptarse con compatibilidad hacia atrás cuando lo hace. (Las entradas están limitadas a lo que el jugador y otras fuentes de entrada (por ejemplo, generador de números aleatorios) pueden hacer, mientras que las salidas incluyen todos los resultados de esas entradas más cualquier otra salida generada por las reglas del juego, como sugerencias de presentación, servidor periódico- eventos paralelos, etc.)

Cualquiera de los dos funciona, aunque hay algunas cosas a considerar.

Primero, recuerde que necesita registrar la información del tiempo. Para juegos con cualquier tipo de velocidad de fotogramas variable, esto puede ser particularmente complicado; debes asegurarte de que tus datos de repetición puedan proporcionar exactamente la misma información de sincronización que el juego originalmente utilizado para la simulación.

También debes tener en cuenta los ajustes en el comportamiento del juego. Si graba la entrada y luego modifica cualquier parte de cómo se maneja la entrada, cómo se resuelve la física, etc., su grabación se vuelve inválida. Incluso si registra eventos del juego, si alguna parte de cómo esos eventos se interpretan cambia, está atascado.

Si solo desea reproducciones, un buen enfoque es registrar una lista específica de posiciones y rotaciones para la entidad del jugador junto con información de sincronización. Deshabilita la mayor parte de la física y otra lógica de juego mientras ejecutas la reproducción como puedas. Lo fácil o factible que esto sea depende de cuántos otros objetos necesite sincronizar.