Le 4 février 2021, nous avons lancé l’alpha 3.12.1 : Assaut sur Stanton, qui a introduit le premier événement dynamique dans l’univers de Star Citizen. Ce qui suit est une autopsie des développeurs principaux eux-mêmes, détaillant ce qui a été livré et leurs réflexions sur la façon dont s’est déroulé l’événement.
Mission XenoThreat
Ce qui s’est bien passé
La conception initiale de XenoThreat a été élaborée par Luke Pressley et moi-même (Tony Z). Nous avons tous deux une bonne connaissance de l’état actuel du jeu et, après quelques itérations, le projet final nous a semblé solide et réaliste. Il y avait une bonne quantité de documentation sur le déroulement de l’événement, y compris une analyse de haut niveau sur la façon de le jouer, les ennemis à faire apparaître, le fonctionnement des récompenses et la façon de tester les changements d’écran. Cette documentation a été conservée tout au long du développement et a servi de référence rapide pour l’équipe d’assurance qualité (QA) et les autres services.
Après des débuts un peu laborieux, la boucle de retours vis-à-vis de XenoThreat a fini par devenir une machine bien huilée. Le processus de collecte des commentaires des joueurs de la phase PTU par l’intermédiaire de l’équipe d’expérience du joueur et des rapports, l’enregistrement des bugs avec les étiquettes appropriées, la révision et le triage des nouveaux bugs chaque jour pour obtenir des décisions prioritaires ont fini par être un processus clairement défini. Plus tard dans le processus, nous avons demandé à l’équipe QA de saisir les tâches de suivi dans JIRA dès l’arrivée des rapports de joueurs au lieu d’attendre les reproductions internes de l’équipe. Cela a permis une itération plus rapide, de sorte que les développeurs ont parfois été en mesure de traiter le retour avant même que l’équipe QA n’ait eu l’occasion de reproduire et répertorier le bug correspondant.
En ce qui concerne l’événement lui-même, un certain nombre de fonctionnalités ont été accueillies positivement. Le partage des revenus, la répartition sociale des tâches et des types de gameplays, et la nature coopérative du déchargement des cargaisons ont été plébiscités par la communauté. En soi, cela a été une grande partie de l’accueil positif. De plus, lorsque tout fonctionnait bien, le look du jeu était magnifique. Nous sommes très satisfaits de l’équilibre entre la conception, les effets visuels et les effets sonores. Nous avons créé une équipe de choc chargée de rendre le combat agréable, ce qui a rendu l’itération rapide plus viable. La narration qui accompagnait la sortie de l’événement était également assez cool, et le commandant du groupe XenoThreat était efficace et intimidant.
Parmi les autres aspects de l’événement que nous avons trouvés réussis, citons les possibilités de revenus importants en jeu pour les joueurs (toutes les phases), les pirates FPS peuplant les sites d’épaves (phase 2) et le style de paiement récompensant le travail d’équipe (phase 2). De nombreux joueurs ont apprécié le fait d’être très bien payés pour avoir participé à toutes les phases de l’événement, ce qui les a incités à continuer à jouer et à rejouer. Bien qu’il y ait eu quelques problèmes avec les personnages IA FPS, leur présence générale a rendu la visite des épaves plus intéressante pour les joueurs et a contribué à la diversité du style de gameplay. Si certaines critiques souhaitaient plus de revenus par boîte livrée dans un système de paiement plus individualisé, bien plus nombreux étaient les joueurs à apprécier le style de paiement orienté vers le travail d’équipe, beaucoup affirmant que cela encourageait la coopération.
S’il est regrettable que nous n’ayons pas pu le lancer à la fin de l’année, la décision de reporter l’événement à 2021 lui a été très bénéfique. Entre ce que nous aurions publié avant Noël et ce que nous avons publié, cela n’a rien à voir en ce qui concerne la stabilité, les performances et la qualité de vie. Ce fut une excellente décision de la part de la direction.
Ce qui ne s’est pas bien passé
Les événements dynamiques présentent un énorme défi en matière de gestion, car leur déroulement dépend de plusieurs départements. Ils exigent qu’un responsable ayant une vision claire et une connaissance de tous les aspects soit présent pour répondre aux questions et aux retours. Afin d’accorder à XenoThreat l’attention qu’il exigeait et méritait, de nombreuses personnes ont dû jongler avec leurs priorités. Ce type d’événement peut facilement entraîner le glissement d’autres priorités. Si des événements de cette ampleur sont nécessaires plusieurs fois par an, ils ne peuvent pas simplement être pris en charge par une équipe existante, car ses autres priorités peuvent en pâtir.
Les dialogues mis en place ont beaucoup apporté à la mission, mais leur préparation a été une entreprise de grande envergure, avec de longs délais pour les livrer ainsi que les déclencheurs de mission. Il n’y a pas eu assez de temps pour intégrer les lignes de dialogue dans la mission pleinement fonctionnelle et itérer sur les changements appropriés. Nous avions déjà intégré des lignes “bouche-trous”, mais comme la fonctionnalité qui les déclenche n’était pas encore totalement opérationnelle et que la mission n’était pas complètement terminée, il a été difficile de les revoir in situ. Dans le passé, nous avons utilisé des programmes comme Visio pour créer des flux pour savoir quelles lignes doivent se déclencher, quand et dans quel ordre. Nous n’avons pas eu le temps de le faire pour XenoThreat, le dialogue a donc été implémenté directement dans la logique. Cela a rendu les processus plus ad hoc, et une planification supplémentaire du diagramme de flux aurait facilité le processus de conception de la logique pour soutenir les déclencheurs de dialogue. Sans surprise, une grande partie du déclenchement des dialogues a dû être fortement intégrée dans la logique de la mission pour qu’il soit déclenché au bon moment, ce qui signifie que les efforts pour examiner les dialogues en situation n’étaient pas réalisables même si tout avait fonctionné et que la mission était terminée lorsque les lignes “bouche-trous” avaient été livrées. Je pense que nous devons être plus attentifs aux attentes concernant l’examen des dialogues dans le mix lorsque celui-ci n’est réellement utilisé que pendant les tests QA, PTU et Evocati.
Plus de temps consacré au prototypage aurait été extrêmement bénéfique, en particulier pour les épaves de Starfarer, car les besoins pour la fonctionnalité ont changé au beau milieu du développement. Des demandes ont été faites pour ajouter la gravité à l’intérieur et pour ajouter la capacité de ciblage et le support de l’interface utilisateur. Nous avons fini par livrer une version des épaves de Starfarer moindre que prévu en raison de problèmes liés à l’apesanteur. Plus de prototypage nous aurait également permis de mieux comprendre l’équilibrage nécessaire pour arriver au point où nous savions que le combat fonctionnerait comme prévu. Il est arrivé que les retours nous conduisent sur une fausse piste, par exemple en nous faisant penser que les performances du serveur sont en cause au lieu de réels problèmes d’équilibrage. Il était donc parfois difficile de déterminer où se situaient les problèmes sans procéder à des tests approfondis pour les vérifier.
Les tests internes étaient parfois particulièrement difficiles en raison de la difficulté de reproduction, de l’ampleur des étapes de reproduction, du grand nombre de testeurs requis et des différences de fuseaux horaires. Parfois, les développeurs obtenaient des bugs sans étapes de reproduction qu’ils étaient incapables de reproduire en interne, tandis que d’autres fois, les étapes de reproduction étaient incroyablement longues et prenaient énormément de temps à tester. Nous devons être en mesure de tester la mission plus facilement afin de mieux comprendre son état à tout moment. Plus tard dans le développement, nous avons ajouté de nouveaux outils pour contourner certains aspects de la mission et modifier les paramètres internes afin d’accélérer le processus de test. Cela aurait dû être fait plus tôt.
Nous avons eu de nombreux retours de notre communauté sur des aspects de l’événement qui auraient pu être améliorés. Les joueurs n’ont pas été informés de la durée de la phase 3 et ont été surpris par sa fin. Une meilleure information pour gérer les attentes aurait amélioré la situation. La terminologie de l’événement concernant les phases était parfois confuse, avec des différences entre la façon dont les choses étaient désignées en interne et ce qui était décrit aux “backers” sur les fils de discussion sur Spectrum.
Nous savions dès le départ que la performance serait un facteur limitant et que cela signifiait que nous ne serions pas en mesure de fournir un nombre suffisant d’ennemis pour générer le niveau de défi que nous souhaitions dans certaines situations. Par conséquent, certains joueurs ont trouvé l’Idris beaucoup trop facile à tuer, ce qui a considérablement nui aux enjeux de la phase 3. Avec les bons armements (torpilles Typhoon), un seul Retaliator pouvait faire tomber les boucliers d’un Idris et plusieurs joueurs pouvaient le tuer en quelques minutes. En raison de la rapidité de la fin de la mission et de la longueur du délai de réapparition, les joueurs qui souhaitaient effectuer cette mission avaient du mal à trouver un serveur où elle était active et, le cas échéant, à y arriver à temps pour y participer. De plus, l’Idris ne constituait pratiquement aucune menace pour les joueurs, même s’ils ne le tuaient pas rapidement. Il agissait surtout comme une “cible ambulante”, de nombreux joueurs ayant mentionné qu’il restait immobile et tirait en continu.
La détection de l’hostilité et la détermination du CrimeStat sont encore trop simplistes, sans modificateur pour les participants se partageant la mission, que le vaisseau touché soit ciblé ou sans aucun lien avec le ciblage. Avec autant de vaisseaux à proximité les uns des autres dans un scénario complexe, les tirs amis étaient fréquents et entraînaient souvent l’attribution accidentelle d’un CrimeStat aux joueurs, leur éviction de la mission et leur envoi en prison à leur mort.
Nous voulions laisser aux joueurs la liberté totale de choisir leur camp, mais le temps nous manquait. Cela a causé des problèmes lorsque, inévitablement, de nombreux joueurs orientés PVP ont pris l’initiative d’attaquer les joueurs qui tentaient de participer à l’événement. Ce phénomène a surtout été observé lors de la phase 2. Mais comme l’événement ne le permettait pas, les participants à la mission avaient peu de moyens d’empêcher ou de contrer ces joueurs, ce qui a donné lieu à l’expresson d’opinions très tranchées de part et d’autre. La plupart des joueurs ont simplement quitté ces serveurs pour en trouver un sans PVP. De notre côté, nous réfléchissons à la façon dont nous pouvons soutenir les deux styles de jeu.
De nombreux joueurs ont fait état d’un mauvais taux de rafraîchissement côté client pendant les deux phases de combat. En outre, de nombreux rapports ont fait état d’assets essentiels à la mission se chargeant trop lentement, notamment les sites d’épaves, les vaisseaux de ravitaillement, les chasseurs du groupe XenoThreat et l’IA FPS (qui se chargeait parfois après que les joueurs avaient commencé à vider le cargo).
Contrairement à la phase 2, la phase 3 s’est concentrée sur le combat en vaisseau. Cela signifie que les autres styles de jeu, tels que la récupération et le combat FPS, n’ont pas été mis à contribution lors de la dernière phase, ce qui a engendré consternation et frustration chez certains joueurs.
Les joueurs disposent de systèmes d’identification d’amis ou d’ennemis (IFF) très limités et superficiels, le rouge représentant soit l’hostilité directe du joueur, soit une personne ayant un CrimeStat, et le bleu représentant tous les autres. Il n’y a aucun moyen pour les joueurs de savoir qui participe à la mission, qui est agressif ou hostile aux autres (sans réseau de communication), et souvent qui est dans leur groupe car les marqueurs de groupe ne sont pas toujours fiables. C’est à pied dans l’épave que cela s’est avéré le plus critique, car aucune identification n’était utilisée et les PNJ hostiles, les joueurs hostiles et les joueurs coopératifs de la mission apparaissaient tous de manière identique.
Les chasseurs IA s’agitaient, se téléportaient, volaient de manière erratique et n’offraient généralement aucune menace, les joueurs les qualifiant fréquemment de chair à canon. De plus, les joueurs ont souvent mentionné à quel point ils semblaient peu nombreux, ce qui limitait le sentiment de danger. Les chasseurs IA semblaient également ne pas avoir de comportements agressifs, comme cibler les transporteurs ou les bombardiers, et ignoraient parfois les dégâts qu’ils subissaient.
Bien que certains joueurs aient déclaré qu’elles étaient bien meilleures que dans les patchs précédents, les sorties EVA restent un problème, en particulier lors des transitions entre grilles physiques (entrée et sortie d’un vaisseau), les joueurs subissant fréquemment des dégâts ou mourant. Parmi les problèmes signalés, citons les malheureuses transitions au cours desquelles les joueurs tombent et/ou subissent des dégâts, les mouvements en vol généralement peu précis et les pertes de contrôle maladroites lorsqu’ils se heurtent à des objets.
Le spam de torpilles a dominé la phase 3 et a été encouragé par les gains financiers massifs en cas de succès. Les Idris n’ont souvent pas réussi à les contrer correctement et la nature simpliste de leur utilisation (verrouillage, lancement, terminé) a fortement contribué au sentiment de “facilité” de la phase 3.
Les systèmes de loi et d’hostilité nécessitent un travail important, notamment en ce qui concerne les tirs amis et les dégâts accidentels. Cela inclut comment et pourquoi nous appliquons un CrimeStat, comment les accusations sont portées, comment l’hostilité est déterminée, et une discussion approfondie sur la façon de mieux identifier les amis et les ennemis. Cela devrait inclure une distinction et des marqueurs pour les joueurs participant à la mission, les joueurs participant à la contre-mission (le cas échéant), les joueurs agressifs, les joueurs hostiles, les criminels et les factions le cas échéant.
Ce que nous ferons différemment pour nous améliorer à l’avenir :
Il y a plusieurs problèmes mentionnés ci-dessus dont nous discutons activement et que nous prévoyons de régler pour les prochains événements. Au cours des semaines à venir, nous examinerons tour à tour chacun de ces problèmes et déterminerons comment y remédier, quelles équipes y travailleront et où ils s’inscriront dans le calendrier. Les questions relatives aux performances, à l’IA, à la conception du PVP et au système de lois sont prioritaires pour que ces événements soient aussi agréables que possible.
Tony Zurovec, directeur de l’Univers persistant
Équipe IA
Ce qui s’est bien passé
XenoThreat a été une excellente occasion d’avoir un objectif partagé par plusieurs équipes. Cela se produit souvent lorsque nous établissons des objectifs communs spécifiques (étapes ou versions spécifiques) et cela rassemble généralement plusieurs départements.
Pour ce type d’événement, nous nous appuyons beaucoup sur d’autres équipes. Par exemple, l’équipe des missions de l’Univers persistant a été extrêmement réactive et nous avions constamment une personne clé à contacter au sujet du déroulement de la mission. Cela nous a permis de comprendre les objectifs qu’ils essayaient d’atteindre, d’ajuster la logique et de suggérer différentes façons d’aborder les problèmes chaque fois que nous le pouvions. La collaboration a été fantastique.
Ces événements nous donnent également l’occasion d’utiliser de nouvelles fonctions et d’améliorer les fonctionnalités existantes. Par exemple, nous avons pu faire la première passe sur le combat de vaisseaux capitaux, dévoiler la nouvelle affectation pour les demandes d’amarrage, et améliorer le flux actuel du monitoring pour le combat de pilotes.
Au cours de l’événement, nous avons spécifiquement examiné les comportements de l’IA et l’expérience du joueur. Le fait que tous les directeurs concernés aient participé à l’examen nous a permis de recueillir rapidement des commentaires et de discuter de ce qui aurait pu être fait dans le délai imparti.
Ce qui ne s’est pas bien passé
L’idée derrière XenoThreat était d’utiliser un délai spécifique attribué à la mission pour atteindre des objectifs très précis. L’intention était de ne pas surcharger l’équipe d’IA de demandes et de prendre des décisions intelligentes en entamant le développement du combat des vaisseaux capitaux. Par exemple, se concentrer sur l’amélioration de la distribution de la sélection des cibles parmi les nombreux opérateurs dans les vaisseaux ou implémenter la possibilité d’utiliser le railgun. Malheureusement, dans le calendrier général, la quantité de travail nécessaire pour rendre tout cela amusant n’a pas permis de prendre en compte les cas particuliers et cela a affecté la charge de travail de l’équipe.
Au cours du développement, nous nous sommes également retrouvés dans des situations où nous avons supposé que les bugs étaient dus au code de l’IA ou aux performances. Or, il s’est avéré qu’il s’agissait d’une combinaison d’autres éléments qui auraient pu être traités plus rapidement s’ils avaient été portés à notre attention. Une meilleure vigilance lors du test du flux peut éviter une grande partie de cette confusion.
Tenter d’améliorer les performances tout en corrigeant les bugs a rendu la dernière partie du développement un peu houleuse, mais nous nous y attendions, nous n’avons donc pas été si surpris.
Francesco Roccucci, directeur de l’intelligence artificielle
Équipe Expérience Véhicules
Ce qui s’est bien passé
Le travail de l’équipe chargée de l’expérience véhicules pendant l’événement XenoThreat s’est principalement concentré sur l’équilibrage de l’expérience de vol des vaisseaux capitaux avec les armes qu’ils utilisent, mais aussi avec les armes qui seraient utilisées contre eux par des vaisseaux comme l’Eclipse et le Retaliator.
Le réglage de l’équilibrage de vol avec l’Idris et le Javelin a permis à l’IA de positionner correctement chaque vaisseau pour attaquer et défendre. Nous avons fait quelques compromis en cours de route, de sorte que lorsque ces vaisseaux seront entre les mains des joueurs, ils seront légèrement différents. Mais à l’époque, c’était la bonne décision à prendre jusqu’à ce que nous ayons amélioré le comportement de certaines tourelles pour qu’elles ne dépendent plus autant du mouvement des vaisseaux.
Les changements les plus importants que nous avons apportés concernent la vitesse et la puissance des armes. L’ensemble de l’événement nous a poussé à ajouter des armes plus puissantes, notamment l’introduction du railgun dans l’Univers persistant, mais nous voulions équilibrer cela avec la vitesse. Plus une arme est puissante, plus elle se déplace lentement, à l’exception du railgun que nous avons utilisé pour repousser les limites de la vitesse dans Star Citizen. Nous voulions vraiment que le railgun soit redouté, en utilisant les visuels pour créer une anticipation de ce qui allait arriver et donner aux joueurs la possibilité de l’éviter si l’Idris réussissait à les aligner, et pour le moment, il s’est vraiment avéré être spécial.
Le point culminant de XenoThreat pour l’équipe chargée de l’expérience véhicules a été de voir les différentes équipes se réunir pour offrir ce qui était un événement fantastique, non seulement pour y participer mais aussi pour le regarder. Nous avons travaillé en étroite collaboration avec les équipes chargées des effets sonores et visuels pour nous assurer que l’équilibre que nous avions mis en place se reflétait fidèlement dans l’apparence et le son. Les développeurs ont passé de nombreuses soirées à regarder les différents streams que les backers avaient organisés, partageant chaque matin les meilleurs moments avec le reste de l’équipe.
Ce qui ne s’est pas bien passé
Du point de vue de l’équilibrage, la principale difficulté que nous avons rencontrée avec XenoThreat était l’obtention de résultats cohérents et reproductibles pour évaluer l’équilibrage dans une bataille dans le monde réel, car l’événement dépendait beaucoup des performances du jeu. Au fur et à mesure du développement, les performances se sont améliorées, mais ce n’est qu’au cours des deux dernières semaines avant la sortie que nous sommes parvenus à un point où, si tout se passait bien, l’événement se déroulait comme prévu du début à la fin.
Mais d’un point de vue positif, les problèmes de performance que nous avons rencontrés pendant le développement ont mis en évidence des problèmes spécifiques avec les armes et les boucliers que nous avons pu améliorer de manière drastique dans des scénarios de moindre performance. Ils ont également mis en évidence certaines lacunes dans l’équilibrage, que nous corrigerons dans les prochaines versions.
Rich Towler, Game Designer en chef
Performance
Ce qui s’est bien passé
Nous cherchons constamment à améliorer les performances, ce qui est très difficile car nous ajoutons constamment de nouvelles fonctionnalités au jeu. Et bien qu’il y ait beaucoup à faire pour obtenir les taux de rafraîchissement que nous visons, je pense que le principal avantage de XenoThreat est d’être parvenu à un niveau qui nous a permis d’offrir un événement agréable à de nombreux joueurs. Lorsque nous nous sommes essayés à ce type de combat de vaisseaux capitaux les années précédentes, nous étions tellement loin du compte en termes de performances que nous n’avons pas pu organiser un événement de cette ampleur.
Ce qui ne s’est pas bien passé
De nombreux joueurs ont fait état d’un mauvais taux de rafraîchissement côté client, en particulier lors des combats de vaisseaux dans la phase 2 et la phase 3, mais surtout dans la phase 3. Nous savons que les performances des serveurs doivent être améliorées, car cela permettra d’améliorer notamment les temps de réponse de l’IA.
Ce que nous ferons différemment à l’avenir
Je pense que la principale leçon à tirer de XenoThreat et des dernières versions est que nous avons besoin d’un meilleur système pour le profilage et l’analyse des performances, afin de disposer des outils permettant à toutes les équipes de cerner et d’optimiser plus facilement les performances plutôt que d’être bloquées ou dépendantes d’une petite poignée d’ingénieurs. L’équipe chargée du moteur et moi-même nous sommes déjà penchés sur la question et avons fait quelques premiers pas cette année. Nous disposons d’un nouveau cadre de stress test facile à utiliser pour le code, d’un meilleur support de profilage de débuggage imGUI et d’une meilleure auto-capture et analyse des données sur les performances. S’il est peut-être un peu tôt pour que ces améliorations portent leurs fruits pour l’Alpha 3.13, cela devrait nous être d’un grand secours à long terme. Cette année, toutes les équipes sont également tenues de consacrer plus de temps aux optimisations qui contribueront à cet effort. Et avec le Server Meshing à l’horizon, ainsi que plusieurs autres optimisations prévues à plus long terme, nous pourrons potentiellement réaliser des gains beaucoup plus importants lorsque celles-ci seront en ligne.
Rob Johnson, Directeur ingénieur – Gameplay de l’Univers persistant