Des nouvelles de Icache, l'Inventaire physique et autres gros développements

[Maarkreidi]

Spectrum recèle parfois des perles d'info de la part des développeurs qui parlent librement de certains développements en cours. Ce qui contrebalance le nombre de postes poubelles que l'on peut y voir prospérer.

Récemment  Chad Mckinney, Lead Gameplay Programmer dans les bureaux de Los Angeles a parlé de l'état de gros développements en cours qui n'apparaissent pas sur les feuille de route mais dont nous avons tous entendu parler dans les ISC (Inside Star Citizen) ou dans les rapports mensuels.

On peut considérer ce fil de discussion comme un AMA non officiel qui regorge d'infos à jours.  Bonne lecture messieurs dames.

 

•  Où en sont actuellement iCache et l'inventaire physique ?

ICache, la persistance globale et l'inventaire physique sont plusieurs très grandes fonctionnalités 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 d'icache/global persistence arrivera avant la fin de l'année, mais je ne veux pas préciser de date exacte. Une chose à mentionner, c'est que la persistance à long terme a effectivement retiré certaines ressources au travail sur 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 réel bénéfice. L'inventaire physique dépend fortement de 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 vaisseaux et donc des concepts tels que les éléments détachés et la propriété physique contre la propriété 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 ?

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 est mis hors service, le jeu devient essentiellement injouable. Pour tout le monde ! Le nouvel icache (cache d'éléments) utilise une flotte de services variés pour optimiser les requêtes de manière évolutive, tout en utilisant les meilleures pratiques en matière de tolérance aux pannes et de récupération. Ainsi, par exemple, tous les nœuds voient 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. La nouvelle cache 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 sur les objets 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. Afin d'obtenir un historique du serveur persistant pour tout ce dont vous avez besoin de faire beaucoup de travail dans le code du serveur pour persister et se recharger 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écharger 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 puisse le ramasser. L'inventaire physique repose donc sur la persistance mondiale, qui repose sur icache.

Mais il y a d'autres caractéristiques qui reposent également sur la persistance globale. Par exemple, nous pouvons maintenant explorer un jeu 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 sur une vitre et elle serait endommagée pendant un certain temps jusqu'à ce que des réparations puissent avoir lieu. Cela persisterait même si le server/shard tombait 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 serveur auquel il était associé, donc rapidement, nous faisons tourner une autre instance, elle récupère l'enregistrement du serveur, puis nous pouvons utiliser le match making pour ramener les joueurs dans le serveur auquel ils viennent de perdre la connexion, et boum, ils sont de retour en action là où ils s'étaient arrêtés.

J'espère que cela vous aidera ?

 

• Qu'en est-il de choses comme l'historique des missions et la persistance de la réputation, les missions données par des PNJ qui donne de la réputation. Dans quelles catégories des choses comme cela tombent-elles ?

Celles-ci seront traitées par un ensemble de services et une base de données différents, icache est spécifique à l'état de l'entité 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 mondiale qui viendra après ICache ?

Ces services ne seront pas mis en ligne avec une persistance mondiale, 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 maillage des serveurs et l'une des grandes questions est bien sûr de savoir comment gérer l'état. Ce ne sera pas avec icache, mais on 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.

 

• En deux ans, nous avons découvert que le service d'État de mission doit être remanié en même temps que l'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.

*ndlr : accrochez vous pour comprendre la réponse, ça montre bien la complexité de leur travail.

Oui, mais pendant sa réalisation, nous devrons en fait le pré-décortiquer pour le nouveau cache fractal, pour une interrogation super-liminale à dimension infinie et un stockage qui persiste avant que les choses n'arrivent et renvoie les résultats de l'interrogation avant que les requêtes ne soient envoyées. Il s'agira d'un échouage post-mortem et donc, naturellement, le réseau chiral est une dépendance, mais pas d'inquiétude, 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 3.7 puis 3.9 avant de disparaître, cela signifie-t-il que votre objectif était de mettre en œuvre la persistance d'icache/global dans 3.7 / 3.9 ?

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é.
 

Ajout du 20/05/2020

• 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 bêta ? Par exemple, Elder Scrolls Online utilise des méga-serveurs, qui est un autre terme pour désigner le maillage des serveurs. 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 maillage de serveur 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 que vous êtes en train de réinventer la roue, de perdre du temps que vous pourriez consacrer à d'autres choses.

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 un projet de très grande envergure comme Star Citizen. Tout d'abord, il faut 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 sont loin d'être épuisés. 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 en accès anticipé 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 possède une en ce moment (https://www.ogre3d.org/2019/08/05/voxel-cone-tracing). Pourquoi Epic n'a-t-il pas simplement utilisé l'un des moteurs existants ou vice-versa ? D'une part, pour des raisons de droits de licence ou de problèmes de licence, mais d'autre part sur le plan technique parce qu'une autre implémentation est construite dans un contexte très 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 résoudre très spécifiquement vos problèmes de la manière la plus directe dans le contexte où votre moteur/jeu existe, sans la lourdeur d'une implémentation générique. Il y a toujours un équilibre à trouver, et vous trouverez toujours dans notre moteur un certain nombre d'intergiciels, tels que Wwise, que nous n'avons pas remplacés ou que nous n'avons pas tenté de réécrire. Il faut savoir 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 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 des 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 que dans SC nous essayons de pousser vers une instance unique 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.

 

 

Source :  Spectrum

Trad @Maarkreidi Swissstarships.org

 

 

[LooPing]

Merci @Maarkreidi, très intéressant...

[Maarkreidi]

Petite mise à jour dans le post de tête avec une réponse qui pourrait coller aussi à la fameuse question qu'on voit déferler sur spectrum depuis la sortie de la démo d Unreal Engine 5.