Comment concevez-vous un système d'enregistrement / de relecture pour un jeu qui change fréquemment?

Je travaille dans un MMORPG gratuit et j'ai un problème.

Je développe (avec d'autres personnes) un système d'enregistrement vidéo pour le jeu. L'idée est fondamentalement: nous enregistrons tous les paquets envoyés et reçus avec des horodatages, plus quelques données locales du client, puis les vidons dans un fichier. Pour lire la vidéo, nous émulons simplement tout ce qui se trouve dans le fichier. Nous avons également la possibilité d'exporter la vidéo vers avi avec ffmpeg.

Le problème est: lorsque nous changeons entre les versions du jeu, il est difficile de maintenir la compatibilité descendante pour la vidéo (commandes ajoutées / supprimées, changements de fonction, etc.). Existe-t-il un bon moyen de gérer ce problème? au lieu d'avoir un tas de joueurs différents et de choisir le bon pour chaque version du fichier vidéo?

Il serait utile de savoir comment les autres jeux gèrent cette situation.

Merci pour l'aide, désolé pour mon anglais.

— Marco
source

Tout comme un peu plus de nourriture pour googler / rechercher: La façon dont vous le faites est exactement la façon dont Quake Games a enregistré les démos d'id, en capturant les packages de serveur. Pour autant que je sache, ils n'ont tout simplement jamais résolu les problèmes de compatibilité.

— Michael Stum

J'ai changé le titre de cette question - il ne s'agit pas vraiment des MMO, sauf que les MMO sont les jeux qui changent le plus souvent.

Réponses:

Notre règle de base est de ne jamais modifier un type de paquet existant. Tout est ajouté à la fin d'une commande existante ou d'une nouvelle commande. Cela rend également beaucoup moins probable pour deux personnes de piétiner sur le travail de l'autre.

— coderanger
source

Dans ce jeu, cela se produit. Des paquets sont ajoutés, supprimés, déplacés (par exemple, il y a quelque temps, nous avons décidé de déplacer tous les paquets liés aux commandes GM vers un "paquet étendu", cela se reproduirait probablement lorsque nous réécrirons le système de guildes. Modifier des commandes / fonctions (changer sa fonctionnalité) est moins probable, mais ce n'est pas le point. Vous dites qu'à partir de maintenant, nous ne devrions supprimer aucun paquet, supprimer les commandes, les laisser simplement inaccessibles côté serveur? Merci pour votre réponse!

— Marco

Oui, dépréciez et laissez-les là. Finalement, les vieux éléments peuvent être supprimés, mais généralement après un an ou deux.

— coderanger

En outre, une planification supplémentaire serait utile. Mieux vous planifiez vos paquets maintenant, moins vous devrez effectuer de modifications à l'avenir.

— Kylotan

Le problème est que le jeu change toujours. Nous ajoutons un nouveau paquet presque tous les mois (nous ajoutons de nouvelles fonctionnalités). Et pourtant, nous devons faire beaucoup de changements aux anciennes fonctionnalités de réécriture de paquets et ainsi de suite ... Mais je suppose que nous pouvons laisser les méthodes là et attendre un an pour les supprimer.

— Marco

L'utilisation de types de paquets plus génériques vous aiderait beaucoup ici. Vous ne devriez pas avoir besoin d'ajouter de nouveaux messages pour chaque nouvelle fonctionnalité que vous implémentez.

— Kylotan

Il n'est pas inconcevable, en particulier sur un PC, qu'ils ne font que versionner le code de gameplay et bumpent la version lorsqu'ils apportent une modification qui affecte le système de rejeu. Si le fichier de relecture est étiqueté avec la version du code de jeu avec lequel il a été créé et que le client a toujours accès à cette version, cela devrait fonctionner correctement.

— U62
source

C'est comme ça que j'ai vu cela en pratique, stockez le numéro de version avec le journal de jeu. Bien sûr, vous devez également conserver les versions logicielles précédentes pour relire les journaux précédents, par exemple dans un référentiel de code source, mais vous devriez probablement le faire de toute façon.

— Ian Schreiber

Merci pour votre réponse, le jeu est gratuit (sous licence GPL), donc tout le monde peut accéder aux anciennes versions du jeu, et même compiler le client afin que ce ne soit pas un problème d'en avoir toutes les différentes versions. Ceci est très utilisé, tous les serveurs alternatifs n'utilisent pas les versions les plus récentes, il y a des serveurs qui exécutent des versions de 2004 ..

— Marco

@Marco: Je soupçonne que le fonctionnement de SC2 est qu'il place presque tout le code dans une DLL. Lorsqu'il charge une relecture, il vérifie la version, charge la DLL de cette version et s'exécute. C'est un peu plus compliqué, mais l'utilisateur n'a besoin que d'une seule installation et un exe peut exécuter toutes les anciennes rediffusions.

— Mooing Duck

Une façon de résoudre ce problème est de s'inspirer d'un jeu appelé "Heroes of Newerth". (qui change toutes les +/- 2 semaines) D'après ce que je peux dire:

Utilisez les correctifs diff pour le jeu et les rediffusions.
Tous les replays sont stockés sur le cloud. Ils expirent finalement.
Si l'utilisateur souhaite regarder une ancienne rediffusion téléchargée, il doit d'abord utiliser le bouton "Compatibilité".
Il semble que ce soit à distance diffère de la dernière version; ou dans le cas où la relecture n'est plus stockée, la télécharge puis fait le diff à distance.

Parce que je ne travaille pas chez S2, je ne peux clairement pas dire que c'est ainsi que cela fonctionne. Cependant, j'ai remarqué une tendance marquée à la taille des téléchargements associée à l'âge de la relecture.

Soit cela, soit ils ajoutent des correctifs d'entité au rejeu (par exemple, le sort X a un effet Y au lieu de l'effet Z). Si des informations relatives aux paquets sont également stockées dans la configuration d'entité, cette correction à chaud d'entité vous permettrait également de comprendre les paquets plus anciens.

Je ne voudrais certainement pas stocker le comportement historique du client car cela peut devenir énorme très rapidement. Surtout lorsque le client met à jour par exemple de 10.1.0 à 10.2.0 (car il doit télécharger chaque patch entre les deux versions, au lieu du patch final).

Google Protobuf est une bonne idée en tant que couche de sérialisation, car il prend en charge des éléments comme celui-ci par conception.

— Jonathan Dickinson
source