Système de relecture: enregistrer des entrées ou des événements?

J'ai lu ceci: Comment concevoir un système de rejeu Mais cela ne répond pas vraiment à ma question.

Mon jeu est construit avec la "vue" cliente du jeu en tant que programme distinct du serveur "modèle" et "contrôleur". (un peu comme un mmo, ou n'importe quel jeu multijoueur construit de cette façon). Le côté serveur est toujours la «vérité» du jeu, il n'accepte que les demandes d'action en entrée des clients et les événements de sortie et les messages «état actuel».

Le modèle de jeu et les règles sont entièrement déterministes avec un cycle de mise à jour "tick" fixe, donc du côté serveur je peux enregistrer à la fois les événements envoyés aux vues client et les demandes d'action. Les deux sont associés à un numéro de cycle spécifique.

La question est: dans ce cas, pour configurer un système de relecture, dois-je utiliser l'entrée, ou les demandes d'action de l'utilisateur (comme suggéré ici) ou les événements?

Il me semble que les deux donneraient exactement la même sortie. Les seules différences que je peux voir sont:

• Les événements donnent la sortie réelle tandis que les demandes d'action doivent être traitées pour donner des événements.
• Les demandes d'action peuvent contenir beaucoup moins de données à enregistrer.

Y a-t-il d'autres choses à considérer?

Étant donné un système déterministe, ils sont logiquement équivalents, donc votre résumé est à peu près correct. Cependant, il y a 2 autres choses qui pourraient me pousser à enregistrer des actions d'entrée plutôt que des événements de sortie:

1. Si vous enregistrez les actions, vous pouvez les utiliser comme données de test plus tard, car elles exercent plus de votre code que la simple relecture des événements. Cela peut aider à diagnostiquer les bogues de plantage, à trouver des régressions comportementales entre les builds, etc.
2. À l'avenir, vous pouvez modifier les événements que vous envoyez pour une certaine action, ou vous pouvez envoyer différents événements à différents clients pour une raison quelconque. Dans ce cas, la relecture pourrait devenir invalide ou incomplète. Le même problème pourrait en théorie s'appliquer aux entrées, mais généralement le domaine des entrées est plus contraint que les sorties et est donc moins susceptible de changer et plus facile à gérer avec une compatibilité descendante quand il le fait. (Les entrées sont limitées à ce que le joueur et les autres sources d'entrée (par exemple, le générateur de nombres aléatoires) peuvent faire, tandis que les sorties incluent tous les résultats de ces entrées plus toutes les autres sorties générées par les règles du jeu, telles que les conseils de présentation, le serveur périodique- événements parallèles, etc.)

Soit fonctionne, bien qu'il y ait quelques points à considérer.

Tout d'abord, n'oubliez pas que vous devez enregistrer les informations de temps. Pour les jeux avec tout type de fréquence d'images variable, cela peut être particulièrement délicat; vous devez vous assurer que vos données de relecture peuvent fournir exactement les mêmes informations de synchronisation que le jeu utilisé à l'origine pour la simulation.

Vous devez également prendre en compte les modifications apportées au comportement du jeu. Si vous enregistrez une entrée, puis modifiez n'importe quelle partie de la façon dont l'entrée est gérée, de la façon dont la physique se résout, etc., votre enregistrement devient invalide. Même si vous enregistrez des événements de jeu, si une partie de la façon dont ces événements sont interprétés change, vous êtes bloqué.

Si vous souhaitez simplement des lectures, une bonne approche consiste à enregistrer une liste spécifique de positions et de rotations pour l'entité du joueur ainsi que des informations de synchronisation. Désactivez autant que possible la physique et les autres logiques de jeu lors de l'exécution de la lecture. La facilité ou la faisabilité de cette opération dépend du nombre d'autres objets dont vous avez besoin pour synchroniser.