Quel est l'avantage de performances d'enregistrer tous les caractères connectés dans les MMO à intervalles réguliers?


26

La majorité des MMORPGS ont un système Worldsave qui enregistrera tous les personnages une fois toutes les X heures. Je suppose que la raison en est la performance. Alors, pourquoi est-ce mieux, en termes de performances, que d'enregistrer un personnage lors de la déconnexion?


34
Ce n'est pas pour la performance; c'est sacrifier un peu de performance pour l' exactitude , ce qui est plus important.
Mason Wheeler

Le temps joue-t-il vraiment un rôle ici? AFAIK, chaque action dans un mmo est enregistrée immédiatement. Vous obtenez un élément et cet élément est ajouté sur le serveur sans délai à votre compte, sinon le serveur devrait se rappeler que vous l'avez fait et le faire 5 minutes plus tard, ce qui n'a aucun avantage. Ou le client devrait se souvenir et l'envoyer 5 minutes plus tard, ce qui vous ouvre maintenant au piratage, car pendant ces 5 minutes n'importe qui peut modifier / ajouter des données à envoyer.
Espérons

4
@HopefullyHelpful Non, ce n'est pas vrai. Chaque action dans un MMO est en mémoire immédiatement, mais c'est transitoire. Tout enregistrer directement sur un stockage persistant est encore beaucoup trop cher, même avec des SSD. Même avec des jeux qui enregistrent directement dans une base de données, la base de données elle-même n'enregistre pas ces données sur le disque immédiatement (ou du moins enregistre uniquement un journal des transactions, pas les données cohérentes - cela doit être reconstruit en cas de plantage et prend un certain temps). peu de temps). Mais économiser sur la déconnexion est une mauvaise idée pour une autre raison - la cohérence.
Luaan

1
Je pensais que cette question allait être plus dans le sens de l'avantage de la performance de l'enregistrement des personnages à intervalles vs en temps réel.
Anthony

2
@Luaan: Il est parfaitement possible d'enregistrer chaque changement d'état sur un stockage persistant, même sur des disques durs mécaniques. (Vous pourriez en avoir besoin de quelques-uns sur des serveurs occupés). L'astuce consiste à ne pas mettre à jour des objets individuels. Au lieu de cela, vous enregistrez un journal des transactions "Player (A). Inventory + = Object (B)`. Périodiquement, vous videz l'état complet. Pour récupérer, vous rechargez la dernière sauvegarde complète et appliquez les dernières transactions du journal des transactions. Puisque vous 'écrivez un fichier séquentiellement, vous atteignez des performances de pointe pour les disques durs mécaniques. Mais pour garder le journal des transactions de taille raisonnable, vous avez besoin des sauvegardes complètes périodiques.
MSalters

Réponses:


66

Ce n'est pas pour la performance. Il s'agit d'une sécurité intégrée. Si le monde enregistre toutes les quelques minutes, si quelque chose arrive au serveur et qu'il s'arrête, tout le monde ne perdra que quelques minutes de progression.

En enregistrant lors de la déconnexion, si le serveur a un problème, tout le monde perdra tout ce qu'il a fait depuis sa connexion. Pour ceux sur des sessions de jeu particulièrement longues (comme cela est courant dans les MMO), ils perdront une quantité importante de données.

Ils sacrifient un peu de performance pour éliminer le risque de perte massive de données.

Bien sûr, vous pouvez facilement stocker les données du lecteur sur les machines clientes, ce qui réduit le trafic réseau. Le problème ici est qu'il est ouvert au piratage. Une fois qu'une personne sait comment tricher, elle la partage et tout le monde le fait.


EDIT: Comme l' a souligné @Philipp , cela supprime également la possibilité de dupliquer des éléments. Avec un système de sauvegarde sur déconnexion si une transaction est effectuée avant un crash du serveur et qu'une personne se déconnecte avant le crash, les deux joueurs sont rétablis à la dernière fois qu'ils se sont déconnectés, soit en supprimant les éléments, soit en les dupliquant.


