Alpha 3.12 Postmortem

[Maarkreidi]

Alpha 3.12 Postmortem

Le 17 décembre 2020, nous avons lancé Alpha 3.12 : Assaut sur Stanton, qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, y compris les ponts de raffinerie, les améliorations de l'IA et les nuages de gaz. Ce qui suit est une autopsie des développeurs principaux eux-mêmes, détaillant ce qui a été livré et leurs réflexions sur la façon dont cela s'est déroulé. En marge, cette autopsie se concentre spécifiquement sur le patch Alpha 3.12 - nous publierons séparément une autopsie Comm-Link portant sur l'événement dynamique XenoThreat.

ALPHA 3.12 POSTMORTEM

L'équipe des véhicules

Ce qui s'est bien passé
Le Pilier Véhicule a principalement soutenu le travail de nombreuses autres équipes pour le Star Citizen Alpha 3.12, en particulier avec le combat du vaisseau capital avant les événements Arlington Bounty, CS5 UEE Navy Idris, et XenoThreat. Nous n'avons pas seulement travaillé sur le fonctionnement et les performances des véhicules (étant les plus grands vaisseaux déployés sur les serveurs à ce jour), mais nous avons également aidé à faire face à la létalité accrue des torpilles grâce à une utilisation plus intelligente et plus efficace des contre-mesures d'IA.

Les joueurs ont également bénéficié de ce travail grâce à la possibilité de choisir le type de contre-mesure et le nombre de tirs en rafale, ce qui ajoute un plus grand choix tactique à l'acte de détournement des missiles et torpilles en approche. Nous avons également ajouté d'autres éléments HUD pour permettre aux joueurs de voir combien de chaque type il leur reste avec la taille actuelle de la salve.

