Le 17 décembre 2020, CIG a lancé l'Alpha 3.12 "Assault on 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, une analyse portant sur l'événement dynamique XenoThreat fera l'objet d'une publication séparée.
Équipe des Véhicules
Le pilier véhicules a principalement soutenu le travail de nombreuses autres équipes pour Star Citizen Alpha 3.12, en particulier avec le combat de navires de guerre en amont de l'Arlington Bounty, du CS5 UEE Navy Idris et des événements de la XenoThreat. Nous avons travaillé non seulement sur le fonctionnement et les performances des véhicules (étant les plus grands navires 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 salve, ajoutant ainsi un plus grand choix tactique à l'acte de détournement des missiles et torpilles entrants. 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 têtes chercheuses 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 salves, 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.
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 de l'Alpha 3.11) qui permet aux joueurs d'identifier rapidement les points d'entrée dans un navire. Ces marqueurs se mettent à jour selon que le navire est à terre ou en mode zéro-g, ce qui supprime une plainte courante des nouveaux joueurs, à savoir qu'ils ne savent pas comment entrer dans leur navire. 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, ils se sont plutôt bien passés 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, Vehicle Director
L'équipe USPU chargée du gameplay
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.
International Aerospace Exposition (IAE)
Nous avons réussi à étendre le contenu de l'IAE au style artistique de haute technologie, 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 choses ont permis à chacun de louer les vaisseaux qu'il était impatient 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 navires 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.
Nous avons eu deux véhicules qui ont été présentés au jeu lors du salon IAE et qui ont vraiment été conçus sur le fil du rasoir. En fin de compte, cela ne nous a permis de verrouiller la conception 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.
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 actifs 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 de problèmes.
Système de réputation
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 d'entrer dans le jeu que nous avons choisi de le sortir sans qu'aucun joueur doive faire face à 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.
En ce qui concerne le développement général de cette fonctionnalité, elle s'est déroulée assez facilement 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.
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 Building Blocks
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 multitude de personnes et s'est avéré être 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 UI nous a également permis d'effacer tous les éléments de l'UI simultanément. Ce processus nous a donné le temps de réfléchir de manière critique à l'avant 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.
Le Front End est très imprégné de la panoplie d'outils CryEngine avec laquelle 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.
En fin de compte, le jeu sur lequel nous avons basé notre Front End 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 Front End à 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, Lead System Designer and USPU Product Owner
Équipe Services et Outils Systémiques
L'équipe des services et outils systémiques (SST) 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 de 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.
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.
Nous cherchons des moyens de mieux rationaliser et distribuer le travail qui arrive dans la 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, Senior Technical Designer
Équipe de Conception
Interception de torpilles par l'AI
Les tourelles de l'Idris qui interceptent les torpilles fonctionnent bien, et cela crée des moments très cool quand elles réussissent leur interception.
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.
Nous allons chercher à améliorer la précision de l'IA afin de mieux contrôler le nombre de torpilles qui se faufilent à travers les défenses de la tourelle.
Utilisation du Mode de Tir des IA et Priorités de Ciblage
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 raisonnable pour sa classe de navire et la taille de sa tourelle.
A la minute près, 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.
Nous rééquilibrerons les rafales de l'AI lorsque des capacités seront introduites pour réduire l'efficacité du maintien du bouton de mise à feu.
Convergence de la précision de l'IA
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.
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 en arrière du mouvement de la cible plutôt que devant, de sorte que les joueurs ne voient pas qu'on leur tire dessus autant.
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 dedans.
Comportement au Combat des Vaisseaux Capitaux
Les vaisseaux capitaux tiennent désormais beaucoup compte de la distance et de la position relative lorsqu'ils engagent d'autres navires. Les navires de guerre sans canon frontal tentent de s'approcher suffisamment pour utiliser toutes leurs tourelles, tandis que ceux qui disposent de gros canons frontaux tentent de rester hors de portée de l'ennemi et d'utiliser leurs puissantes armes à longue portée.
Le choix de la tactique ne tient pas suffisamment compte de la force du vaisseau AI par rapport à la cible. Par exemple, lorsque l'Idris combat une canonnière ou un navire de guerre, 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 prendre dans un combat rapproché.
Nous allons répéter la sélection de la tactique pour que l'IA considère son propre navire et sa propre cible de manière plus détaillée que la seule classe du navire. Nous voudrons également permettre aux traits de caractère du pilote d'affecter également le comportement du navire capital.
Panneaux des Ascenseurs
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 quelle toile de forme. Cela signifie que tous les futurs panneaux peuvent utiliser les deux mêmes fichiers, tout en ayant un aspect différent.
Le système de transit est très difficile à mettre en place et à tester dans sa forme actuelle, l'équipe de l'UI n'a pas pu le faire fonctionner correctement et a dû s'appuyer sur celle du Level Design pour le mettre en œuvre. Cependant, les équipes de l'Interface Utilisateur et de 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 du Building Blocks est extrêmement longue en raison du manque d'outils et de l'impossibilité de fusionner des fichiers.
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.
Station de Raffinage
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 elle-même est un excellent endroit pour développer la boucle de jeu avec très peu de retouches, ce qui devrait permettre une itération plus rapide en cours de route.
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 le louent, et de fournir plus d'expériences de jeu pour l'Argo MOLE ou les joueurs multiples avec des Prospectors.
A l'avenir, il faudra faire tester la partie artistique de l'UI 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.
Rework de l'Interface Utilisateur Minier
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ératant rapidement sur des morceaux de toile de l'interface utilisateur pour prendre en charge les 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.
Le premier passage du remodelage de l'interface utilisateur dans les mines a été plus difficile à 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.
Nous allons réitérer 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, Star Citizen Live Director
Pilier de Base du Jeu
Poutre de traction du Multi-Tool
Le rayon tracteur du Multi-Tool 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 en Alpha 3.12 est de faciliter la collecte des boîtes de fret lors des EVA, soit pendant les missions "Lost in Space", soit pour la collecte du butin après un combat. 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 la poutre du 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 signalisation. Cela signifie que nous sommes en mesure de montrer clairement les cinq états d'un objet en le regardant simplement :
- L'objet peut être soulevé
- L'objet peut être soulevé mais est hors de portée
- L'objet est trop lourd
- L'objet ne peut jamais être levé
- 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.
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 choix prioritaire pour nous concentrer sur l'expérience de base et nous assurer que celle-ci était aussi soignée que possible pour la libération. Cela arrive tout le temps avec les fonctionnalités et c'est la nature 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.
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 choses les plus importantes que j'essaie d'améliorer est de donner aux concepteurs de la mission 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
Le zérotage 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 caractéristiques ne sont pas vues sous leur meilleur jour lors de la première inspection ou qu'elles sont 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.
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. 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é 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 se reproduit sur une planète, une série de patchs (carrés) se développent autour d'eux, dont la taille ne cesse d'augmenter. Ces patchs couvrent la qualité du rendu (graphique) et la collision physique, les patchs plus éloignés ayant moins de détails et finalement aucune collision (car la physique est relativement chère). Aujourd'hui, lorsque vous vous déplacez, les patchs se mettent à jour dynamiquement, mais ce n'est pas un à un. Ainsi, un patch que vous venez de passer peut encore avoir sa collision car vous pouvez vouloir y retourner et il est plus performant de le garder à court terme que de continuer à le charger et le décharger. Dans ce cas, cela signifie que lorsqu'un concepteur chargeait dans l'éditeur pour tester la fonction, le patch é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.
Si je pouvais remonter dans le temps, je m'assurerais certainement que la fonction ait é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.
Gemini A03 Sniper Rifle & Behring FS-9 LMG
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/fusils à 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 de supprimer une zone sans perte énorme de précision.
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.
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
Localisations
Ponts de la Raffinerie des Stations Spatiales
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 l'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.
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.
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 et Polissage des planètes de Stanton
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 à Stanton les nouveaux flux de travail améliorés développés lors de la création des planètes et des lunes de Pyro.
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 globale. 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 complexifier 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é correctement traités 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 le 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 qui s'accumule sur le sommet des rochers de Daymar.
Alors que nous essayions de terminer l'année et d'atteindre la sortie de l'Alpha 3.12, certaines lunes n'ont pas pu être amenées au niveau finit que nous souhaitions. 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é.
Un plus grand nombre d'assets permettra de réduire la fatigue des artistes 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.
Aménagement de l'Espace du Système Stanton
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 de l'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.
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.
Nous sommes déjà en train d'améliorer notre processus de développement et d'étudier les moyens de le perfectionner. Nous explorons comment nous pouvons relier le paysage spatial de fond en des formes plus miniaturisées, qui conduisent ensuite à 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 l'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 Squadron 42, 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éphysialisation 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 végétation de flexion du 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 en 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 moteur central, nous avons mis en place un chemin de sélection dynamique des zones dans le système de zones. Nous avons également corrigé quelques bogues d'élimination liés à la distance de visionnement pour les objets de la taille d'un pixel qui sont entrés dans l'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 programmateur 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 l'Object Container Streaming.
En ce qui concerne la gestion des crashs, nous capturons maintenant une pile hexa du fil de rendu et l'incorporons dans des mini-dumps que vous nous envoyez (en option) au cas où le jeu 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
Dispositif de Test pour l'Equilibrage des Charges
Le réchauffeur de pestilence pour l'Alpha 3.12 a reçu des mises à jour importantes. Tout d'abord, le réchauffeur 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 d'usurpation d'identité. Cela multiplie par 10 le nombre d'instances du réchauffeur que nous pouvons exécuter en même temps.
Un important sous-système a été ajouté qui permet au réchauffeur 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é par 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 Connexion 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 Persistante
Création d'Entités et Découplage du Spawn
En préparation de la diffusion continue, le processus de création des entités a été découplé de la reproduction 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 de la 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 Spawn des vagues de navires AI ou du respawn 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 Server Meshing, où la simulation du jeu sur plusieurs serveurs de jeu aurait aggravé les problèmes de désynchronisation dus aux erreurs de synchronisation.
Autorité API
En préparation du Server Meshing, l'équipe a effectué un balayage des tâches restantes pour convertir le code à l'Autorité API. Au cours des 12 derniers mois, toutes les équipes ont coordonné leurs efforts pour mettre à jour le code du moteur de fin de 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 unique chiffre.
Flux de Connexion
Dans un Server Meshing, un client peut se connecter à de nombreux serveurs différents pendant une session de jeu. Une partie du travail du Server Meshing 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
