Alpha 3.13 & Invictus Launch Week Postmortem

[Maarkreidi]

 

 

Alpha 3.13 & Invictus Launch Week Postmortem

 

Le 22 avril 2021, nous avons lancé l'Alpha 3.13 : Underground Infamy, qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, notamment l'amarrage de vaisseau à vaisseau, des entrées de grottes supplémentaires et le gestionnaire de réputation. Ce qui suit est un postmortem 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é. Ce compte rendu porte à la fois sur le patch Alpha 3.13 et sur l'événement Invictus Launch Week.

 

Pilier des Véhicules

John Crewe, Vehicle Director 

 

Pour la version Alpha 3.13 de Star Citizen, le pilier Véhicules a fourni un mélange de nouvelles fonctionnalités, les bases de futures initiatives, et notre habituelle livraison de contenu.

 

Merlin/Constellation Docking

Qu'est-ce qui s'est bien passé ?

Nous avons réussi à apporter une fonctionnalité attendue depuis longtemps à l'un des vaisseaux les plus emblématiques de Star Citizen. Bien que nous ayons eu l'intention de le faire dans l'Alpha 3.12, la décision de passer un trimestre supplémentaire à le peaufiner a porté ses fruits lors de la sortie, car il était beaucoup plus stable et plus étendu que prévu.

 

Qu'est-ce qui a moins bien fonctionné ?

La décision de reporter XenoThreat à 2021 a fait que nous avons été pris plus longtemps que prévu dans la correction des bugs pour l'événement, ce qui a réduit notre capacité à réagir aux problèmes de la fonctionnalité avant qu'elle ne soit envoyée aux Evocati pour les tests.

 

Ce que nous ferons différemment à l'avenir

D'une manière générale, le processus de mise en œuvre de la fonctionnalité s'est bien déroulé, donc à part le fait de tester plus tôt, il n'y a pas grand-chose que nous allons améliorer à l'avenir.

 

Noms et numéros de série des véhicules

Qu'est-ce qui a bien fonctionné ?

La possibilité de personnaliser son vaisseau est une fonctionnalité demandée depuis longtemps, et c'est quelque chose que nous voulions offrir depuis bien plus longtemps, mais nous avons eu quelques problèmes techniques à résoudre en coulisses concernant le rendu et le flux des droits de la plate-forme au jeu. La livraison d'une petite sélection de vaisseaux a permis de tester la technologie et de mieux comprendre les limites du système.

 

Qu'est-ce qui ne s'est pas bien passé ?

Le plus gros problème, et de loin, était la lisibilité, en particulier pour les noms courts où la taille de la police est restée la même que pour un nom de 32 caractères maximum. Un nom court, combiné à un éclairage extérieur du vaisseau moins qu'idéal et à l'impossibilité de personnaliser la couleur du texte, a entraîné de gros problèmes de lisibilité.

 

Ce que nous ferons différemment à l'avenir

Nous travaillons avec les équipes Graphisme et Interface utilisateur sur une meilleure implémentation via les Building Blocks pour nous permettre de changer dynamiquement la taille de la police en fonction de la longueur de la chaîne de caractères saisie. Une disposition UV optimisée sera créée à cet effet. Le système de peinture sera également amélioré à l'avenir pour permettre aux joueurs de choisir la couleur du nom afin d'éviter les collisions.

 

Dégradation visuelle de la coque

Qu'est-ce qui a bien fonctionné ?

Depuis l'introduction de la dégradation des objets et des défaillances dans Star Citizen Alpha 3.6, il manquait la dégradation visuelle de la coque du vaisseau en même temps que celle des autres objets. Maintenant que nous l'avons fait, vous avez une meilleure idée de l'état de votre vaisseau grâce aux images de la coque, sans avoir à chercher dans les MFD. Le système est lié à notre pipeline de production existant pour les véhicules, nous n'avons donc pas eu à revenir en arrière et à l'ajouter aux vaisseaux, ce qui a rendu la mise en œuvre beaucoup plus rapide.

 

Qu'est-ce qui ne s'est pas bien passé ?

Un certain nombre de vaisseaux n'ont pas été pris en compte lors de nos tests internes, ce qui a conduit à ce que la verrière soit entièrement "grattée" et bloque la vue. Ce n'était pas notre intention - l'objectif était de limiter l'usure au bord de la vue.