La dernière modification apportée aux contre-mesures a été une extension des modifications apportées à l'Alpha 3.11. Cela permet à chaque type de contre-mesure de fonctionner contre tous les types de chercheurs de missiles, mais modifie leur efficacité en fonction du type et du nombre de missiles entrants. Les leurres ont remplacé les fusées éclairantes en tant que distraction ponctuelle limitée dans le temps, tandis que le bruit, autrefois appelé paillettes, est devenu un bloqueur de signal de zone d'effet (plus de contre-mesures lancées, plus de chances d'usurpation). Nous avons également modifié les missiles eux-mêmes afin d'obtenir des variations mineures dans leur trajectoire, de sorte qu'une contre-mesure réussie ne détourne pas tous les missiles de la même manière. En plus du contrôle manuel de la taille des rafales, nous avons ajouté une fonction de panique qui vide 25 % des contre-mesures disponibles afin de tenter de maîtriser une vague de missiles entrants.

Ce qui ne s'est pas bien passé
Nous avons découvert de nombreux problèmes dans la configuration et l'équilibre des missiles qui ont provoqué des comportements étranges. Cependant, nous avons décidé de laisser cela en attendant que les missiles soient convertis à l'IFCS 2.0 dans Alpha 3.13, car cela nécessite un réajustement complet de tous les comportements des missiles. À l'avenir, nous voulons étendre les contre-mesures en donnant aux joueurs un meilleur retour sur leurs propres signatures et capacités de missiles, qui commenceront à être mis en ligne avec le mode opérateur de missiles.

L'identification de l'entrée d'un véhicule est une fonction de qualité de vie très demandée (s'appuyant sur les notifications ASOP Hangar Spawn d'Alpha 3.11) qui permet aux joueurs d'identifier rapidement les points d'entrée dans un vaisseau. Ces marqueurs se mettent à jour selon que le vaisseau est à terre ou en mode zéro-g, supprimant ainsi une plainte courante des nouveaux joueurs, à savoir qu'ils ne savent pas comment entrer dans leur vaisseau. Parfois, ces affichages sont très décalés par rapport au véhicule, ce que nous examinons, mais c'était à peu près le seul point négatif de cette fonctionnalité et elle a été généralement bien accueillie.

La principale diffusion de contenu dans Alpha 3.12 était l'Esperia Talon et le Talon Shrike, qui sont une paire de chasseurs légers qui élargissent la gamme dans le jeu. En général, cela s'est plutôt bien passé et nous avons discuté de leur développement dans plusieurs épisodes d'ISC, y compris notre travail sur le Hard Surface Shader et les matériaux iridescents.

Malheureusement, quelques problèmes étaient présents à la sortie de la version et nous avons l'intention de les corriger dans les prochains patchs. Il s'agit notamment de l'écran nécessitant de basculer dans Arena Commander (également présent sur le Prowler) et des lance-missiles du Talon Shrike qui s'arrêtent parfois de fonctionner après un grand nombre de tirs.

John Crewe
Directeur Véhicules

 

L'équipe du PU US chargée du jeu
Le quatrième trimestre de l'USPU est toujours très chargé. Pas seulement pour nous, mais pour toute l'entreprise. Voici un bref résumé de nos initiatives les plus importantes que nous avons pu mettre entre vos mains au cours du trimestre. Heureusement, pour le meilleur ou pour le pire, nous n'avons pas eu de démo massive de CitizenCon à préparer pour cette année, mais cela ne nous a pas empêchés d'être extrêmement occupés.

Exposition internationale de l'aérospatiale (IAE) 

Ce qui s'est bien passé
Nous avons réussi à étendre le contenu de l'IAE au style artistique high-tech, qui a eu lieu à New Babbage sur la planète microTech. Nous avons ajouté plusieurs nouveautés à l'événement cette année, en essayant de répondre aux commentaires des fans. Tout d'abord, nous avons fait fonctionner le hall d'exposition de chaque fabricant pendant deux jours consécutifs au cas où les fans manqueraient le premier et nous avons prolongé la période de location gratuite d'un jour à deux jours. Heureusement, ces deux mesures ont permis à chacun de louer les vaisseaux qu'il avait envie d'essayer. Nous avions également deux salles d'exposition ouvertes tous les jours. Cela a évidemment permis aux joueurs de voir plus de choses et, dans l'esprit de "plus de choses à voir", nous avons décidé de présenter un grand nombre de nos composants de vaisseaux et de nos armes dans le hall principal. Entre les deux halls actifs chaque jour et tous les objets supplémentaires, c'était un véritable témoignage que notre technologie est de plus en plus optimisée, comme nous n'aurions jamais pu le faire dans le passé. Enfin, pour essayer d'étendre l'accessibilité, nous avons ajouté une série de kiosques de location dans la salle "Best In Show", qui a fonctionné pendant quatre jours. Dans ces kiosques, nous avons mis tous les véhicules qui ont été présentés pendant toute la durée du salon et avons donné la même période de location de deux jours. Entre tout cela, nous pensons que c'est l'itération la plus intéressante que nous ayons créée jusqu'à présent.

Ce qui ne s'est pas si bien passé
Nous avons eu deux véhicules qui ont été présentés au jeu lors du salon IAE et qui ont vraiment été au point en ce qui concerne leur développement. En fin de compte, cela ne nous a permis de verrouiller la construction que quelques jours avant le salon. Comme cette exposition est ouverte au public en novembre, elle a dû être publiée sous forme de patch pour la version Alpha 3.11. Le fait de ne pas pouvoir verrouiller le build avant de passer au build Alpha 3.12 a causé des problèmes de gestion de fichiers. Des correctifs critiques sont toujours en cours de réalisation pour la version finale et ces mêmes correctifs doivent également être intégrés dans le nouveau contenu du flux. Cela conduit inévitablement à ce que le travail soit piétiné ici et là et, à la fin de la journée, mange un temps précieux qui pourrait être utilisé pour corriger d'autres bogues ou faire de nouvelles choses. En outre, certaines choses que nous avions l'intention de garder secrètes jusqu'à un moment plus proche de l'événement ont fait l'objet de fuites. Ce n'était pas vraiment un problème majeur, mais c'est toujours agréable de pouvoir surprendre les fans de temps en temps.

Ce que nous allons faire différemment à l'avenir
Il y a quelques points sur lesquels je veux vraiment me concentrer au fur et à mesure que nous avançons dans cet événement :

• Modularité/réutilisation des ressources des événements précédents. Plus vite nous pourrons réaliser ces événements, plus nous aurons de temps pour nous concentrer sur de nouvelles idées de contenu ou d'autres systèmes solaires.
• Planification de la préproduction. Nous savons que l'événement aura lieu à nouveau en novembre prochain, c'est pourquoi j'aimerais régler le plus tôt possible des questions telles que la palette de couleurs, les logos de l'événement, le lieu, etc. De cette façon, lorsque viendra le moment de travailler sur le contenu, personne n'attendra que quelque chose soit décidé et nous pourrons simplement nous mettre au travail.
• Intégrez tout le contenu de l'événement dans le build afin d'éviter d'avoir besoin d'un point release. Comme mentionné ci-dessus, avoir deux flux/branches de diffusion fonctionnant en parallèle est tout simplement une source d'ennuis.

Système de réputation

Ce qui s'est bien passé
Un autre système important qui a été ajouté au quatrième trimestre est le système de réputation que nous avons toujours eu l'intention d'avoir. Bien qu'il ne soit pas encore visible pour les joueurs, ils peuvent en faire l'expérience grâce à nos donneurs de mission et à certaines de nos chaînes de mission (la chaîne des chasseurs de primes est la série la plus notable qui est actuellement débloquée par les gains de réputation). Toutes les missions n'ont pas encore été converties au nouveau système, bien que ce soit un processus continu qui se déroulera au cours du prochain trimestre ou des deux prochains mois. Ce nouveau système de réputation sera la base d'un nombre important de systèmes de jeu à mesure que nous avancerons. Non seulement ce sera la principale façon dont le contenu sera diffusé aux joueurs, mais il sera également lié à des éléments tels que les réponses des PNJ (que l'on voit actuellement dans les donneurs de mission), les avantages et bénéfices qui peuvent être obtenus en participant au contenu, le suivi de la progression des joueurs dans leur carrière, la dictée des relations entre les organisations au sein du jeu, et un certain nombre d'autres boucles de jeu essentielles. Nous avons estimé qu'il était si important pour le jeu que nous avons choisi de le sortir sans qu'aucun joueur ne soit confronté à une interface utilisateur (qui est en cours pour la sortie du premier et du deuxième trimestre). Mais parce que cela va être tellement ancré dans un nombre important de systèmes en cours de développement, nous avons estimé que cela valait la peine de faire ce sacrifice. Non seulement il sera représenté dans une IU de réputation autonome qui permettra aux joueurs de voir leur parcours professionnel avec diverses organisations, mais il permettra également de suivre les PNJs clés avec lesquels ils ont interagi ainsi que leur statut actuel avec chacun d'entre eux. Les réputations seront exposées dans cette IU au fur et à mesure qu'elles seront rencontrées dans l'univers afin d'encourager les joueurs à voyager et à s'engager dans le contenu pour les exposer. De plus, nous allons réorganiser le gestionnaire de missions pour inclure la visibilité des joueurs quant aux exigences de réputation dont ils ont besoin pour acquérir des missions. La réputation va être l'un des plus grands mécanismes de progression que Star Citizen aura en dehors de l'économie puisque nous sommes un jeu de bac à sable basé sur les compétences et non sur des systèmes de "leveling" ou d'"arbre de talents". La réputation est désormais également axée sur le service. Cela signifie que tous les gains de réputation peuvent être préservés entre les patchs, ce qui sera une bonne chose pour les joueurs.

Ce qui ne s'est pas bien passé
En ce qui concerne le développement général de cette fonctionnalité, il s'est déroulé sans problème une fois que nous avons pu nous y mettre. Nous avions commencé à travailler dessus environ un an auparavant, mais nous avons malheureusement été entraînés dans des tâches plus prioritaires à l'époque. Si j'avais dû le refaire, j'aurais maintenu l'équipe sur ce projet jusqu'à ce qu'il soit terminé et que les changements UI/UX souhaités y soient apportés. Le fait que l'interface utilisateur ne soit pas en place au moment de la sortie du jeu, même si cela ne brise pas le jeu, est un élément essentiel de cette fonctionnalité. L'assurance que toutes nos fonctionnalités sont intuitives repose souvent sur ce type de retour visuel.

Ce que nous allons faire différemment à l'avenir
Pour l'avenir, j'aimerais essayer de prévoir le temps nécessaire à la publication d'un article plus "complet". Bien qu'il ne soit pas toujours possible de convertir tout le contenu existant d'un jeu sur de nouveaux systèmes comme celui-ci, j'aimerais essayer de faire en sorte que nous puissions en faire plus lorsque de grands changements comme ceux-ci se produiront à l'avenir. J'étais heureux que nous ayons mis en place plus que l'intention initiale, mais j'aurais aimé avoir plus de temps avec l'équipe de mission pour aider à convertir encore plus que nous ne l'avons fait. La prochaine fois que quelque chose d'aussi fondamental que cela se produira, j'aimerais personnellement faire un meilleur travail de sensibilisation globale au sein de l'entreprise afin que nous puissions en convertir autant que possible.

Conversion du front-end en blocs de construction

Ce qui s'est bien passé
Nous avons pu convertir les deux premiers écrans de l'interface utilisateur pour utiliser notre technologie Building Blocks. En général, je pense que ce processus s'est assez bien déroulé. Il n'a pas nécessité une tonne de personnes et a constitué un travail assez autonome. Nous avons également eu l'occasion de régler quelques problèmes que nous voulions résoudre depuis l'ajout du service "nouveaux amis" au premier trimestre 2020. Le passage à notre nouveau système d'interface utilisateur nous a également permis d'effacer tous les éléments de l'interface utilisateur ensemble. Ce processus nous a donné le temps de réfléchir de manière critique à tous les aspects du projet, qui a beaucoup évolué ces dernières années. Nous l'avons également mis en place de manière à ce que la solution actuelle puisse s'étendre à mesure que nous ajoutons des systèmes solaires. Nous avons nettoyé l'écran principal afin de pouvoir mieux voir les images de fond. Je suis heureux que nous ayons pu attribuer une image différente pour chaque zone d'atterrissage possible ; je pense que cela aide vraiment à donner aux nouveaux joueurs une idée du type d'emplacement qu'ils choisissent.

Ce qui ne s'est pas si bien passé
Le front-end est très imprégné de l'ensemble d'outils CryEngine avec lequel nous avons commencé. Le système Building Blocks fonctionne sur la base d'entités, ce qui signifie que nos données de base doivent être chargées pour que nous ayons une entité sur laquelle faire tourner le canevas. En plus de cela, le système original nécessite un niveau pour être chargé. Pour cette raison, nous n'avons pas pu remplacer d'éléments avant de sélectionner le mode de jeu auquel les joueurs veulent jouer (du moins pas avec la technologie/implémentation basée sur les Building-Blocks). La solution ultime est de retravailler complètement cette base de code, mais cela dépassait largement le cadre de ce que nous avons pu traiter, et ce n'était pas non plus notre principale directive ici.

Ce que nous allons faire différemment à l'avenir
En fin de compte, le jeu sur lequel nous avons basé notre frontend original est très différent de celui vers lequel nous nous dirigeons aujourd'hui. Je ne sais pas à quel point l'équipe de l'USPU va changer le frontend à l'avenir, mais la prochaine fois que nous ferons des changements ici, j'aimerais vraiment travailler à la vision finale. Cela nous permettrait de vraiment rationaliser la nouvelle expérience utilisateur afin que l'entrée dans le jeu pour la première fois, ou le retour dans le jeu pour les joueurs qui reviennent, soit aussi simple et intuitive que possible. Comme nous avons ajouté de nouvelles fonctionnalités une à la fois, cette partie du jeu en a souffert. Si l'on peut redéfinir cette partie à partir de la base, il y a beaucoup de choses que nous ferions différemment en fonction de l'évolution du jeu.

Rob Reininger
Concepteur principal du système et responsable de projet de l'USPU

 

Équipe Services et outils systémiques

Ce qui s'est bien passé
L'équipe SST (Systemic Services and Tools) a continué à travailler sur la simulation Quantum et à l'intégrer dans les services, parallèlement à des présentations internes de nouvelles technologies que nous sommes heureux de partager bientôt avec la communauté.

Le travail administratif s'est déroulé au cours du dernier trimestre afin de réorienter les ressources internes de CIG vers les SST. L'équipe va s'agrandir pour répondre aux besoins croissants de services et de soutien pour Quantum dans de nombreux aspects du jeu.

En dehors des services et du travail de simulation, SST a créé de nouveaux outils pour soutenir le système de réputation à venir et la façon dont la réputation est distribuée dans l'univers du jeu. SST continue à soutenir l'économie Star Citizen avec des outils de données pour aider à réduire la quantité massive de données pendant que nous nous préparons à ce que Quantum prenne les rênes.

Ce qui ne s'est pas si bien passé
Lors de la transition vers un département plus important, nous avons eu quelques difficultés à répondre aux autres équipes. Des éléments comme le service de la raffinerie n'ont pas reçu l'attention immédiate dont ils avaient besoin alors que notre attention était ailleurs.

Ce que nous allons faire différemment à l'avenir
Nous cherchons des moyens de mieux rationaliser et distribuer le travail qui arrive à SST pour l'équipe en pleine croissance. De plus, nous avons mis en place une messagerie automatisée pour compléter la communication sortant de la SST vers les équipes dépendantes.

Jake Muehle
Concepteur technique principal

 

Équipe de conception

Interception de torpilles par l'IA

Ce qui s'est bien passé
Les tourelles de l'Idris qui interceptent les torpilles fonctionnent bien, et cela crée des moments très cool quand elles réussissent à intercepter.

Ce qui ne s'est pas si bien passé
La précision de l'IA n'est pas assez bonne pour abattre de manière fiable les torpilles entrantes en fonction de la vitesse de trame du serveur.

Ce que nous allons faire différemment à l'avenir
Nous allons chercher à améliorer la précision de l'IA afin de mieux contrôler le nombre de torpilles qui se glissent dans les défenses de la tourelle.

Utilisation du mode de tir de l'IA et priorités de ciblage

Ce qui s'est bien passé
L'IA utilisant le tir en rafale améliore grandement l'aspect du tir de tourelle de l'IA. De plus, les priorités de ciblage permettent de s'assurer que l'IA attaque une cible sensible pour sa classe de vaisseau/taille de tourelle.

Ce qui ne s'est pas bien passé
A la minute, l'utilisation du tir en rafale désavantage l'IA par rapport aux joueurs car le tir entièrement automatique augmente les dégâts.

Ce que nous allons faire différemment à l'avenir
Nous rééquilibrerons les rafales de l'IA lorsque des condensateurs seront introduits pour réduire l'efficacité du maintien du bouton de mise à feu.

Convergence de la précision de l'IA

Ce qui s'est bien passé
Le nouveau système de précision agit de manière plus crédible car il suit la position de la cible et continue à tirer sur cette position jusqu'à ce que la cible se déplace. Ce système est préférable à l'ancien système où l'objectif de l'IA basculait sauvagement lorsqu'elle tentait de manquer des cibles fixes devant elle.

Ce qui ne s'est pas si bien passé
L'IA n'est pas assez précise pour représenter un niveau de menace décent pour le joueur à la minute près. De plus, le nouveau système a tendance à manquer derrière le mouvement de la cible plutôt que devant, de sorte que les joueurs ne voient pas qu'on leur tire dessus autant.

Ce que nous allons faire différemment à l'avenir
Nous voulons améliorer la précision globale et faire en sorte que les différents PNJ aient une différence de précision plus perceptible entre l'IA qualifiée et non qualifiée. Le système de précision sera également répété pour que les tirs soient plus fréquents en dehors de la cible et non en dessous.

Comportement au combat des vaisseaux capitaux

Ce qui s'est bien passé
Les vaisseaux capitaux tiennent désormais beaucoup compte de la distance et de la position relative lorsqu'ils engagent d'autres navires. Les vaisseaux capitaux sans canons frontaux tentent de s'approcher suffisamment pour utiliser toutes leurs tourelles, tandis que ceux dotés de gros canons frontaux tentent de se tenir hors de portée de l'ennemi et d'utiliser leurs puissantes armes à longue portée.

Ce qui ne s'est pas si bien passé
Le choix de la tactique ne tient pas suffisamment compte de la force du vaisseau d'IA par rapport à la cible. Par exemple, lorsque l'Idris combat un vaisseau de combat ou un vaisseau capital, il tentera de rester à distance et d'utiliser son canon sur rail. Cela a souvent du sens, mais peut l'amener à fuir des navires de combat plus petits qu'il pourrait facilement vaincre dans un combat à distance rapprochée.

Ce que nous allons faire différemment à l'avenir
Nous allons répéter la sélection de la tactique pour que l'IA considère son propre vaisseau et sa propre cible de manière plus détaillée que la seule classe du vaisseau. Nous voudrons également permettre aux traits de caractère du pilote d'affecter le comportement du vaisseau capital.

Panneaux d'ascenseur

Ce qui s'est bien passé
Nous avons réussi à poser les bases des futurs panneaux d'ascenseur (et autres écrans relookables), en leur faisant hériter leur style du système de transport en commun et en les rendant utilisables sur n'importe quels canevas de forme. Cela signifie que tous les futurs panneaux peuvent utiliser les deux mêmes fichiers, tout en ayant un aspect différent.

Ce qui ne s'est pas bien passé
Le système de transit est très difficile à mettre en place et à tester dans sa forme actuelle - l'équipe de l'interface utilisateur n'a pas pu le faire fonctionner correctement et a dû s'en remettre à la conception de niveau pour le mettre en œuvre. Cependant, l'interface utilisateur et la conception de niveau n'ont pas fonctionné en même temps, ce qui a entraîné le démarrage et l'arrêt du travail dans différents flux et l'oubli de certains bogues. La mise en œuvre des nouveaux styles de blocs de construction est extrêmement longue en raison du manque d'outils et de l'impossibilité de fusionner des fichiers.

Ce que nous allons faire différemment à l'avenir
Nous nous assurerons que la fonctionnalité est développée, mise en œuvre et testée en une seule fois dans un flux de fonctionnalités afin que les bogues soient détectés et corrigés avant qu'elle ne soit "terminée". Nous nous assurerons également que l'équipe qui possède la fonctionnalité a le temps de corriger les problèmes de code dans le cadre du cycle de développement de la fonctionnalité et que l'équipe chargée de l'interface utilisateur se concentre sur l'interface utilisateur.

Raffinage à la station

Ce qui s'est bien passé
Nous avons terminé la boucle de jeu initiale pour le raffinage, avec des raffineries ayant leurs propres spécialisations en matière de matériaux, des charges de travail et la possibilité de raffiner, de collecter et de vendre des matériaux raffinés à différents endroits de la galaxie. Les ponts des raffineries elles-mêmes sont spectaculaires et l'interface utilisateur du terminal de la raffinerie est idéale pour développer la boucle de jeu, avec très peu de retouches à faire, ce qui devrait permettre d'accélérer les itérations en cours de route.

Ce qui ne s'est pas si bien passé
Notre planification de chaque étape a été extrêmement minutieuse, cependant, en raison de plusieurs situations indépendantes de notre volonté, nous n'avons pas pu atteindre un point suffisamment tôt pour équilibrer la boucle de la raffinerie comme nous l'avions prévu. Nous avons donc proposé une autre série de changements déjà prévus sous la forme d'un rééquilibrage minier initial pour compenser au mieux jusqu'à ce que nous puissions ramener le bilan de la raffinerie au niveau que nous souhaitions initialement. Ce rééquilibrage minier a eu pour avantage supplémentaire de rendre le MISC Prospector un peu plus attrayant pour les personnes qui commencent ou qui louent, et de fournir plus d'expériences de jeu pour l'Argo MOLE ou les multiples joueurs avec Prospectors.

Ce que nous allons faire différemment à l'avenir
Faire tester la version artistique de IU plus tôt. Certains joueurs ne savaient pas avec quelles parties de l'écran ils pouvaient interagir et cela nous aurait donné plus de temps pour faire des changements.

Refonte de l'interface utilisateur dans le secteur minier

Ce qui s'est bien passé
Nous avons retravaillé l'ensemble de l'interface utilisateur de l'industrie minière pour travailler avec les Building Blocks. Cela s'est passé beaucoup plus facilement que ce que nous aurions pu espérer, car une grande partie de la configuration de la boucle de jeu de l'exploitation minière a fonctionné avec les Building Blocks dès le départ, sans aucune retouche. Cela nous a donné une marge de manœuvre pour ajouter plus à l'interface utilisateur de l'exploitation minière que ce que nous avions prévu à l'origine, ce qui signifie que nous avons pu non seulement fournir une interface utilisateur entièrement nouvelle et évolutive sur trois véhicules miniers différents, mais nous avons également démontré cette évolutivité en itérant rapidement sur des morceaux de grille de l'interface utilisateur pour prendre en charge des systèmes précédemment introduits. Nous avons ainsi inclus les cargaisons volatiles et ajouté une toute nouvelle pièce de cale qui fournit aux joueurs des informations que nous avons toujours voulues mais n'avons jamais eu la capacité de le faire.

Ce qui ne s'est pas bien passé
Le premier passage du remodelage de l'interface utilisateur du secteur minier a été plus délicat à mettre en œuvre qu'à construire, les différents véhicules ayant des espaces différents à leur disposition pour l'interface utilisateur, ce qui signifie que de nombreux ajustements en coulisses ont été nécessaires pour afficher l'interface utilisateur de manière confortable. Ce système est encore en cours de mise au point et, avec l'arrivée prochaine de nouvelles technologies, nous espérons pouvoir diffuser l'interface utilisateur d'une manière légèrement plus attrayante et plus efficace que la version actuelle.

Ce que nous ferons différemment à l'avenir
Nous allons répéter plus rapidement à l'avenir sur ce genre de choses, car nous avons maintenant une meilleure compréhension des éléments constitutifs et de leurs avantages.

Todd Papy
Directeur Star Citizen Live

 

Pilier de base du gameplay

Faisceau tracteur multi-outils

Le rayon tracteur multi-outils est un ajout passionnant au "verse" et constitue une fonctionnalité de base qui débloque plusieurs boucles de jeu sur lesquelles nous travaillons, comme le transport de marchandises et les espaces de traversée EVA. Le principal cas d'utilisation du rayon tracteur dans Alpha 3.12 est de faciliter la collecte des boîtes de fret lors des EVA, soit pendant les missions spatiales perdues, soit pour la collecte du butin après le combat avec les vaisseaux. En surface, le rayon tracteur est un outil de pointage, mais sous le capot, il se passe beaucoup de choses, et je pense que l'équipe a fait un travail fantastique en créant une fonction vraiment systémique, accessible et facile à utiliser.

Le premier défi que nous avons dû relever est que nous voulions qu'il fonctionne dans plusieurs conditions de gravité différentes et qu'il utilise le poids d'un objet. Cela a entraîné plusieurs problèmes, car dans le cas du zéro-g, tout est en apesanteur, ce qui signifie que vous pouvez potentiellement déplacer quelque chose d'énorme qui pèse très peu. Par exemple, une boule de polystyrène de la taille d'une planète. Nous avons conçu le faisceau tracteur autour de deux concepts fondamentaux : le volume et la force. Le volume dicte la taille générale de l'objet que vous pouvez soulever, tandis que la force dicte l'effort que l'arme doit appliquer pour soulever l'objet. Cela signifie que pour tout objet ayant un collisionneur de masse et de physique (ce que tout objet devrait déjà avoir), la force nécessaire pour le soulever est automatiquement calculée en utilisant la gravité de l'environnement. Cela nous a permis de construire une fonction qui fonctionne avec n'importe quel objet physique du jeu sans avoir à faire beaucoup de réglages manuels.

Le deuxième défi était d'expliquer au joueur ce qu'il peut et ne peut pas soulever sans avoir à faire un ADS sur tout ou, pire encore, à faire des essais et des erreurs. Heureusement, le Multi-Tool dispose déjà d'un petit écran à l'arrière qui nous a permis de mettre en place une iconographie simple en plus d'un système de codage couleur des feux de circulation. Cela signifie que nous sommes en mesure de montrer clairement les cinq états d'un objet en le regardant simplement :

1. L'objet peut être soulevé
2. L'objet peut être soulevé mais est hors de portée
3. L'objet est trop lourd
4. L'objet ne peut jamais être levé
5. Vous vous rendrez à l'objet

Nous avons certes fourni des informations supplémentaires dans la vue ADS, mais tout ce que vous devez savoir se trouve au dos de l'outil et j'ai été très heureux que nous ayons pu distiller autant d'informations sur un si petit écran.

Ce qui ne s'est pas si bien passé
Lorsque vous planifiez une fonctionnalité, vous voulez identifier l'expérience principale et ensuite décrire les mécanismes secondaires qui amélioreraient cette expérience. Par exemple, un mécanisme de saut est une fonction autonome, mais vous pouvez décider que le contrôle aérien (un mécanisme secondaire) améliore cette expérience de base. Avec le Tractor Beam, nous nous sommes assis et avons identifié l'expérience de base qui consiste à pouvoir manipuler des objets et l'utiliser comme un grappin en EVA, et je pense que nous avons réussi. Mais il y avait des mécanismes secondaires que j'aurais aimé expédier et que nous n'avons pas eu le temps de livrer. Plus précisément, permettre la manipulation de votre trajectoire à l'aide des propulseurs de votre combinaison lorsque vous utilisez la fonctionnalité du grappin en G zéro.

Malheureusement, les deux systèmes n'ont pas vraiment bien fonctionné ensemble, la force utilisée pour vous traîner ayant priorité sur toute force utilisée par les propulseurs de la combinaison. De plus, le fait que l'EVA soit également passée à l'utilisation de l'IFCS au même moment n'a pas aidé et cela nous a conduit à devoir faire un appel prioritaire pour nous concentrer sur l'expérience de base et nous assurer que celle-ci était aussi polie que possible pour la sortie. Cela arrive tout le temps avec les fonctionnalités et c'est la nature même du développement de jeux, mais c'est dommage qu'il ait manqué la première itération. Nous ajouterons cette fonctionnalité dans une version ultérieure.

Ce que nous ferons différemment à l'avenir
La mise à disposition d'une fonctionnalité nécessite la coordination de nombreuses équipes différentes, de la VFX à l'audio en passant par l'équipe chargée de la fonctionnalité. L'une des principales choses que j'essaie d'améliorer est de donner aux concepteurs de missions plus de temps pour leur permettre d'intégrer toutes ces différentes fonctionnalités dans le "verse" de manière significative. Si vous avez lu mes précédents comptes rendus, vous constaterez probablement que j'essaie activement d'améliorer ce point, mais comme plusieurs équipes et calendriers sont impliqués, il faut un peu de temps pour s'adapter. Si je pouvais remonter dans le temps, j'aurais probablement essayé de mettre une version simple entre les mains des concepteurs de mission/niveau plus tôt pour qu'ils puissent jouer avec un peu plus.

Zérotage des armes

Ce qui s'est bien passé
Le réglage des armes, comme le titre le suggère, permet de régler les armes à zéro à différentes distances, ce qui permet de tirer avec précision à des distances beaucoup plus éloignées. Cela signifie que la lunette de visée tient compte de la chute de la balle à une distance spécifique et vous permet d'ajuster la visée de manière à pouvoir toujours pointer votre réticule sur la cible. Autrement dit, vous n'avez pas besoin de viser au-dessus de la cible. Nous disposons déjà de nombreuses lunettes de visée et le premier défi consistait à décider quelles lunettes de visée devaient être mises à zéro, puis à décider si elles devaient être mises à zéro automatiquement ou manuellement. Cela a donné lieu à un débat beaucoup plus large sur les fabricants et leurs caractéristiques spécifiques, comme la haute technologie ou la basse technologie. Alors que l'équipe aurait pu se concentrer sur la caractéristique et la faire ressortir, elle a également élaboré un plan à long terme pour les accessoires des oscilloscopes, non seulement pour les fabricants actuels mais aussi pour les futurs.

C'est une chose à laquelle je crois fondamentalement - que même si nous travaillons sur un produit vivant, nous devrions prendre des décisions en fonction de l'expérience finale du jeu sorti. C'est parfois difficile car cela peut signifier que certaines fonctionnalités ne sont pas vues sous leur meilleur jour lors de la première inspection ou mal comprises à court terme par les joueurs. Mais c'est mon travail de m'assurer que nous travaillons à la vision finale et l'équipe a fait un travail fantastique en fournissant une fonctionnalité qui est amusante à utiliser mais évolutive dans le futur.

Ce qui ne s'est pas bien passé
C'est le premier élément sur lequel un des nouveaux membres de notre équipe a travaillé. Nous avons donc veillé à ce qu'il ait tout le temps nécessaire pour le livrer bien avant la sortie de la version finale. En fait, la fonctionnalité (pas les visuels) a été livrée le trimestre précédent et il a fait un excellent travail. Maintenant, dans la plupart des cas, c'est fantastique car cela signifie que nous pouvons nous concentrer sur l'expérience et nous assurer qu'elle est de la plus haute qualité. Dans le cas présent, cependant, en raison d'autres priorités et du fait que cela a été fait bien avant la sortie, l'équipe de test n'a pas pu se concentrer pleinement sur le projet, car elle était (à juste titre) occupée à vérifier les choses qui allaient être mises en ligne. Malheureusement, cela signifie qu'un cas fondamental a été manqué jusqu'à juste avant la publication, à savoir que la mise à zéro n'a pas fonctionné lorsque les correctifs de physique pour l'environnement ont été publiés.

Permettez-moi de vous expliquer. Lorsqu'un personnage spawn sur une planète, une série d'éléments (carrés) se développent autour d'eux, dont la taille ne cesse d'augmenter. Ces blocs couvrent la qualité du rendu (graphique) et la collision physique, les blocs plus éloignés étant moins détaillés et finalement sans collision (la physique étant relativement coûteuse). Aujourd'hui, lorsque vous vous déplacez, les blocs se mettent à jour dynamiquement, mais ce n'est pas un à un. Ainsi, un bloc que vous venez de quitter peut toujours avoir sa collision, car vous pouvez vouloir y retourner et il est plus performant de le conserver à court terme que de continuellement le charger et le décharger. Dans ce cas, cela signifie que lorsqu'un concepteur chargeait dans l'éditeur pour tester la fonction, le bloc était chargé et ensuite ils se déplaçaient à 2 km de là pour tester la mise à zéro des armes et cela fonctionnait. Cependant, si un joueur n'était jamais allé à la position initiale, il n'y aurait pas de collision et le scope n'aurait donc rien à tester. Cela signifie que dans des conditions de jeu normales, cela n'a pas fonctionné comme prévu. Nous avons donc dû ré-autoriser le code de mise à zéro des armes pour le tester sur la géométrie de rendu plutôt que sur la physique. Bien que cette modification ne soit pas majeure, elle n'était pas idéale car nous avions prévu de travailler sur d'autres fonctionnalités.

Ce que nous allons faire différemment à l'avenir
Si je pouvais remonter dans le temps, je m'assurerais certainement que la fonction a été testée de manière approfondie lorsqu'elle a été achevée, plutôt que d'attendre le traditionnel "go/no go". Bien que cela n'ait pas affecté la sortie de la fonction, cela a eu des répercussions sur les travaux futurs, car nous avons dû revoir nos priorités au cours du trimestre.

Fusil de sniper Gemini A03 & Behring FS-9 LMG

Ce qui s'est bien passé
Comme pour chaque arme que nous ajoutons au jeu, nous devons toujours nous assurer qu'elle s'inscrit dans la matrice des armes existantes et qu'elle offre quelque chose d'unique qui n'existe pas encore. Avec le fusil de sniper Gemini A03, l'intention était de fabriquer un fusil de tireur d'élite léger et réactif, d'un calibre inférieur à celui de ses homologues plus lourds, mais d'une vitesse et d'une précision élevées. Je pense que l'équipe a vraiment atteint cet objectif et a trouvé un bon équilibre entre les fusils de sniper de haut calibre comme le P6-LR et les armes plus orientées vers l'assaut comme le Gemini S71. Alors que le A03 était un simple ajout, le Behring FS-9 était un peu plus compliqué. Les LMG en tant que catégorie d'armes ne sont pas en très bonne place en ce moment car ils sont dépassés par les SMG/les fusils de chasse à courte distance et dépassés par les fusils d'assaut à moyenne et longue portée. C'est une chose dont nous sommes parfaitement conscients et nous avons travaillé en coulisses pour améliorer la situation. Le Behring FS-9 établit la norme pour ce que nous voulons que les LMG soient : des mitrailleuses de grande capacité qui permettent aux joueurs d'arroser une zone sans perte énorme de précision.

Ce qui ne s'est pas bien passé
Pendant que nous travaillions sur le FS-9, nous travaillions également sur les intentions de conception de tous les autres LMG afin de pouvoir fournir une mise à jour générale en une seule version. Malheureusement, nous avons manqué de temps sur les armes existantes, bien que nous ayons réussi à faire quelques ajustements pour augmenter leur efficacité. Nous avons l'intention de mettre à jour les LMG existantes pour les porter au même niveau de qualité que le FS-9, mais cela signifie à court terme qu'elles sont largement supérieures aux autres armes de la même catégorie. Mais comme je l'ai mentionné plus haut, je vais toujours hiérarchiser les décisions en fonction de l'objectif final que nous voulons atteindre, afin que nous avancions constamment.

Ce que nous ferons différemment à l'avenir
Nous avons un plan de révision de toutes les catégories d'armes et nous espérons que vous pourrez constater que chaque arme que nous sortons est légèrement améliorée par rapport à celles qui l'ont précédée. Avec cette intention, j'aurais ajouté plus de temps pour peaufiner les LMG existantes car j'aurais aimé les sortir toutes ensemble. Quelle que soit votre expérience, vous apprenez toujours et c'est quelque chose que je mettrai en œuvre pour les armes futures.

Richard Tyrer
Core Gameplay Director

 

Emplacements/Lieux

Ponts de la raffinerie de la station spatiale

Ce qui s'est bien passé
Pour ce communiqué, nous avons pu présenter les ponts des raffineries à certains endroits spécifiques de la station spatiale. Ces espaces ont pour thème les boucles de jeu de l'exploitation minière et du raffinage et servent également d'emplacement pour de futures possibilités de jeu. À l'intérieur du pont de la raffinerie, nous avons créé un espace spécifique pour le raffinage et le traitement, ainsi qu'un espace de boutique et de guilde en dessous.

Après avoir vu la réaction aux ponts de cargaison et aux nouveaux intérieurs de la station spatiale dans Alpha 3.11, nous avons approuvé les commentaires sur le fait que les joueurs voulaient voir un lien plus visible avec l'extérieur pour comprendre physiquement où ils se trouvent dans la station. Même si nous étions assez avancés dans le développement de l'intérieur du pont de la raffinerie, nous avons pivoté et adapté l'espace pour inclure le mini pont d'observation près des halls d'ascenseur. Visuellement, nous voulions depuis un certain temps explorer une expérience de la station spatiale plus axée sur l'activité industrielle, y compris la composition globale de la station jusqu'à l'intérieur chaud et bruyant.

Ce qui ne s'est pas si bien passé
C'était une honte de ne pas voir des chargements spécifiques de NPC se libérer avec les ponts des raffineries ou de ne pas pouvoir étendre certaines des utilisations spécifiques. Cependant, tout cela est prévu et nous espérons les voir bientôt en ligne.

Ce que nous allons faire différemment à l'avenir
Comme nous l'avons mentionné plus haut, nous avons introduit le pont d'observation assez tard dans le processus, de sorte que nous aurions pu concevoir un espace supérieur en gardant cela à l'esprit lors de la conception et du whiteboxing.

Améliorations planétaires de Stanton et polissage

Ce qui s'est bien passé
Continuant à s'appuyer sur les améliorations planétaires apportées tout au long de l'année 2020, c'était la première occasion pour l'équipe d'introduire les nouveaux flux de travail améliorés développés lors de la création des planètes et des lunes de Pyro à Stanton.

L'amélioration du flux de travail comprenait le fait d'avoir le temps et la concentration nécessaires pour approfondir le processus de peinture global. Pour des planètes comme Stanton I et IV, la peinture globale a été entièrement refaite pour être plus précise en ce qui concerne les paramètres de température et pour obtenir un meilleur mélange et une meilleure distribution des teintes. Dans la deuxième partie de la peinture, tous les objets présents et les règles de distribution ont été créés à partir de zéro. En général, l'objectif était de faire plus avec moins. Ainsi, plutôt que d'utiliser plusieurs types de géologie dans le même espace, il suffit d'en utiliser un ou deux qui fonctionnent très bien ensemble. Le résultat final est quelque chose de beaucoup plus réaliste et naturel. Un bon exemple de cela est celui de Daymar. Un autre domaine que nous voulions améliorer était l'utilisation accrue d'objets de dispersion au sol pour compliquer la lecture du terrain. Nous avons combiné un mélange de ressources géologiques comme les plaques, les éboulis et les petites roches avec la distribution des packs géologiques pour donner une lecture beaucoup plus intégrée de la scène.

De plus, certains ensembles géologiques exceptionnels ont été convertis pour utiliser le shader organique et ont été traités correctement par Houdini dans le cadre de notre pipeline.

De nouvelles fonctionnalités techniques ont été mises en ligne au cours de cette version et nous avons été ravis d'en profiter, la première étant le déplacement de terrain qui remplace POM. Ainsi, vous pouvez maintenant voir la géométrie du terrain se tesseler et se déplacer en donnant la profondeur réelle et des intersections plus complexes avec les objets. La deuxième caractéristique est l'accumulation de biomes, ce qui signifie que les objets peuvent recevoir, selon la procédure, une fine couche de matériau sur leur surface supérieure en fonction du biome. Par exemple, le sable s'accumule sur le sommet des rochers à Daymar.

Ce qui ne s'est pas si bien passé
Alors que nous essayions de terminer l'année et d'atteindre la sortie d'Alpha 3.12, certaines lunes n'ont pas pu être amenées au niveau de polissage que nous voulions. En outre, dans le cadre de l'introduction de nos nouveaux flux de travail et de notre nouvelle méthodologie dans le système Stanton, nous avons remarqué que les styles visuels entre certaines lunes deviennent trop proches les uns des autres et que nous perdons une certaine diversité.

Ce que nous allons faire différemment à l'avenir
Un plus grand nombre d'assets permettra de réduire la fatigue artistique et d'améliorer la diversité visuelle. C'est pourquoi, en ce début d'année, nous investissons du temps et de l'énergie dans un plus grand nombre d'assets.

L'aménagement de l'espace du système Stanton

Ce qui s'est bien passé
Nous étions tous très excités de pouvoir présenter la technologie du nuage de gaz dans le cadre de l'unité de production d'Alpha 3.12. De nombreuses équipes ont travaillé dur pour créer cette nouvelle fonctionnalité. Le processus consistait donc à mettre en place une équipe dédiée à la création de contenu pour Stanton, puis à commencer à examiner ce que nous pourrions faire pour les points de Lagrange.

Étant donné qu'il s'agissait de la première version de la technologie, je pense que nous avons créé une variété de scénarios visuels pour montrer le potentiel de la technologie.

Ce qui ne s'est pas bien passé
Comme il s'agissait de la première version, il y avait évidemment beaucoup à faire en termes de performances, et nous pouvons faire beaucoup en termes de perfectionnement du pipeline. Il y a également du bruit visible dans certains scénarios d'éclairage que nous aimerions réduire à l'avenir si les performances le permettent.

Ce que nous ferons différemment à l'avenir
Nous sommes déjà en train d'améliorer notre processus de développement et d'étudier les moyens de l'améliorer. Nous étudions comment nous pouvons relier le paysage spatial d'arrière-plan en des formes plus miniaturisées, qui débouchent ensuite sur des poches de gaz plus petites et volumétriques. Pour les futures possibilités de jeu, nous cherchons à encourager le jeu risque/récompense à l'intérieur des poches de gaz avec des éléments tels que la foudre, les radiations, les plages de température et le pilotage.

Ian Leyland
Star Citizen Art Director

 

Technologie

Pour Alpha 3.12, l'équipe graphique s'est principalement concentrée sur l'amélioration de la stabilité et la correction des bugs des différentes fonctionnalités graphiques utilisées dans la version. De nombreuses corrections de bogues étaient liées à l'introduction de nuages de gaz, comme la correction d'un modèle de tremblement visible lorsque le soleil est obscurci par un nuage et l'amélioration des systèmes d'abattage volumétrique et d'abattage de particules pour empêcher les nuages de gaz et les particules de se détacher à l'intérieur des vaisseaux spatiaux. De tels problèmes étaient attendus mais largement inévitables car, bien que la technologie ait été largement utilisée dans le développement de SQ42, les illustrations et les scénarios sont très différents dans le PU. En outre, la nature de bac à sable de l'unité de production et les tests approfondis qu'elle reçoit ont permis de découvrir ou de soulever en priorité de nombreux problèmes inconnus jusqu'alors.

L'équipe a également réussi à résoudre des douzaines d'autres bugs, allant des ombres portées à l'exposition excessive de la caméra lorsqu'une planète est survolée. La proportion de temps consacrée à la correction des bugs par rapport aux nouvelles fonctionnalités a été plus élevée que ce que nous aurions idéalement souhaité, mais l'accent est toujours mis sur la stabilité et la qualité à la fin de l'année et le travail sur les fonctionnalités a déjà repris, ce qui n'est donc pas préoccupant. Malgré le ralentissement du travail sur les fonctionnalités, nous avons réussi à maintenir de bons progrès sur le nouveau moteur de rendu Gen12, qui sera notre principal objectif pour le début de 2021.

L'équipe de physique a travaillé sur le prototype de corps mou volumétrique ainsi que sur le rendu de la déformation volumétrique qui s'y rapporte. De plus, diverses optimisations ont été réalisées en physique. Par exemple, nous avons amélioré l'enchaînement de divers sous-systèmes, ajouté des requêtes de grille spatiale plus rapides, supprimé la contestation de l'accès à la file d'attente de commande locale, et supprimé la contestation des fonctions d'étape des acteurs/entités vivantes (en améliorant les performances d'étape des entités vivantes par un facteur de 2x - 5x). Nous avons également mis en place une meilleure méthode de préphysicalisation des parcelles de terrain de la planète utilisées pour les contrôles de collision. En ce qui concerne la détection des collisions, nous avons également résolu un problème de longue date qui pouvait introduire des contacts fantômes supplémentaires loin de l'endroit où les contacts réels étaient traités. En outre, des améliorations ont été apportées à la mise en file d'attente des événements. Le premier projet de propagation des ondes de choc matérialisées a été soumis et des grilles de physique en forme de boîte ainsi que des traînées de balles ont été ajoutées. Le soutien du SDF a été amélioré et des recherches ont commencé sur les améliorations à apporter à la mise en place de la flexion de la végétation au toucher.

En ce qui concerne le moteur de rendu, nous avons poursuivi la transition vers Gen12 et le remaniement correspondant. Par exemple, nous avons ajouté un ensemble de fonctionnalités paramétrables pour le pipeline différé, mis en place des mises à jour de l'ensemble des ressources par objet (y compris la mise à jour RTT pour les brosses) pour le rendu de scènes Gen12 et la mise en cache de l'état du pipeline existant (pour sauvegarder les appels de l'API DX pendant que nous sommes encore en pleine transition vers Gen12). Dans le système de shaders, nous avons nettoyé tout le code de rechargement des shaders, ce qui améliorera l'édition des shaders pendant le développement et donnera une réponse bien meilleure lors de la modification des paramètres des spécifications du système (par exemple, les paramètres graphiques qui nécessitent l'utilisation de différentes combinaisons de shaders). Nous avons également commencé un plus grand remaniement du système de cache des shaders, car il est assez dépassé et constitue une source constante de problèmes en ce qui concerne la maintenance et l'aptitude du Gen12. Plusieurs optimisations ont été faites dans le code de rendu. Par exemple, la façon dont les constantes matérielles sont téléchargées vers le GPU a été simplifiée et optimisée.

Du côté graphique, diverses corrections de profondeur de champ ont été apportées. Le shader de cheveux a bénéficié de plusieurs améliorations, comme la possibilité de désactiver les reflets spéculaires sur les cils, l'amélioration de l'occlusion des limites à la naissance des cheveux, la prise en charge des lumières ambiantes dans l'ombrage avant, ainsi que l'amélioration de la qualité des cheveux pendant les coupes de la caméra. L'approximation du double lobe pour le skin shader a été améliorée et le eye shader a également bénéficié de quelques améliorations. En ce qui concerne les atmosphères, les nuages et le raymarcher unifié, les améliorations mentionnées dans la précédente autopsie sont maintenant disponibles dans Alpha 3.12. Cela étant fait, la plupart du temps, on s'est concentré sur le rendu volumétrique des nuages. Le projet initial du moteur de rendu des nuages a été mis en œuvre et le travail sur les ombres volumétriques des nuages a bien progressé. Les travaux sur les ombres volumétriques des nuages ont bien progressé. Les améliorations de la mise en forme locale des nuages vont commencer. Notez qu'il reste encore beaucoup de travail à faire avant la sortie de la version.

Pour le système du noyau du moteur, nous avons mis en place un parcours d'abattage dynamique dans le système de zones. Nous avons également corrigé quelques bogues d'élimination liés à la distance de visualisation pour les objets de la taille d'un pixel qui sont entrés dans Alpha 3.11. Les gens ont déjà remarqué qu'ils peuvent maintenant voir les joueurs à plus de 1000 mètres au lieu de quelques centaines. De nombreuses corrections de bogues et améliorations ont été apportées aux zones visuelles, telles que la correction des maillages en streaming pour les zones visuelles animées et la possibilité d'ajouter des zones visuelles aux articulations CGA. Le système d'entités a reçu plusieurs améliorations et optimisations pour éviter les mises à jour et les recherches inutiles. De même, le gestionnaire des agrégats de l'entité a reçu des optimisations de bas niveau pour améliorer l'équilibrage du travail et réduire l'utilisation de la mémoire et les conflits lors du travail avec les bulles de l'entité. Quelques améliorations de moindre importance ont également été apportées au planificateur de mises à jour des composants de l'entité. La logique d'élimination des arbres Radix a été améliorée, sa logique de threading a été ajustée pour réduire les conflits et l'élimination des SIMD a été mise en œuvre pour vérifier jusqu'à quatre bulles par rapport aux objets par nœud. En ce qui concerne les performances, les progrès se poursuivent sur le profileur de moteur, qui a fait l'objet de nombreuses améliorations. Les travaux sur un profileur à échantillonnage en temps réel basé sur des traces d'événements commenceront bientôt. Diverses optimisations ont été mises en œuvre dans le système d'entités, les mises à jour de composants et le système de zones. Sur la base de la télémétrie du PU et du PTU, nous avons poursuivi nos investigations en cours sur l'utilisation de la mémoire. Ainsi, l'allocateur de mémoire et le système de suivi de la mémoire à l'échelle du moteur, y compris sa chaîne d'outils, ont été considérablement remaniés et améliorés. Afin d'améliorer encore les performances de nos serveurs, le DGS Linux a été remplacé par un exécutable monolithique pour permettre au compilateur de générer un meilleur code (en particulier l'accès au stockage local des threads). Dans le cadre de notre initiative visant à mettre en place un système de régression des performances, nous avons également ajouté un test de stress pour le streaming de conteneurs d'objets.

En ce qui concerne la gestion des crashs, nous capturons maintenant une pile hex du thread de rendu et l'intégrons dans des mini-dumps que vous nous envoyez (en option) au cas où le jeu se planterait. Cela nous permet de récupérer la totalité de la pile d'appel du fil de rendu pendant le débogage post-mortem sans avoir besoin de binaires tiers (qui pourraient faire partie de la pile d'appel ou du pilote vidéo) pour dérouler complètement la pile. Cela permet de gagner beaucoup de temps car nous n'avons pas besoin de télécharger les différents pilotes utilisés par les joueurs.

Pour ce qui est de l'animation, nous avons fixé le code de manière à ce que les formes des personnages se mélangent et que le système d'éclairage dynamique ne bascule pas trop tard à chaque coupure de caméra lors du rendu des scènes de coupe.

Enfin, la prise en charge du C++ 14 a été activée pour l'ensemble des projets de l'éditeur client-serveur et des outils pertinents.

Technologie en ligne

Cadre d'essai pour l'équilibrage des charges
Le réducteur de parasites pour Alpha 3.12 a fait l'objet de mises à jour importantes. Tout d'abord, le dispositif utilise désormais le nouveau système d'identification JWT qui lui permet de récupérer très rapidement de nombreux jetons à des fins de personnification. Cela multiplie par 10 le nombre d'instances du warmer que nous pouvons exécuter en même temps.

Un important sous-système a été ajouté qui permet au warmer de se connecter en tant que service à la passerelle de diffusion, ce qui permet d'exécuter des scénarios de charge qui se coordonnent à la fois en tant que client connecté via le hub et en tant que service sur le réseau de diffusion.

Améliorations de la simultanéité du backend
Nous avons pu augmenter les performances du service variable, des chargements et du service de cache de persistance principal. La stabilité du backend a considérablement augmenté, surpassant les performances et la fiabilité que nous avions dans les versions précédentes. Notre code réseau de bas niveau a été mis à jour pour améliorer à la fois les performances, l'évolutivité et la robustesse. Nous avons également apporté plusieurs corrections et optimisations au service de transactions, aux locations et à notre processeur de droits.

Une journalisation unifiée et centralisée
Grâce à notre nouveau système d'enregistrement centralisé unifié, tous les services envoient des messages JSON formatés à une base de données Elasticsearch centralisée. Chaque événement du journal est étiqueté et des données dynamiques telles que les ID de compte, les ID de joueur, etc. sont extraites dans des champs nommés, ce qui rend la recherche d'événements ou de champs spécifiques - tels qu'un "AccountID" - très efficace. Cela permet aux développeurs d'accéder facilement aux journaux à partir d'un endroit centralisé et de suivre les messages et les événements complexes qui se produisent entre plusieurs services.

Technologie de la persistance

Création d'entités et découplage de la génération d'objet (spawn)
En préparation de la diffusion continue, le processus de création des entités a été découplé de la production des entités. Cela nous permet d'"ensemencer" l'état initial de l'univers dans la base de données persistante en créant toutes les entités dynamiques avant la simulation. Les processus DGS permettront ensuite de créer des entités persistantes (spawn/despawn) à partir de cette base de données pendant la simulation. Il s'agit là d'un important pas en avant pour un univers totalement persistant.

Files d'attente parallèles pour le spawn
Comme optimisation, nous avons introduit plusieurs files d'attente parallèles sur chaque serveur de jeu. Cela nous permet de créer plusieurs emplacements distincts (comme Lorville et New Babbage) en parallèle sur des threads séparés sur le même serveur. Les versions précédentes n'avaient qu'une seule file d'attente et donc (dans cet exemple) nous ne commencions pas sur New Babbage tant que Lorville n'était pas entièrement reproduit. Sur les serveurs occupés, cela peut vraiment réduire le temps d'attente dans certains cas. Par exemple, lors du spawning des vagues de vaisseaux AI ou du respawning dans un hab.

Technologie réseau

Temps et désynchronisation
La façon dont le moteur mesure le passage du temps a été complètement révisée. La précision a été améliorée tant dans la mesure du temps que dans sa synchronisation entre le serveur et les clients. La façon dont le moteur utilise le temps pour mettre à jour sa logique et sa simulation physique a été modifiée afin d'éliminer les erreurs qui pourraient faire que le temps de simulation passe différemment sur le serveur et les clients. De nombreux petits bogues qui avaient provoqué une augmentation des erreurs de synchronisation sur des serveurs fonctionnant depuis longtemps ont également été corrigés. La synchronisation en réseau des véhicules et des objets physiques a été mise à jour pour tirer pleinement parti des améliorations. Le résultat cumulé de tous ces changements a été une réduction significative des problèmes de latence et de désynchronisation dans de nombreux domaines, même dans des conditions de test difficiles pour les performances du réseau et des serveurs. Outre l'amélioration de l'expérience générale des joueurs, ce travail était une étape nécessaire vers le maillage des serveurs, où la simulation du jeu sur plusieurs serveurs de jeu aurait aggravé les problèmes de désynchronisation dus aux erreurs de synchronisation.

API de l'autorité
En préparation du maillage du serveur, l'équipe a effectué un balayage des tâches restantes pour convertir le code à l'API de l'Autorité. Au cours des 12 derniers mois, toutes les équipes ont coordonné leurs efforts pour mettre à jour le code du moteur final du jeu en fonction de ce nouveau système. Grâce à leur travail, une grande majorité de ces tâches ont été réalisées. Grâce à un effort concerté, nous avons réduit le nombre de tâches restantes à un chiffre.

Flux de connexion
Dans un maillage de serveurs, un client peut se connecter à de nombreux serveurs différents pendant une session de jeu. Une partie du travail de maillage des serveurs nécessite de séparer le processus de connexion d'un client à un serveur en plusieurs étapes distinctes. Ces étapes peuvent ensuite être exécutées indépendamment sans qu'un client ait à abandonner complètement sa session de jeu existante. Des progrès significatifs ont été réalisés dans ce sens, mais il reste encore beaucoup à faire.

Marco Corbetta
VP of Technology

 

Rendez-vous dans le "Verse" !

 

Nous pensons qu'il est très utile de donner ce niveau d'information sur notre processus de développement, en particulier lorsque vous pouvez lire les processus de réflexion, les réflexions et les enseignements directement de nos développeurs principaux. Comme nous l'avons mentionné la dernière fois, nous nous engageons à un développement transparent et nous continuerons à fournir le postmortems des patchs trimestriels à l'avenir.

Trad : @Maarkreidi SwissStarships.org