Le dernier rapport Post Mortem dans lequel les développeurs de Star Citizen font le point sur le contenu de la version publiée remonte à février 2022 avec l'autopsie de l'Alpha 3.16. Alors quand CIG nous propose un rapport Post Mortem des Alpha 3.18 et 3.19 réunies, autant dire que cela s'avère une grande et bonne surprise, d'autant plus que ce rapport est l'occasion pour CIG de faire le point sur les débuts difficiles du Persistent Entity Streaming (PES) de l'Alpha 3.18 et de ce que cela va appliquer dans l'avenir, dont manifestement un retour au déploiement progressif du Server Meshing statique, ce qui va probablement avoir de lourdes conséquences sur le délai de sortie de la tant attendue Alpha 4.0...
Analyse post mortem de l'Alpha 3.18
Comme beaucoup de joueurs l'ont vécu, CIG a 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, la mise en jeu du Vulture, le surprenant Scorpius Antares, de nouvelles rivières et de nouvelles missions, la plus grande vedette du patch a été la livraison du Persistent Entity Streaming (PES), qui a complètement réécrit la façon dont est sauvegardé 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 l'Univers Persistant (PU). Et, tout aussi important, le PES a été la dernière étape nécessaire à la mise en place d'un maillage statique des serveurs (Server Meshing Static).
Beaucoup de ceux qui suivent Star Citizen ont compris à quel point la livraison de l'Alpha 3.18 était importante pour CIG 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, qui a été déployé sur les serveurs PTU (Public Test Universe) pour être testé en décembre 2022, puis ont passé les trois mois suivants à renforcer et améliorer le PES pour le lancer sur le service Live de Star Citizen le plus rapidement possible.
Cependant, lorsque l'heure de vérité a sonné et que l'Alpha 3.18 a été livrée sur le Live, le choc subi par le système a été au-delà de ce qui avait été prévu. S'il est vrai que CIG s'attendait à 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 qui avaient été prévenus), dire que CIG avait été surpris par l'ampleur du chaos du lancement de PES serait un euphémisme.
L'attente du PES et de la version 3.18 était tout simplement sans précédent pour CIG.
Lorsque le patch est sorti le 10 mars, CIG a 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. Il est question de "tentatives de connexion" car, comme vous le savez tous, le service a été tellement submergé par le trafic et les problèmes de démarrage du 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 (directeur technique) sur le PES, CIG a sous-estimé les forces multiplicatives du passage sur le 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 le service qui dépassait les 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 le Live.
CIG a beaucoup appris du lancement du PES, et bien qu'ils soient encore en train de se remettre, et qu'ils regrettent que le service ait été compromis dans les premiers jours et les premières semaines du déploiement, cela leur a certainement enseigné une leçon précieuse pour valoriser et préserver l'intégrité du service plus que cela ne l'avait été fait dans le passé. C'est pourquoi, alors que CIG commence à déployer le fractionnement de la couche de réplication et la récupération en cas de crash - deux choses désormais permises par PES – ils le ferons progressivement, et alors qu'ils commencent à livrer le Server Meshing, ils créeront des canaux de test dédiés pour durcir davantage ces nouvelles technologies et mettre en oeuvre des normes et des seuils avant de les "graduer" vers le PTU puis le Live.
Vous commencerez à voir les ramifications de cela plus tard dans l'année et CIG vous en dira plus sur cette nouvelle approche du déploiement de nouvelles technologies potentiellement perturbatrices et changeantes pour le service de jeu, mais il s'agit pour CIG de s'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.
Persistent Entity Streaming
Le développement du Persistent Entity Streaming (PES) a impliqué une équipe diversifiée de programmeurs possédant des compétences spécialisées dans de multiples 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é venant du PTU se sont bien déroulés, établissant une base positive pour d'autres améliorations. Toutefois, des problèmes sont apparus (voir ci-dessous).
Enfin, l'architecture du système et l'API du 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 la recherche et du développement du PES ont posé des défis, obligeant les ingénieurs à inventer des moyens de contourner des problèmes imprévus. En raison de la nature fondamentale du PES, son intégration dans le code du jeu Star Citizen a entraîné des changements significatifs 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 nécessaire 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 le 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 du Live ; le groupe avait estimé une augmentation de x10 de l'activité du backend mais a été confronté à une augmentation de x20+ 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, le PES a fortement modifié la manière dont ils sont autorisés et créés dans le jeu. Cela permet d'améliorer l'expérience de l'utilisateur (qui peut choisir l'endroit où un vaisseau est créé), mais aussi de réduire considérablement 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 le 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, ce qui a obligé les équipes à ensemencer/créer de nouveaux shards et à les distribuer, diluant ainsi l'effet de la persistance sur ces shards.
Plusieurs bogues 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 shards et retarde le retour des joueurs dans l'inventaire global, ce qui peut avoir pour conséquence de "bloquer" un personnage dans un shard.
Ce que nous ferons mieux/projets futurs
A l'avenir, nous allons finaliser et utiliser le nouveau Cloud Test Launcher pour tester de manière adéquate les shards du jeu à l'échelle. Cet outil simulera les comportements des joueurs et permettra à l'assurance qualité 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 du PES est maintenant passée au maillage statique des serveurs et adopte une approche de transformation pour ce nouveau projet. Contrairement au 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 caractéristiques de leur jeu. Combinée avec le Cloud Test Launcher, cette approche vise à faciliter le processus d'intégration du Static Server Meshing.
En mettant en oeuvre ces mesures, nous visons à améliorer nos capacités de test et à atténuer les difficultés d'intégration, en garantissant une livraison plus fluide des technologies fondamentales tout en minimisant les perturbations dans le jeu.
Rivières
L'inclusion des rivières a marqué une étape importante dans la quête pour créer des planètes plus réalistes et plus immersives. Nous avons été très satisfaits des améliorations apportées aux canyons fluviaux entre les Alpha 3.18 et 3.19 grâce à l'amélioration du 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é nécessaire pour placer méticuleusement et vérifier les rivières résultantes afin d'assurer 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
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 pièces et d'entrées plus grandes, ce qui est une condition essentielle avant de pouvoir remplacer les anciennes grottes.
Piste de Course de PTV
Elle a été créée très rapidement ; nous nous sommes lancés dans l'idée qu'il s'agissait d'un lieu 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 circuits de karting, et l'ajout d'un bon habillage, d'une bonne thématisation et d'un bon éclairage. 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. Nous avons depuis vu des courses organisées sur la piste. Nous avons également obtenu la prise en charge du code pour les améliorations de l'entité de réapparition des véhicules, de sorte que si les gens s'écrasent, se cassent ou abandonnent le Greycat PTV, 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'un test d'assurance qualité et n'avait pas encore été corrigée. 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 des missions 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
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 nous basant sur les commentaires que nous avons reçus et nous ajouterons des analyses supplémentaires pour mieux comprendre la participation.
Jumptown
Les changements de lieu 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 de la part de l'équipe Art a été bien au-delà de ce que nous attendions.
Ce qui n'a pas marché
L'implémentation du PES a entraîné des problèmes de performance autour du site après la destruction d'un grand nombre de navires. 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
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 piste, ce qui nous a aidés à déterminer où elles devaient se situer dans le classement de difficulté et quels devaient être les temps cibles.
Ce qui n'a pas fonctionné
Les mauvaises performances 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
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 géniale.
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
La mission d'évasion de la prison est étonnamment bien jouée et offre aux joueurs un nouveau moyen d'effacer 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
Lors de la prochaine version, nous corrigerons tous les bugs possibles, y compris le problème de l'apparition de l'Ursa.
Drake Vulture
L'ajout du "starter" tant attendu de la carrière de Salvage en même temps que sa boucle de gameplay a été une étape importante 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 marché
Les quelques plaintes concernant la traversée du vaisseau en raison des mécanismes de jeu sont en quelque sorte le résultat de l'évolution de la mécanique de récupération qui, au fil du temps, a nécessité plus d'interventions manuelles que ce qui était 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
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 nécessitaient un peu plus de puissance que prévu et l'équipe a bien réagi en ajustant à la fois la base et l'Antares 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 modes Master 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
Nous avons été en mesure d'aider les deux équipes à introduire deux fonctionnalités clés dans le PU, le Salvage nécessitant beaucoup de temps sur les actifs artistiques et le Cargo nécessitant un passage sur tous les vaisseaux par la conception.
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, utilisé par tous les vaisseaux, conviendrait dès le départ. Cependant, nous nous sommes rapidement rendu compte qu'il nous faudrait faire une passe complète sur chaque vaisseau pour améliorer la qualité, car vous regardez les visuels de beaucoup plus près que le système de dégâts.
En outre, le mécanisme de jeu a été construit autour de l'idée que vous seriez en mesure de gratter la coque entière à 100%. 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 parvenait 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é.
Grattage de la coque
La première itération tant attendue du gameplay du Salvage est enfin arrivée avec l'Alpha 3.18, qui permet aux joueurs de gratter les 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 et des pièces de métal récupérables, 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 grattage de coque en même temps que celle du Drake Vulture a permis au vaisseau de bénéficier d'un système de jeu approprié, et l'Aegis Reclaimer dispose enfin d'un système de jeu adéquat.
Ce qui n'a pas fonctionné
Un grand nombre de fonctionnalités et de systèmes sur lesquels reposait le Hull Scraping étaient encore en cours de développement lorsque nous avons construit 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 façon dont les joueurs trouveraient des objets récupérables dans l'univers bien trop tard dans le processus, et le travail d'équilibrage pour la distribution des objets récupérables 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 grattage de coque.
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.
Analyse post mortem de l'Alpha 3.19
Contrats de sauvetage
Nous sommes très fiers de ce que nous avons accompli. Au départ, nous avions prévu de sortir la mission avec le grattage de coque, mais nous avons réussi à inclure la cargaison et la toute nouvelle fonctionnalité des composants détachables. La mission a également été bien accueillie par les backers.
Ce qui n'a pas marché
Nous n'avons pas choisi les meilleurs vaisseaux pour la mission, car seuls certains ont des composants internes détachables et des coques en or pour le grattage (ce que nous n'avons découvert qu'après coup). De plus, en raison de la maladie d'un développeur, la première version a été très approximative en ce qui concerne l'apparition des cargaisons, ce qui signifie que nous n'avons pas eu le temps d'équilibrer correctement le jeu ou de vérifier que tous les objets pouvaient être vendus.
L'équipe chargée de l'économie a dû modifier la valeur des armes des navires très tard dans le développement. Cela était nécessaire pour équilibrer la question problématique de l'assurance, qui nécessite un rééquilibrage supplémentaire. Ce changement a déçu certains joueurs qui s'étaient habitués à des récompenses plus élevées.
Ce que nous ferons mieux/projets futurs
Pour la prochaine version, nous choisirons des vaisseaux plus appropriés avec des composants internes détachables.
Expérience des nouveaux joueurs
Nous avons reçu de nombreux commentaires positifs de la part des nouveaux joueurs, qui estiment que l'Expérience du nouveau joueur les a aidés à apprendre le jeu. Les améliorations visuelles apportées à l'Area 18 ont considérablement amélioré la navigation, ainsi que les nouveaux contrôles et les indices contextuels.
Tout au long du développement de la NPE (New Player Expérience), nous avons pu apporter de nombreuses améliorations à notre système de missions, comme l'introduction de la persistance des missions, qui nous permet de reprendre une mission au dernier objectif actif si un joueur perd sa connexion ou subit un plantage du client.
Ce qui n'a pas fonctionné
La mission est en grande partie modulaire, mais pas entièrement, ce qui signifie qu'un travail supplémentaire est nécessaire pour l'adapter à d'autres endroits. Nous n'avons pas eu suffisamment de temps ou de soutien pour enseigner au joueur la gestion de l'inventaire ou l'interaction avec les magasins.
En ce qui concerne la production elle-même, New Player Experience était une initiative inter-équipes et, en tant que telle, a été compliquée à coordonner. Le support de production pour New Player Experience a changé plusieurs fois car il n'appartenait pas à une équipe dédiée.
En outre, nous n'avons pas bénéficié d'un soutien suffisant pour résoudre les problèmes visuels liés aux éléments existants du HUD, qui entraient en conflit avec les nouveaux contrôles et les indices contextuels.
Ce que nous ferons mieux/projets futurs
Nous avons commencé à travailler sur la modularisation des parties restantes de l'expérience du nouveau joueur afin de réduire la maintenance et de nous permettre de l'apporter à plusieurs endroits. Nous introduirons également des composants supplémentaires dans la NPE, tels que la gestion de l'inventaire, les achats et bien d'autres choses encore.
RSI Lynx
Le Lynx a commencé par être une adaptation très simpliste de l'Ursa, mais au fur et à mesure que nous avancions, nous avons pensé qu'il méritait plus. Il a donc été doté d'une géométrie et de matériaux presque entièrement nouveaux, ce qui s'est avéré payant puisque le véhicule a désormais l'allure qu'il mérite et qu'il s'intègre parfaitement au Constellation Phoenix.
Nous avons également réussi à intégrer une grande quantité de contenu interactif dans le véhicule, notamment des chaises animées, des téléviseurs, des casiers et des réfrigérateurs.
Ce qui n'a pas marché
L'augmentation de la portée du travail pour le véhicule (principalement la refonte de l'ensemble du cockpit) a conduit l'équipe des véhicules à travailler plus longtemps que prévu, ce qui a laissé moins de temps aux autres équipes, telles que les équipes VFX et Audio, pour faire leur travail.
Ce que nous ferons mieux/projets futurs
La prochaine fois, nous veillerons à ce que les ajustements de la portée soient discutés avec toutes les équipes et à ce qu'elles n'attendent pas inutilement que tous les aspects soient livrés pour commencer leur passe.
Mirai Fury et Fury MX
Malgré sa taille, la série Fury est l'un des véhicules les plus complexes que nous ayons jamais mis dans le jeu, nécessitant des animations et des machines d'état complexes, le tout comprimé dans un espace très restreint. Il a également été livré en avance sur le calendrier, car nous étions tellement enthousiasmés par le véhicule que nous avons commencé la production avant que le concept ne soit officiellement terminé.
Les caractéristiques du véhicule ont permis d'améliorer les propulseurs à cardan pour qu'ils fonctionnent comme nous l'avions imaginé. Cela signifie que le Khartu-al et le San'tok.yai en bénéficieront à l'avenir.
Le bouclier anti-explosion du MX a été notre première véritable incursion dans l'intégration d'une interface utilisateur Building Blocks personnalisée dans le pipeline du véhicule plutôt que de réutiliser d'autres éléments, comme les panneaux de contrôle des portes.
Ce qui n'a pas fonctionné
Il nous a fallu plusieurs tentatives pour mettre au point certaines technologies nécessaires aux rotations des propulseurs, et nous avons accidentellement causé d'autres problèmes avec les propulseurs d'autres vaisseaux, mais tout a été résolu avant la sortie de la version.
Le MX devait à l'origine avoir des racks à missiles génériques, mais il était clair dès le départ qu'ils devaient être personnalisés pour éviter qu'ils ne soient lancés dans le corps ou les ailes lorsqu'ils sont remplacés par d'autres. Cela réduit malheureusement la personnalisation du joueur, mais le rend finalement plus fiable à l'usage.
Ce que nous ferons mieux/projets futurs
Nous sommes assez satisfaits de la façon dont le Fury et le Fury MX se sont développées et il n'y a pas eu d'éléments particuliers lors de leur développement qui nécessiteraient des ajustements à l'avenir.
Tractor Beam - Attachement/détachement de l'objet
Enfin, les joueurs peuvent piller les véhicules pour en extraire des composants et des armes, ce qui élargit considérablement la boucle de jeu de la récupération. Cette fonctionnalité offre également des opportunités de jeu supplémentaires pour d'autres fonctionnalités, telles que l'échange de têtes et de modules miniers, et constitue une base solide pour la fonctionnalité de rayon tracteur de véhicule.
En interne, l'équipe chargée du contenu des véhicules s'est montrée très réactive pour résoudre les problèmes de contenu liés aux composants et aux armes existants.
Ce qui n'a pas fonctionné
Cette fonctionnalité n'était pas prévue à l'origine pour l'Alpha 3.19, et nous avons donc dû travailler dans un délai très court. La QATR de cette fonctionnalité a également révélé de nombreux problèmes de contenu qui n'ont pas pu être résolus à temps pour la sortie.
Ce que nous ferons mieux/projets futurs
Nous avons commencé à demander un soutien en aval bien plus tôt dans le processus afin que les changements de contenu nécessaires puissent être effectués en prévision de la préparation de la fonctionnalité, au lieu de faire le transfert vers la fin du développement.
Rééquilibrage de l'exploitation minière
L'accueil de la communauté a été fantastique et nous sommes très satisfaits de la façon dont la sortie s'est déroulée ; des métas et des problèmes d'équilibre de longue date ont été résolus et le minage est maintenant une boucle de jeu beaucoup plus nuancée qui permet des stratégies multiples.
Les changements apportés aux rayons tracteurs ont grandement bénéficié à la boucle de jeu minière en permettant d'échanger les têtes minières, les modules et les pods. Nous avons également identifié un meilleur processus pour équilibrer les boucles de jeu de manière holistique.
Ce qui n'a pas fonctionné
Certains problèmes n'ont pu être résolus qu'après la sortie du jeu, comme les roches minables qui explosaient toujours, et la redistribution et le rééquilibrage des prix des boutiques ont nécessité de nombreux allers-retours entre les différentes équipes avant d'être correctement mis en oeuvre.
Les tests ont révélé de nombreux problèmes et cas limites en matière de prix et de distribution, qui ont nécessité des corrections et des réajustements constants.
Ce que nous ferons mieux/projets futurs
Nous voulons continuer à améliorer notre communication sur le minage avec la communauté et rester à l'écoute des commentaires critiques afin de rendre le minage meilleur possible.
Nous ferons également davantage confiance aux données que nous recueillons pour éclairer les futures décisions de conception concernant le gameplay du minage.
