Où en sont actuellement l'iCache et l'Inventaire Physique ?
Le genre de question piège d'un bailleur de fonds à laquelle Chad McKinney (Lead Gameplay Engineer) a répondu sur le Spectrum, ainsi qu'à quelques questions qui ont suivies.
Q&R avec Chad McKinney sur l'iCache et la Persistance Globale
Cela fait très longtemps que nous n'avons pas eu de mise à jour, est-ce que CIG peut nous donner plus d'informations ?
Chris a mentionné qu'elle était prévue pour le milieu de l'année, mais au cours des deux derniers patchs, la persistance des navires et des hab n'existe plus et je pense que beaucoup d'entre nous veulent savoir où elle en est maintenant. Je suis sûr que c'est quelque chose que beaucoup d'entre nous attendent avec impatience d'être ajoutés.
L'iCache, la persistance globale et l'inventaire physique sont plusieurs très grandes caractéristiques sur lesquelles travaillent de multiples équipes sous des angles différents. C'est l'une de nos plus grandes priorités en tant qu'entreprise et nous y travaillons activement.
À ce stade, je pense que le niveau 1 de l'iCache/Persistence Globale arrivera avant la fin de l'année, mais je ne veux pas préciser les dates exactes. Une chose à mentionner est que la persistance à long terme a effectivement retiré certaines ressources au travail sur l'iCache, mais nous avons décidé que cela en valait la peine puisque l'amélioration de la qualité de vie des joueurs serait un tel avantage.
L'inventaire physique dépend fortement de l'iCache et de la persistance globale, et tout notre système a été conçu autour de cela (contrairement à l'ancien système qui était entièrement construit autour des ports d'objets sur les joueurs et les navires et donc des concepts tels que les objets en vrac et la propriété physique ou légale n'étaient pas naturels pour fonctionner). C'est pourquoi l'inventaire physique viendra naturellement après l'achèvement de ce travail, bien que nous essayions de trouver des moyens de commencer à travailler en parallèle lorsque c'est possible.
Quelle est exactement la différence entre iCache, Persistance Globale et Inventaire Physique ?
J'ai lu un ancien rapport mensuel où il était appelé pCache.
Quelle est la différence entre pCache et iCache ?
Le pCache (cache de persistance) est l'ancien système, utilisant un cache monolithique pour les requêtes vers la base de données des éléments persistants. Comme vous pouvez l'imaginer, ce système n'est pas très évolutif, et pire encore, lorsqu'il tombe en panne, le jeu devient essentiellement injouable. Pour tout le monde !
Le nouvel iCache (cache d'éléments) utilise une flotte de services proliférante pour optimiser les requêtes de manière évolutive, tout en utilisant les meilleures pratiques de tolérance aux pannes et de récupération. Ainsi, par exemple tous les nœuds ont leurs données répliquées sur le réseau, de sorte que même si l'un d'entre eux tombe en panne, seule une réponse partielle est brièvement perdue et un nouveau est rapidement reconstruit à sa place, d'où une régénération automatique. Le nouvel iCache est également construite en tenant compte de nos systèmes de jeu et en comprenant comment nous devons interroger les données des serveurs de jeu. À ce stade, nous avons une bien meilleure idée du fonctionnement du jeu qu'au moment de la création de l'ancien pCache. Nous pouvons donc concevoir nos données d'articles et notre schéma d'interrogation de manière à rendre ce nouveau système efficace et minimal, ce qui contribuera également à la stabilité et à l'évolutivité.
La Persistance Globale est le terme que certains d'entre vous ont peut-être remarqué que j'ai évoqué dans certains de mes commentaires et c'est parce qu'il s'agit d'un ensemble de fonctionnalités connexes mais différentes qui doivent également être mises en œuvre. Ce n'est pas parce que vous disposez d'une base de données et d'un système d'interrogation performant pour ces données que le jeu les utilise automatiquement dans tous les systèmes de jeu, ni que les serveurs/shards ont un état persistant, mais cela vous donne un outil à utiliser pour activer cela. Pour que l'historique du serveur soit persistant pour tout, vous devez faire beaucoup de travail dans le code du serveur pour qu'il persiste et se recharge dans cet état, c'est la persistance globale. J'en parle tout le temps parce que cela touche beaucoup de choses, par exemple l'inventaire physique. Les inventaires ne sont que des conteneurs d'objets, mais ils sont matérialisés parce qu'ils sont eux-mêmes des entités persistantes avec un état. Cela signifie que vous pouvez avoir un sac à dos contenant des armes ou d'autres objets et avoir un moyen de les ranger/désarrimer de cet inventaire, mais aussi que cet inventaire peut être instancié dans le monde et laissé dans un véhicule ou déposé au sommet d'une montagne sur une lune pour qu'un autre joueur le ramasse. L'inventaire physique repose donc sur la persistance globale, qui repose sur l'iCache.
Mais il y a d'autres caractéristiques qui reposent également sur la persistance globale. Par exemple, nous pouvons maintenant explorer un gameplay qui peut modifier de façon permanente ou à long terme des emplacements dans le jeu, par exemple les dommages causés à une station spatiale. Port Olisar pourrait subir une attaque et elle serait endommagée pendant un certain temps jusqu'à ce que des réparations puissent être effectuées. Cela persisterait même si le serveur venait à tomber en panne, car il n'est plus seulement en état de mémoire. Il y en a encore beaucoup d'autres, comme la récupération complète du serveur après une panne. Les gens se plaignent souvent de la perte de cargaison après un crash du serveur, car nous ne pouvons pas faire revenir les joueurs dans leurs vaisseaux en ce moment après un crash du serveur ; contrairement à un crash du client, nous perdons l'état du serveur. Avec la persistance globale, cela sera enregistré dans l'enregistrement du shard auquel il était associé, donc rapidement, nous pouvons faire tourner une autre instance, elle récupère l'enregistrement du shard, puis nous pouvons utiliser le match making pour ramener les joueurs dans le shard avec lequel ils viennent de perdre la connexion, et boum, ils sont de retour en action là où ils s'étaient arrêtés.
Ne serait-il pas plus rapide de se contenter d'obtenir une licence pour toute la technologie d'un MMO mature, où toutes les choses ont non seulement été programmées, mais aussi corrigées et perfectionnées au fil des ans dans des conditions réelles non beta ?
Par exemple, Elder Scrolls Online utilise des méga-serveurs, qui est un autre terme pour désigner le Server Meshing. Ils enregistrent également des états entièrement persistants pour les objets et les missions et peuvent récupérer tout cela après un plantage du client et du serveur. Et ESO n'est pas le seul jeu où le Server Meshing et la persistance complète sont entièrement mis en œuvre et perfectionnés (c'est-à-dire sans bogue). Ainsi, de grandes portions de leur code pourraient être réutilisées. On a l'impression de réinventer la roue, de perdre un temps que l'on pourrait consacrer à autre chose.
Je vois ce genre de réponse de temps en temps, alors j'ai pensé que je pourrais donner un aperçu des raisons pour lesquelles cette approche ne serait pas la plus logique pour une entreprise de grande envergure comme Star Citizen. Tout d'abord, il s'agit de trouver quelqu'un qui vous accordera une licence pour un produit qui est en fait ce dont vous avez besoin. Il y a bien sûr beaucoup de grands jeux qui ont été réalisés, et beaucoup de moteurs qui ont fait du chemin. L'industrie a en effet résolu de nombreux problèmes en le faisant, par exemple la récente démo technologique d'Unreal 5 a montré des graphismes fous, ce qui est probablement une évolution de leur implémentation de traçage de cône de voxel qui était au début de l'accès dans UE4. Ce que vous ne savez peut-être pas, c'est qu'il existe déjà d'autres implémentations de la même approche dans d'autres moteurs, même Ogre3D en a une en ce moment (Ogre3D Voxel Cone Tracing). Pourquoi Epic n'a-t-il pas simplement utilisé l'un des moteurs existants ou vice-versa ? Eh bien, d'une part, à cause des frais de licence ou des problèmes de licence, mais d'autre part au niveau technique parce qu'une autre implémentation est construite dans un contexte complètement différent. Souvent, vous passerez autant de temps à essayer d'intégrer la solution de quelqu'un d'autre qu'à l'écrire vous-même, mais lorsque vous l'écrivez vous-même, vous pouvez la faire fonctionner de manière très spécifique et résoudre vos problèmes de la manière la plus directe possible dans le contexte où votre moteur/jeu existe, sans le gonflement d'une implémentation générique. Il y a toujours un équilibre à trouver, et vous trouverez toujours dans notre moteur un certain nombre de middleware, tels que Wwise, que nous n'avons pas remplacés ou que nous n'avons pas tenté de réécrire. Il s'agit de choisir ses batailles, et je peux vous dire que c'est souvent une erreur de miser fortement sur vos systèmes fondamentaux les plus importants sur une autre entité et d'espérer que leur solution répond vraiment à vos besoins et que vous obtiendrez le soutien dont vous avez besoin. Cela n'entre même pas en ligne de compte dans la manière dont vous allez prendre en charge votre technologie, ou si vous prévoyez de créer plusieurs jeux ou si vous souhaitez obtenir vous-même une licence pour le moteur. Les jeux vidéo et autres domaines de programmation haute performance bénéficient grandement de solutions spécifiques très pointues, ce qui explique pourquoi, en 2020, de nombreuses très grandes entreprises développent encore leurs propres moteurs et ne se sont pas contentées de converger vers une solution sectorielle unique pour un moteur.
Pour reprendre votre exemple de Elder Scrolls Online, leurs problèmes sont très différents de ceux des Star Citizens. Le système d'inventaire est beaucoup plus simple, et leur persistance dans le monde est inexistante. ESO utilise beaucoup le sharding avec l'instanciation dynamique, alors qu'à SC nous essayons de pousser vers une instance singulière unifiée dans n'importe quelle région et éventuellement dans le monde entier. Il ne serait même pas logique d'essayer de prendre leur infrastructure et de l'intégrer à la nôtre pour résoudre les problèmes que nous voulons résoudre. Source : J'ai travaillé sur Elder Scrolls Online.
Qu'en est-il de choses comme l'historique des missions et la persistance de la réputation ?
La mission qui donne de la réputation, dans quelles catégories cela tombe-il ?
Celles-ci seront traitées par un ensemble de services et une base de données différents, l'iCache est spécifique à l'état des entités dans le jeu, tandis que les missions et la réputation sont un ensemble de données différent.
Leur persistance relèverait-elle de la Persistance globale qui viendra après l'iCache ?
Ils ne seront pas mis en ligne avec une persistance globale, bien que le service de réputation ait déjà été mis en place et que certains travaux sur le gameplay aient déjà été effectués pour le connecter, bien que nous ne l'ayons pas encore vraiment utilisé. Le système de mission subit son propre grand remaniement pour le Server Meshing et l'une des grandes questions est bien sûr de savoir comment gérer l'état. Ce ne sera pas avec iCache, mais il pourrait utiliser un système similaire avec les mêmes types de fonctionnalités, mais pas littéralement la base de données des objets.
Inb4 en 2 ans, nous avons découvert que le service d'état de mission doit être refaçonné avec icache et d'autres services afin de simplifier les opérations de persistance et de réduire le TCO. Un nouveau service appelé uCache (cache universel) a été introduit comme carte sur la feuille de route.
Oui, mais pendant qu'il est en cours, nous devrons en fait le prédéterminer pour le nouveau cache fractal, pour une requête super-liminale à dimension infinie et un stockage qui persiste les choses avant qu'elles n'arrivent et renvoie les résultats de la requête avant que les requêtes ne soient envoyées. Il s'agira d'un échouage post-mortem et le réseau chiral est donc naturellement une dépendance, mais ne vous inquiétez pas, nous avons un homme de confiance dans l'effort de prolifération du réseau.
Donc, lorsque l'inventaire physique était sur la feuille de route pour la 3.7 puis la 3.9 avant de disparaître, cela signifie-t-il que votre objectif était de mettre en œuvre la persistance d'iCache/global en 3.7/3.9 ?
... ou cela signifie-t-il que la feuille de route est pleine de conneries ?
Une des équipes travaillant sur les composants de niveau beaucoup plus élevé de l'inventaire physique avait prévu de commencer à travailler dessus en 3.7, mais il y a eu un désalignement sur la dépendance de l'iCache, c'est pourquoi elle a été repoussée lorsque nous nous sommes alignés. Nous sommes une grande entreprise et aucune équipe ne sait tout, donc ce genre de choses arrive, désolé.
