Le 4 février 2021, nous avons lancé Alpha 3.12.1 : Assault on Stanton, qui a introduit le premier événement dynamique de l’univers Star Citizen. Ce qui suit est un post-mortem des développeurs seniors eux-mêmes, détaillant ce qui a été livré et leurs réflexions sur la façon dont cela s’est passé.
Qu’est-ce qui s’est bien passé?
La conception initiale de XenoThreat a été élaborée par Luke Pressley et moi (Tony Z). Nous avons tous les deux une solide connaissance pratique de l’état actuel du jeu et, après quelques itérations, le pitch final nous a semblé solide et réaliste. Il y avait une bonne quantité de documentation sur la façon dont l’événement se déroulerait, y compris une description détaillée de la façon de le jouer, des ennemis qui devraient apparaître, du fonctionnement des récompenses et de la façon de tester les remplacements d’écran. Tout cela a été maintenu tout au long du développement, qui a servi de référence rapide pour le QA et d’autres départements.
Après un début un peu maladroit, la boucle de rétroaction sur XenoThreat a fini par être une machine assez bien huilée. Le processus de collecte des commentaires du PTU via l’équipe d’expérience du joueur et les rapports de rétroaction, l’inscription des bogues avec les étiquettes appropriées, et l’examen et le tri de nouveaux bogues chaque jour pour obtenir des appels prioritaires ont fini par être un processus très propre. Nous avons passé un appel plus tard dans le processus pour que le contrôle qualité entre les tâches de suivi dans JIRA dès que le rapport de rétroaction est arrivé au lieu d’attendre les reproductions internes. Cela a permis une itération plus rapide, de sorte que parfois les développeurs étaient en mesure de répondre aux commentaires avant même que le contrôle qualité n’ait eu la possibilité de saisir un bogue approprié.
En ce qui concerne l’événement lui-même, un certain nombre de caractéristiques ont été bien accueillies. Le pool de revenus partagés, la distribution de style social des tâches et des types de jeu, et la nature de travail en commun du déchargement de la cargaison étaient extrêmement populaires auprès de la communauté. C’était en soi une grande partie de l’accueil positif. De plus, lorsque tout fonctionnait bien, la sensation et l’apparence étaient époustouflantes. Nous sommes très satisfaits de la façon dont l’équilibre entre la conception, les effets visuels et les effets spéciaux se sont réunis. Nous avons créé une équipe de frappe dédiée à rendre le combat agréable, ce qui a rendu l’itération rapide plus viable. Le récit qui accompagnait la sortie était également assez cool, et le commandant de XenoThreat était efficace et intimidant.
Les autres aspects de l’événement que nous avons trouvés réussis étaient les grandes opportunités de revenus dans le jeu pour les joueurs (toutes les phases), les pirates FPS qui peuplent les sites d’épaves (phase 2) et le style de paiement axé sur l’équipe (phase 2). De nombreux joueurs ont apprécié le bonus d’être très bien payé pour avoir organisé l’événement dans toutes les phases – cela incitait davantage le jeu continu et la rejouabilité accrue. Bien qu’il y ait eu quelques problèmes avec les personnages FPS AI, leur présence générale a rendu le passage des sites d’épaves plus intéressant pour les joueurs et a ajouté au style de jeu varié. Certains détracteurs voulaient plus de revenus par boîte dans un système de paiement plus individualisé, mais il y en avait beaucoup plus qui aimaient le style de paiement axé sur l’équipe, beaucoup disant qu’il encourageait la coopération.
S’il est regrettable que nous n’ayons pas pu le lancer en fin d’année, la décision de reporter l’événement jusqu’en 2021 lui a massivement profité. La différence entre ce que nous aurions sorti avant Noël et ce que nous avons fait est de jour comme de nuit en ce qui concerne la stabilité, les performances et la qualité de vie. Ce fut une excellente décision de la part de l’équipe de direction.
Qu’est-ce qui ne s’est pas si bien passé?
Les événements dynamiques sont un énorme exploit de gestion car leur livraison repose sur plusieurs départements. Ils exigent qu’un seul gestionnaire ayant une vision claire et une connaissance de tous les aspects soit disponible pour répondre aux questions et répondre aux commentaires. Afin de donner à XenoThreat l’attention qu’elle exigeait et méritait, beaucoup de gens ont dû jongler avec les responsabilités. Ce type de chose peut facilement conduire à un glissement d’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 leurs autres responsabilités peuvent en souffrir.
Le dialogue a beaucoup contribué à la mission, mais y parvenir était une grande entreprise avec de longs délais pour la livrer et les déclencheurs de la mission. Le temps était insuffisant pour intégrer les lignes réelles à la mission pleinement opérationnelle et effectuer une itération sur les changements appropriés. Nous avons eu des lignes d’espace réservé plus tôt mais, en raison de la fonctionnalité qui les a déclenchées ne fonctionnant toujours pas pleinement et la mission n’étant pas complètement terminée, il était difficile de les examiner sur place. Dans le passé, nous avons utilisé des programmes tels que Visio pour créer des flux indiquant quelles lignes déclenchent quand et quel ordre doit avoir lieu. Nous n’avons pas eu le temps de faire cela pour XenoThreat, donc le dialogue a é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 prendre en charge les déclencheurs de dialogue. Étonnamment, une grande partie du déclenchement du dialogue a dû être fortement intégrée à la logique de la mission pour qu’elle soit déclenchée au bon moment, ce qui signifiait que les efforts pour revoir le dialogue dans son contexte étaient irréalistes même si tout avait fonctionné et que la mission s’était terminée lorsque l’espace réservé. les lignes ont été livrées. Je pense que nous devons être plus attentifs aux attentes concernant la révision des dialogues dans le mixage lorsque ce mix ne joue vraiment que pendant les tests de contrôle qualité, PTU et Evocati.
Plus de temps passé au prototypage aurait été extrêmement bénéfique, en particulier pour les épaves de Starfarer, car les exigences en matière de fonctionnalités ont changé au milieu du développement. Des demandes ont été faites pour ajouter de la gravité aux intérieurs et pour ajouter une capacité de ciblage et une prise en charge de l’interface utilisateur. Nous avons fini par expédier avec une version de moins des épaves de Starfarer que prévu à l’origine en raison de problèmes avec le zéro-g. Plus de prototypage nous aurait également permis de mieux comprendre quel équilibre était nécessaire pour arriver au point où nous savions que le combat fonctionnait comme prévu. Il y a eu des moments où les commentaires pouvaient être de faux débats, tels que les performances du serveur étant une cause au lieu de problèmes d’équilibre réels. Cela rendait parfois difficile de déterminer où les problèmes se produisaient sans des tests approfondis à vérifier.
Les tests internes étaient parfois particulièrement difficiles en raison de la difficulté de reproduction, de l’ampleur des étapes de repro, du grand nombre de testeurs requis et des différences de fuseau horaire. Parfois, les développeurs recevaient des bogues sans étapes de repro qu’ils ne pouvaient pas reproduire en interne, tandis que d’autres fois, les étapes de repro étaient incroyablement longues et prenaient un temps considérable à 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 pour accélérer le processus de test. Cela aurait dû être fait plus tôt.
Il y a eu beaucoup de retours de notre communauté sur des aspects de l’événement qui auraient pu être meilleurs. Les joueurs n’ont pas été informés de la durée pendant laquelle la phase 3 resterait active et ont été surpris de la fin. Une meilleure information pour gérer les attentes aurait amélioré la situation. La terminologie des événements concernant les phases était parfois déroutante, avec des différences entre la façon dont les choses étaient référencées en interne et ce qui était décrit aux contributeurs sur les fils de rétroaction de Spectrum.
