Sistema de repetição: gravar entradas ou eventos?

Eu li o seguinte: Como projetar um sistema de repetição Mas isso realmente não responde à minha pergunta.

Meu jogo é construído com o cliente "view" do jogo como um programa separado do servidor "model" e "controller". (um pouco como um mmo ou qualquer jogo multiplayer criado dessa maneira). O lado do servidor é sempre a "verdade" do jogo; ele aceita apenas solicitações de ação como entrada dos clientes e eventos de saída e mensagens "estado atual".

O modelo e as regras do jogo são totalmente determinísticos com um ciclo fixo de atualização "tick", para que no lado do servidor eu possa registrar os eventos enviados para as visualizações do cliente e as solicitações de ação. Ambos estão associados a um número de ciclo específico.

A questão é: nesse caso, para configurar um sistema de reprodução, devo usar a entrada ou solicitações de ação do usuário (conforme sugerido lá) ou os eventos?

Parece-me que ambos dariam exatamente a mesma saída. As únicas diferenças que posso ver são:

• Eventos fornece a saída real, enquanto as solicitações de ação precisam ser processadas para fornecer eventos.
• As solicitações de ação podem ter muito menos dados a serem registrados.

Há outras coisas a considerar?

Dado um sistema determinístico, eles são logicamente equivalentes; portanto, seu resumo está praticamente correto. No entanto, existem mais duas coisas que me influenciam a registrar ações de entrada em vez de eventos de saída:

1. Se você salvar as ações, poderá usá-las como dados de teste posteriormente, pois elas exercitam mais seu código do que apenas a reprodução de eventos. Isso pode ajudar no diagnóstico de erros de travamento, na busca de regressões comportamentais entre compilações, etc.
2. No futuro, você poderá alterar os eventos enviados para uma determinada ação ou enviar eventos diferentes para clientes diferentes por algum motivo. Nesse caso, a reprodução pode se tornar inválida ou incompleta. O mesmo problema poderia em teoria se aplicar às entradas, mas geralmente o domínio das entradas é mais restrito do que as saídas e, portanto, é menos provável que seja alterado e mais fácil de acomodar quando houver compatibilidade com versões anteriores. (As entradas são limitadas ao que o jogador e outras fontes de entrada (por exemplo, gerador de números aleatórios) podem fazer, enquanto as saídas incluem todos os resultados dessas entradas, além de quaisquer outras saídas geradas pelas regras do jogo, como dicas de apresentação, eventos paralelos etc.)

Ou funciona, embora haja algumas coisas a considerar.

Primeiro, lembre-se de que você precisa registrar informações de tempo. Para jogos com qualquer tipo de taxa de quadros variável, isso pode ser particularmente complicado; você precisa garantir que seus dados de reprodução possam fornecer exatamente as mesmas informações de tempo que o jogo originalmente usou para simulação.

Você também precisa dar conta de ajustes no comportamento do jogo. Se você gravar entrada e depois ajustar qualquer parte de como a entrada é manipulada, como a física é resolvida etc., sua gravação se torna inválida. Mesmo se você gravar eventos do jogo, se alguma parte de como esses eventos forem interpretados mudar, você ficará preso.

Se você deseja apenas reproduções, uma boa abordagem é gravar uma lista específica de posições e rotações para a entidade do jogador, juntamente com informações de tempo. Desabilite o máximo de física e outra lógica de jogo enquanto estiver executando a reprodução possível. O quão fácil ou viável é isso depende de quantos outros objetos você precisa sincronizar.