L'équipe chargée du contenu doit donc revenir en arrière et ajuster manuellement les cartes d'usure et les paramètres sur les anciens vaisseaux.

 

Ce que nous ferons différemment à l'avenir

Comme nous l'avons mentionné, certains vaisseaux présentent une usure trop importante dans des zones clés, ce qui sera corrigé au cas par cas. À l'avenir, en ce qui concerne les dommages physiques, il ne s'agira plus d'une caractéristique purement visuelle, mais d'une caractéristique ayant des conséquences sur la structure et le jeu.

 

 

Accostage entre vaisseaux et stations

Bien qu'elle ne fasse pas officiellement partie de la version Alpha 3.13, nous avons en fait lancé cette fonctionnalité avec le patch, bien qu'elle soit désactivée et prête à être mise en ligne avec la 3.13.1 (semaine de lancement d'Invictus). Nous avions initialement prévu d'intégrer les deux fonctions dans le même patch, mais nous avons décidé de ne pas l'intégrer officiellement, pour les mêmes raisons que celles qui nous ont poussés à ne pas intégrer l'amarrage Connie/Merlin, afin d'améliorer la qualité de la version.

 

Tumbril Cyclone MT

Le Cyclone MT a été un véhicule surprenant sur lequel nous avons travaillé pendant les périodes d'inactivité entre les sorties et qui a permis d'élargir notre gamme de véhicules terrestres, en particulier pour les théâtres de guerre.

Le défi d'avoir une tourelle montée contrôlant à la fois les missiles et les armes a causé quelques problèmes lors de la phase de configuration, mais le MT fournit une puissance de feu supplémentaire intéressante à la gamme Cyclone au prix d'être le plus lent de la famille.

 

 

Greycat ROC-DS

Le ROC-DS est un véhicule qui a connu des difficultés lors de son développement et de sa sortie publique, ayant été conçu à l'origine pour être le véhicule principal de la famille. Cependant, en raison des délais de production, nous avons dû sortir le ROC bien avant le ROC-DS. L'objectif initial était de sortir les deux en même temps pour offrir des options plus claires aux joueurs, mais le décalage important entre les deux n'a fait qu'accroître les problèmes de perception concernant son rôle et son utilité.

Bien que le ROC-DS ait bénéficié d'améliorations considérables au cours des phases Evocati et PTU, augmentant à la fois sa capacité et sa portée, ces objectifs n'ont pas été suffisamment communiqués au début du cycle de sortie, ce qui l'a fait souffrir plus que prévu. Le ROC-DS n'a jamais été censé être une nette amélioration du ROC ; c'est un complément permettant à deux joueurs de travailler ensemble dans des endroits plus exigeants et plus éloignés de la base.

Il est actuellement en mauvaise position, mais les changements à venir dans le comportement de l'inventaire, le système de cargaison et les grottes lui permettront peut-être de retrouver la position que nous avions prévue pour lui. Si ce n'est pas le cas, nous étudierons d'autres changements pour améliorer son accueil.

 

 

Pilier Live

Todd Papy, directeur de Star Citizen Live 

 

EUPU : Sous-composants miniers 

Qu'est-ce qui s'est bien passé ?

Nous avons continué à approfondir et à développer le gameplay de l'exploitation minière et nous avons mis en place les sous-composants sans trop de difficultés. Le processus de demande de test d'assurance qualité (QATR) s'est également bien déroulé, avec une excellente communication au sein de l'équipe.

 

Qu'est-ce qui ne s'est pas bien passé ?

La stabilité du développement du jeu était précaire, ce qui a entraîné des retards dans la mise à jour des builds avec les intégrations. 

 

Ce que nous ferons différemment à l'avenir

L'équipe crée des QATR pour intégrer son travail au développement du jeu comme un processus habituel. Malheureusement, le service d'assurance qualité a été très occupé par les versions Alpha 3.13 et 3.13.1, qui étaient toutes deux importantes. Cela affecte actuellement l'efficacité du processus QATR, ce qui entraîne un retard important dans les intégrations de sprint des versions non à venir.

 

 

Contenu de Mission Live : Livraisons sensibles au Quantum et livraisons multi-dépôts minutées 

Qu'est-ce qui s'est bien passé ?

Tout s'est bien passé car nous avons utilisé des technologies existantes, dont une grande partie avait été créée pour la mission XenoThreat.

 

Qu'est-ce qui ne s'est pas bien passé ?

Certaines des boîtes ne se sont pas comportées comme prévu, ce qui s'est avéré être un problème avec le comportement des entités. Les minuteurs n'indiquaient pas le bon temps et la boîte explosait à deux minutes de la fin. 

Hurston n'est pas le meilleur endroit pour les missions de long vol à cause de la distribution des emplacements. Nous avons augmenté les gains mais nous allons continuer à les améliorer.

 

Ce que nous ferons différemment à l'avenir

Nous devons améliorer le transfert des comportements des entités et clarifier les responsabilités entre les équipes. 

 

Pilier du Cœur du Gameplay 

Richard Tyrer, directeur du jeu S42 FPS 

 

Armes montées 

Qu'est-ce qui a bien fonctionné ?

Par sa nature même, Star Citizen est un jeu d'armes mixtes combinant le combat à pied, en véhicule et en vaisseau. Les armes montées s'intègrent directement dans cette combinaison en permettant aux joueurs à pied de se mesurer aux véhicules et aux petits vaisseaux. Nous avons déjà le lance-missiles Animus et le railgun Scourge, mais ils n'offrent qu'une faible résistance avant que vous ne soyez à court de munitions. Avec l'intention à long terme de créer des fermes et des avant-postes, nous voulions fournir au joueur et à l'IA des options supplémentaires pour défendre ces zones.  

Nous avons dû relever deux grands défis avec le canon monté : sa taille et le système de contrôle. Les plus attentifs d'entre vous auront probablement remarqué que le canon monté est une arme de vaisseau de taille 1, car nous avions besoin de ce type de puissance de feu. Si ces armes sont petites sur un vaisseau, elles sont énormes dans les mains des joueurs, ce qui nous a posé plusieurs problèmes. Tout d'abord, il occupait tout l'écran à la première personne, ce qui rendait la ligne de visée terrible, et ensuite, le point de pivot des armes de vaisseau n'était pas idéal pour un personnage essayant de viser vers le bas et de pivoter verticalement. Comme nous avions déjà une arme de vaisseau, nous avons pu l'intégrer rapidement dans l'éditeur, ce qui nous a permis d'itérer très tôt sur l'expérience à la première personne sans avoir à trop nous soucier des métriques. Cela a été une véritable aubaine car nous avons pu travailler sur le pivot de l'arme, ses angles de vue et les vues ADS tout en conservant la crédibilité d'une arme capable d'abattre un vaisseau.  

L'autre défi auquel nous avons été confrontés était le schéma de contrôle. Nous avons longuement débattu pour savoir si nous devions utiliser un schéma de contrôle plus centré sur les FPS ou quelque chose de plus proche d'une tourelle de vaisseau. Heureusement, nous avions prévu suffisamment de temps pour mettre en œuvre les deux schémas et y jouer pour voir lequel était le meilleur. Cela nous a permis d'affiner l'expérience et de livrer une bonne première itération. Nous avons également prévu à long terme d'essayer d'ajouter les options de contrôle supplémentaires aux écrans de menu afin que les joueurs puissent choisir ce qu'ils préfèrent.  

 

Qu'est-ce qui a moins bien fonctionné ?

L'utilisation d'une arme de vaisseau préexistante nous a permis d'itérer très tôt et de régler les paramètres sans avoir à créer toute une série de nouvelles illustrations. Cela avait aussi l'avantage qu'à l'avenir, toute arme de vaisseau de taille 1 pourrait théoriquement être montée sur un support. Malheureusement, cela ne s'est pas passé aussi facilement que nous l'espérions, car les armes de vaisseau se montent par le haut plutôt que par le bas. Cela signifie que l'arme était montée à l'envers et avait beaucoup de géométrie supplémentaire qui bloquait la vue principale. Bien qu'il s'agisse d'un problème relativement facile à résoudre, cela signifie que toute nouvelle arme que nous souhaitons utiliser à l'avenir nécessitera des ajustements artistiques et des données supplémentaires pour la prendre en charge.  

 

Ce que nous ferons différemment à l'avenir

Les armes montées sont une fonctionnalité qui nécessite l'intervention d'une équipe chargée du contenu (il ne s'agit pas d'une fonctionnalité systémique comme le saut ou le statut d'acteur). Bien que nous souhaitions toujours mettre les fonctionnalités entre les mains des joueurs le plus rapidement possible à des fins de test, je pense que son implémentation actuelle dans les PU ne sert pas vraiment à grand-chose. Avec le recul, je pense qu'il aurait été préférable de l'implémenter, de demander un feedback spécifique des PTU/Evocati, puis de la publier dans un patch ultérieur, une fois que les équipes de contenu auraient eu suffisamment de temps pour construire quelque chose autour de cette fonctionnalité.

 

Pousser/tirer des chariots. 

Qu'est-ce qui a bien fonctionné ? 

La fonction de poussée/traction de chariot permet aux joueurs d'interagir avec un objet, tel qu'un chariot ou un bloc, et de le pousser ou le tirer dans la direction de leur choix (à condition qu'ils aient de la prise). Star Citizen étant un jeu de type "bac à sable" avec de multiples gravités et planètes, nous devions nous assurer que cette fonctionnalité était systémique afin qu'elle puisse fonctionner et s'adapter à différents poids et environnements. Nous voulions également que le chariot soit physiquement correct, les charges les plus lourdes étant plus difficiles à contrôler. L'équipe a travaillé directement avec les programmeurs de physique pour créer un modèle physiquement correct qui donne vraiment l'impression de pousser un chariot ou un bloc. Le personnage s'appuie sur des charges plus lourdes et les commandes donnent l'impression d'être lourdes et ancrées dans le sol.  

 

Qu'est-ce qui n'a pas bien fonctionné ?

L'équipe s'est attachée à ce que le chariot soit bien ancré dans le monde et a construit une carte de test élaborée pour tester de multiples facettes de la fonctionnalité, notamment le chargement sur un vaisseau. Cela a mis en évidence un problème important. Un grand nombre de chariots construits au fil des ans avaient été conçus pour une métrique de caractère avec des roues relativement petites. Malheureusement, les vaisseaux ont tous des rampes différentes, certaines ayant des bords anguleux très durs et d'autres ne s'abaissant pas du tout pour toucher le sol. Cela signifie que de nombreux chariots ont eu du mal à monter les rampes des vaisseaux et, dans certains cas, n'ont pas pu franchir le bord de la rampe car il était trop large (pensez à essayer de pousser un chariot de supermarché sur un trottoir). Comme l'équipe Véhicules était déjà prévue pour le trimestre, nous n'avons pas pu offrir l'expérience complète du chariot.  

 

Ce que nous ferons différemment à l'avenir

La fonction "pousser/tirer" des chariots a toujours été conçue pour servir deux objectifs : un mécanisme de puzzle et le chargement des marchandises. En tant que mécanisme d'énigme, la fonctionnalité fonctionne bien et permet aux concepteurs de commencer à créer des missions/espaces nouveaux et intéressants où les joueurs peuvent utiliser des chariots et des blocs pour accéder à des points de vue plus élevés. En tant que mécanisme de chargement de marchandises, il n'est pas à la hauteur en raison des limitations des roues et de la taille des rampes des vaisseaux. À l'avenir, nous développerons un chariot aéroglisseur qui atténuera une grande partie de nos problèmes et qui s'appuiera sur les chariots plus traditionnels pour les zones d'atterrissage et les missions spécifiques.  

 

Gameplay et services systémiques

Tony Zurovec, PU Game Director

 

Interface utilisateur de la réputation

Qu'est-ce qui a bien marché ?

Dans le cadre de l'Alpha 3.13, nous avons été en mesure de publier l'interface utilisateur de la réputation, donnant aux joueurs une représentation visuelle et un contexte pour notre version initiale T0 du système de réputation au quatrième trimestre 2020. Pour cette version, nous avions relié la réputation aux missions de chasse à la prime (et à quelques autres), mais les joueurs n'avaient aucune visibilité sur les raisons pour lesquelles la progression de leur mission changeait. Nous avons également institué la première passe de récompense des joueurs en fonction de leur progression de réputation. Avec l'interface utilisateur maintenant en place, les joueurs ont beaucoup plus de clarté sur leur statut avec les organisations et les donneurs de mission.

Le développement et le lancement de cette fonctionnalité se sont déroulés sans heurts pour l'équipe. Les rapports d'analyse que nous avons reçus ont montré des résultats incroyablement positifs avec les joueurs dans la version Alpha 3.13, ce qui a entraîné un taux d'engagement plus élevé dans les missions de chasse à la prime. 

 

Qu'est-ce qui ne s'est pas bien passé ?

Il y a eu un contretemps inattendu avec certaines modifications du service de réputation qui n'ont pas été bien communiquées à l'équipe chargée des fonctionnalités. Il en a résulté quelques corrections urgentes qui ont dû être effectuées très peu de temps avant la sortie de la version Alpha 3.13.

De plus, nous n'avons pas encore converti l'intégralité du contenu de nos missions au nouveau système, et nous n'avons pas eu le temps de remanier les comportements des donneurs de mission pour qu'ils soient aussi réactifs aux compteurs d'affinité et de fiabilité. Bien qu'il s'agisse d'un effort continu et que les joueurs doivent s'attendre à des progrès constants, il faudra malheureusement du temps pour passer en revue l'ensemble de nos missions et remanier les comportements des donneurs de mission.

 

Ce que nous ferons différemment à l'avenir ?

Nous nous efforcerons d'améliorer notre communication globale sur les fonctionnalités à l'avenir, notamment pour celles qui impliquent des services ou un soutien externe de l'équipe des fonctionnalités. Les initiatives inter-équipes ont toujours connu un certain niveau de rupture de communication en raison de notre distribution mondiale, et nous cherchons donc toujours à améliorer ce processus. Plus précisément, nous essayons de créer davantage de documents de conception technique (TDD) avant de lancer ces initiatives plus importantes. Cela devrait contribuer à une prise de conscience mondiale, puisque tous les groupes concernés sont tenus de fournir un retour sur les TDD au cours de ce processus. 

En outre, avec le système maintenant en place et notre deuxième système stellaire à l'horizon une fois que le maillage des serveurs sera en ligne, nous avons des discussions de conception en cours sur la façon dont nous allons structurer les organisations au sein de l'univers pour les cinq premiers systèmes. Ces discussions portent notamment sur l'expérience des nouveaux joueurs et leur emplacement de départ, sur la façon dont les joueurs progressent dans un seul système et sur la façon dont les grandes organisations influenceront le contenu de plusieurs systèmes. Cela nous permet également de définir le gameplay de chacun des principaux types de mission, le plan actuel prévoyant d'associer chaque type de mission aux pistes de réputation au sein des organisations. Tout au long de ce processus, nous avons fait des progrès significatifs vers (ce que nous pensons) être la version/vision initiale de la façon dont cette mécanique de progression majeure affectera l'expérience globale du joueur. Bien que nous devions encore obtenir l'approbation finale, nous pensons que cela correspond à la façon dont la réputation a été présentée au public et nous sommes impatients de faire avancer les choses.

 

Semaine de Lancement d'Invictus

Qu'est-ce qui s'est bien passé ?

L'exposition associée à la Semaine de lancement Invictus s'est déroulée sans problème. Il s'agit d'un processus que nous avons effectué plusieurs fois jusqu'à présent, donc la mise en place d'un nouvel événement expo est une procédure connue.

D'un autre côté, l'équipe de l'USPU a contribué à la sortie de certaines fonctionnalités supplémentaires d'Invictus, qui élargissent notre boîte à outils de service de mission dynamique. C'est la première fois que nous avons pu modifier l'inventaire d'une boutique de façon dynamique en fonction des événements du jeu (ce que nous appelons les Modificateurs de boutique dynamiques). Ce système sera finalement lié/contrôlé par l'outil Quanta dont vous avez pu nous voir parler dans notre dernière présentation vidéo. Nous pouvons également l'utiliser non seulement pour ajouter de nouveaux articles spécifiques à un événement, mais aussi pour modifier la consommation ou le réapprovisionnement de ces produits par une boutique, ce qui modifie le prix global de l'article. Ces changements sont limités dans le temps pendant l'événement, ce qui nous permet de modifier le climat économique d'autant de magasins que nous le souhaitons pour obtenir les résultats souhaités.

Nous avons également ajouté quelque chose de connexe qui nous aidera éventuellement à développer la profession de cargo. Nous les appelons "déclencheurs de seuil de prix". Ils sont destinés à nous permettre de déclencher des missions en fonction des inventaires des boutiques qui atteignent des niveaux désignés. Cependant, comme première étape vers la création de missions, nous les avons utilisés pour donner aux joueurs un aperçu précieux de ce qui est actuellement demandé (à acheter ou à vendre) à un endroit donné pendant la durée de l'événement. Cela a été fait temporairement par le biais des entrées du journal qui sont générées par le système de mission. Maintenant que ces éléments sont en place, la prochaine étape consistera à envoyer des demandes à l'échelle du jeu (à la distance de notre choix dans un système stellaire ou entre des systèmes), dans le cadre de notre évolution vers un univers piloté par les Quanta. Bien que le travail de visualisation des informations de la boutique dans le journal soit une solution temporaire, toutes les fonctionnalités sous-jacentes sont implémentées comme prévu, il y aura donc très peu de travail à faire une fois que nous aurons refait l'interface du gestionnaire de mission ou ajouté un certain niveau d'informations économiques ailleurs dans le jeu (le calendrier de cet ajout est encore à déterminer).

Enfin, tout cela étant dit, les joueurs ont apprécié le fait que les boutiques exposent des objets et/ou changent les prix de façon dynamique pendant l'événement. Nous avons hâte de développer ce système, car c'est vraiment l'un des principaux fondements des systèmes économiques et de fret.

 

Qu'est-ce qui n'a pas bien fonctionné ?

Certains changements apportés au système de train d'atterrissage des vaisseaux ont entraîné des irrégularités dans les valeurs de compression par défaut ou générées. Cela a entraîné de nombreux tests fastidieux de notre part pour nous assurer que tout était placé comme prévu, afin de pouvoir confirmer que tout ce que nous pouvions voir était un problème véritable et non un simple problème de placement.

En ce qui concerne les modificateurs d'atelier dynamiques, le plus gros facteur de stress a été le fait que certaines fonctionnalités sont arrivées assez tard dans le processus, ce qui a laissé très peu de temps pour les tester dans le PTU. Si cette fonctionnalité n'avait pas très bien fonctionné lorsque nous l'avons finalement obtenue, le problème aurait été plus important. L'événement Ninetails Lockdown (censé sortir avec l'Alpha 3.13, puis Invictus, et enfin l'Alpha 3.14), était également en concurrence pour la ressource AQ pendant cette période, ce qui est l'une des principales raisons pour lesquelles il a été repoussé à l'Alpha 3.14. La priorité devant rester sur Invictus, nous n'avons eu d'autre choix que de sacrifier Ninetails, ce qui a été une déception en interne.

Le flux de travail pour la mise en place des modificateurs de boutique et des déclencheurs de seuil de prix n'était pas non plus propice à la réalisation rapide de changements à grande échelle. En outre, la situation est actuellement un peu confuse car, historiquement, nous utilisons le contexte d'"achat" et de "vente" du point de vue du joueur, mais cela a été en quelque sorte inversé dans le contexte des déclencheurs de seuil. Cela entraîne évidemment une grande confusion lors de la configuration de ces derniers et doit absolument être corrigé avant d'aller plus loin avec cette fonctionnalité.

En outre, tout en réglant les déclencheurs de seuil, nous avions un fort désir de modifier les entrées de la boutique que nous n'avions pas la possibilité de modifier à partir de l'interface de modification de la boutique dans Subsumption, y compris le décalage du prix de base, l'inventaire actuel, et quelques autres. Nous avons contourné ce problème en ajoutant des objets à l'inventaire pour les configurer, PUIS en changeant leur contexte d'achat à vente lorsque les marchandises étaient disponibles pour être collectées/achetées ailleurs dans l'univers. Bien qu'il s'agisse d'une tactique courante pour les concepteurs lorsque les outils ne font pas ce qu'ils veulent, elle est généralement désapprouvée parce qu'elle ajoute des dettes techniques qu'il faudra corriger plus tard.

 

Ce que nous ferons différemment à l'avenir

J'aimerais intégrer au moteur des fonctions de débogage supplémentaires qui nous permettraient de résoudre rapidement les problèmes de compression des trains d'atterrissage. Pour l'instant, nous avons déjà ajouté quelques nouvelles méthodes de débogage dans le jeu depuis notre dernière expo. Cependant, ces anomalies pourraient potentiellement être plus faciles à repérer avec un retour d'information supplémentaire sur le débogage. À l'approche de la prochaine expo, j'aimerais consacrer du temps à faire en sorte que ces problèmes soient facilement identifiés et résolus par des solutions basées sur les données.

Nous aimerions voir une meilleure coordination entre l'AQ et les équipes de développement qui nécessitent une implication à grande échelle de l'AQ, comme Invictus et Ninetails. Nous avons certainement vu et reconnu plusieurs des points douloureux que cela a causé, mais cela va continuer à se produire à mesure que nous faisons plus de ces événements, donc nous devrons resserrer ce flux de travail à l'avenir. Idéalement, nous devrions essayer d'obtenir la livraison de toutes les fonctionnalités de jeu et des services connexes bien avant toute date de livraison potentielle. Par exemple, bien avant de brancher le prochain flux de diffusion et certainement avant de passer à une phase de PTU. J'aimerais également voir moins de développement de fonctionnalités dans le flux de sortie à mesure que nous avançons.

Bien que cela doive encore être programmé, j'aimerais que la présentation de l'interface utilisateur des entrées de journal soit améliorée dans les futures révisions, car elles concernent les produits de base qui sont demandés. Il faut les classer par zone d'atterrissage et ensuite, dans chaque zone d'atterrissage, montrer ce que vous pouvez acheter et ce que vous pouvez vendre. La solution idéale serait d'avoir un type d'information économique disponible quelque part comme la carte des étoiles, ou une application séparée, mais comme mentionné ci-dessus, ce travail doit actuellement être programmé, donc tout ajout est à déterminer.  

 

Fonctionnalités des Missions

Qu'est-ce qui s'est bien passé ?

XenoThreat et Fleet Week ont été deux événements majeurs sur lesquels l'équipe chargée des missions a travaillé au cours du premier trimestre 2021. La collaboration entre nous et les autres départements sur ces deux initiatives, en particulier l'AQ, a été plus forte que jamais, et nous pensons que cela se voit dans le produit fini.

XenoThreat avait besoin d'un peu plus de temps pour s'équilibrer et aplanir les derniers bogues et, heureusement, nous avons eu droit à ce délai, même si l'attente initiale était qu'il sorte pour les fêtes de fin d'année.

Heureusement, nous avons pu ajouter du contenu dans les grottes. Cela ne faisait même pas partie de notre liste de livrables prévus pour le trimestre, mais il nous a semblé dommage de sortir de nouvelles entrées de grottes sans que quelque chose y soit présent. Nous avons également ajouté beaucoup plus de lieux de mission dans l'anneau d'astéroïdes Yela. 

Notre équipe a pu ajouter une nouvelle interface graphique de débogage, qui s'avère désormais précieuse pour identifier les problèmes à un rythme beaucoup plus rapide. Et la création de nouvelles missions de livraison s'est déroulée rapidement et en douceur, notamment grâce à des modules de mission bien établis et à la réutilisation d'entités de XenoThreat. 

 

Qu'est-ce qui a moins bien fonctionné ?

XenoThreat, comme nous l'avons mentionné, n'a pas atteint la date de sortie prévue. C'est évidemment regrettable mais, étant donné l'ampleur de ce que nous voulions réaliser avec cet événement, nous avons estimé que c'était compréhensible et, heureusement, nous avons pu lui donner le temps nécessaire pour le peaufiner jusqu'à ce qu'il soit prêt. 

La création et le maintien d'entités uniques ont également posé problème. Par exemple, les boîtes sensibles au voyage quantique étaient un mélange du travail de plusieurs équipes, donc en ce qui concerne les bugs, il était souvent difficile d'avoir de l'avance. La maintenance continue de ces boîtes pourrait désormais poser problème, car il n'y a pas vraiment de développeur défini pour les gérer et les entretenir. 

Les vaisseaux parasites ont également causé des problèmes au niveau du système juridique qui n'ont été repérés qu'après la sortie de la version Alpha 3.13.

 

Ce que nous ferons différemment à l'avenir

Nous ferons en sorte que l'équipe soit incluse dans toutes les fonctionnalités susceptibles d'affecter ou de nécessiter le soutien du système juridique, afin d'essayer d'anticiper et, espérons-le, de minimiser les problèmes imprévus pour les initiatives futures.  

 

Services et outils systémiques

Qu'est-ce qui a bien fonctionné ?

Les ressources supplémentaires des équipes backend ont permis de soulager immédiatement la charge de travail de l'équipe Systemic Services & Tools (SST). Le SuperCache a été déployé et le travail a pu commencer sur plusieurs initiatives à plus long terme visant à intégrer Quantum dans davantage de services. La présentation publique s'est bien déroulée et a été accueillie très positivement. La technologie que nous avons investie dans les écrans de présentation sera utilisée à l'avenir pour démontrer d'autres concepts de haut niveau.  

Quasar a été déployé. Il s'agit de l'outil de mission dynamique présenté dans la vidéo de mise à jour du SST publiée en avril. Le développement de Quasar a été simple grâce au travail effectué avec Odin l'année dernière, qui a permis de réaliser la plupart des travaux de base nécessaires pour se connecter aux services en direct et aux instances DGS. À l'avenir, l'outil Quasar fournira une plate-forme par laquelle le contenu dynamique des missions pourra être instancié via Quantum.

Le travail sur le service ATC s'est poursuivi et la SST a consacré du temps au développement d'un décompresseur de Conteneur d'Objet autonome pour permettre l'injection de points de données spécifiques dans les assets sans avoir à réexporter manuellement chaque Conteneur d'Objet via l'éditeur. Ce travail permettra de débloquer plusieurs autres zones critiques pour la manipulation des données nécessaires aux futurs projets de la SST. 

 

Qu'est-ce qui n'a pas marché ?

Un nouveau service d'IA à haute vitesse était nécessaire pour cartographier les positions en direct des PNJs créés par les missions, ce qui s'est avéré être d'une complexité trompeuse. Ce nouveau service a nécessité le travail de plusieurs équipes et piliers, ce qui a entraîné des retards et des difficultés dans les tests. De nombreuses ressources de notre équipe continuent d'être absorbées par la résolution de bugs qui ne relèvent finalement pas de notre sphère de responsabilité. 

 

Ce que nous ferons différemment à l'avenir

Les futures présentations seront beaucoup plus simples en termes de contenu et nous avons investi dans des outils de visualisation pour pouvoir montrer rapidement et facilement des concepts de haut niveau sur la Starmap.  

Nous avons identifié les problèmes à l'origine des retards dans les nouveaux services, comme le service d'IA à haut débit, et nous sommes désormais mieux à même de gérer les initiatives inter-équipes de ce type à l'avenir. Les bases de Quantum étant posées, nous allons pouvoir nous concentrer sur l'intégration d'autres services. 

Nous sommes désormais mieux à même d'identifier les problèmes qui ne relèvent pas de la responsabilité de notre équipe et nous prévoyons de réacheminer ces problèmes vers les équipes appropriées, ce qui permettra aux membres de notre équipe de gagner le temps dont ils ont besoin pour développer les services. 

 

 

Lieux

Ian Leyland, directeur artistique de Star Citizen

 

Qu'est-ce qui s'est bien passé ?

La semaine de lancement d'Invictus au Tobin Convention Centre a été fantastique à voir, tout comme les nouveaux modules d'amarrage des stations spatiales et les docks militaires pour l'événement. En dehors de ce que nous avons publié dans l'Alpha 3.13, cela a permis à l'équipe de se concentrer sur la réalisation de progrès solides sur les futurs sites du jeu.

 

Qu'est-ce qui ne s'est pas bien passé ?

La fonction d'accostage a provoqué des allers-retours entre les différentes équipes concernées, ce qui a réduit l'efficacité. La fonction de poussée/traction des chariots a créé de nombreux bugs pour les équipes, qui auraient pu être réduits également.

 

Ce que nous ferons différemment à l'avenir

En interne, nous suivons un processus de validation des fonctionnalités et des emplacements. Dans le cas d'une fonctionnalité comme l'amarrage, les équipes ont été très pressées de construire la fonctionnalité et de créer les emplacements en même temps. À l'avenir, pour réduire l'inefficacité que cela crée, nous chercherons à avoir un tampon plus important entre la création d'une fonctionnalité et la création de l'emplacement qui l'utilise.

 

Trad : @Maarkreidi SwissStarships.org