Lancement de l’Alpha 3.18
Comme beaucoup de nos joueurs l’ont vécu, nous avons lancé l’Alpha 3.18 le 10 mars de cette année, et à côté d’une foule de nouvelles fonctionnalités très médiatisées comme le Salvage, le vaisseau volant Vulture, le surprenant Scorpius Antares, de nouveaux fleuves et de nouvelles missions, la plus grande vedette du patch a été notre livraison du Persistent Entity Streaming (PES), qui a complètement réécrit la façon dont nous sauvegardons l’état dans le jeu et a inauguré la promesse d’un véritable univers persistant où les actions d’un joueur peuvent rester dans le jeu pour que d’autres puissent interagir avec lui et créer un environnement vivant où vous pouvez littéralement laisser votre marque dans le PU. Et, tout aussi important, PES a été la dernière étape nécessaire à la mise en place d’un maillage statique des serveurs.
Beaucoup de ceux qui suivent Star Citizen ont compris à quel point la livraison de l’Alpha 3.18 était importante pour nous et pour le jeu lui-même. De nombreuses équipes de CIG ont passé la majeure partie de la seconde moitié de l’année dernière à terminer le Persistent Entity Streaming, que nous avons déployé sur nos serveurs Public Test Universe pour les tester en décembre 2022, puis ont passé les trois mois suivants à le renforcer et à l’améliorer pour le lancer sur notre service Live Star Citizen le plus rapidement possible.
Cependant, lorsque l’heure de vérité a sonné et que l’Alpha 3.18 a été expédiée sur Live, le choc subi par le système a été supérieur à ce que nous avions prévu. S’il est vrai que nous nous attendions à ce que PES crée une expérience difficile au départ, le temps d’aplanir les problèmes qui ne pouvaient que se révéler à grande échelle (et nous avions prévenu), dire que nous avons été surpris par l’ampleur du chaos provoqué par le lancement de PES serait un euphémisme.
L’attente de PES et de la version 3.18 était tout simplement sans précédent pour nous. Lorsque le patch est sorti le 10 mars, nous avons enregistré les pics les plus élevés de connexions par minute et par heure, ainsi que le plus grand nombre de tentatives de connexion en une journée pendant les premiers jours du lancement. Nous disons “tentatives de connexion” car, comme vous le savez tous, le service a été tellement submergé par le trafic et les difficultés initiales de PES que de nombreux joueurs n’ont pas pu entrer dans le jeu, car divers problèmes ont bloqué les utilisateurs tout au long de l’entonnoir de connexion. Certains étaient bloqués dans les files d’attente, d’autres n’arrivaient pas à charger leur personnage, d’autres encore étaient bloqués sur un écran de chargement infini. Comme vous pouvez le lire dans le compte-rendu de Benoit Beausojour (notre directeur technique) sur PES, nous avons sous-estimé les forces multiplicatives du passage à Live et de la création et de la persistance de chaque entité créée par les joueurs à travers leurs actions, créant une charge sur notre service qui dépassait nos prévisions initiales. Et il a fallu des semaines, voire des mois, pour exposer, diagnostiquer, créer des correctifs, les tester et les déployer pour restaurer le service, tout cela alors que le jeu tournait toujours sur Live.
Nous avons beaucoup appris du lancement de PES, et bien que nous soyons encore en train de nous remettre, et que nous regrettions que le service ait été compromis dans les premiers jours et les premières semaines du déploiement, cela nous a certainement enseigné une leçon précieuse pour valoriser et préserver l’intégrité du service plus que nous ne l’avions fait dans le passé. C’est pourquoi, lorsque nous commencerons à déployer le fractionnement de la couche de réplication et la récupération en cas de panne – deux choses désormais permises par PES – nous le ferons progressivement, et lorsque nous commencerons à livrer le Server Meshing, nous créerons des canaux de test dédiés pour renforcer ces nouvelles technologies et mettre en œuvre des normes et des seuils avant de les “graduer” vers PTU et ensuite Live. Vous commencerez à voir les ramifications de cela plus tard dans l’année et nous vous en dirons plus sur notre nouvelle approche du déploiement de nouvelles technologies potentiellement perturbatrices et changeantes pour le service de jeu, mais il s’agit pour nous de nous engager réellement à préserver l’expérience des centaines de milliers, voire des millions, qui jouent maintenant à Star Citizen en tant que service de jeu en direct, même s’il s’agit d’une version alpha encore en développement.
Streaming d’entités persistantes
Ce qui a bien marché
Le développement du Persistent Entity Streaming (PES) a impliqué une équipe de programmeurs aux compétences spécialisées dans de nombreux domaines au sein du groupe Core Tech et de Turbulent. Cette collaboration a été cruciale pour la réussite de la construction de ce système complexe. L’équipe de choc a suivi des sprints et des objectifs alignés, facilités par des ingénieurs et des producteurs seniors, qui ont été soutenus par des réunions régulières. Cela a permis une communication efficace et a minimisé les erreurs de communication ou les malentendus techniques.
L’équipe d’intervention a maintenu un niveau élevé de qualité du code, en veillant à ce qu’il fasse l’objet d’une conception approfondie, de discussions et de multiples révisions avant d’être intégré dans la base de code principale.
Le déploiement initial dans l’univers de test public (PTU) et les tests avec la communauté PTU se sont bien déroulés, établissant une base positive pour d’autres améliorations. Cependant, des problèmes sont apparus (voir ci-dessous).
Enfin, l’architecture du système et l’API de PES, qui sont basées sur des files d’attente durables, ont prouvé qu’elles pouvaient se remettre des pires problèmes en toute sécurité et qu’elles tendraient toujours vers le rétablissement.
Ce qui n’a pas fonctionné
Les aspects de recherche et de développement de PES ont posé des défis, requérant des ingénieurs qu’ils inventent des moyens de contourner des problèmes imprévus. En raison de la nature fondamentale de PES, son intégration dans le code du jeu Star Citizen a entraîné des changements importants qui ont perturbé le jeu à un niveau très bas, et certaines équipes de jeu n’étaient pas préparées à l’effort d’intégration requis pour ramener les systèmes de jeu à la parité ou pour convertir et exploiter la nouvelle couche de persistance pour les fonctionnalités existantes.
Les problèmes liés aux changements introduits par PES ne sont apparus que lors d’une utilisation à grande échelle et sous une forte charge de joueurs, ce qui a entraîné des retards dans l’identification et la résolution des problèmes. De plus, des fonctionnalités qui n’étaient pas censées utiliser la persistance ont été affectées par des retards insignifiants (comme les systèmes de tramway, les files d’attente pour les joueurs, etc.)
Nous avons également sous-estimé le facteur de multiplication entre le PTU et les opérations Live ; le groupe avait estimé une augmentation de 10x de l’activité du backend mais a été confronté à une augmentation de 20x+ des requêtes, de la taille des messages de flux et de l’activité globale, ce qui a provoqué des interruptions de service généralisées lors du lancement initial.
En ce qui concerne les véhicules, PES a fortement modifié la manière dont ils sont autorisés et créés dans le jeu. Cela permet une meilleure expérience utilisateur (où vous pouvez choisir où un vaisseau finit par être créé), mais aussi une réduction significative de la taille de l’inventaire/de la base de données globale pour les vaisseaux qui ne sont jamais utilisés.
Des problèmes majeurs ont également été découverts à grande échelle avec un moteur de base de données tiers que PES utilise pour ses fonctionnalités. Ces problèmes ont donné lieu à des cycles de demande/réponse très instables ainsi qu’à des files d’attente importantes. Ces problèmes ont également eu des effets d’entraînement, un serveur de base de données entrant dans une situation de blocage entraînant l’arrêt du traitement des demandes par l’ensemble du cluster (au lieu d’un seul shard) pendant un certain temps. Il s’agissait d’une cause majeure d’instabilité tout au long de l’Alpha 3.18.x jusqu’à ce que l’équipe ait identifié et programmé une solution de contournement pour atténuer les effets. En outre, de multiples problèmes de verrouillage à l’échelle ont été découverts dans le système de base de données global (même moteur), ce qui a entraîné un arrêt périodique de toutes les demandes adressées aux systèmes d’inventaire. L’équipe a dû enquêter et faire rapport à nos fournisseurs pour déterminer des solutions de contournement et, en fin de compte, des correctifs qui empêcheraient le moteur de base de données de se verrouiller.
Dans le moteur de base de données, plusieurs shards ont atteint des limites dures jusqu’alors inconnues quant au nombre maximum d’entités allouées, obligeant les équipes à ensemencer/créer de nouveaux shards et à les distribuer, diluant ainsi l’effet de la persistance sur ces shards.
Plusieurs bugs ont été découverts (en ces temps instables) dans la gestion des erreurs dans certaines parties du flux de connexion qui ont bloqué certains comptes de différentes manières liées à la création de personnages. On a découvert que la gestion des crashs de serveurs prenait beaucoup plus de temps en raison d’un nouveau processus qui intervient pendant l’analyse post-mortem. Cela affecte l’analyse post-mortem des tessons et retarde le retour des joueurs dans l’inventaire global, ce qui peut avoir pour conséquence de “bloquer” un personnage dans un tesson.
Ce que nous ferons mieux/projets futurs
À l’avenir, nous finaliserons et utiliserons le nouveau lanceur de tests en nuage afin de tester correctement les cartes du jeu à grande échelle. Cet outil simulera les comportements des joueurs et permettra à la division QA et aux ingénieurs de connecter plusieurs clients de jeu modifiés à l’espace de jeu. L’utilisation de ressources informatiques en nuage permettra de réaliser des tests de résistance efficaces, ce qui aidera à identifier et à résoudre les problèmes liés à des serveurs très chargés avant de passer à la version en direct.
L’équipe responsable de PES est maintenant passée au maillage statique des serveurs et adopte une approche de transformation pour ce nouveau projet. Contrairement à PES, cette technologie fondamentale peut être intégrée progressivement dans la base de code, en évitant une approche perturbatrice de type “Big Bang”. Certaines parties de la technologie Server Meshing sont déjà à la disposition de l’équipe de jeu pour tester la compatibilité avec les fonctionnalités de leur jeu. Combinée avec le Cloud Test Launcher, cette approche vise à faciliter le processus d’intégration de Static Server Meshing.
En mettant en œuvre ces mesures, nous visons à améliorer nos capacités de test et à atténuer les défis d’intégration, en assurant une livraison plus fluide des technologies fondamentales tout en minimisant les perturbations dans le jeu.
Rivières
Ce qui s’est bien passé
L’inclusion des rivières a marqué une étape importante dans notre quête pour créer des planètes plus réalistes et plus immersives. Nous sommes très satisfaits des améliorations apportées aux canyons fluviaux entre les versions Alpha 3.18 et 3.19 grâce à l’amélioration de notre pipeline de ressources. Et le soutien de l’équipe de Planet Tech pour résoudre les problèmes techniques au cours de ce processus a été remarquable.
Ce qui n’a pas fonctionné
L’outil de placement procédural des rivières n’était pas dans un état aussi bon que nous l’avions espéré lorsque nous avons commencé à l’utiliser. Par conséquent, un effort manuel considérable a été requis pour placer méticuleusement et vérifier les rivières résultantes afin de garantir leur qualité optimale. En outre, cette limitation a également entraîné une diminution du nombre de rivières que nous avons pu générer.
Ce que nous ferons mieux/projets futurs
Les nombreux problèmes qui ont été identifiés et résolus avec succès au cours de cette première série de rivières ont déjà eu un impact significatif sur la fluidité de l’expérience pour la prochaine fois. Bien qu’il reste encore beaucoup de travail avant que nous puissions créer des paysages planétaires avec des rivières qui ressemblent à la réalité, nous avons fait des progrès substantiels et nous sommes maintenant beaucoup plus proches de notre objectif que jamais auparavant.
Grottes de sable
Ce qui a bien marché
Nous sommes très satisfaits des résultats de cette première phase de développement d’un pipeline amélioré pour produire des pièces individuelles pour tous les archétypes de grottes et pour définir l’identité visuelle de nos grottes de sable. Le fait que nous ayons pu sortir un premier ensemble de petits systèmes de grottes de cette phase de prototypage grâce à l’effort concerté de plusieurs départements a été la cerise sur le gâteau pour nous.
Ce qui n’a pas marché
En l’absence d’outils permettant d’assembler les lieux de manière procédurale ou de les placer automatiquement sur des planètes prêtes à l’emploi, nous avons dû construire et placer chaque grotte manuellement, ce qui a constitué la principale contrainte quant au nombre de grottes que nous pouvions placer sur les planètes du système de Stanton.
Malheureusement, ces grottes ont dû être mises à disposition sans missions, ce qui en fait des lieux que le joueur doit activement rechercher pour les découvrir.
Ce que nous ferons mieux/projets futurs
Nous sommes actuellement en train de peaufiner les nouveaux visuels des grottes rocheuses, qui constitueront le prochain archétype. Nous avons hâte d’utiliser l’outil de localisation pour construire une plus grande variété de systèmes de grottes.
De plus, nous allons travailler à la prise en charge de connexions, de salles et d’entrées plus grandes, ce qui est un requis essentiel avant de pouvoir remplacer les anciennes grottes.
Piste de course PTV
Ce qui a bien marché
Il a été créé très rapidement ; nous nous sommes lancés avec l’idée qu’il s’agissait d’un endroit simple, avec un délai court et un impact minimal sur les autres équipes. Cependant, nous avons réalisé beaucoup plus en trois semaines que ce à quoi nous nous attendions au départ, avec un bon kit modulaire pour les pistes de course de style kart, et l’ajout d’un habillage, d’une thématisation et d’un éclairage de qualité. Nous avons été ravis de constater l’enthousiasme de la communauté, en particulier celle des coureurs, lorsque la piste a été présentée au public pour la première fois. Depuis, nous avons vu des courses organisées sur la piste. Nous avons également obtenu la prise en charge du code pour les mises à jour de l’entité de réapparition des véhicules, de sorte que si les gens s’écrasent, se cassent ou abandonnent le PTV Greycat, il réapparaît dans la zone de départ de la piste. Nous pouvons également définir des valeurs telles que le temps de réapparition.
Ce qui n’a pas marché
Bien que la piste ait été terminée avant la sortie de l’Alpha 3.17, elle n’avait pas encore fait l’objet d’une division QA et n’avait pas encore été corrigée des bugs. Nous avons donc décidé de la conserver jusqu’à l’Alpha 3.18. Nous étions loin de nous douter que l’Alpha 3.18 allait être retardée à ce point, si bien que la piste, bien que complète, est arrivée dans les mains du public bien plus tard que nous l’avions espéré.
Ce que nous ferons mieux/projets futurs
Nous développerons certainement d’autres circuits modulaires à l’avenir (et nous en avons un autre en préparation), mais ce projet est pour l’instant en veilleuse. Nous essaierons de soutenir d’autres véhicules terrestres de taille similaire, comme le Greycat STV, à l’avenir également (les premiers essais ont été positifs). Nous allons également travailler avec l’équipe Mission pour envisager l’ajout d’une mission de type circuit de course sur les pistes, ce qui permettra de suivre les temps de course, les points de contrôle et les tours, et permettra à la mission d’offrir des récompenses aux joueurs.
Poste de sécurité de Kareah
Ce qui a bien marché
Nous n’aurions jamais pu imaginer le niveau de soutien que nous avons reçu de la part de l’équipe artistique, qui a vraiment rajeuni l’endroit.
L’activité de bac à sable déclenchée par les joueurs a été bien accueillie, et les analyses ont montré que le piratage de CrimeStats à Kareah est toujours très populaire, ce qui nous préoccupait car nous prenions un risque en supprimant les autres lieux de piratage.
Ce qui n’a pas fonctionné
La mission présente encore des imperfections qui doivent être corrigées, ce qui est en cours. Par ailleurs, des besoins supplémentaires en matière d’analyse des activités du bac à sable ont été identifiés afin de mieux comprendre la participation des joueurs.
Ce que nous ferons mieux/projets futurs
Nous continuerons d’améliorer l’activité et l’emplacement du bac à sable en fonction des commentaires que nous avons reçus et nous ajouterons des analyses supplémentaires pour mieux comprendre la participation.
Jumptown
Ce qui a bien marché
Les changements apportés à l’emplacement ont été très bien accueillis, la participation des joueurs a été constamment très élevée et le soutien que nous avons reçu d’Art a été bien au-delà de ce à quoi nous nous attendions.
Ce qui n’a pas marché
L’implémentation de PES a entraîné des problèmes de performance autour de l’emplacement après la destruction de nombreux vaisseaux. Nous voulions également redéployer les emplacements avec RASTAR. Cependant, nous n’avons pas pu le faire à l’époque, car cela brisait les boutiques.
Ce que nous ferons mieux/projets futurs
Pour la prochaine édition des événements mondiaux, nous prévoyons de redéployer les emplacements sur différentes planètes afin d’offrir un gameplay différent. Par exemple, dans une atmosphère épaisse, sur des planètes à gravité plus élevée et dans des forêts.
Épreuves chronométrées
Ce qui a bien marché
Le nouveau contenu de course et les modes de contre-la-montre ont été bien accueillis par la communauté de course, aidée par les équipes de contenu qui ont produit beaucoup plus de pistes que nous n’aurions pu l’espérer.
Dans le backend, les analyses que nous avons ajoutées étaient fantastiques et nous ont permis de faire des analyses très approfondies de chaque circuit, ce qui nous a aidés à déterminer où ils devaient se situer dans le classement de difficulté et quels devaient être les temps cibles.
Ce qui n’a pas marché
Les performances médiocres du serveur ont nécessité la création d’un nouveau système sophistiqué de suivi des points de contrôle, bien que les marqueurs ne se mettent toujours pas à jour de manière aussi réactive que nous le souhaiterions.
Les analyses montrent également que relativement peu de joueurs débloquent la deuxième piste.
Missions d’infiltration – Orison
Ce qui a bien marché
Les nouveaux environnements FPS ont été bien accueillis et constituent un changement rafraîchissant après les installations souterraines que nous avons connues pendant des années. La possibilité d’attaquer les lieux à pied ou à bord d’un vaisseau était également très intéressante.
Ce qui n’a pas marché
Nous avons dû désactiver les missions pour l’Alpha 3.19 parce que nous voulions publier Siege of Orison, mais nous n’avons pas pu le faire à temps, ni les nouveaux clusters de plateformes (où nous devions les relocaliser).
Ce que nous ferons mieux/projets futurs
Nous avons déplacé les missions vers les nouveaux clusters de plates-formes et nous les publierons dès que possible.
Activités dans les prisons
Ce qui a bien marché
La mission d’évasion de la prison est étonnamment bien jouée et offre aux joueurs un nouveau moyen d’améliorer leurs statistiques de criminalité. À l’intérieur de la prison, le butin de l’IA et les nouveaux terminaux de vente ont été bien accueillis ; les joueurs ont trouvé que la nouvelle IA rendait la prison plus vivante et leur offrait un autre moyen de gagner des points de mérite.
Ce qui n’a pas marché
L’Ursa Rover continue d’apparaître sous terre, la vente d’objets au kiosque de la prison n’est toujours pas fiable et des IA excessives apparaissent en raison d’un problème de placard d’apparition.
Ce que nous ferons mieux/projets futurs
Pour la prochaine version, nous corrigerons tous les bugs que nous pourrons, y compris le problème de l’apparition d’Ursa.
Drake Vulture
Ce qui a bien marché
L’ajout du “starter” tant attendu de la carrière de Salvage en même temps que sa boucle de gameplay a été une grande étape pour l’équipe Véhicule. Bien que le véhicule ait été commencé il y a un certain temps, nous l’avons gardé pour nous assurer qu’il sortirait bien avec la boucle de gameplay plutôt que sans, et cela a permis à l’équipe d’ajouter quelques fonctionnalités supplémentaires au vaisseau pour s’assurer qu’il répondait à toutes les normes actuelles.
Ce qui n’a pas fonctionné
Quelques plaintes entourant la traversée du vaisseau en raison de la mécanique de gameplay étaient en quelque sorte le produit de la mécanique de Salvage évoluant au fil du temps pour requérir plus d’entrée manuelle qu’initialement prévu lors de la conception du véhicule en 2018.
Ce que nous ferons mieux/projets futurs
Sortir des véhicules en même temps que leurs boucles de gameplay plutôt que plus tôt dans le projet (voir Starfarer et Reclaimer) est quelque chose que nous nous sommes efforcés de faire ces derniers temps, et nous continuerons à viser à le faire.
RSI Scorpius Antares
Ce qui a bien marché
L’Antares a été conçu parallèlement au Scorpius de base comme une variante optionnelle à mettre en production à l’avenir, la section de la queue du vaisseau étant décrite comme la partie pouvant faire l’objet d’un changement de géométrie. Cependant, au cours du développement, il est apparu clairement que les besoins de l’EMP et du moteur quantique requéraient un peu plus de puissance que prévu et l’équipe a bien réagi en ajustant à la fois la base et l’Antarès pour que la disposition des composants convienne aux deux.
Ce qui n’a pas fonctionné
Nous n’avons pas pu résoudre certains problèmes techniques qui ont réduit la capacité du second joueur à contrôler les fonctions de pilotage et à disposer d’un écran multifonctions plus performant.
Ce que nous ferons mieux/projets futurs
Avec les Master Modes et les nouveaux MFD à venir, nous devrions voir le copilote bénéficier de plus de fonctions de jeu plutôt que d’être moitié passager, moitié presseur de boutons.
Salvage & Cargo – Gameplay des véhicules
Ce qui s’est bien passé
Nous avons pu aider les deux équipes à introduire deux fonctionnalités clés dans le PU, le Salvage requérant beaucoup de temps sur les éléments artistiques et le Cargo nécessitant un passage sur tous les vaisseaux par le Design.
Ce qui n’a pas fonctionné
Malheureusement, l’ampleur du travail pour le Salvage a été considérablement sous-estimée, car nous pensions que le système de dégâts UV2 existant que tous les vaisseaux utilisaient conviendrait dès le départ. Cependant, nous nous sommes rapidement rendu compte qu’il faudrait faire une passe complète sur chaque vaisseau pour améliorer la qualité, car on regarde les visuels de beaucoup plus près que le système de dégâts.
De plus, le mécanisme de jeu a été construit autour de l’idée que vous seriez capable de scraping 100% de la coque. Cependant, cela n’a pas été pris en compte dans la configuration des dégâts de l’UV2, de sorte que certaines zones étaient inaccessibles, ce qui a provoqué la frustration des premiers testeurs qui ne pouvaient pas “100%” d’un vaisseau.
Ce que nous ferons mieux/projets futurs
Nous sommes maintenant plus étroitement intégrés aux équipes travaillant sur des fonctionnalités importantes comme celle-ci, de sorte que les problèmes peuvent être trouvés et étudiés avant que le développement ne commence vraiment, plutôt que d’être intégrés une fois que le prototype a été achevé.
Hull Scraping
Ce qui s’est bien passé
La première itération tant attendue du gameplay de Salvage est finalement arrivée avec l’Alpha 3.18, qui permet aux joueurs de scraping des matériaux de la coque et de les échanger ou de les utiliser pour des réparations sur le terrain. La boucle de gameplay principale a été généralement bien accueillie et offre un contraste intéressant avec les autres activités.
Nous avons également étendu le système de récolte avec des épaves de vaisseaux et des pièces de métal à salvager, et introduit la première version miniature de l’Artisanat en permettant aux joueurs de créer quelques objets sélectionnés à l’aide du CMR.
La sortie du Hull scraping en même temps que celle du Drake Vulture a permis au vaisseau de bénéficier d’un système de jeu adéquat, et le Récupérateur d’égide dispose enfin d’un système de jeu approprié.
Ce qui n’a pas fonctionné
Beaucoup de fonctionnalités et de systèmes sur lesquels Hull s’appuyait étaient encore en cours de développement lorsque nous avons mis au point le système de jeu principal. Cela signifie que la fonctionnalité a été confiée à l’équipe EUPU dans un délai assez court.
Nous avons abordé la question de la manière dont les joueurs trouveraient des objets à récupérer dans l’univers bien trop tard dans le processus, et le travail d’équilibrage pour la distribution des objets à récupérer n’a pas été correctement planifié.
Tous les véhicules n’ont pas pu être mis à jour avec la nouvelle carte de dégâts, ce qui signifie que certains véhicules ne fonctionneront toujours pas correctement avec le Hull Scraping.
Ce que nous ferons mieux/projets futurs
Nous avons modifié notre approche en ce qui concerne la précocité de l’implication des autres équipes, ce qui signifie que les équipes en aval sont impliquées dès la phase de prototypage. Nous avons également introduit des étapes supplémentaires au cours desquelles les équipes en aval et les équipes de contenu peuvent examiner et approuver les progrès réalisés avant de passer à l’étape suivante.