Les commentaires ne sont pas pour une discussion approfondie; cette conversation a été déplacée vers le chat .
Josh

5

Les premiers systèmes qui enregistraient uniquement lors de la déconnexion avaient également tendance à enregistrer régulièrement lorsque le joueur était actif. Dans ces systèmes, généralement des MUD (donjons multi-utilisateurs), le personnage était conservé en mémoire jusqu'à ce qu'il soit périodiquement transféré dans un fichier.

Cela signifiait que si un utilisateur se déconnectait sans "camper", il se retrouvait généralement à plusieurs chambres de distance et manquait un tas de butin, XP, etc., lors de la dernière sauvegarde. À cet égard, cela se comportait beaucoup comme la façon dont les RPG de console jouent aujourd'hui (vous devez sauvegarder votre jeu sans éteindre la console, ou vous perdez tout depuis la dernière fois que vous avez enregistré).

Le système fonctionnait conformément à sa destination, car les personnages ne pouvaient pas interagir les uns avec les autres, sauf éventuellement par le biais d'un système de "messagerie" où ils pouvaient s'envoyer des messages et des éléments. Les chances de perdre des objets et de progresser avaient tendance à être assez importantes, mais n'affectaient qu'un personnage à la fois dans la plupart des cas.

La fonctionnalité de sauvegarde du monde est née parce que les personnages ont finalement pu interagir directement les uns avec les autres, de sorte que tous les personnages jouant devaient être dans un état cohérent, sinon la duplication et la suppression d'éléments pourraient se produire. Ce n'était pas un problème dans le scénario MUD, car il était difficile d'abuser du système d'une manière qui entraînait une duplication des articles ou des devises, mais c'était incroyablement facile à faire dans les premiers MUD MMO. Le joueur A donne au joueur B un élément, le joueur B sauvegarde et le joueur A se déconnecte sans sauvegarder. Duplication instantanée.

Worldsave n'est pas un avantage de performance, mais conçu pour empêcher la tricherie. Je me souviens avoir joué sur des systèmes où l'événement worldsave a été littéralement annoncé à l'avance, et souvent suspendu le système entier pendant une minute pendant que le serveur mettait à jour tous ses fichiers. Bien que cela ait empêché la triche, ce n'était pas très pratique pour les utilisateurs de ces systèmes.

Cela nous amène à l'état actuel des choses. Aujourd'hui, nous n'utilisons pas les fonctions de type worldsave. Nous utilisons des bases de données. Cela nous permet de nous assurer que la duplication et la suppression sont réduites autant que possible. Les personnages existent sous forme d'enregistrements dans une base de données, et chaque transaction entre joueurs est une transaction de base de données littérale; soit l'action est entièrement validée, soit elle sera annulée.

À moins de bugs inhabituels dans le système, vous bénéficiez des avantages de l'enregistrement de fichiers de caractères individuels (temps de sauvegarde rapides) et des avantages de worldsaves (pas de tricherie), sans les inconvénients de l'un ou l'autre (perte de progression significative et duplication d'éléments).

Lors de la conception d'un MMO moderne, vous souhaitez créer des procédures stockées dans une base de données et utiliser ces procédures pour effectuer des transactions. Par exemple, lors d'un échange entre deux joueurs, cela pourrait ressembler à ceci:

start transaction;
insert into inventory (playerid, itemid) values (111, 222);
delete from inventory where playerid=111 and itemid=444;
insert into inventory (playerid, itemid) values (333, 444);
delete from inventory where playerid=333 and itemid=222;
commit;

(Remarque: ce SQL n'est pas écrit de manière pratique et est uniquement destiné à être un exemple).

De cette façon, s'il y a un crash avant la validation, le système revient à un état où le joueur 111 et le joueur 333 ont toujours les objets d'origine, tandis qu'après la validation, le commerce est terminé. Il n'y a aucune possibilité de duplication, car les personnages sont enregistrés en même temps, comme le garantit la base de données.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.