Le 4 février 2021, CIG a 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 analyse des développeurs principaux eux-mêmes, détaillant ce qui a été livré et leurs pensées sur la façon dont cela s'est passé.
Mission XenoThreat
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 approfondie de la façon de jouer, des ennemis à faire apparaître, du fonctionnement des récompenses et de la façon de tester les modifications apportées à l'écran. Cette documentation a été conservée tout au long du développement et a servi de référence rapide pour l'assurance qualité et les autres services.
Après des débuts quelque peu maladroits, la boucle de rétroaction de XenoThreat a fini par devenir une machine bien huilée. Le processus de collecte des commentaires du PTU par l'intermédiaire de l'équipe d'expérience du joueur et des rapports de retours d'information, l'envoi des bogues avec les étiquettes appropriées, la révision et le triage des nouveaux bogues chaque jour pour obtenir des appels prioritaires ont fini par être un processus très propre. Plus tard dans le processus, nous avons demandé à l'équipe d'assurance qualité de saisir les tâches de suivi dans JIRA dès l'arrivée du rapport de retour d'expérience au lieu d'attendre les reproductions internes. Cela a permis une itération plus rapide, de sorte que les développeurs ont parfois été en mesure de traiter le retour d'information avant même que l'assurance qualité ait eu l'occasion de saisir le bogue 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 distribution sociale des tâches et des types de jeu, et la nature coopérative du déchargement des cargaisons ont été immensément populaires auprès de la communauté. En soi, cela a été une grande partie de l'accueil positif. De plus, lorsque tout fonctionnait bien, l'aspect et le look du jeu étaient magnifiques. 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 était également assez cool, et le commandant XenoThreat était efficace et intimidant.
Parmi les autres aspects de l'événement que nous avons trouvés réussis, citons les importantes possibilités de revenus en jeu pour les joueurs (toutes les phases), les pirates FPS peuplant les sites d'épaves (phase 2) et le style de paiement axé sur l'é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 FPS AI, leur présence générale a rendu la visite des sites d'épaves plus intéressante pour les joueurs et a contribué à la diversité du style de jeu. Il y a eu quelques mécontents qui voulaient plus de revenus par boîte dans un système de paiement plus individualisé, mais il y en a eu beaucoup plus qui ont aimé le style de paiement orienté vers l'équipe, beaucoup disant que cela encourageait la coopération.
Même 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. La différence entre ce que nous aurions publié avant Noël et ce que nous avons sorti est le jour et la nuit en ce qui concerne la stabilité, les performances et la qualité de vie. L'équipe de direction a pris une excellente décision.
Qu'est-ce qui ne s'est pas si bien passé ?
Les événements dynamiques sont un énorme exploit de gestion, car leur réalisation dépend de plusieurs départements. Ils nécessitent un responsable unique, doté d'une vision claire et d'une connaissance de tous les aspects, qui soit disponible pour répondre aux questions et aux commentaires. Afin d'accorder à XenoThreat l'attention qu'elle exigeait et méritait, de nombreuses personnes ont dû jongler avec les responsabilités. Ce type d'événement peut facilement entraîner le glissement des autres responsabilités. Si des événements de cette ampleur sont nécessaires plusieurs fois par an, ils ne peuvent pas simplement être absorbés par une équipe existante, car ses autres responsabilités peuvent en pâtir.
Le dialogue a ajouté beaucoup à la mission, mais son intégration a été une entreprise de grande envergure avec de longs délais de livraison et de déclenchement de la mission. Nous n'avons pas eu le temps d'intégrer les lignes réelles dans la mission entièrement fonctionnelle et d'itérer sur les changements appropriés. Nous avons intégré des lignes de remplacement plus tôt, mais comme la fonction qui les a déclenchées n'était pas encore totalement opérationnelle et que la mission n'était pas complètement terminée, il a été difficile de les examiner in situ. Dans le passé, nous avons utilisé des programmes comme Visio pour créer des flux de lignes qui se déclenchent à un moment donné et dans un ordre donné. 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. De manière surprenante, une grande partie du déclenchement du dialogue a dû être fortement intégré dans la logique de la mission pour qu'il soit déclenché au bon moment, ce qui signifie que les efforts pour analyser le dialogue dans son contexte n'étaient pas réalistes, même si tout avait fonctionné et que la mission s'était terminée lorsque les lignes de remplacement avaient été délivrées. Je pense que nous devons être plus attentifs aux attentes concernant l'examen du dialogue dans le mixage lorsque ce mixage n'est réellement utilisé que pendant les tests de QA, PTU et Evocati.
Plus de temps consacré au prototypage aurait été extrêmement bénéfique, en particulier pour les épaves du Starfarer, car les exigences de la fonctionnalité ont changé au milieu du développement. Des demandes ont été faites pour ajouter la gravité aux intérieurs et pour ajouter la capacité de ciblage et le support de l'interface utilisateur. Nous avons fini par livrer une version des épaves du Starfarer inférieure à celle prévue à l'origine en raison de problèmes liés à la gravité zéro. Un plus grand nombre de prototypes nous aurait également permis de mieux comprendre l'équilibre nécessaire pour arriver au point où nous savions que le combat fonctionnait comme prévu. Il est arrivé que le retour d'information soit une fausse piste, par exemple que les performances du serveur soient en cause plutôt que de réels problèmes d'équilibre. 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 bogues 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.
Notre communauté nous a fait part de nombreux commentaires 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 commentaires du 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 fait dérailler la phase 3. Avec les bons chargements (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écupération, 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 n'offrait pratiquement aucune menace aux joueurs, même s'ils ne le tuaient pas rapidement. Il agissait surtout comme une éponge à balles, 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 à la mission partagée si le vaisseau touché est 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 aboutissaient souvent à ce que les joueurs obtiennent accidentellement un CrimeStat, soient écartés de la mission et envoyés en prison à leur mort.
Nous voulions laisser aux joueurs la liberté totale de choisir leur camp, mais le temps nous manquait. Cela a posé 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 été le plus répandu lors de la phase 2. Mais comme l'événement ne le permettait pas, les participants à la mission avaient peu de moyens de l'empêcher ou de le contrer, ce qui a donné lieu à des 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 framerate client pendant les deux phases de combat. En outre, de nombreux rapports ont fait état d'actifs essentiels à la mission se chargeant lentement, notamment les sites d'épaves, les vaisseaux de ravitaillement, les chasseurs des XenoThreat et l'IA FPS (qui se chargeait parfois après que les joueurs aient commencé à vider le cargo).
Contrairement à la phase 2, la phase 3 s'est concentrée sur les combats de vaisseaux. Cela signifie que les autres styles de jeu, tels que la récupération et le combat FPS, n'ont pas pu contribuer, ce qui a provoqué une consternation et une frustration considérables 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 de l'IA se déplaçaient, se déformaient, 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 leur nombre semblait faible, ce qui limitait le sentiment de danger. Les chasseurs de l'IA semblaient également ne pas avoir de comportements agressifs, comme cibler les cargos ou les bombardiers, et ignoraient parfois les dégâts qu'ils subissaient.
Bien que certains joueurs aient déclaré que le jeu était bien meilleur que les patchs précédents, l'EVA reste un problème, en particulier lors des transitions entre les grilles physiques (entrée et sortie d'un vaisseau), les joueurs subissant fréquemment des dégâts ou mourant même. Des transitions malheureuses où les joueurs tombent et/ou subissent des dégâts ont été signalées, de même que des mouvements en vol peu soignés et imprécis, et des pertes de contrôle maladroites lors de chocs avec des objets.
Le spam de torpilles a dominé la phase 3 et a été encouragé par les gains massifs en cas de succès. Les Idrises 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 droit et d'hostilité nécessitent un travail important, notamment en ce qui concerne les tirs amis et les dommages 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 de la mission, les joueurs de 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ésoudre pour les événements futurs. Au cours des semaines à venir, nous examinerons tour à tour chacun des commentaires 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 au premier plan de nos préoccupations pour que ces événements soient aussi bons que possible.
-- Tony Zurovec, Persistent Universe Game Director
Équipe IA
XenoThreat a été une excellente occasion d'avoir un objectif commun à plusieurs équipes. C'est courant 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 de la mission PU 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 fonctionnalités et d'améliorer celles qui existent déjà. Par exemple, nous avons pu faire la première passe sur le combat de vaisseaux capitaux, exposer la nouvelle affectation pour demander l'amarrage, et améliorer le flux actuel du mastergraph 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 n'a pas si bien marché
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 commençant 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 multiples opérateurs de sièges de vaisseaux ou implémenter la possibilité d'utiliser le railgun. Malheureusement, dans le calendrier général, la quantité de travail nécessaire pour itérer sur le fait de rendre le jeu amusant signifiait que la prise en compte des cas limites n'était pas entièrement prise en compte 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 diligence raisonnable lors du test du flux peut éviter une grande partie de cette confusion.
Tenter d'améliorer les performances tout en corrigeant les bogues a rendu la dernière partie du développement un peu mouvementée, mais nous nous y attendions, nous n'avons donc pas été si surpris.
-- Francesco Roccucci, AI Director
Équipe chargée de l'expérience des véhicules
Le travail de l'équipe chargée de l'expérience des véhicules sur XenoThreat s'est principalement concentré sur l'équilibre 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'équilibre de vol avec l'Idris et le Javelin a consisté à permettre à 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és à ajouter des armes plus puissantes, notamment l'introduction du railgun dans le PU, 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 a tiré pour être spécial.
Le point culminant de XenoThreat pour l'équipe chargée de l'expérience des 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 mis en place, partageant chaque matin les meilleurs moments avec le reste de l'équipe.
Qu'est-ce qui ne s'est pas bien passé ?
Du point de vue de l'équilibre, la principale difficulté que nous avons rencontrée avec XenoThreat était d'obtenir des résultats cohérents et reproductibles pour évaluer l'équilibre dans une bataille réelle, 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 du début à la fin comme prévu.
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 moins performants. Ils ont également mis en évidence certaines lacunes dans l'équilibre du jeu, que nous corrigerons dans les prochaines versions.
-- Rich Towler, Lead Game Designer
Performances
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 point positif en termes de performances pour XenoThreat est que nous avons atteint 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.
Qu'est-ce qui ne s'est pas bien passé ?
De nombreux joueurs ont fait état d'un framerate client médiocre, notamment lors des batailles de vaisseaux en phase 2 et en phase 3, en particulier lors de la phase 3. Nous savons que les performances du serveur doivent être améliorées, car cela permettra d'améliorer des choses comme 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 de profilage et de régression des performances, afin de disposer des outils permettant à toutes les équipes de profiler 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 des moteurs 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 test de stress facile à utiliser pour le code, d'un meilleur support de profilage de débogage imGUI et d'une meilleure capture et analyse automatiques des données de performance. S'il est peut-être un peu tôt pour porter beaucoup de résultats 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 qui se profile à l'horizon, ainsi que plusieurs autres optimisations planifiées à plus long terme, nous pourrons potentiellement réaliser des gains beaucoup plus significatifs lorsque celles-ci seront en ligne.
-- Rob Johnson, Engineering Director, Persistent Universe Gameplay
