Chad McKinney, ingénieur gameplay en chef chez Cloud Imperium Games, a pris le temps de répondre à plusieurs questions sur l’iCache, la persistance globale et l’inventaire physique, qui sont en cours de développement et qui risquent de grandement changer la façon de jouer de Star Citizen dans un futur plus ou moins proche. Un grand merci à Insosama qui, en plus de la relecture, a ajouté quelques annotations dans le texte. Pour les afficher, passez votre souris sur les chiffres (exemple : [0]).
Question par TAF
Où en sont actuellement iCache et l’inventaire physique ? – Il y a 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’ils étaient prévus pour le milieu de l’année, mais au cours des deux derniers patchs, la persistance des vaisseaux et des habs n’existe plus et je pense que beaucoup d’entre nous veulent savoir où ils en sont maintenant et attendent avec impatience que ces fonctionnalités soient ajoutées.
Réponse par Chad McKinney
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 au sein de l’entreprise et nous y travaillons activement. À ce stade, je pense que le tier 1 d’iCache et de la persistance globale 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 retiré certaines ressources du travail sur l’iCache, mais nous avons décidé que cela en valait la peine puisque l’amélioration de la qualité de l’expérience des joueurs constituerait un bénéfice. 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 de points physiques identifiés sur lesquels étaient chargés des sous composants, les “ItemPort”, directement sur les joueurs et les vaisseaux. Avec cet ancien système, des concepts tels que les objets en vrac et la propriété physique ou légale n’étaient pas aisément implémentable). C’est pourquoi l’inventaire physique viendra naturellement après l’achèvement de ce travail, bien que nous essayons de trouver des moyens de commencer à travailler en parallèle lorsque c’est possible.
Question par pwazz
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 ?
Réponse par Chad McKinney
pCache (cache de persistance) est l’ancien système, où toutes les requêtes vers la base de données des éléments persistants du jeu étaient stockées dans un cache monolithique. C’est à dire que le cache, une zone mémoire tampon et temporaire, se présentait sous la forme d’une pile d’instruction mémorisée sans tri dans un endroit commun. 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 (“item cache”, ou cache des objets) utilise un ensemble de nombreux services[1] 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, l’ancien mono cache est réparti sur plusieurs noeuds différents et tous ceux ci voient leurs données répliquées sur le réseau. Ainsi, même si l’un d’entre eux tombe en panne, seule une partie des données est brièvement perdue et un nouveau est rapidement reconstruit à sa place, d’où une régénération automatique. Le nouveau cache est également construit en tenant compte de nos systèmes propres et interroge ainsi les données des serveurs de jeu en respectant au mieux les nouvelles méthodologies mises en place. À 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’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. Il s’agit d’un ensemble de caractéristiques 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 de requête efficace pour les interroger, que le jeu les utilisera automatiquement partout où cela serait possible, ni que les serveurs et les shards[2] supporteront la persistance, mais cela vous donne un outil pour l’activer. Pour que l’historique du serveur soit persistant pour tout, vous devez faire beaucoup de travail dans le code de celui-ci pour qu’il soit capable de sauvegarder puis recharger n’importe laquelle de ses données, c’est la persistance globale. J’en parle tout le temps parce que cela touche beaucoup de choses, comme 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 iCache.
Mais il y a d’autres caractéristiques qui reposent également sur la persistance globale. Par exemple, nous pouvons maintenant envisager un gameplay qui peut modifier de manière permanente ou à long terme des emplacements dans le jeu, par exemple des dommages sur une station spatiale. Port Olisar pourrait subir une attaque sur un “shard” (voir note précédente) et il serait endommagé pendant un certain temps jusqu’à ce que des réparations puissent être effectuées. Cela persisterait même si le serveur tombait en panne, car il n’est plus seulement stocké localement dans une mémoire unique. Il y en a beaucoup plus, comme la récupération complète du serveur après un crash. Les gens se plaignent souvent de la perte de cargaison après un plantage du serveur, car nous ne pouvons pas faire revenir les joueurs dans leurs vaisseaux en ce moment après un crash serveur ; contrairement à un crash client, nous perdons en effet l’état du serveur avec toute ses données actuellement. Avec la persistance globale, cela sera enregistré dans le registre du shard mutualisé auquel il était associé, donc rapidement nous faisons tourner une autre instance, elle récupère le registre du shard à partir des données mutualisées sur les autres serveurs, puis nous pouvons utiliser le matchmaking pour ramener les joueurs dans le nouveau shard comme si c’était celui avec lequel ils avaient perdu la connexion, et boum, ils sont de retour en action là où ils s’étaient arrêtés.
J’espère que cela vous aide ?
Question par Rain Walker
Qu’en est-il des éléments tels que la persistance de l’historique et de la réputation des missions, la réputation des donneurs de missions, et des catégories dans lesquelles ces éléments entrent ?
Réponse par Chad McKinney
Ceux-ci seront traités par un ensemble différent de services et une base de données différente, 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 traité séparément et différemment.
Question par Rain Walker
Leur persistance relèverait-elle de la persistance globale qui viendra après iCache ?
Réponse par Chad McKinney
Ils ne seront pas mis en ligne avec la persistance globale, non. Notons tout de même que le service de réputation a déjà été mis en place et qu’un certain travail sur le gameplay a déjà été effectué pour le lier à la persistance, mais à ce stade nous n’avons pas encore vraiment profité de ces nouvelles fonctionnalités. 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, simplement transposé à une nouvelle base de données qui ne serait pas celle des objets.
Dans le même fil de discussion Spectrum, une question a également été posée sur la pertinence de prendre autant de temps pour développer et coder de telles technologies pour Star Citizen.
Question par Anxi
Ne serait-il pas plus rapide de se contenter d’obtenir une licence pour toute la technologie d’un MMO éprouvé, où toutes ces 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, The 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 TESO n’est pas le seul jeu où le Server Meshing et la persistance globale sont entièrement mis en œuvre et perfectionnés (c’est-à-dire sans bugs). 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.
Réponse par Chad McKinney
Je vois ce genre de question 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 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 gagné en maturité. L’industrie a en effet résolu de nombreux problèmes au fil des années. On retiendra la récente démo technologique d’Unreal Engine 5 qui a fait la preuve de sa capacité à afficher des graphismes impressionnants, ce qui est probablement une évolution de leur implémentation d’une techno, le “traçage de cône de voxel[3]” qui était déjà proposé en avant-première dès l’UE4. Ce que vous ne savez peut-être pas également, c’est qu’il existe déjà d’autres implémentations de la même approche dans d’autres moteurs. Même Ogre3D[4] en a un en ce moment. Pourquoi Epic[5] n’a-t-il pas simplement récupéré un déjà existant ou vice-versa ? Eh bien, d’une part, à cause des frais ou des problèmes de licence, mais également pour des raisons techniques parce qu’une autre implémentation est construite dans un contexte complètement différent : celui du moteur spécifique pour lequel ces solutions ont été développées. Souvent, vous passerez autant de temps à essayer d’intégrer la solution de quelqu’un d’autre dans votre propre programme, qu’à la réécrire et recoder entièrement vous-même. Autre avantage, lorsque vous l’écrivez vous-même, vous pouvez résoudre des problèmes très spécifiquement de la manière la plus spécialisée dans le contexte de votre moteur/jeu, sans les contraintes d’une implémentation dite générique qui doit fonctionner pour tous les cas. 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és de réécrire. Il s’agit de choisir ses priorités, 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éponde vraiment à vos besoins, voire même que vous obtiendrez le moindre support de leur part. Cela sans même prendre en compte la manière dont vous allez prendre en charge votre technologie, si vous prévoyez de créer un ou plusieurs jeux, ou encore si vous souhaitez obtenir vous-même une licence pour le moteur. Les jeux vidéo et autres domaines de programmation de 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 chacun de leur côté, et ne se sont pas contentées de converger vers une solution industrielle unique pour un moteur commun.
Pour reprendre votre exemple de The Elder Scrolls Online, leurs problèmes sont très différents de ceux de Star Citizen. Le système d’inventaire est beaucoup plus simple, et leur persistance mondiale est inexistante. TESO utilise beaucoup le sharding avec l’instanciation des parties des joueurs en dynamique, alors que dans SC, nous essayons de pousser vers une instance unique et unifiée commune à n’importe quelle région, voire si possible 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 The Elder Scrolls Online.