Préserver la mémoire

Dans le cadre du projet EVE Evolved, le travail se poursuit pour mettre à niveau le client et le serveur d'EVE Online de Python 2 à Python 3. Ce travail est important pour garantir que nous disposons de fondations solides sur lesquelles bâtir et nous préparer à de nombreuses années de développement futur.

La maison des archives

Cette dernière édition d'EVE Evolved examine la mémoire des agents NPC, sa gestion bureaucratique du suivi des quelque 100 000 missions attribuées chaque jour, ainsi que certains défis intéressants qu'elle pose et qui pourraient affecter les joueurs à l'avenir.

Dans ce blog, « agent » désigne les agents NPC qui peuplent EVE : ces personnages attachants qui vous demandent (parfois grossièrement) de transporter leurs déchets vers une autre station, d'éliminer la dernière menace pirate ou, de sauver cette demoiselle en détresse pour la énième fois, en échange d'une récompense.

Commencer simplement

Comme vous aimez tous les analyses techniques approfondies, nous allons bientôt entrer dans les détails. Mais pour ceux qui veulent seulement le résumé, voici les points clés :

• Dans le cadre de la modernisation d'EVE Online par le passage à Python 3, des changements doivent être apportés à la façon dont les données des agents NPC sont stockées. Des améliorations en coulisses seront apportées au suivi des missions et autres interactions avec les agents. Cela nécessite de supprimer certaines anciennes données et de convertir celles qui restent dans un format plus pérenne.

  • Ce processus sera en grande partie invisible. Le seul impact perceptible concernera l'ancienne progression des missions, celle enregistrée avant le 29 septembre 2026.

• Votre réputation auprès des NPC est préservée, et tous les agents que vous avez déverrouillés resteront disponibles, même si vous ne vous connectez pas ou n'êtes pas actuellement Omega. Vous ne perdrez aucune progression.

• Si vous demandez une nouvelle mission d'agent (ou réussissez/échouez à une mission existante) à partir d'aujourd'hui, la progression de cette mission sera désormais automatiquement reportée dans la nouvelle mémoire.

• Si vous avez interagi avec un agent AVANT aujourd'hui et que vous n'interagissez pas avec cet agent APRÈS aujourd'hui pour mettre à jour cette progression, les tâches de cet agent seront effacées et supprimées lorsque la migration vers Python 3 sera entièrement terminée.

  • Nous n'avons pas encore de calendrier précis pour cette suppression, car elle ne constitue qu'une partie de l'importante migration vers Python 3. Ce processus prendra des mois, pas simplement des jours. À l'approche de cette échéance, nous vous préviendrons avant d'effacer la mémoire.

  • Si vous avez une mission proposée/acceptée AVANT aujourd'hui et que vous n'interagissez pas avec l'agent pour terminer cette mission après aujourd'hui, sa progression sera effacée ultérieurement, à un moment donné.

  • Si vous avez engagé un agent de recherche pour générer des points de recherche AVANT aujourd'hui, vous devrez accomplir au moins une mission avec cet agent après aujourd'hui pour qu'il reste actif. (Vous n'aurez besoin de le faire qu'une seule fois par agent et par personnage). À terme, nous supprimerons toutes les anciennes missions de recherche qui n'ont pas été touchées depuis aujourd'hui.

En bref, si vous effectuez activement des missions d'agent, vous pouvez continuer à jouer normalement et rien ne changera. Si certains agents vous tiennent à cœur (en particulier les agents de recherche), rendez-leur visite et accomplissez une mission pour eux afin qu'ils ne vous oublient pas.

Maintenant que vous connaissez les bases, si vous souhaitez en savoir plus sur les tendances des agents à accumuler des informations et certains secrets du passé, poursuivez votre lecture…

Le choc de deux mondes

Pour comprendre ce que nous entendons par la mémoire des agents, nous devons d'abord disposer d'un peu de contexte. Si l'on décompose l'ensemble du projet Python 3, cela fait apparaître les grands domaines suivants :

• Exécution - Les exécutables du client et du serveur qui font fonctionner le jeu.

• Données - Les éléments d'information qui définissent l'expérience unique qu'est EVE Online. Ceux-ci peuvent être encore divisés davantage :

  • Données de contenu - Les modèles, textures, mots, statistiques et tout ce que créent nos artistes, concepteurs et rédacteurs. Certaines de ces données vous sont fournies avec le client, et d'autres ne résident que sur nos serveurs.

  • Données réseau - Les paquets d'informations qui circulent via Internet entre votre client et notre serveur, ainsi qu'entre les plus de 200 nœuds de notre cluster de serveurs dans le centre de données.

• Données persistantes - Le « fichier de sauvegarde » toujours plus volumineux qui enregistre les plus de 20 ans de progression qui ont eu lieu dans le jeu. Il s'agit principalement de l'immense base de données SQL au cœur d'EVE. C'est là que réside la mémoire de l'agent.

