Le 22 avril 2021, CIG a lancé l'Alpha 3.13: Underground Infamy
, qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, y compris l'amarrage de navire à navire, des entrées de grottes supplémentaires et le gestionnaire de réputation. Ce qui suit est un rapport post mortem 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é. En outre, ce compte-rendu porte à la fois sur le patch Alpha 3.13 et sur l'événement de l'Invictus Launch Week.
Pilier Véhicules
Dans le cadre de 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.
Amarrage Merlin/Constellation
Nous avons réussi à apporter une fonctionnalité très attendue à l'un des vaisseaux les plus emblématiques de Star Citizen. Même si nous avions prévu de le faire dans la version 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.
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 proposée aux Evocati pour les tests.
D'une manière générale, le processus de mise en place de la fonctionnalité s'est bien déroulé, donc à part le fait de la 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
La possibilité de personnaliser votre vaisseau est une fonctionnalité demandée depuis longtemps, et c'est quelque chose que nous voulions offrir depuis 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.
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é.
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
Depuis l'introduction de la dégradation des objets et des ratés dans Star Citizen Alpha 3.6, il manquait la dégradation visuelle de la coque de votre vaisseau en même temps que celle des autres objets. Maintenant que c'est fait, vous avez une meilleure idée de l'état de votre vaisseau grâce à l'affichage de la coque, sans avoir à chercher sur le 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 navires, ce qui a rendu la mise en œuvre beaucoup plus rapide.
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 recouverte 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 et les paramètres d'usure sur les anciens vaisseaux.
Comme nous l'avons mentionné, certains vaisseaux présentent une usure excessive 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 gameplay.
Accostage de Navire à Station
Bien qu'elle ne fasse pas officiellement partie de la version Alpha 3.13, nous avons en fait lancé cette fonctionnalité avec le patch, même si elle a été désactivée pour être mise en ligne avec la 3.13.1 (semaine de lancement d'Invictus). Nous avions initialement prévu d'intégrer les deux fonctionnalités dans le même patch, mais nous avons décidé de ne pas le faire, pour les mêmes raisons que celles qui nous ont poussés à ne pas proposer l'amarrage Connie/Merlin, afin d'améliorer la qualité de la version.
Tumbril Cyclone MT
Le Cyclone MT est un véhicule surprenant sur lequel nous avons travaillé pendant les périodes d'inactivité entre les versions. Il a permis d'élargir notre gamme de véhicules terrestres, en particulier pour Theaters of War.
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, car il avait é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 amélioration claire du ROC ; c'est un compagnon 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.
-- John Crewe, Vehicle Director
Pilier Live
EUPU : Sous-composants miniers
Nous avons continué à approfondir et à développer le gameplay de l'exploitation minière et nous avons réussi à mettre 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.
La stabilité du développement du jeu était faible, ce qui a entraîné des retards dans la mise à jour des builds avec les intégrations.
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 l'intégration des sprint des versions non à venir.
Contenu de la mission en direct :
Livraisons sensibles aux Quantum & livraisons multi-dépôts chronométrées
Tout s'est bien passé car nous avons utilisé des technologies existantes, dont une grande partie avait été créée pour la mission XenoThreat.
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.
Nous devons améliorer le transfert des comportements de l'entité et clarifier les responsabilités entre les équipes.
-- Todd Papy, Star Citizen Live Director
Pilier du gameplay de base
Armes montées
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 taille 1, car nous avions besoin de ce type de puissance de feu. Si ces armes sont petites sur un navire, 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, la ligne de visée était donc 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 du viseur 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 navire.
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 le 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.
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 présentait également 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.
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 du 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
Cette fonctionnalité 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 bien ancrées.
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 navire. 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 navires 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 navires 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à occupée pour le trimestre, nous n'avons pas pu offrir l'expérience complète du chariot.
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 de puzzle, la technologie 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 limites des roues et de la taille des rampes des navires. À 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.
-- Richard Tyrer, SQ42 FPS Game Director
Gameplay et services systémiques
Interface Utilisateur des réputations
Dans le cadre de l'Alpha 3.13, nous avons été en mesure de publier l'interface utilisateur des réputations, 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.
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.
Nous nous efforcerons d'améliorer notre communication globale sur les fonctionnalités à l'avenir, notamment pour celles qui impliquent des services ou le soutien d'une équipe de fonctionnalité externe. 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 Server Meshing 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
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 donnée connue.
D'un autre côté, l'équipe 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.
Star Citizen: Quantum, Quasar, and Virtual AI
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 solaire 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.
Certains changements apportés au système de train d'atterrissage des navires 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 légitime 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 avec la bande passante de l'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é.
De plus, lors de la mise au point des 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 qu'il faudra corriger plus tard.
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 sur le 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.
Caractéristiques de la mission
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 de 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.
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 accorder 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é un 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 des problèmes, car il n'y a pas vraiment de développeur défini pour les posséder et les entretenir.
Les vaisseaux parasites ont également causé des problèmes au niveau du système de lois qui n'ont été repérés qu'après la sortie initiale de la version Alpha 3.13.
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 de lois 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
Les ressources supplémentaires des équipes de backend ont permis de soulager immédiatement la charge de travail de l'équipe des services et outils systémiques (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 ressources 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.
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é.
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 prévoyons de les réacheminer vers les équipes appropriées, ce qui permettra aux membres de notre équipe de gagner le temps nécessaire au développement des services.
-- Tony Zurovec, PU Game Director
Sites
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 emplacements du jeu.
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 pousser/tirer des chariots a créé de nombreux bugs pour les équipes, qui auraient pu être réduits également.
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.
-- Ian Leyland, Star Citizen Art Director