• Écosystème de développement - Les outils et processus que nous, les développeurs, utilisons au quotidien pour vous proposer ce jeu.

Demande d'agent

Maintenant que nous savons où réside la mémoire de l'agent, nous pouvons parler de ce qu'elle est réellement. Chaque fois que votre personnage interagit avec l'un des agents NPC, nous enregistrons cette information dans la base de données. L'interaction peut consister à demander une nouvelle mission, réussir (ou échouer) une mission proposée auparavant, commencer une mission de recherche ou de localisation, ou obtenir une recommandation auprès de l'un des agents spéciaux du scénario.

Chaque agent connaît l'état de sa dernière interaction avec chaque personnage auquel il a parlé. Si vous êtes allé voir un agent il y a 20 ans et avez commencé une mission visant à récupérer des holobandes douteuses, cet agent se souvient de vous et attend toujours de vous dire que vous n'avez pas accompli le travail dans un délai raisonnable !

Les souvenirs qu'un agent pourrait conserver sur votre personnage incluent :

• La mission qu'il vous a proposée et son état (par exemple, le NPC cible a-t-il déjà été éliminé ?)

• Si l'agent effectue une tâche de recherche et comment celle-ci progresse

• Si l'agent a pour mission de localiser un autre personnage pour vous

• Votre progression dans une chaîne de scénarios

• Les missions d'intrigue épique ou de carrière que vous avez accomplies

Notez que la réputation de votre personnage avec les personnages/corporations NPC ne fait PAS partie de la mémoire de cet agent. La réputation constitue une mécanique distincte avec sa propre méthode de suivi de l'état.

Récupération de données

Enfin, nous pouvons nous intéresser à la manière dont ces données sont stockées et récupérées, ainsi qu'à la raison d'être de ce blog.

Au tout début des années 2000, alors qu'EVE Online achevait sa dernière phase avant son lancement, la base de données de mémoire des agents a été conçue. Le prérequis était de stocker l'état complexe représentant les interactions entre une paire agent/personnage. Normalement, dans la conception de bases de données, nous essayons de construire des modèles très formels de tables et de relations pour de telles données. Mais les prérequis de mémoire des agents étaient plus confus et dynamiques - chaque interaction comportait des ensembles de variables très différents (imaginez décrire une mission de livraison plutôt qu'une recommandation dans le cadre d'un scénario, par exemple), et les conceptions changeaient rapidement à mesure que le jeu évoluait.

À cette époque, le mouvement NoSQL moderne n'avait pas encore commencé. EVE utilisait MSSQL pour sa couche de persistance. Un programmeur astucieux a réalisé qu'il pouvait prendre l'objet Python stockant la mémoire d'un agent, le sérialiser en un blob binaire et stocker ce blob sous forme de texte dans une table de base de données.

Ensuite, la prochaine fois que l'agent est réveillé par une interaction avec un personnage, l'inverse se produit. Le blob binaire de cet agent est récupéré dans la base de données et désérialisé pour le reconvertir en objet Python, qui est ensuite injecté dans l'agent en cours d'exécution, restaurant ainsi sa mémoire. (En Python, ce processus est également appelé pickling et unpickling .)

Bien que cela ait permis de résoudre le problème immédiat, cela a créé deux problèmes futurs :

• Les blobs de mémoire n'étaient pas facilement accessibles aux recherches. La puissance d'une base de données vient de la recherche : trouver toutes les entrées dont un paramètre a une certaine valeur. Mais le fait que chaque mémoire soit contenue dans une enveloppe Python empêchait d'interroger efficacement son contenu. Pour trouver toutes les mémoires liées à la demoiselle susmentionnée, par exemple, il faudrait charger chaque mémoire, une à la fois, dans Python afin de pouvoir la vérifier. Pas idéal.

• Le format des données était lié à la version de Python utilisée. À mesure que le langage Python évoluait, de nouvelles fonctionnalités ont été ajoutées et d'autres ont été dépréciées puis finalement abandonnées. Cela signifiait que, dans un avenir plus ou moins proche, ces souvenirs deviendraient illisibles - perdus, comme des larmes dans la pluie. Avec le passage de Python 2 à Python 3, cet avenir est imminent.

La cachette

Pour expliquer ce problème par une analogie non technique, imaginez que vous deviez entreposer vos affaires pendant votre déménagement. Une solution serait de tout emballer dans un unique et immense conteneur de transport scellé, puis de l'envoyer dans l'entrepôt de stockage (cela correspondrait à « sérialiser » vos données). Cette méthode est flexible (le camion transportant votre conteneur ne se soucie pas de savoir si votre collection de musique contient des vinyles ou des CD), rapide à mettre en œuvre, et le transport de conteneurs est devenu un processus standardisé.

Plus tard, lorsque vous emménagez dans votre nouvelle maison, vous faites livrer le conteneur et pouvez déballer vos biens précieux. Cependant, cela présente un inconvénient : si l'entrepôt doit faire l'objet d'un audit de sécurité pour vérifier qu'il ne stocke aucun matériau illégal, la seule façon de procéder serait d'ouvrir et de fouiller chaque conteneur à la main. Ce n'est pas très efficace.

Équipé pour la tâche

Malgré les inconvénients à long terme de l'approche, elle a fonctionné. EVE Online a été lancé et a perduré. La solution de mémoire de l'agent est restée et a remarquablement bien tenu le coup, avec le recul. Mais rien ne peut durer éternellement.

Nettoyer les archives

La migration vers Python 3 nous offre une occasion en or (que nous ne pouvons pas ignorer… littéralement) de rectifier les péchés de notre passé. Nous devons abandonner le manque de flexibilité et l'obsolescence inhérente au stockage de blobs Python dans une base de données SQL. Parallèlement, nous profitons de cette occasion pour faire du ménage et supprimer une grande quantité de données accumulées. (La table de mémoire des agents est l'une des plus volumineuses de notre base de données, et l'une des rares qui ne fait que croître sans jamais diminuer.)

Le duo de la mort

Ce travail a déjà commencé en coulisses. Nous avons récemment mis à jour la façon dont nous chargeons et enregistrons la mémoire des agents. Chaque fois qu'une nouvelle mémoire doit être enregistrée, nous le faisons désormais sous deux formes parallèles :

• L'ancienne forme opaque de blob Python, exactement comme nous l'avons toujours fait.

• Une nouvelle forme transparente et pérenne, qui ne repose pas sur un format Python particulier, et qui est également ouverte pour une meilleure recherche et une adaptabilité future.

Toutes les nouvelles mémoires et celles mises à jour existeront pour l'instant sous les deux formats. Si vous demandez aujourd'hui une mission à un agent, cette mémoire est enregistrée dans les deux formats. Cela nous permet de choisir le format à privilégier lors du chargement de la mémoire d'un agent. Cela réduit également le risque, car nous pouvons vérifier que les deux formats racontent la même histoire avant de désactiver l'ancienne méthode.

Lorsque nous devons recharger la mémoire d'un agent depuis la base de données, nous disposons désormais de plusieurs options quant à la source traitée en priorité, que nous modifierons en trois phases :

• Phase 1 : Dans un premier temps, nous continuerons à charger uniquement depuis l'ancien stockage, jusqu'à ce que nous soyons convaincus que le nouveau format fonctionne correctement.

• Phase 2 : Nous allons ensuite changer la priorité afin de d'abord rechercher une mémoire dans le nouveau format, puis, si rien n'est trouvé, de revenir au chargement depuis l'ancien formulaire.

• Phase 3 : À terme (lorsque nous aurons entièrement migré tout le reste vers Python 3), nous cesserons complètement de lire l'ancien format. Seules les mémoires sauvegardées dans le nouveau format seront accessibles aux agents. Nous pourrons alors enfin supprimer de la base de données les anciennes mémoires héritées qui n'ont jamais été mises à jour, ce qui ravira nos administrateurs de bases de données.

À compter d'aujourd'hui, toute nouvelle mémoire sera transférée avec nous lors de la migration vers Python 3. Cette migration sera longue, vous aurez donc largement le temps d'interagir avec vos agents, d'obtenir de nouvelles missions ou de terminer celles en cours. Cela se comptera en mois, pas en jours. À l'approche de la phase 3, nous veillerons à vous en informer.

Des matériaux pour se préparer à la guerre

Il existe certaines mémoires que nous devons absolument conserver, quel que soit leur âge, même si le personnage associé ne se connecte pas ou ne génère pas de mémoire mise à jour avec chaque agent. Certaines missions de didacticiel ou d'intrigue épique ne peuvent être effectuées qu'une seule fois, par exemple, nous devons donc en assurer le suivi. Dans ces cas limités, nous migrerons automatiquement les données vers un nouveau format en arrière-plan.

Un élément important de la relation entre les personnages et les agents est leur réputation. C'est ce sur quoi vous travaillez en gravissant les échelons, des agents de niveau 1 aux agents de niveau 4, voire 5. Toutes les réputations entre les personnages et les agents NPC/corporations/factions seront préservées et ne seront pas affectées par ces changements. Ces réputations ne seront ni réinitialisées ni perdues.

En construction

Le travail se poursuit sur la migration vers Python 3. Outre la partie « simple » consistant à convertir le code client/serveur, la mise à jour de tout ce qui entoure le code représente tout autant de travail, voire davantage. Les nombreux outils que nos développeurs utilisent chaque jour. Les nombreuses interfaces où un processus Python communique avec un autre composant via un réseau. Les processus de déploiement qui nous permettent d'appuyer sur un bouton et de mettre une expansion en ligne.

Et, comme nous l'avons vu ici, même les données stockées dans une base de données ont parfois besoin d'être actualisées.

Bon vol, et à bientôt dans un autre blog o7