Rechercher dans la communauté

Alpha 3.18 & 3.19 Post Mortem Lancement de l'Alpha 3.18 Comme beaucoup de nos joueurs l'ont expérimenté, nous avons lancé l'Alpha 3. 18 le 10 mars de cette année, et à côté d'une foule de nouvelles fonctionnalités très médiatisées comme le Salvage, le Vulture pilotable, le surprenant Scorpius Antares, de nouveaux fleuves et de nouvelles missions, la plus grande vedette du patch a été notre livraison de Persistent Entity Streaming (PES), qui a complètement réécrit la façon dont nous sauvegardons l'état dans le jeu et a inauguré la promesse d'un véritable univers persistant où les actions d'un joueur peuvent rester dans le jeu pour que d'autres puissent interagir avec lui et créer un environnement vivant où vous pouvez littéralement laisser votre marque dans le PU. Et, tout aussi important, PES a été la dernière étape nécessaire à la mise en place d'un maillage statique des serveurs. Beaucoup de ceux qui suivent Star Citizen ont compris à quel point la livraison de l'Alpha 3.18 était importante pour nous et pour le jeu lui-même. De nombreuses équipes de CIG ont passé la majeure partie de la seconde moitié de l'année dernière à terminer le Persistent Entity Streaming, que nous avons déployé sur nos serveurs Public Test Universe pour les tester en décembre 2022, puis ont passé les trois mois suivants à le renforcer et à l'améliorer pour le lancer sur notre service Live Star Citizen le plus rapidement possible. Cependant, lorsque l'heure de vérité a sonné et qu'Alpha 3.18 a été livré sur le service Live, le choc subi par le système a été supérieur à ce que nous avions prévu. S'il est vrai que nous nous attendions à ce que PES crée une expérience difficile au départ, le temps d'aplanir les problèmes qui ne pouvaient que se révéler à grande échelle (et nous avions prévenu), dire que nous avons été surpris par l'ampleur du chaos du lancement de PES serait un euphémisme. L'attente de PES et de la version 3.18 était tout simplement sans précédent pour nous. Lorsque le patch est sorti le 10 mars, nous avons enregistré les pics les plus élevés de connexions par minute et par heure, ainsi que le plus grand nombre de tentatives de connexion en une journée pendant les premiers jours du lancement. Nous disons "tentatives de connexion" car, comme vous le savez tous, le service a été tellement submergé par le trafic et les problèmes de démarrage de PES que de nombreux joueurs n'ont pas pu entrer dans le jeu, divers problèmes ayant bloqué les utilisateurs tout au long de l'entonnoir de connexion. Certains étaient bloqués dans les files d'attente, d'autres n'arrivaient pas à charger leur personnage, d'autres encore étaient bloqués sur un écran de chargement infini. Comme vous pouvez le lire dans le compte-rendu de Benoit Beauséjour (notre directeur technique sur PES), nous avons sous-estimé les forces multiplicatives du passage à Live et de la création et de la persistance de chaque entité créée par les joueurs à travers leurs actions, créant une charge sur notre service qui dépassait nos prévisions initiales. Et il a fallu des semaines, voire des mois, pour exposer, diagnostiquer, créer des correctifs, les tester et les déployer pour restaurer le service, tout cela alors que le jeu tournait toujours sur le Live. Nous avons beaucoup appris du lancement de PES, et bien que nous soyons encore en train de nous remettre, et que nous regrettions que le service ait été compromis dans les premiers jours et les premières semaines du déploiement, cela nous a certainement enseigné une leçon précieuse pour valoriser et préserver l'intégrité du service plus que nous ne l'avions fait dans le passé. C'est pourquoi, alors que nous commençons à déployer le fractionnement de la couche de réplication et la récupération en cas de crash - deux choses désormais permises par PES - nous le ferons progressivement, et alors que nous commençons à livrer le Server Meshing, nous créerons des canaux de test dédiés pour renforcer davantage ces nouvelles technologies et mettre en œuvre des normes et des seuils avant de les "graduer" vers PTU et ensuite Live. Vous commencerez à voir les ramifications de cela plus tard dans l'année et nous vous en dirons plus sur notre nouvelle approche du déploiement de nouvelles technologies potentiellement perturbatrices et changeantes pour le service de jeu, mais il s'agit pour nous de nous engager réellement à préserver l'expérience des centaines de milliers, voire des millions, qui jouent maintenant à Star Citizen en tant que service de jeu en direct, même s'il s'agit d'une version alpha encore en développement. Persistent Entity Streaming Ce qui a fonctionné Le développement de Persistent Entity Streaming (PES) a impliqué une équipe de programmeurs aux compétences spécialisées dans de nombreux domaines au sein du groupe Core Tech et de Turbulent. Cette collaboration a été cruciale pour la réussite de la construction de ce système complexe. L'équipe de choc a suivi des sprints et des objectifs alignés, facilités par des ingénieurs et des producteurs seniors, qui ont été soutenus par des réunions régulières. Cela a permis une communication efficace et a minimisé les erreurs de communication ou les malentendus techniques. L'équipe de choc a maintenu un niveau élevé de qualité du code, en veillant à ce qu'il fasse l'objet d'une conception approfondie, de discussions et de multiples révisions avant d'être intégré dans la base de code principale. Le déploiement initial dans l'univers de test public (PTU) et les tests avec la communauté du PTU se sont bien déroulés, établissant une base positive pour d'autres améliorations. Toutefois, des problèmes sont apparus (voir ci-dessous). Enfin, l'architecture du système et l'API de PES, qui sont basées sur des files d'attente durables, ont prouvé qu'elles pouvaient se remettre des pires problèmes en toute sécurité et qu'elles tendraient toujours vers le rétablissement. Ce qui n'a pas bien fonctionné Les aspects de recherche et de développement de PES ont posé des défis, exigeant des ingénieurs qu'ils inventent des moyens de contourner des problèmes imprévus. En raison de la nature fondamentale de PES, son intégration dans le code du jeu Star Citizen a entraîné des changements significatifs qui ont perturbé le jeu à un niveau très profond, et certaines équipes de jeu n'étaient pas préparées à l'effort d'intégration nécessaire pour ramener les systèmes de jeu à la parité ou pour convertir et exploiter la nouvelle couche de persistance pour les fonctionnalités existantes. Les problèmes liés aux changements introduits par PES ne sont apparus que lors d'une utilisation à grande échelle et sous une forte charge de joueurs, ce qui a entraîné des retards dans l'identification et la résolution des problèmes. De plus, des fonctionnalités qui n'étaient pas censées utiliser la persistance ont été affectées par des retards insignifiants (comme les systèmes de tramway, les files d'attente pour les joueurs, etc.) Nous avons également sous-estimé le facteur de multiplication entre le PTU et les opérations Live ; le groupe avait estimé une augmentation de 10x de l'activité du backend mais a été confronté à une augmentation de 20x+ des requêtes, de la taille des messages de flux et de l'activité globale, ce qui a provoqué des interruptions de service généralisées lors du lancement initial. En ce qui concerne les véhicules, PES a fortement modifié la manière dont ils sont autorisés et créés dans le jeu. Cela permet d'améliorer l'expérience de l'utilisateur (qui peut choisir l'endroit où un vaisseau est créé), mais aussi de réduire considérablement la taille de l'inventaire/de la base de données globale pour les vaisseaux qui ne sont jamais utilisés. Des problèmes majeurs ont également été découverts à grande échelle avec un moteur de base de données tiers que PES utilise pour ses fonctionnalités. Ces problèmes ont donné lieu à des cycles de demande/réponse très instables ainsi qu'à des files d'attente importantes. Ces problèmes ont également eu des effets d'entraînement, un serveur de base de données entrant dans une situation de blocage entraînant l'arrêt du traitement des demandes par l'ensemble du cluster (au lieu d'un seul shard) pendant un certain temps. Il s'agissait d'une cause majeure d'instabilité tout au long de l'Alpha 3.18.x jusqu'à ce que l'équipe ait identifié et programmé une solution de contournement pour atténuer les effets. En outre, de multiples problèmes de verrouillage à l'échelle ont été découverts dans le système de base de données global (même moteur), ce qui a entraîné un arrêt périodique de toutes les demandes adressées aux systèmes d'inventaire. L'équipe a dû enquêter et faire rapport à nos fournisseurs pour déterminer des solutions de contournement et, en fin de compte, des correctifs qui empêcheraient le moteur de base de données de se verrouiller. Dans le moteur de base de données, plusieurs shards ont atteint des limites dures jusqu'alors inconnues quant au nombre maximum d'entités allouées, ce qui a obligé les équipes à ensemencer/créer de nouveaux shards et à les distribuer, diluant ainsi l'effet de la persistance sur ces shards. Plusieurs bogues ont été découverts (en ces temps instables) dans la gestion des erreurs dans certaines parties du flux de connexion qui ont bloqué certains comptes de différentes manières liées à la création de personnages. On a découvert que la gestion des crashs de serveurs prenait beaucoup plus de temps en raison d'un nouveau processus qui intervient pendant l'analyse post-mortem. Cela affecte l'analyse post-mortem des instances et retarde le retour des joueurs dans l'inventaire global, ce qui peut avoir pour conséquence de bloquer le personnage d'un joueur dans une instance. Ce que nous ferons mieux/projets futurs À l'avenir, nous finaliserons et utiliserons le nouveau Cloud Test Launcher pour tester de manière adéquate les cartes du jeu à grande échelle. Cet outil simulera les comportements des joueurs et permettra à l'assurance qualité et aux ingénieurs de connecter plusieurs clients de jeu modifiés à l'espace de jeu. L'utilisation de ressources informatiques dans le cloud permet de réaliser des tests de résistance efficaces, qui aideront à identifier et à résoudre les problèmes liés à des serveurs très chargés avant le passage à la version Live. L'équipe responsable de PES est maintenant passée au maillage statique des serveurs et adopte une approche de transformation pour ce nouveau projet. Contrairement à PES, cette technologie fondamentale peut être intégrée progressivement dans la base de code, en évitant une approche perturbatrice de type "Big Bang". Certaines parties de la technologie Server Meshing sont déjà à la disposition de l'équipe de jeu pour tester la compatibilité avec les fonctionnalités de leur jeu. Combinée avec le Cloud Test Launcher, cette approche vise à faciliter le processus d'intégration de Static Server Meshing. En mettant en œuvre ces mesures, nous visons à améliorer nos capacités de test et à atténuer les défis d'intégration, en assurant une livraison plus fluide des technologies fondamentales tout en minimisant les perturbations dans le jeu. Les Rivières Ce qui a bien marché L'inclusion des rivières a marqué une étape importante dans notre quête pour créer des planètes plus réalistes et plus immersives. Nous avons été très satisfaits des améliorations apportées aux canyons fluviaux entre Alpha 3.18 et 3.19 grâce à l'amélioration de notre pipeline de ressources. Et le soutien de l'équipe de Planet Tech pour résoudre les problèmes techniques au cours de ce processus a été remarquable. Ce qui n'a pas fonctionné L'outil de placement procédural des rivières n'était pas dans un état aussi bon que nous l'avions espéré lorsque nous avons commencé à l'utiliser. Par conséquent, un effort manuel considérable a été nécessaire pour placer méticuleusement et vérifier les rivières résultantes afin d'assurer leur qualité optimale. En outre, cette limitation a également entraîné une diminution du nombre de rivières que nous avons pu générer. Ce que nous ferons mieux/projets futurs Les nombreux problèmes qui ont été identifiés et résolus avec succès au cours de cette première série de rivières ont déjà eu un impact significatif sur la fluidité de l'expérience pour la prochaine fois. Bien qu'il reste encore beaucoup de travail avant que nous puissions créer des paysages planétaires avec des rivières qui ressemblent à la réalité, nous avons fait des progrès substantiels et nous sommes maintenant beaucoup plus proches de notre objectif que jamais auparavant. Grottes de sable Ce qui s'est bien passé Nous sommes très satisfaits des résultats de cette première phase de développement d'un pipeline amélioré pour produire des salles individuelles pour tous les archétypes de grottes et pour définir l'identité visuelle de nos grottes de sable. Le fait que nous ayons pu sortir un premier ensemble de petits systèmes de grottes de cette phase de prototypage grâce à l'effort concerté de plusieurs départements a été la cerise sur le gâteau pour nous. Ce qui n'a pas marché En l'absence d'outils permettant d'assembler les lieux de manière procédurale ou de les placer automatiquement sur des planètes prêtes à l'emploi, nous avons dû construire et placer chaque grotte manuellement, ce qui a constitué la principale contrainte quant au nombre de grottes que nous pouvions placer sur les planètes du système de Stanton. Malheureusement, ces grottes ont dû être mises à disposition sans missions, ce qui en fait des lieux que le joueur doit activement rechercher pour les découvrir. Ce que nous ferons mieux/projets futurs Nous sommes actuellement en train de peaufiner les nouveaux visuels des grottes rocheuses, qui constitueront le prochain archétype. Nous avons hâte d'utiliser l'outil de localisation pour construire une plus grande variété de systèmes de grottes. De plus, nous allons travailler sur la prise en charge de connexions, de pièces et d'entrées plus grandes, ce qui est une exigence clé avant de pouvoir remplacer les anciennes grottes. Circuit de course PTV Ce qui s'est bien passé Il a été créé très rapidement ; nous nous sommes lancés dans l'idée qu'il s'agissait d'un lieu simple, avec un délai court et un impact minimal sur les autres équipes. Cependant, nous avons réalisé beaucoup plus en trois semaines que ce à quoi nous nous attendions au départ, avec un bon kit modulaire pour les pistes de course de style kart, et l'ajout d'un bon habillage, d'un bon thème et d'un bon éclairage. Nous avons été ravis de constater l'enthousiasme de la communauté, en particulier celle des coureurs, lorsque la piste a été présentée au public pour la première fois. Nous avons depuis vu des courses organisées sur la piste. Nous avons également obtenu la prise en charge du code pour les améliorations de l'entité de réapparition des véhicules, de sorte que si les gens s'écrasent, se cassent ou abandonnent le PTV Greycat, il réapparaît dans la zone de départ de la piste. Nous pouvons également définir des valeurs telles que le temps de réapparition. Ce qui n'a pas marché Bien que la piste ait été terminée avant la sortie de l'Alpha 3.17, elle n'avait pas encore fait l'objet d'un test d'assurance qualité et n'avait pas encore été corrigée. Nous avons donc décidé de la conserver jusqu'à l'Alpha 3.18. Nous étions loin de nous douter que l'Alpha 3.18 allait être retardée à ce point, si bien que la piste, bien que complète, est arrivée dans les mains du public bien plus tard que nous l'avions espéré. Ce que nous ferons mieux/projets futurs Nous développerons certainement d'autres circuits modulaires à l'avenir (et nous en avons un autre en préparation), mais ce projet est pour l'instant en veilleuse. Nous essaierons de soutenir d'autres véhicules terrestres de taille similaire, comme le Greycat STV, à l'avenir également (les premiers tests ont été positifs). Nous allons également travailler avec l'équipe Mission pour envisager l'ajout d'une mission de type circuit de course sur les pistes, ce qui permettra de suivre les temps de course, les points de contrôle et les tours, et permettra à la mission d'offrir des récompenses aux joueurs. Poste de sécurité de Kareah Ce qui a bien marché Nous n'aurions jamais pu imaginer le niveau de soutien que nous avons reçu de la part de l'équipe artistique, qui a vraiment rajeuni l'endroit. L'activité de bac à sable déclenchée par les joueurs a été bien accueillie, et les analyses ont montré que le piratage de CrimeStats à Kareah est toujours très populaire, ce qui nous préoccupait car nous prenions un risque en supprimant les autres lieux de piratage. Ce qui n'a pas fonctionné La mission présente encore des imperfections qui doivent être corrigées, ce qui est en cours. Par ailleurs, des besoins supplémentaires en matière d'analyse des activités du bac à sable ont été identifiés afin de mieux comprendre la participation des joueurs. Ce que nous ferons mieux/projets futurs Nous continuerons d'améliorer l'activité et l'emplacement du bac à sable en nous basant sur les commentaires que nous avons reçus et nous ajouterons des analyses supplémentaires pour mieux comprendre la participation. Jumptown Ce qui s'est bien passé Les changements de lieu ont été très bien accueillis, la participation des joueurs a été constamment très élevée et le soutien que nous avons reçu de la part d'Art a été bien au-delà de ce que nous attendions. Ce qui n'a pas marché L'implémentation de PES a entraîné des problèmes de performance autour de l'emplacement après la destruction d'un grand nombre de vaisseaux. Nous voulions également redéployer les emplacements avec RASTAR. Cependant, nous n'avons pas pu le faire à l'époque car cela brisait les boutiques. Ce que nous ferons mieux/projets futurs Pour la prochaine édition des événements mondiaux, nous prévoyons de redéployer les emplacements sur différentes planètes afin d'offrir un gameplay différent. Par exemple, dans une atmosphère épaisse, sur des planètes à gravité plus élevée et dans des forêts. Épreuves chronométrées Ce qui a bien marché Le nouveau contenu de course et les nouveaux modes de contre-la-montre ont été bien accueillis par la communauté de course, aidée par les équipes de contenu qui ont produit beaucoup plus de pistes que nous n'aurions pu l'espérer. Dans le backend, les analyses que nous avons ajoutées étaient fantastiques et nous ont permis de faire des analyses très approfondies de chaque piste, ce qui nous a aidés à déterminer où elles devaient se situer dans le classement de difficulté et quels devaient être les temps cibles. Ce qui n'a pas fonctionné Les mauvaises performances du serveur ont nécessité la création d'un nouveau système sophistiqué de suivi des points de contrôle, bien que les marqueurs ne se mettent toujours pas à jour de manière aussi réactive que nous le souhaiterions. Les analyses montrent également que relativement peu de joueurs débloquent la deuxième piste. Missions d'infiltration - Orison Ce qui a bien marché Les nouveaux environnements FPS ont été bien accueillis et constituent un changement rafraîchissant après les installations souterraines que nous avons connues pendant des années. La possibilité de prendre d'assaut les lieux à pied ou à bord de vaisseaux était également géniale. Ce qui n'a pas marché Nous avons dû désactiver les missions pour l'Alpha 3.19 parce que nous voulions publier Siege of Orison, mais nous n'avons pas pu le faire à temps, ni les nouveaux clusters de plateformes (où nous devions les relocaliser). Ce que nous ferons mieux/projets futurs Nous avons déplacé les missions vers les nouveaux clusters de plates-formes et nous les publierons dès que possible. Activités dans les prisons Ce qui a bien marché La mission d'évasion de la prison est étonnamment bien jouée et offre aux joueurs un nouveau moyen d'effacer leurs statistiques de criminalité. À l'intérieur de la prison, le butin de l'IA et les nouveaux terminaux de vente ont été bien accueillis ; les joueurs ont trouvé que la nouvelle IA rendait la prison plus vivante et leur donnait un autre moyen de gagner des mérites. Ce qui n'a pas marché L'Ursa Rover continue d'apparaître sous terre, la vente d'objets au kiosque de la prison n'est toujours pas fiable et l'IA apparaît en trop grand nombre en raison d'un problème de placard de spawn. Ce que nous ferons mieux/projets futurs Lors de la prochaine version, nous corrigerons tous les bugs possibles, y compris le problème de l'apparition de l'Ursa. Drake Vulture Ce qui a bien marché L'ajout du "starter" tant attendu de la carrière de Salvage en même temps que sa boucle de gameplay a été une étape importante pour l'équipe Véhicule. Bien que le véhicule ait été commencé il y a un certain temps, nous l'avons gardé pour nous assurer qu'il sortirait bien avec la boucle de gameplay plutôt que sans, et cela a permis à l'équipe d'ajouter quelques fonctionnalités supplémentaires au vaisseau pour s'assurer qu'il répondait à toutes les normes actuelles. Ce qui n'a pas marché Quelques plaintes entourant la traversée du vaisseau en raison de la mécanique de gameplay étaient en quelque sorte le produit de la mécanique de Salvage évoluant au fil du temps pour nécessiter plus d'entrées manuelles que prévu initialement lors de la conception du véhicule en 2018. Ce que nous ferons mieux/projets futurs Sortir des véhicules en même temps que leurs boucles de gameplay plutôt que plus tôt dans le projet (voir Starfarer et Reclaimer) est quelque chose que nous nous sommes efforcés de faire ces derniers temps, et nous continuerons à viser à faire cela. RSI Scorpius Antares Ce qui a bien marché L'Antares a été conçu parallèlement au Scorpius de base comme une variante optionnelle à mettre en production ultérieurement, la section de la queue du vaisseau étant décrite comme la partie pouvant faire l'objet d'un changement de géométrie. Cependant, au cours du développement, il est apparu clairement que les besoins de l'EMP et du moteur quantique nécessitaient un peu plus de puissance que prévu et l'équipe a bien réagi en ajustant à la fois la base et l'Antares pour que la disposition des composants convienne aux deux. Ce qui n'a pas fonctionné Nous n'avons pas pu résoudre certains problèmes techniques qui ont réduit la capacité du second joueur à contrôler les fonctions de pilotage et à disposer d'un écran multifonctions plus performant. Ce que nous ferons mieux/projets futurs Avec les modes Master et les nouveaux MFD à venir, nous devrions voir le copilote bénéficier de plus de fonctions de jeu plutôt que d'être moitié passager, moitié presseur de boutons. Salvage & Cargo - Gameplay des véhicules Ce qui s'est bien passé Nous avons été en mesure d'aider les deux équipes à introduire deux fonctionnalités clés dans le PU, Salvage nécessitant beaucoup de temps sur les assets artistiques et Cargo nécessitant un passage sur tous les vaisseaux par la conception. Ce qui n'a pas fonctionné Malheureusement, l'ampleur du travail pour Salvage a été considérablement sous-estimée, car nous pensions que le système de dégâts UV2 existant que tous les vaisseaux utilisaient conviendrait dès le départ. Cependant, nous nous sommes rapidement rendu compte qu'il faudrait faire une passe complète sur chaque vaisseau pour améliorer la qualité, car on regarde les visuels de beaucoup plus près que le système de dégâts. En outre, le mécanisme de jeu a été construit autour de l'idée que vous seriez en mesure de gratter la coque entière à 100 %. Cependant, cela n'a pas été pris en compte dans la configuration des dégâts de l'UV2, de sorte que certaines zones étaient inaccessibles, ce qui a provoqué la frustration des premiers testeurs qui ne pouvaient pas atteindre 100 % d'un vaisseau. Ce que nous ferons mieux/projets futurs Nous sommes maintenant plus étroitement intégrés aux équipes travaillant sur des fonctionnalités importantes comme celle-ci, de sorte que les problèmes peuvent être trouvés et étudiés avant que le développement ne commence vraiment, plutôt que d'être intégrés une fois que le prototype a été achevé. Grattage de la coque Ce qui s'est bien passé La première itération tant attendue du gameplay Salvage est enfin arrivée avec l'Alpha 3.18, qui permet aux joueurs de gratter les matériaux de la coque et de les échanger ou de les utiliser pour des réparations sur le terrain. La boucle de gameplay principale a été généralement bien accueillie et offre un contraste intéressant avec les autres activités. Nous avons également étendu le système de récolte avec des épaves de vaisseaux et des pièces de métal récupérables, et introduit la première version miniature de l'Artisanat en permettant aux joueurs de créer quelques objets sélectionnés à l'aide du CMR. La sortie du grattage de coque en même temps que celle du Drake Vulture a permis au vaisseau de bénéficier d'un système de jeu approprié, et le Aegis Reclaimer dispose enfin d'un système de jeu adapté. Ce qui n'a pas fonctionné Un grand nombre de fonctionnalités et de systèmes sur lesquels reposait le Hull Scraping étaient encore en cours de développement lorsque nous construisions le système de jeu principal. Cela signifie que la fonctionnalité a été confiée à l'équipe EUPU dans un délai assez court. Nous avons abordé la façon dont les joueurs trouveraient des objets récupérables dans l'univers bien trop tard dans le processus, et le travail d'équilibrage pour la distribution des objets récupérables n'a pas été correctement planifié. Tous les véhicules n'ont pas pu être mis à jour avec la nouvelle carte de dégâts, ce qui signifie que certains véhicules ne fonctionneront toujours pas correctement avec le grattage de coque. Ce que nous ferons mieux/projets futurs Nous avons modifié notre approche en ce qui concerne la précocité de l'implication des autres équipes, ce qui signifie que les équipes en aval sont impliquées dès la phase de prototypage. Nous avons également introduit des étapes supplémentaires au cours desquelles les équipes en aval et les équipes de contenu peuvent examiner et approuver les progrès réalisés avant de passer à l'étape suivante. Alpha 3.19 Contrats de récupération Ce qui s'est bien passé Nous sommes très fiers de ce que nous avons accompli ; au départ, nous ne pensions sortir qu'avec le grattage de coque, mais nous avons réussi à inclure la cargaison et la toute nouvelle fonctionnalité des composants détachables. La mission a également été bien accueillie par les backers. Ce qui n'a pas marché Nous n'avons pas choisi les meilleurs vaisseaux pour la mission, car seuls certains d'entre eux ont des composants internes détachables et des coques aux normes Gold pour le grattage (ce que nous n'avons découvert qu'après coup). De plus, en raison de la maladie d'un développeur, la première version a été très approximative en ce qui concerne l'apparition des cargaisons, ce qui signifie que nous n'avons pas eu le temps d'équilibrer correctement le jeu ou de vérifier que tous les objets pouvaient être vendus. L'équipe Économie a dû modifier la valeur des armes des vaisseaux très tard dans le développement. Cela était nécessaire pour équilibrer la question problématique de l'assurance, qui nécessite un rééquilibrage supplémentaire. Ce changement a déçu certains joueurs qui s'étaient habitués à des récompenses plus élevées. Ce que nous ferons mieux/projets futurs Pour la prochaine version, nous choisirons des vaisseaux plus appropriés avec des composants internes détachables. Expérience pour les nouveaux joueurs Ce qui s'est bien passé Nous avons reçu de nombreux commentaires positifs de la part des nouveaux joueurs, qui estiment que l'Expérience du nouveau joueur les a aidés à apprendre le jeu. Les améliorations visuelles apportées à la Zone 18 ont considérablement amélioré la navigation, ainsi que les nouveaux contrôles et les indices contextuels. Tout au long du développement de cette nouvelle expérience, nous avons pu apporter de nombreuses améliorations à notre système de missions, comme l'introduction de la persistance des missions, qui nous permet de reprendre une mission au dernier objectif actif si un joueur perd sa connexion ou subit un plantage du client. Ce qui n'a pas fonctionné La mission est en grande partie modulaire, mais pas entièrement, ce qui signifie qu'un travail supplémentaire est nécessaire pour l'adapter à d'autres lieux. Nous n'avons pas eu suffisamment de temps ou de soutien pour enseigner au joueur la gestion de l'inventaire ou l'interaction avec les magasins. En ce qui concerne la production elle-même, New Player Experience était une initiative inter-équipes et, en tant que telle, a été compliquée à coordonner. Le support de production pour New Player Experience a changé plusieurs fois car il n'appartenait pas à une équipe dédiée. En outre, nous n'avons pas bénéficié d'un soutien suffisant pour résoudre les problèmes visuels liés aux éléments existants du HUD, qui entraient en conflit avec les nouveaux contrôles et les indices contextuels. Ce que nous ferons mieux/projets futurs Nous avons commencé à travailler sur la modularisation des parties restantes de l'expérience du nouveau joueur afin de réduire la maintenance et de nous permettre de l'apporter à plusieurs endroits. Nous introduirons également des composants supplémentaires dans la NPE, tels que la gestion de l'inventaire, les achats et bien d'autres choses encore. RSI Lynx Ce qui a bien marché Le Lynx a commencé par être une adaptation très simpliste de l'Ursa, mais au fur et à mesure que nous avancions, nous avons pensé qu'il méritait plus. Il a donc été doté d'une géométrie et de matériaux presque entièrement nouveaux, ce qui s'est avéré payant puisque le véhicule a désormais l'allure qu'il mérite et qu'il s'intègre parfaitement au Constellation Phoenix. Nous avons également réussi à intégrer une grande quantité de contenu interactif dans le véhicule, notamment des chaises animées, des téléviseurs, des casiers et des réfrigérateurs. Ce qui n'a pas marché L'augmentation de la portée du travail pour le véhicule (principalement la refonte de l'ensemble du cockpit) a conduit l'équipe Véhicule à travailler plus longtemps que prévu, ce qui a laissé moins de temps aux autres équipes, telles que les équipes VFX et Audio, pour faire leur travail. Ce que nous ferons mieux/projets futurs La prochaine fois, nous veillerons à ce que les ajustements de la portée soient discutés avec toutes les équipes et à ce qu'elles n'attendent pas inutilement que tous les aspects soient livrés pour commencer leur passe. Mirai Fury et Fury MX Ce qui a bien marché Malgré sa taille, la série Fury est l'un des véhicules les plus complexes que nous ayons jamais mis dans le jeu, nécessitant des animations et des machines d'état complexes, le tout comprimé dans un espace très restreint. Il a également été livré en avance sur le calendrier, car nous étions tellement enthousiasmés par le véhicule que nous avons commencé la production avant que le concept ne soit officiellement terminé. Les équipes des fonctionnalités du véhicule ont permis d'améliorer les propulseurs à cardan pour qu'ils fonctionnent comme nous l'avions imaginé. Cela signifie que le Khartu-al et le San'tok.yai en bénéficieront à l'avenir. Le bouclier anti-explosion du MX a été notre première véritable incursion dans l'intégration d'une interface utilisateur Building Blocks personnalisée dans le pipeline du véhicule plutôt que de réutiliser d'autres éléments, comme les panneaux de contrôle des portes. Ce qui n'a pas fonctionné Il nous a fallu plusieurs tentatives pour mettre au point certaines technologies nécessaires aux rotations des propulseurs, et nous avons accidentellement causé d'autres problèmes avec les propulseurs d'autres vaisseaux, mais tout a été résolu avant la sortie de la version. Le MX devait à l'origine avoir des racks à missiles génériques, mais il était clair dès le départ qu'ils devaient être personnalisés pour éviter qu'ils ne soient lancés dans le corps ou les ailes lorsqu'ils sont remplacés par d'autres. Cela réduit malheureusement la personnalisation du joueur, mais le rend finalement plus fiable à l'usage. Ce que nous ferons mieux/projets futurs Nous sommes assez satisfaits de la façon dont la Fury et la Fury MX ont évolué et il n'y a pas eu d'éléments particuliers dans leur développement qui nécessitent des ajustements à l'avenir. Faisceau tracteur - Attachement/détachement de l'objet Ce qui a bien marché Enfin, les joueurs peuvent piller les véhicules pour en extraire des composants et des armes, ce qui élargit considérablement la boucle de jeu de la récupération. Cette fonctionnalité offre également des opportunités de jeu supplémentaires pour d'autres fonctionnalités, telles que l'échange de têtes et de modules miniers, et constitue une base solide pour la fonctionnalité de rayon tracteur pour véhicules. En interne, l'équipe chargée du contenu des véhicules s'est montrée très réactive pour résoudre les problèmes de contenu liés aux composants et aux armes existants. Ce qui n'a pas fonctionné Cette fonctionnalité n'était pas prévue à l'origine pour l'Alpha 3.19, et nous avons donc dû travailler dans un délai très court. Le retour de QA pour cette fonctionnalité a également révélé de nombreux problèmes de contenu qui n'ont pas pu être résolus à temps pour la sortie. Ce que nous ferons mieux/projets futurs Nous avons commencé à demander un soutien en aval bien plus tôt dans le processus afin que les changements de contenu nécessaires puissent être effectués en prévision de la préparation de la fonctionnalité, au lieu de faire le transfert vers la fin du développement. Rééquilibrage de l'exploitation minière Ce qui s'est bien passé L'accueil de la communauté a été fantastique et nous sommes très satisfaits de la façon dont la sortie s'est déroulée ; des métas et des problèmes d'équilibre de longue date ont été résolus et le minage est maintenant une boucle de jeu beaucoup plus nuancée qui permet des stratégies multiples. Les changements apportés aux rayons tracteurs ont grandement bénéficié à la boucle de jeu minière en permettant d'échanger les têtes minières, les modules et les pods. Nous avons également identifié un meilleur processus pour équilibrer les boucles de jeu de manière globale. Ce qui n'a pas fonctionné Certains problèmes n'ont pu être résolus qu'après la sortie du jeu, comme les roches minables qui explosaient toujours, et la redistribution et le rééquilibrage des prix des boutiques ont nécessité de nombreux allers-retours entre les différentes équipes avant d'être correctement mis en œuvre. Les tests ont révélé de nombreux problèmes et cas limites en matière de prix et de distribution, qui ont nécessité des corrections et des réajustements constants. Ce que nous ferons mieux/projets futurs Nous voulons continuer à améliorer notre communication sur le minage avec la communauté et rester à l'écoute des commentaires critiques afin de rendre le minage le meilleur possible. Nous ferons également davantage confiance aux données que nous recueillons pour éclairer les futures décisions de conception concernant le gameplay du minage. Trad : @Maarkreidi Starcitizeninfo.fr Voir la totalité de News

Alpha 3.16 Postmortem Le 22 décembre 2021, nous avons lancé l'Alpha 3.16 : Return to Jumptown, qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, y compris la sortie de l'événement dynamique Jumptown 2.0, le remaniement du grav-lev, et des vaisseaux abandonnés avec des pièges à éviter et des objets de valeur à sécuriser. Ce cycle de correctifs a été unique. Comme nous l'avons mentionné dans un Roadmap Roundup en décembre, Star Citizen Alpha 3.15 a mis plus de temps à sortir que prévu, ce qui a limité le temps dont nous disposions pour stabiliser la base de code de la 3.16. C'est pourquoi nous avons décidé de nous brancher sur le flux de développement de la version 3.15 pour éviter de mettre en péril la stabilité globale (qui est la meilleure depuis des années). En adoptant cette approche, nous avons opéré sur la même base de code que celle qui se trouve actuellement sur les serveurs live, tout en intégrant manuellement les fonctionnalités de la 3.16 (en particulier celles que nous jugeons à faible risque d'intégration). Ce qui suit est un post-mortem des développeurs principaux eux-mêmes, détaillant ce qui a été livré et leurs pensées sur la façon dont cela s'est passé. Véhicules John Crewe, Vehicle Director Le pilier Véhicules a connu une livraison relativement limitée pour l'Alpha 3.16, les équipes chargées des fonctionnalités et de l'expérience des véhicules s'étant principalement concentrées sur le remaniement du grav-lev. Ce qui s'est bien passé L'état antérieur de grav-lev laissait beaucoup à désirer, tant du côté interne que du côté public, car il ne se comportait jamais comme nous le voulions. Le grav-lev présentait de nombreux problèmes, tant sur le plan technique que visuel, que la refonte a permis de résoudre presque entièrement. L'expérience est maintenant beaucoup plus viscérale, permettant aux joueurs de choisir leur hauteur et de faire des virages inclinés beaucoup plus spectaculaires sans risquer de rouler. La récupération en cas de crash et le système de descente automatique après la sortie du siège ont également résolu des problèmes de longue date avec le système, qui laissait souvent les motos inaccessibles ou immobiles. Ce qui a moins bien fonctionné Dans l'ensemble, le nouveau système est nettement plus performant, mais il présente encore des problèmes occasionnels de détection de l'environnement, notamment lors de l'accès à des véhicules plus étroits. Bien que de nombreux véhicules n'aient jamais été conçus pour accueillir des motos grav-lev, nous voulons améliorer l'expérience de ceux qui tentent leur chance. Ce que nous ferons à l'avenir En ce qui concerne le contenu des véhicules, nous avons publié le Drake Cutlass Steel. Il a fait ses débuts en même temps que le travail supplémentaire de l'équipe chargée de la fonctionnalité des acteurs, qui a développé sa technologie de canon monté pour lui permettre de prendre en charge des états de déploiement animés. Le Steel est une alternative au populaire Anvil Valkyrie, rivalisant avec lui en termes d'armes et de capacité de transport de troupes avec un châssis plus petit et plus agile. Dans les prochains patchs, nous nous pencherons sur sa maniabilité et ses valeurs de blindage afin d'améliorer sa capacité de survie dans les zones de largage, où il n'atteint pas actuellement les objectifs souhaités. IA Francesco Roccucci, Directeur IA L'équipe AI n'a pas eu de livraisons majeures pour l'Alpha 3.16. Nous nous sommes principalement concentrés sur l'amélioration de l'expérience du barman. Ce qui s'est bien passé En général, la branche de la publication a été très stable pour nous, ce qui nous a permis de résoudre de nombreux problèmes, de soumettre beaucoup d'améliorations et de travailler ensemble vers un objectif très spécifique. Ce qui ne s'est pas si bien passé Nous avons eu plusieurs cas de soumissions piétinant d'autres changements, surtout du côté de la base de données d'animation Mannequin (ADB). Cela a fait resurgir des bogues précédemment corrigés, ce qui a entraîné une certaine frustration. La structure actuelle que nous utilisons est bonne en termes de maintien de certaines branches plus stables, mais elle peut également obliger l'équipe à consacrer plus de temps à l'intégration des bogues corrigés dans les flux de fonctionnalités. Ce que nous ferons différemment à l'avenir Nous nous concentrons actuellement sur la création de cartes de test des fonctionnalités. Celles-ci serviront de porte d'entrée lors de la validation des soumissions, car elles permettront de s'assurer que les modifications n'ont pas d'effets secondaires ou ne contiennent pas de données erronées. Nous souhaitons également que l'équipe se réunisse et définisse une liste de contrôle à suivre avant d'effectuer des soumissions jusqu'à ce que nous puissions obtenir des outils de validation plus automatiques. Emplacements Todd Papy, directeur de Star Citizen Live Vaisseaux abandonnés (MTL) Ce qui s'est bien passé Le concepteur de niveaux était en charge de tous les aspects de gameplay des lieux, y compris leur emplacement, la navigation, la distribution des ingrédients de gameplay et des lootboxes, les missions disponibles et le flux dans chaque lieu. Les tests de jeu internes et les données du PTU ont fourni de nombreux retours significatifs sur la navigation et la lisibilité. L'équipe a été extrêmement impressionnée par le niveau de retour de la communauté, qui sera utile lors du développement de ce type de lieux. Toute l'interaction de la communauté a été vraiment appréciée par l'équipe. La collaboration entre les équipes de conception, d'art et d'éclairage a été amusante, efficace et a donné des résultats impressionnants avec un minimum de frustrations. Ce qui ne s'est pas si bien passé Il a parfois été difficile d'obtenir des fonctionnalités soutenues par d'autres équipes (mines, butin, débogage de mission, balayage). Nous n'avions pas assez de testeurs QATR (Quality Assurance Test Request). De ce fait, l'équipe a dû trouver et résoudre de nombreux bugs qui affectaient ces emplacements. Nous avons eu quelques contretemps concernant le processus de transition vers la publication (mentionné dans l'introduction ci-dessus) qui ont fini par réduire le temps dont nous disposions pour la publication. Il en a résulté un retour en arrière de dernière minute, avec un branchement sur une version plus ancienne, ce qui a causé des tensions au sein de l'équipe et a été discuté comme quelque chose que nous aimerions vraiment éviter de faire à nouveau. Ce que nous ferons différemment à l'avenir Nous commencerons par une meilleure répartition des tâches et définirons la structure des niveaux et le flux de production avant de commencer à construire des choses. Une vérification de l'intégrité de l'entité sera effectuée avant son utilisation (les assets du Caterpillar présentaient de nombreux problèmes), ce qui laissera plus de temps pour la mise au point et l'itération. Nous viserons également à obtenir plus tôt la première version jouable à l'emplacement réel, et un audit des fonctionnalités et des dépendances avec les autres équipes devrait avoir lieu plus tôt. En ce qui concerne les tests, nous fournirons à l'AQ des documents de conception élaborés dès le début, afin que leurs plans de test soient prêts à temps pour le QATR et qu'ils soient plus efficaces pour trouver les problèmes légitimes qui brisent le jeu. Les testeurs devraient également disposer d'outils appropriés pour tester les missions et forcer les missions dans certains endroits. Jumptown 2.0 Ce qui a bien marché L'avant-poste de laboratoire de drogues original/initial était assez fade et n'offrait pas d'art visuel au joueur, ni d'opportunités d'exploration et de pillage, ni de JcJ/couverture aux joueurs. Pour Jumptown 2.0, nous voulions changer les choses pour offrir une meilleure expérience aux joueurs. Nous avons eu un bon coup de départ où nous avons défini les limites de ce que nous pouvions faire, qui ont été acceptées et respectées. Nous avons ensuite procédé à une refonte visuelle de l'extérieur des laboratoires de drogues, en ajoutant des options de couverture du sol et du toit. À l'intérieur, nous avons fourni aux joueurs des distributeurs de marchandises physiques pour transporter des marchandises et des sections de laboratoires de drogues nouvelles et améliorées. C'était vraiment génial d'avoir le temps de développer les avant-postes plus que ce que nous avions prévu et je pense que c'est bien mieux ainsi. Ce qui ne s'est pas si bien passé L'ajout de dernière minute des tourelles montées a été un peu difficile ; idéalement, cela aurait dû être intégré dès le début. Même si c'est génial de voir ces avant-postes mis à jour pour l'événement dynamique, ils seront finalement remplacés lorsque nous créerons la v2 des avant-postes high-tech. Nous avons rencontré quelques difficultés liées à la répartition de l'équipe entre Austin et le Royaume-Uni. À l'avenir, nous chercherons à mettre en place des transferts plus approfondis et à désigner une partie prenante supplémentaire basée dans le fuseau horaire de l'UE afin d'améliorer la collaboration. Comme nous l'avons mentionné plus haut, le fait de devoir changer de flux de contenu si tard dans le processus a entraîné une pression supplémentaire sur l'équipe. Ce que nous ferons différemment à l'avenir Dans l'ensemble, le nouveau laboratoire de drogues amélioré est nettement meilleur, mais il présente encore quelques problèmes et nous pensons que si les autres équipes avaient eu plus de temps et de soutien, l'expérience globale de l'événement aurait pu être bien meilleure. Un aspect que nous voudrions améliorer est la taille de la base et du laboratoire de drogues. Cependant, cela nécessitera un investissement en temps plus important. En agrandissant l'intérieur, nous aurions plus de possibilités de couverture et de jeu JcJ. Un autre aspect que nous pourrions améliorer est la façon dont les joueurs entrent dans la base. En ajoutant des points d'entrée et de sortie supplémentaires, nous pourrions éviter que les joueurs soient pris en embuscade par d'autres à travers la seule porte. Enfin, il serait bon d'étendre la couverture plus loin du laboratoire afin d'offrir une meilleure protection contre les vaisseaux et les bombardiers qui arrivent, ce qui encouragerait les actions PVP au sol. Trad : @Maarkreidi SwissStarships.org Voir la totalité de News

Alpha 3.13 & Invictus Launch Week Postmortem Le 22 avril 2021, nous avons lancé l'Alpha 3.13 : Underground Infamy, qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, notamment l'amarrage de vaisseau à vaisseau, des entrées de grottes supplémentaires et le gestionnaire de réputation. Ce qui suit est un postmortem des développeurs principaux eux-mêmes, détaillant ce qui a été livré et leurs pensées sur la façon dont cela s'est passé. Ce compte rendu porte à la fois sur le patch Alpha 3.13 et sur l'événement Invictus Launch Week. Pilier des Véhicules John Crewe, Vehicle Director Pour la version Alpha 3.13 de Star Citizen, le pilier Véhicules a fourni un mélange de nouvelles fonctionnalités, les bases de futures initiatives, et notre habituelle livraison de contenu. Merlin/Constellation Docking Qu'est-ce qui s'est bien passé ? Nous avons réussi à apporter une fonctionnalité attendue depuis longtemps à l'un des vaisseaux les plus emblématiques de Star Citizen. Bien que nous ayons eu l'intention de le faire dans l'Alpha 3.12, la décision de passer un trimestre supplémentaire à le peaufiner a porté ses fruits lors de la sortie, car il était beaucoup plus stable et plus étendu que prévu. Qu'est-ce qui a moins bien fonctionné ? La décision de reporter XenoThreat à 2021 a fait que nous avons été pris plus longtemps que prévu dans la correction des bugs pour l'événement, ce qui a réduit notre capacité à réagir aux problèmes de la fonctionnalité avant qu'elle ne soit envoyée aux Evocati pour les tests. Ce que nous ferons différemment à l'avenir D'une manière générale, le processus de mise en œuvre de la fonctionnalité s'est bien déroulé, donc à part le fait de tester plus tôt, il n'y a pas grand-chose que nous allons améliorer à l'avenir. Noms et numéros de série des véhicules Qu'est-ce qui a bien fonctionné ? La possibilité de personnaliser son vaisseau est une fonctionnalité demandée depuis longtemps, et c'est quelque chose que nous voulions offrir depuis bien plus longtemps, mais nous avons eu quelques problèmes techniques à résoudre en coulisses concernant le rendu et le flux des droits de la plate-forme au jeu. La livraison d'une petite sélection de vaisseaux a permis de tester la technologie et de mieux comprendre les limites du système. Qu'est-ce qui ne s'est pas bien passé ? Le plus gros problème, et de loin, était la lisibilité, en particulier pour les noms courts où la taille de la police est restée la même que pour un nom de 32 caractères maximum. Un nom court, combiné à un éclairage extérieur du vaisseau moins qu'idéal et à l'impossibilité de personnaliser la couleur du texte, a entraîné de gros problèmes de lisibilité. Ce que nous ferons différemment à l'avenir Nous travaillons avec les équipes Graphisme et Interface utilisateur sur une meilleure implémentation via les Building Blocks pour nous permettre de changer dynamiquement la taille de la police en fonction de la longueur de la chaîne de caractères saisie. Une disposition UV optimisée sera créée à cet effet. Le système de peinture sera également amélioré à l'avenir pour permettre aux joueurs de choisir la couleur du nom afin d'éviter les collisions. Dégradation visuelle de la coque Qu'est-ce qui a bien fonctionné ? Depuis l'introduction de la dégradation des objets et des défaillances dans Star Citizen Alpha 3.6, il manquait la dégradation visuelle de la coque du vaisseau en même temps que celle des autres objets. Maintenant que nous l'avons fait, vous avez une meilleure idée de l'état de votre vaisseau grâce aux images de la coque, sans avoir à chercher dans les MFD. Le système est lié à notre pipeline de production existant pour les véhicules, nous n'avons donc pas eu à revenir en arrière et à l'ajouter aux vaisseaux, ce qui a rendu la mise en œuvre beaucoup plus rapide. Qu'est-ce qui ne s'est pas bien passé ? Un certain nombre de vaisseaux n'ont pas été pris en compte lors de nos tests internes, ce qui a conduit à ce que la verrière soit entièrement "grattée" et bloque la vue. Ce n'était pas notre intention - l'objectif était de limiter l'usure au bord de la vue. L'équipe chargée du contenu doit donc revenir en arrière et ajuster manuellement les cartes d'usure et les paramètres sur les anciens vaisseaux. Ce que nous ferons différemment à l'avenir Comme nous l'avons mentionné, certains vaisseaux présentent une usure trop importante dans des zones clés, ce qui sera corrigé au cas par cas. À l'avenir, en ce qui concerne les dommages physiques, il ne s'agira plus d'une caractéristique purement visuelle, mais d'une caractéristique ayant des conséquences sur la structure et le jeu. Accostage entre vaisseaux et stations Bien qu'elle ne fasse pas officiellement partie de la version Alpha 3.13, nous avons en fait lancé cette fonctionnalité avec le patch, bien qu'elle soit désactivée et prête à être mise en ligne avec la 3.13.1 (semaine de lancement d'Invictus). Nous avions initialement prévu d'intégrer les deux fonctions dans le même patch, mais nous avons décidé de ne pas l'intégrer officiellement, pour les mêmes raisons que celles qui nous ont poussés à ne pas intégrer l'amarrage Connie/Merlin, afin d'améliorer la qualité de la version. Tumbril Cyclone MT Le Cyclone MT a été un véhicule surprenant sur lequel nous avons travaillé pendant les périodes d'inactivité entre les sorties et qui a permis d'élargir notre gamme de véhicules terrestres, en particulier pour les théâtres de guerre. Le défi d'avoir une tourelle montée contrôlant à la fois les missiles et les armes a causé quelques problèmes lors de la phase de configuration, mais le MT fournit une puissance de feu supplémentaire intéressante à la gamme Cyclone au prix d'être le plus lent de la famille. Greycat ROC-DS Le ROC-DS est un véhicule qui a connu des difficultés lors de son développement et de sa sortie publique, ayant été conçu à l'origine pour être le véhicule principal de la famille. Cependant, en raison des délais de production, nous avons dû sortir le ROC bien avant le ROC-DS. L'objectif initial était de sortir les deux en même temps pour offrir des options plus claires aux joueurs, mais le décalage important entre les deux n'a fait qu'accroître les problèmes de perception concernant son rôle et son utilité. Bien que le ROC-DS ait bénéficié d'améliorations considérables au cours des phases Evocati et PTU, augmentant à la fois sa capacité et sa portée, ces objectifs n'ont pas été suffisamment communiqués au début du cycle de sortie, ce qui l'a fait souffrir plus que prévu. Le ROC-DS n'a jamais été censé être une nette amélioration du ROC ; c'est un complément permettant à deux joueurs de travailler ensemble dans des endroits plus exigeants et plus éloignés de la base. Il est actuellement en mauvaise position, mais les changements à venir dans le comportement de l'inventaire, le système de cargaison et les grottes lui permettront peut-être de retrouver la position que nous avions prévue pour lui. Si ce n'est pas le cas, nous étudierons d'autres changements pour améliorer son accueil. Pilier Live Todd Papy, directeur de Star Citizen Live EUPU : Sous-composants miniers Qu'est-ce qui s'est bien passé ? Nous avons continué à approfondir et à développer le gameplay de l'exploitation minière et nous avons mis en place les sous-composants sans trop de difficultés. Le processus de demande de test d'assurance qualité (QATR) s'est également bien déroulé, avec une excellente communication au sein de l'équipe. Qu'est-ce qui ne s'est pas bien passé ? La stabilité du développement du jeu était précaire, ce qui a entraîné des retards dans la mise à jour des builds avec les intégrations. Ce que nous ferons différemment à l'avenir L'équipe crée des QATR pour intégrer son travail au développement du jeu comme un processus habituel. Malheureusement, le service d'assurance qualité a été très occupé par les versions Alpha 3.13 et 3.13.1, qui étaient toutes deux importantes. Cela affecte actuellement l'efficacité du processus QATR, ce qui entraîne un retard important dans les intégrations de sprint des versions non à venir. Contenu de Mission Live : Livraisons sensibles au Quantum et livraisons multi-dépôts minutées Qu'est-ce qui s'est bien passé ? Tout s'est bien passé car nous avons utilisé des technologies existantes, dont une grande partie avait été créée pour la mission XenoThreat. Qu'est-ce qui ne s'est pas bien passé ? Certaines des boîtes ne se sont pas comportées comme prévu, ce qui s'est avéré être un problème avec le comportement des entités. Les minuteurs n'indiquaient pas le bon temps et la boîte explosait à deux minutes de la fin. Hurston n'est pas le meilleur endroit pour les missions de long vol à cause de la distribution des emplacements. Nous avons augmenté les gains mais nous allons continuer à les améliorer. Ce que nous ferons différemment à l'avenir Nous devons améliorer le transfert des comportements des entités et clarifier les responsabilités entre les équipes. Pilier du Cœur du Gameplay Richard Tyrer, directeur du jeu S42 FPS Armes montées Qu'est-ce qui a bien fonctionné ? Par sa nature même, Star Citizen est un jeu d'armes mixtes combinant le combat à pied, en véhicule et en vaisseau. Les armes montées s'intègrent directement dans cette combinaison en permettant aux joueurs à pied de se mesurer aux véhicules et aux petits vaisseaux. Nous avons déjà le lance-missiles Animus et le railgun Scourge, mais ils n'offrent qu'une faible résistance avant que vous ne soyez à court de munitions. Avec l'intention à long terme de créer des fermes et des avant-postes, nous voulions fournir au joueur et à l'IA des options supplémentaires pour défendre ces zones. Nous avons dû relever deux grands défis avec le canon monté : sa taille et le système de contrôle. Les plus attentifs d'entre vous auront probablement remarqué que le canon monté est une arme de vaisseau de taille 1, car nous avions besoin de ce type de puissance de feu. Si ces armes sont petites sur un vaisseau, elles sont énormes dans les mains des joueurs, ce qui nous a posé plusieurs problèmes. Tout d'abord, il occupait tout l'écran à la première personne, ce qui rendait la ligne de visée terrible, et ensuite, le point de pivot des armes de vaisseau n'était pas idéal pour un personnage essayant de viser vers le bas et de pivoter verticalement. Comme nous avions déjà une arme de vaisseau, nous avons pu l'intégrer rapidement dans l'éditeur, ce qui nous a permis d'itérer très tôt sur l'expérience à la première personne sans avoir à trop nous soucier des métriques. Cela a été une véritable aubaine car nous avons pu travailler sur le pivot de l'arme, ses angles de vue et les vues ADS tout en conservant la crédibilité d'une arme capable d'abattre un vaisseau. L'autre défi auquel nous avons été confrontés était le schéma de contrôle. Nous avons longuement débattu pour savoir si nous devions utiliser un schéma de contrôle plus centré sur les FPS ou quelque chose de plus proche d'une tourelle de vaisseau. Heureusement, nous avions prévu suffisamment de temps pour mettre en œuvre les deux schémas et y jouer pour voir lequel était le meilleur. Cela nous a permis d'affiner l'expérience et de livrer une bonne première itération. Nous avons également prévu à long terme d'essayer d'ajouter les options de contrôle supplémentaires aux écrans de menu afin que les joueurs puissent choisir ce qu'ils préfèrent. Qu'est-ce qui a moins bien fonctionné ? L'utilisation d'une arme de vaisseau préexistante nous a permis d'itérer très tôt et de régler les paramètres sans avoir à créer toute une série de nouvelles illustrations. Cela avait aussi l'avantage qu'à l'avenir, toute arme de vaisseau de taille 1 pourrait théoriquement être montée sur un support. Malheureusement, cela ne s'est pas passé aussi facilement que nous l'espérions, car les armes de vaisseau se montent par le haut plutôt que par le bas. Cela signifie que l'arme était montée à l'envers et avait beaucoup de géométrie supplémentaire qui bloquait la vue principale. Bien qu'il s'agisse d'un problème relativement facile à résoudre, cela signifie que toute nouvelle arme que nous souhaitons utiliser à l'avenir nécessitera des ajustements artistiques et des données supplémentaires pour la prendre en charge. Ce que nous ferons différemment à l'avenir Les armes montées sont une fonctionnalité qui nécessite l'intervention d'une équipe chargée du contenu (il ne s'agit pas d'une fonctionnalité systémique comme le saut ou le statut d'acteur). Bien que nous souhaitions toujours mettre les fonctionnalités entre les mains des joueurs le plus rapidement possible à des fins de test, je pense que son implémentation actuelle dans les PU ne sert pas vraiment à grand-chose. Avec le recul, je pense qu'il aurait été préférable de l'implémenter, de demander un feedback spécifique des PTU/Evocati, puis de la publier dans un patch ultérieur, une fois que les équipes de contenu auraient eu suffisamment de temps pour construire quelque chose autour de cette fonctionnalité. Pousser/tirer des chariots. Qu'est-ce qui a bien fonctionné ? La fonction de poussée/traction de chariot permet aux joueurs d'interagir avec un objet, tel qu'un chariot ou un bloc, et de le pousser ou le tirer dans la direction de leur choix (à condition qu'ils aient de la prise). Star Citizen étant un jeu de type "bac à sable" avec de multiples gravités et planètes, nous devions nous assurer que cette fonctionnalité était systémique afin qu'elle puisse fonctionner et s'adapter à différents poids et environnements. Nous voulions également que le chariot soit physiquement correct, les charges les plus lourdes étant plus difficiles à contrôler. L'équipe a travaillé directement avec les programmeurs de physique pour créer un modèle physiquement correct qui donne vraiment l'impression de pousser un chariot ou un bloc. Le personnage s'appuie sur des charges plus lourdes et les commandes donnent l'impression d'être lourdes et ancrées dans le sol. Qu'est-ce qui n'a pas bien fonctionné ? L'équipe s'est attachée à ce que le chariot soit bien ancré dans le monde et a construit une carte de test élaborée pour tester de multiples facettes de la fonctionnalité, notamment le chargement sur un vaisseau. Cela a mis en évidence un problème important. Un grand nombre de chariots construits au fil des ans avaient été conçus pour une métrique de caractère avec des roues relativement petites. Malheureusement, les vaisseaux ont tous des rampes différentes, certaines ayant des bords anguleux très durs et d'autres ne s'abaissant pas du tout pour toucher le sol. Cela signifie que de nombreux chariots ont eu du mal à monter les rampes des vaisseaux et, dans certains cas, n'ont pas pu franchir le bord de la rampe car il était trop large (pensez à essayer de pousser un chariot de supermarché sur un trottoir). Comme l'équipe Véhicules était déjà prévue pour le trimestre, nous n'avons pas pu offrir l'expérience complète du chariot. Ce que nous ferons différemment à l'avenir La fonction "pousser/tirer" des chariots a toujours été conçue pour servir deux objectifs : un mécanisme de puzzle et le chargement des marchandises. En tant que mécanisme d'énigme, la fonctionnalité fonctionne bien et permet aux concepteurs de commencer à créer des missions/espaces nouveaux et intéressants où les joueurs peuvent utiliser des chariots et des blocs pour accéder à des points de vue plus élevés. En tant que mécanisme de chargement de marchandises, il n'est pas à la hauteur en raison des limitations des roues et de la taille des rampes des vaisseaux. À l'avenir, nous développerons un chariot aéroglisseur qui atténuera une grande partie de nos problèmes et qui s'appuiera sur les chariots plus traditionnels pour les zones d'atterrissage et les missions spécifiques. Gameplay et services systémiques Tony Zurovec, PU Game Director Interface utilisateur de la réputation Qu'est-ce qui a bien marché ? Dans le cadre de l'Alpha 3.13, nous avons été en mesure de publier l'interface utilisateur de la réputation, donnant aux joueurs une représentation visuelle et un contexte pour notre version initiale T0 du système de réputation au quatrième trimestre 2020. Pour cette version, nous avions relié la réputation aux missions de chasse à la prime (et à quelques autres), mais les joueurs n'avaient aucune visibilité sur les raisons pour lesquelles la progression de leur mission changeait. Nous avons également institué la première passe de récompense des joueurs en fonction de leur progression de réputation. Avec l'interface utilisateur maintenant en place, les joueurs ont beaucoup plus de clarté sur leur statut avec les organisations et les donneurs de mission. Le développement et le lancement de cette fonctionnalité se sont déroulés sans heurts pour l'équipe. Les rapports d'analyse que nous avons reçus ont montré des résultats incroyablement positifs avec les joueurs dans la version Alpha 3.13, ce qui a entraîné un taux d'engagement plus élevé dans les missions de chasse à la prime. Qu'est-ce qui ne s'est pas bien passé ? Il y a eu un contretemps inattendu avec certaines modifications du service de réputation qui n'ont pas été bien communiquées à l'équipe chargée des fonctionnalités. Il en a résulté quelques corrections urgentes qui ont dû être effectuées très peu de temps avant la sortie de la version Alpha 3.13. De plus, nous n'avons pas encore converti l'intégralité du contenu de nos missions au nouveau système, et nous n'avons pas eu le temps de remanier les comportements des donneurs de mission pour qu'ils soient aussi réactifs aux compteurs d'affinité et de fiabilité. Bien qu'il s'agisse d'un effort continu et que les joueurs doivent s'attendre à des progrès constants, il faudra malheureusement du temps pour passer en revue l'ensemble de nos missions et remanier les comportements des donneurs de mission. Ce que nous ferons différemment à l'avenir ? Nous nous efforcerons d'améliorer notre communication globale sur les fonctionnalités à l'avenir, notamment pour celles qui impliquent des services ou un soutien externe de l'équipe des fonctionnalités. Les initiatives inter-équipes ont toujours connu un certain niveau de rupture de communication en raison de notre distribution mondiale, et nous cherchons donc toujours à améliorer ce processus. Plus précisément, nous essayons de créer davantage de documents de conception technique (TDD) avant de lancer ces initiatives plus importantes. Cela devrait contribuer à une prise de conscience mondiale, puisque tous les groupes concernés sont tenus de fournir un retour sur les TDD au cours de ce processus. En outre, avec le système maintenant en place et notre deuxième système stellaire à l'horizon une fois que le maillage des serveurs sera en ligne, nous avons des discussions de conception en cours sur la façon dont nous allons structurer les organisations au sein de l'univers pour les cinq premiers systèmes. Ces discussions portent notamment sur l'expérience des nouveaux joueurs et leur emplacement de départ, sur la façon dont les joueurs progressent dans un seul système et sur la façon dont les grandes organisations influenceront le contenu de plusieurs systèmes. Cela nous permet également de définir le gameplay de chacun des principaux types de mission, le plan actuel prévoyant d'associer chaque type de mission aux pistes de réputation au sein des organisations. Tout au long de ce processus, nous avons fait des progrès significatifs vers (ce que nous pensons) être la version/vision initiale de la façon dont cette mécanique de progression majeure affectera l'expérience globale du joueur. Bien que nous devions encore obtenir l'approbation finale, nous pensons que cela correspond à la façon dont la réputation a été présentée au public et nous sommes impatients de faire avancer les choses. Semaine de Lancement d'Invictus Qu'est-ce qui s'est bien passé ? L'exposition associée à la Semaine de lancement Invictus s'est déroulée sans problème. Il s'agit d'un processus que nous avons effectué plusieurs fois jusqu'à présent, donc la mise en place d'un nouvel événement expo est une procédure connue. D'un autre côté, l'équipe de l'USPU a contribué à la sortie de certaines fonctionnalités supplémentaires d'Invictus, qui élargissent notre boîte à outils de service de mission dynamique. C'est la première fois que nous avons pu modifier l'inventaire d'une boutique de façon dynamique en fonction des événements du jeu (ce que nous appelons les Modificateurs de boutique dynamiques). Ce système sera finalement lié/contrôlé par l'outil Quanta dont vous avez pu nous voir parler dans notre dernière présentation vidéo. Nous pouvons également l'utiliser non seulement pour ajouter de nouveaux articles spécifiques à un événement, mais aussi pour modifier la consommation ou le réapprovisionnement de ces produits par une boutique, ce qui modifie le prix global de l'article. Ces changements sont limités dans le temps pendant l'événement, ce qui nous permet de modifier le climat économique d'autant de magasins que nous le souhaitons pour obtenir les résultats souhaités. Nous avons également ajouté quelque chose de connexe qui nous aidera éventuellement à développer la profession de cargo. Nous les appelons "déclencheurs de seuil de prix". Ils sont destinés à nous permettre de déclencher des missions en fonction des inventaires des boutiques qui atteignent des niveaux désignés. Cependant, comme première étape vers la création de missions, nous les avons utilisés pour donner aux joueurs un aperçu précieux de ce qui est actuellement demandé (à acheter ou à vendre) à un endroit donné pendant la durée de l'événement. Cela a été fait temporairement par le biais des entrées du journal qui sont générées par le système de mission. Maintenant que ces éléments sont en place, la prochaine étape consistera à envoyer des demandes à l'échelle du jeu (à la distance de notre choix dans un système stellaire ou entre des systèmes), dans le cadre de notre évolution vers un univers piloté par les Quanta. Bien que le travail de visualisation des informations de la boutique dans le journal soit une solution temporaire, toutes les fonctionnalités sous-jacentes sont implémentées comme prévu, il y aura donc très peu de travail à faire une fois que nous aurons refait l'interface du gestionnaire de mission ou ajouté un certain niveau d'informations économiques ailleurs dans le jeu (le calendrier de cet ajout est encore à déterminer). Enfin, tout cela étant dit, les joueurs ont apprécié le fait que les boutiques exposent des objets et/ou changent les prix de façon dynamique pendant l'événement. Nous avons hâte de développer ce système, car c'est vraiment l'un des principaux fondements des systèmes économiques et de fret. Qu'est-ce qui n'a pas bien fonctionné ? Certains changements apportés au système de train d'atterrissage des vaisseaux ont entraîné des irrégularités dans les valeurs de compression par défaut ou générées. Cela a entraîné de nombreux tests fastidieux de notre part pour nous assurer que tout était placé comme prévu, afin de pouvoir confirmer que tout ce que nous pouvions voir était un problème véritable et non un simple problème de placement. En ce qui concerne les modificateurs d'atelier dynamiques, le plus gros facteur de stress a été le fait que certaines fonctionnalités sont arrivées assez tard dans le processus, ce qui a laissé très peu de temps pour les tester dans le PTU. Si cette fonctionnalité n'avait pas très bien fonctionné lorsque nous l'avons finalement obtenue, le problème aurait été plus important. L'événement Ninetails Lockdown (censé sortir avec l'Alpha 3.13, puis Invictus, et enfin l'Alpha 3.14), était également en concurrence pour la ressource AQ pendant cette période, ce qui est l'une des principales raisons pour lesquelles il a été repoussé à l'Alpha 3.14. La priorité devant rester sur Invictus, nous n'avons eu d'autre choix que de sacrifier Ninetails, ce qui a été une déception en interne. Le flux de travail pour la mise en place des modificateurs de boutique et des déclencheurs de seuil de prix n'était pas non plus propice à la réalisation rapide de changements à grande échelle. En outre, la situation est actuellement un peu confuse car, historiquement, nous utilisons le contexte d'"achat" et de "vente" du point de vue du joueur, mais cela a été en quelque sorte inversé dans le contexte des déclencheurs de seuil. Cela entraîne évidemment une grande confusion lors de la configuration de ces derniers et doit absolument être corrigé avant d'aller plus loin avec cette fonctionnalité. En outre, tout en réglant les déclencheurs de seuil, nous avions un fort désir de modifier les entrées de la boutique que nous n'avions pas la possibilité de modifier à partir de l'interface de modification de la boutique dans Subsumption, y compris le décalage du prix de base, l'inventaire actuel, et quelques autres. Nous avons contourné ce problème en ajoutant des objets à l'inventaire pour les configurer, PUIS en changeant leur contexte d'achat à vente lorsque les marchandises étaient disponibles pour être collectées/achetées ailleurs dans l'univers. Bien qu'il s'agisse d'une tactique courante pour les concepteurs lorsque les outils ne font pas ce qu'ils veulent, elle est généralement désapprouvée parce qu'elle ajoute des dettes techniques qu'il faudra corriger plus tard. Ce que nous ferons différemment à l'avenir J'aimerais intégrer au moteur des fonctions de débogage supplémentaires qui nous permettraient de résoudre rapidement les problèmes de compression des trains d'atterrissage. Pour l'instant, nous avons déjà ajouté quelques nouvelles méthodes de débogage dans le jeu depuis notre dernière expo. Cependant, ces anomalies pourraient potentiellement être plus faciles à repérer avec un retour d'information supplémentaire sur le débogage. À l'approche de la prochaine expo, j'aimerais consacrer du temps à faire en sorte que ces problèmes soient facilement identifiés et résolus par des solutions basées sur les données. Nous aimerions voir une meilleure coordination entre l'AQ et les équipes de développement qui nécessitent une implication à grande échelle de l'AQ, comme Invictus et Ninetails. Nous avons certainement vu et reconnu plusieurs des points douloureux que cela a causé, mais cela va continuer à se produire à mesure que nous faisons plus de ces événements, donc nous devrons resserrer ce flux de travail à l'avenir. Idéalement, nous devrions essayer d'obtenir la livraison de toutes les fonctionnalités de jeu et des services connexes bien avant toute date de livraison potentielle. Par exemple, bien avant de brancher le prochain flux de diffusion et certainement avant de passer à une phase de PTU. J'aimerais également voir moins de développement de fonctionnalités dans le flux de sortie à mesure que nous avançons. Bien que cela doive encore être programmé, j'aimerais que la présentation de l'interface utilisateur des entrées de journal soit améliorée dans les futures révisions, car elles concernent les produits de base qui sont demandés. Il faut les classer par zone d'atterrissage et ensuite, dans chaque zone d'atterrissage, montrer ce que vous pouvez acheter et ce que vous pouvez vendre. La solution idéale serait d'avoir un type d'information économique disponible quelque part comme la carte des étoiles, ou une application séparée, mais comme mentionné ci-dessus, ce travail doit actuellement être programmé, donc tout ajout est à déterminer. Fonctionnalités des Missions Qu'est-ce qui s'est bien passé ? XenoThreat et Fleet Week ont été deux événements majeurs sur lesquels l'équipe chargée des missions a travaillé au cours du premier trimestre 2021. La collaboration entre nous et les autres départements sur ces deux initiatives, en particulier l'AQ, a été plus forte que jamais, et nous pensons que cela se voit dans le produit fini. XenoThreat avait besoin d'un peu plus de temps pour s'équilibrer et aplanir les derniers bogues et, heureusement, nous avons eu droit à ce délai, même si l'attente initiale était qu'il sorte pour les fêtes de fin d'année. Heureusement, nous avons pu ajouter du contenu dans les grottes. Cela ne faisait même pas partie de notre liste de livrables prévus pour le trimestre, mais il nous a semblé dommage de sortir de nouvelles entrées de grottes sans que quelque chose y soit présent. Nous avons également ajouté beaucoup plus de lieux de mission dans l'anneau d'astéroïdes Yela. Notre équipe a pu ajouter une nouvelle interface graphique de débogage, qui s'avère désormais précieuse pour identifier les problèmes à un rythme beaucoup plus rapide. Et la création de nouvelles missions de livraison s'est déroulée rapidement et en douceur, notamment grâce à des modules de mission bien établis et à la réutilisation d'entités de XenoThreat. Qu'est-ce qui a moins bien fonctionné ? XenoThreat, comme nous l'avons mentionné, n'a pas atteint la date de sortie prévue. C'est évidemment regrettable mais, étant donné l'ampleur de ce que nous voulions réaliser avec cet événement, nous avons estimé que c'était compréhensible et, heureusement, nous avons pu lui donner le temps nécessaire pour le peaufiner jusqu'à ce qu'il soit prêt. La création et le maintien d'entités uniques ont également posé problème. Par exemple, les boîtes sensibles au voyage quantique étaient un mélange du travail de plusieurs équipes, donc en ce qui concerne les bugs, il était souvent difficile d'avoir de l'avance. La maintenance continue de ces boîtes pourrait désormais poser problème, car il n'y a pas vraiment de développeur défini pour les gérer et les entretenir. Les vaisseaux parasites ont également causé des problèmes au niveau du système juridique qui n'ont été repérés qu'après la sortie de la version Alpha 3.13. Ce que nous ferons différemment à l'avenir Nous ferons en sorte que l'équipe soit incluse dans toutes les fonctionnalités susceptibles d'affecter ou de nécessiter le soutien du système juridique, afin d'essayer d'anticiper et, espérons-le, de minimiser les problèmes imprévus pour les initiatives futures. Services et outils systémiques Qu'est-ce qui a bien fonctionné ? Les ressources supplémentaires des équipes backend ont permis de soulager immédiatement la charge de travail de l'équipe Systemic Services & Tools (SST). Le SuperCache a été déployé et le travail a pu commencer sur plusieurs initiatives à plus long terme visant à intégrer Quantum dans davantage de services. La présentation publique s'est bien déroulée et a été accueillie très positivement. La technologie que nous avons investie dans les écrans de présentation sera utilisée à l'avenir pour démontrer d'autres concepts de haut niveau. Quasar a été déployé. Il s'agit de l'outil de mission dynamique présenté dans la vidéo de mise à jour du SST publiée en avril. Le développement de Quasar a été simple grâce au travail effectué avec Odin l'année dernière, qui a permis de réaliser la plupart des travaux de base nécessaires pour se connecter aux services en direct et aux instances DGS. À l'avenir, l'outil Quasar fournira une plate-forme par laquelle le contenu dynamique des missions pourra être instancié via Quantum. Le travail sur le service ATC s'est poursuivi et la SST a consacré du temps au développement d'un décompresseur de Conteneur d'Objet autonome pour permettre l'injection de points de données spécifiques dans les assets sans avoir à réexporter manuellement chaque Conteneur d'Objet via l'éditeur. Ce travail permettra de débloquer plusieurs autres zones critiques pour la manipulation des données nécessaires aux futurs projets de la SST. Qu'est-ce qui n'a pas marché ? Un nouveau service d'IA à haute vitesse était nécessaire pour cartographier les positions en direct des PNJs créés par les missions, ce qui s'est avéré être d'une complexité trompeuse. Ce nouveau service a nécessité le travail de plusieurs équipes et piliers, ce qui a entraîné des retards et des difficultés dans les tests. De nombreuses ressources de notre équipe continuent d'être absorbées par la résolution de bugs qui ne relèvent finalement pas de notre sphère de responsabilité. Ce que nous ferons différemment à l'avenir Les futures présentations seront beaucoup plus simples en termes de contenu et nous avons investi dans des outils de visualisation pour pouvoir montrer rapidement et facilement des concepts de haut niveau sur la Starmap. Nous avons identifié les problèmes à l'origine des retards dans les nouveaux services, comme le service d'IA à haut débit, et nous sommes désormais mieux à même de gérer les initiatives inter-équipes de ce type à l'avenir. Les bases de Quantum étant posées, nous allons pouvoir nous concentrer sur l'intégration d'autres services. Nous sommes désormais mieux à même d'identifier les problèmes qui ne relèvent pas de la responsabilité de notre équipe et nous prévoyons de réacheminer ces problèmes vers les équipes appropriées, ce qui permettra aux membres de notre équipe de gagner le temps dont ils ont besoin pour développer les services. Lieux Ian Leyland, directeur artistique de Star Citizen Qu'est-ce qui s'est bien passé ? La semaine de lancement d'Invictus au Tobin Convention Centre a été fantastique à voir, tout comme les nouveaux modules d'amarrage des stations spatiales et les docks militaires pour l'événement. En dehors de ce que nous avons publié dans l'Alpha 3.13, cela a permis à l'équipe de se concentrer sur la réalisation de progrès solides sur les futurs sites du jeu. Qu'est-ce qui ne s'est pas bien passé ? La fonction d'accostage a provoqué des allers-retours entre les différentes équipes concernées, ce qui a réduit l'efficacité. La fonction de poussée/traction des chariots a créé de nombreux bugs pour les équipes, qui auraient pu être réduits également. Ce que nous ferons différemment à l'avenir En interne, nous suivons un processus de validation des fonctionnalités et des emplacements. Dans le cas d'une fonctionnalité comme l'amarrage, les équipes ont été très pressées de construire la fonctionnalité et de créer les emplacements en même temps. À l'avenir, pour réduire l'inefficacité que cela crée, nous chercherons à avoir un tampon plus important entre la création d'une fonctionnalité et la création de l'emplacement qui l'utilise. Trad : @Maarkreidi SwissStarships.org

XenoThreat Postmortem Le 4 février 2021, nous avons lancé l'Alpha 3.12.1 : Assaut sur Stanton, qui a introduit le premier événement dynamique dans l'univers de Star Citizen. Ce qui suit est un post-mortem des développeurs principaux eux-mêmes, détaillant ce qui a été livré et leurs pensées sur la façon dont cela s'est passé. Mission XenoThreat Qu'est-ce qui a bien fonctionné ? La conception initiale de XenoThreat a été élaborée par Luke Pressley et moi-même (Tony Z). Nous avons tous deux une bonne connaissance de l'état actuel du jeu et, après quelques itérations, le projet final nous a semblé solide et réaliste. Il y avait une bonne quantité de documentation sur le déroulement de l'événement, y compris une ventilation de haut niveau sur la façon de le jouer, les ennemis à faire apparaître, le fonctionnement des récompenses et la façon de tester les changements d'écran. Cette documentation a été conservée tout au long du développement et a servi de référence rapide pour l'assurance qualité et les autres services. Après des débuts quelque peu maladroits, la boucle de rétroaction de XenoThreat a fini par devenir une machine bien huilée. Le processus de collecte des commentaires du PTU par l'intermédiaire de l'équipe d'expérience des joueurs et des rapports de commentaires, l'enregistrement des bogues avec les étiquettes appropriées, la révision et le triage des nouveaux bogues chaque jour pour obtenir des appels prioritaires ont fini par être un processus très propre. Plus tard dans le processus, nous avons demandé à l'équipe d'assurance qualité de saisir les tâches de suivi dans JIRA dès l'arrivée du rapport de retour d'expérience au lieu d'attendre les reproductions internes. Cela a permis une itération plus rapide, de sorte que les développeurs ont parfois été en mesure de traiter le retour d'information avant même que l'AQ n'ait eu l'occasion de saisir un bogue approprié. En ce qui concerne l'événement lui-même, un certain nombre de fonctionnalités ont été accueillies positivement. Le partage des revenus, la distribution sociale des tâches et des types de jeu, et la nature coopérative du déchargement des cargaisons ont été immensément populaires auprès de la communauté. En soi, cela a été une grande partie de l'accueil positif. De plus, lorsque tout fonctionnait bien, l'aspect et le look du jeu étaient magnifiques. Nous sommes très satisfaits de l'équilibre entre la conception, les effets visuels et les effets sonores. Nous avons créé une équipe de choc chargée de rendre le combat agréable, ce qui a rendu l'itération rapide plus viable. La narration qui accompagnait la sortie était également assez cool, et le commandant XenoThreat était efficace et intimidant. Parmi les autres aspects de l'événement que nous avons trouvés réussis, citons les importantes possibilités de revenus en jeu pour les joueurs (toutes les phases), les pirates FPS peuplant les sites d'épaves (phase 2) et le style de paiement axé sur l'équipe (phase 2). De nombreux joueurs ont apprécié le fait d'être très bien payés pour avoir participé à toutes les phases de l'événement, ce qui les a incités à continuer à jouer et à rejouer. Bien qu'il y ait eu quelques problèmes avec les personnages FPS AI, leur présence générale a rendu la visite des sites d'épaves plus intéressante pour les joueurs et a ajouté au style varié du jeu. Il y a eu quelques détracteurs qui voulaient plus de revenus par boîte dans un système de paiement plus individualisé, mais il y en a beaucoup plus qui ont aimé le style de paiement orienté vers l'équipe, beaucoup disant que cela encourageait la coopération. Même s'il est regrettable que nous n'ayons pas pu le lancer à la fin de l'année, la décision de reporter l'événement à 2021 lui a été très bénéfique. La différence entre ce que nous aurions publié avant Noël et ce que nous avons publié est le jour et la nuit en ce qui concerne la stabilité, les performances et la qualité de vie. L'équipe de direction a pris une excellente décision. Qu'est-ce qui ne s'est pas si bien passé ? Les événements dynamiques sont un énorme exploit de gestion, car leur déroulement dépend de plusieurs départements. Ils exigent qu'un responsable ayant une vision claire et une connaissance de tous les aspects soit présent pour répondre aux questions et aux commentaires. Afin d'accorder à XenoThreat l'attention qu'elle exigeait et méritait, de nombreuses personnes ont dû jongler avec les responsabilités. Ce type d'événement peut facilement entraîner le glissement d'autres responsabilités. Si des événements de cette ampleur sont nécessaires plusieurs fois par an, ils ne peuvent pas simplement être absorbés par une équipe existante, car ses autres responsabilités peuvent en pâtir. Le dialogue a apporté beaucoup à la mission, mais sa mise en place a été une entreprise de grande envergure, avec de longs délais pour le livrer ainsi que pour les déclencheurs de la mission. Il n'y a pas eu assez de temps pour intégrer les lignes réelles dans la mission pleinement fonctionnelle et itérer sur les changements appropriés. Nous avons intégré des lignes de remplacement plus tôt, mais comme la fonction qui les a déclenchées n'était pas encore totalement opérationnelle et que la mission n'était pas complètement terminée, il a été difficile de les examiner in situ. Dans le passé, nous avons utilisé des programmes comme Visio pour créer des flux de lignes qui se déclenchent quand et dans quel ordre. Nous n'avons pas eu le temps de le faire pour XenoThreat, le dialogue a donc été implémenté directement dans la logique. Cela a rendu les processus plus ad hoc, et une planification supplémentaire du diagramme de flux aurait facilité le processus de conception de la logique pour soutenir les déclencheurs de dialogue. De manière surprenante, une grande partie du déclenchement du dialogue a dû être fortement intégré dans la logique de la mission pour qu'il soit déclenché au bon moment, ce qui signifie que les efforts pour revoir le dialogue dans son contexte n'étaient pas réalistes même si tout avait fonctionné et que la mission s'était terminée lorsque les lignes de remplacement avaient été délivrées. Je pense que nous devons être plus attentifs aux attentes concernant l'examen du dialogue dans le mixage lorsque ce mixage n'est réellement utilisé que pendant les tests AQ, PTU et Evocati. Plus de temps consacré au prototypage aurait été extrêmement bénéfique, en particulier pour les épaves du Starfarer, car les exigences de la fonctionnalité ont changé au milieu du développement. Des demandes ont été faites pour ajouter la gravité aux intérieurs et pour ajouter la capacité de ciblage et le support de l'interface utilisateur. Nous avons fini par livrer une version des épaves du Starfarer de moins que prévu en raison de problèmes liés à la gravité. Un plus grand nombre de prototypes nous aurait également permis de mieux comprendre l'équilibre nécessaire pour arriver au point où nous savions que le combat fonctionnait comme prévu. Il est arrivé que le retour d'information soit une fausse piste, par exemple que les performances du serveur soient en cause plutôt que de réels problèmes d'équilibre. Il était donc parfois difficile de déterminer où se situaient les problèmes sans procéder à des tests approfondis pour les vérifier. Les tests internes étaient parfois particulièrement difficiles en raison de la difficulté de reproduction, de l'ampleur des étapes de reproduction, du grand nombre de testeurs requis et des différences de fuseaux horaires. Parfois, les développeurs obtenaient des bogues sans étapes de reproduction qu'ils étaient incapables de reproduire en interne, tandis que d'autres fois, les étapes de reproduction étaient incroyablement longues et prenaient énormément de temps à tester. Nous devons être en mesure de tester la mission plus facilement afin de mieux comprendre son état à tout moment. Plus tard dans le développement, nous avons ajouté de nouveaux outils pour contourner certains aspects de la mission et modifier les paramètres internes afin d'accélérer le processus de test. Cela aurait dû être fait plus tôt. Notre communauté nous a fait part de nombreux commentaires sur des aspects de l'événement qui auraient pu être améliorés. Les joueurs n'ont pas été informés de la durée de la phase 3 et ont été surpris par sa fin. Une meilleure information pour gérer les attentes aurait amélioré la situation. La terminologie de l'événement concernant les phases était parfois confuse, avec des différences entre la façon dont les choses étaient désignées en interne et ce qui était décrit aux backers sur les fils de commentaires de Spectrum. Nous savions dès le départ que la performance serait un facteur limitant et que nous ne serions pas en mesure de fournir un nombre suffisant d'ennemis pour générer le niveau de défi que nous souhaitions dans certaines situations. Par conséquent, certains joueurs ont trouvé l'Idris beaucoup trop facile à tuer, ce qui a considérablement fait dérailler la phase 3. Avec les bons chargements (torpilles Typhoon), un seul Retaliator pouvait faire tomber les boucliers d'un Idris et plusieurs joueurs pouvaient le tuer en quelques minutes. En raison de la rapidité de la fin de la mission et de la longueur du délai de récupération, les joueurs qui souhaitaient effectuer cette mission avaient du mal à trouver un serveur où elle était active et, le cas échéant, à y arriver à temps pour y participer. De plus, l'Idris n'offrait presque aucune menace aux joueurs, même s'ils ne le tuaient pas rapidement, il agissait surtout comme une éponge à balles, de nombreux joueurs ayant mentionné qu'il restait immobile et tirait en continu. La détection de l'hostilité et la détermination du CrimeStat sont encore trop simplistes, sans modificateur pour les participants à la mission partagée si le vaisseau touché est ciblé ou sans aucun lien avec le ciblage. Avec autant de vaisseaux à proximité les uns des autres dans un scénario complexe, les tirs amis étaient fréquents et aboutissaient souvent à ce que les joueurs obtiennent accidentellement un CrimeStat, soient écartés de la mission et envoyés en prison à leur mort. Nous voulions laisser aux joueurs la liberté totale de choisir leur camp, mais le temps nous manquait. Cela a causé des problèmes lorsque, inévitablement, de nombreux joueurs orientés PVP ont pris l'initiative d'attaquer les joueurs qui tentaient l'événement. Ce phénomène a été le plus répandu lors de la phase 2. Mais comme l'événement ne le permettait pas, les participants à la mission avaient peu de moyens de l'empêcher ou de le contrer, ce qui a donné lieu à des opinions très tranchées de part et d'autre. La plupart des joueurs ont simplement quitté ces serveurs pour en trouver un sans PVP. De notre côté, nous réfléchissons à la façon dont nous pouvons soutenir les deux styles de jeu. De nombreux joueurs ont fait état d'un mauvais framerate client pendant les deux phases de combat. En outre, de nombreux rapports ont fait état d'actifs essentiels à la mission se chargeant lentement, notamment les sites d'épaves, les vaisseaux de ravitaillement, les chasseurs de la XenoThreat et l'IA du FPS (qui se chargeait parfois après que les joueurs aient commencé à vider le cargo). Contrairement à la phase 2, la phase 3 s'est concentrée sur les combats de vaisseaux. Cela signifie que les autres styles de jeu, tels que la récupération et le combat FPS, n'ont pas pu contribuer, ce qui a provoqué une consternation et une frustration considérables chez certains joueurs. Les joueurs disposent de systèmes d'identification d'amis ou d'ennemis (IFF) très limités et superficiels, le rouge représentant soit l'hostilité directe du joueur, soit une personne ayant un CrimeStat, et le bleu représentant tous les autres. Il n'y a aucun moyen pour les joueurs de savoir qui participe à la mission, qui est agressif ou hostile aux autres (sans réseau de communication), et souvent qui est dans leur groupe car les marqueurs de groupe ne sont pas toujours fiables. C'est à pied dans l'épave que cela s'est avéré le plus critique, car aucune identification n'était utilisée et les PNJ hostiles, les joueurs hostiles et les joueurs coopératifs de la mission apparaissaient tous de manière identique. Les chasseurs de l'IA se déplaçaient, se déformaient, se téléportaient, volaient de manière erratique et n'offraient généralement aucune menace, les joueurs les qualifiant fréquemment de chair à canon. De plus, les joueurs ont souvent mentionné à quel point leur nombre semblait faible, ce qui limitait le sentiment de danger. Les chasseurs de l'IA semblaient également ne pas avoir de comportements agressifs, comme cibler les cargos ou les bombardiers, et ignoraient parfois les dégâts qu'ils subissaient. Bien que certains joueurs aient déclaré que le jeu était bien meilleur que les patchs précédents, l'EVA reste un problème, en particulier lors des transitions entre les grilles physiques (entrée et sortie d'un vaisseau), les joueurs subissant fréquemment des dégâts ou mourant même. Des transitions malheureuses où les joueurs tombent et/ou subissent des dégâts ont été signalées, de même que des mouvements en vol peu soignés et imprécis, et des pertes de contrôle maladroites lors de chocs avec des objets. Le spam de torpilles a dominé la phase 3 et a été encouragé par les gains massifs en cas de succès. Les Idris n'ont souvent pas réussi à les contrer correctement et la nature simpliste de leur utilisation (verrouillage, lancement, terminé) a fortement contribué au sentiment de "facilité" de la phase 3. Les systèmes de droit et d'hostilité nécessitent un travail important, notamment en ce qui concerne les tirs amis et les dommages accidentels. Cela inclut comment et pourquoi nous appliquons un CrimeStat, comment les accusations sont portées, comment l'hostilité est déterminée, et une discussion approfondie sur la façon de mieux identifier les amis et les ennemis. Cela devrait inclure une distinction et des marqueurs pour les joueurs de la mission, les joueurs de la contre-mission (si approprié), les joueurs agressifs, les joueurs hostiles, les criminels, et les factions le cas échéant. Ce que nous ferons différemment pour nous améliorer à l'avenir : Il y a plusieurs problèmes mentionnés ci-dessus dont nous discutons activement et que nous prévoyons d'aborder pour les événements futurs. Au cours des semaines à venir, nous examinerons tour à tour chacun de ces commentaires et déterminerons comment y remédier, quelles équipes y travailleront et où ils s'inscriront dans le calendrier. Les questions relatives aux performances, à l'IA, à la conception du PVP et au système de lois sont au premier plan de nos préoccupations pour que ces événements soient aussi bons que possible. Tony Zurovec, Persistent Universe Game Director Équipe AI Qu'est-ce qui s'est bien passé ? XenoThreat a été une excellente occasion de fixer un objectif d'entreprise pour plusieurs équipes. C'est courant lorsque nous établissons des objectifs communs spécifiques (étapes ou versions spécifiques) et cela rassemble généralement plusieurs départements. Pour ce type d'événement, nous nous appuyons beaucoup sur d'autres équipes. Par exemple, l'équipe Mission PU a été extrêmement réactive et nous avions constamment une personne clé à contacter au sujet du déroulement de la mission. Cela nous a permis de comprendre les objectifs qu'ils essayaient d'atteindre, d'ajuster la logique et de suggérer différentes façons d'aborder les problèmes chaque fois que nous le pouvions. La collaboration a été fantastique. Ces événements nous donnent également l'occasion d'utiliser de nouvelles fonctionnalités et d'améliorer celles qui existent déjà. Par exemple, nous avons pu faire la première passe sur le combat de vaisseaux capitaux, exposer la nouvelle affectation pour demander l'amarrage, et améliorer le flux actuel du mastergraph pour le combat de pilotes. Au cours de l'événement, nous avons spécifiquement examiné les comportements de l'IA et l'expérience du joueur. Le fait que tous les directeurs concernés aient participé à l'examen nous a permis de recueillir rapidement des commentaires et de discuter de ce qui aurait pu être fait dans le délai imparti. Ce qui n'a pas si bien marché L'idée derrière XenoThreat était d'utiliser un délai spécifique attribué à la mission pour atteindre des objectifs très précis. L'intention était de ne pas surcharger l'équipe d'IA de demandes et de prendre des décisions intelligentes en commençant le développement du combat des vaisseaux capitaux. Par exemple, se concentrer sur l'amélioration de la distribution de la sélection des cibles parmi les opérateurs de sièges de vaisseaux multiples ou implémenter la possibilité d'utiliser le railgun. Malheureusement, dans le calendrier général, la quantité de travail nécessaire pour itérer sur le fait de rendre le jeu amusant signifiait que la prise en compte des cas limites n'était pas entièrement prise en compte et cela a affecté la charge de travail de l'équipe. Au cours du développement, nous nous sommes également retrouvés dans des situations où nous avons supposé que les bugs étaient dus au code de l'IA ou aux performances. Or, il s'est avéré qu'il s'agissait d'une combinaison d'autres éléments qui auraient pu être traités plus rapidement s'ils avaient été portés à notre attention. Une meilleure diligence raisonnable lors du test du flux peut éviter une grande partie de cette confusion. Tenter d'améliorer les performances tout en corrigeant les bogues a rendu la dernière partie du développement un peu mouvementée, mais nous nous y attendions, nous n'avons donc pas été si surpris. Francesco Roccucci, AI Director Équipe chargée de l'expérience des véhicules Qu'est-ce qui a bien fonctionné ? Le travail de l'équipe chargée de l'expérience des véhicules sur XenoThreat s'est principalement concentré sur l'équilibrage de l'expérience de vol des vaisseaux capitaux avec les armes qu'ils utilisent, mais aussi avec les armes qui seraient utilisées contre eux par des vaisseaux comme l'Eclipse et le Retaliator. Le réglage de l'équilibre de vol avec l'Idris et le Javelin a consisté à permettre à l'IA de positionner correctement chaque vaisseau pour attaquer et défendre. Nous avons fait quelques compromis en cours de route, de sorte que lorsque ces vaisseaux seront entre les mains des joueurs, ils seront légèrement différents. Mais à l'époque, c'était la bonne décision à prendre jusqu'à ce que nous ayons amélioré le comportement de certaines tourelles pour qu'elles ne dépendent plus autant du mouvement des vaisseaux. Les changements les plus importants que nous avons apportés concernent la vitesse et la puissance des armes. L'ensemble de l'événement nous a poussés à ajouter des armes plus puissantes, notamment l'introduction du railgun dans le PU, mais nous voulions équilibrer cela avec la vitesse. Plus une arme est puissante, plus elle se déplace lentement, à l'exception du railgun que nous avons utilisé pour repousser les limites de la vitesse dans Star Citizen. Nous voulions vraiment que le railgun soit redouté, en utilisant les visuels pour créer une anticipation de ce qui allait arriver et donner aux joueurs la possibilité de l'éviter si l'Idris réussissait à les aligner, et pour le moment, il a tiré pour être spécial. Le point culminant de XenoThreat pour l'équipe chargée de l'expérience des véhicules a été de voir les différentes équipes se réunir pour offrir ce qui était un événement fantastique, non seulement pour y participer mais aussi pour le regarder. Nous avons travaillé en étroite collaboration avec les équipes chargées des effets sonores et visuels pour nous assurer que l'équilibre que nous avions mis en place se reflétait fidèlement dans l'apparence et le son. Les développeurs ont passé de nombreuses soirées à regarder les différents streams que les backers avaient mis en place, partageant chaque matin les meilleurs moments avec le reste de l'équipe. Qu'est-ce qui ne s'est pas bien passé ? Du point de vue de l'équilibre, la principale difficulté que nous avons rencontrée avec XenoThreat était d'obtenir des résultats cohérents et reproductibles pour évaluer l'équilibre dans une bataille réelle, car l'événement dépendait beaucoup des performances du jeu. Au fur et à mesure du développement, les performances se sont améliorées, mais ce n'est qu'au cours des deux dernières semaines avant la sortie que nous sommes parvenus à un point où, si tout se passait bien, l'événement se déroulait du début à la fin comme prévu. Mais d'un point de vue positif, les problèmes de performance que nous avons rencontrés pendant le développement ont mis en évidence des problèmes spécifiques avec les armes et les boucliers que nous avons pu améliorer de manière drastique dans des scénarios moins performants. Ils ont également mis en évidence certaines lacunes dans l'équilibre du jeu, que nous corrigerons dans les prochaines versions. Rich Towler, concepteur principal du jeu Performance Qu'est-ce qui s'est bien passé ? Nous cherchons constamment à améliorer les performances, ce qui est très difficile car nous ajoutons constamment de nouvelles fonctionnalités au jeu. Et bien qu'il y ait beaucoup à faire pour obtenir les taux de rafraîchissement que nous visons, je pense que le principal point positif en termes de performances pour XenoThreat est que nous avons atteint un niveau qui nous a permis d'offrir un événement agréable à de nombreux joueurs. Lorsque nous nous sommes essayés à ce type de combat de vaisseaux capitaux les années précédentes, nous étions tellement loin du compte en termes de performances que nous n'avons pas pu organiser un événement de cette ampleur. Qu'est-ce qui ne s'est pas bien passé ? De nombreux joueurs ont fait état d'un framerate client médiocre, notamment lors des batailles de vaisseaux en phase 2 et en phase 3, en particulier en phase 3. Nous savons que les performances du serveur doivent être améliorées, car cela permettra d'améliorer des choses comme les temps de réponse de l'IA. Ce que nous ferons différemment à l'avenir : Je pense que la principale leçon à tirer de XenoThreat et des dernières versions est que nous avons besoin d'un meilleur système de profilage et de régression des performances, afin de disposer des outils permettant à toutes les équipes de profiler et d'optimiser plus facilement les performances plutôt que d'être bloquées ou dépendantes d'une petite poignée d'ingénieurs. L'équipe des moteurs et moi-même nous sommes déjà penchés sur la question et avons fait quelques premiers pas cette année. Nous disposons d'un nouveau cadre de test de stress facile à utiliser pour le code, d'un meilleur support de profilage de débogage imGUI et d'une meilleure capture et analyse automatiques des données de performance. S'il est peut-être un peu tôt pour porter beaucoup de résultats pour l'Alpha 3.13, cela devrait nous être d'un grand secours à long terme. Cette année, toutes les équipes sont également tenues de consacrer plus de temps aux optimisations qui contribueront à cet effort. Et avec le maillage des serveurs à l'horizon, ainsi que plusieurs autres optimisations prévues à plus long terme, nous pourrons potentiellement réaliser des gains beaucoup plus importants lorsque celles-ci seront en ligne. Rob Johnson, directeur de l'ingénierie - Persistent Universe Gameplay Trad : @Maarkreidi SwissStarships.org

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 : 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. 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

Alpha 3.11 Postmortem Le 8 octobre 2020, nous avons lancé Alpha 3.11 High Impact, qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, y compris les ponts de cargaison, les réactions de force et la première étape de la suppression de la zone d'armistice élargie. Ce qui suit est un compte-rendu 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é. ALPHA 3.11 POSTMORTEM L'équipe des véhicules Le pilier Véhicule a eu un quartier beaucoup plus léger avec Alpha 3.11 par rapport à la livraison faite dans Alpha 3.10, mais ce que nous avons livré a, nous l'espérons, eu un grand impact sur l'expérience de jeu. Série Origin 100 L'équipe chargée du contenu des véhicules a livré la série Origin 100 en Alpha 3.11, comprenant les 100i, 125a et 135c. La série 100 ajoute un vaisseau de départ alternatif au jeu ainsi qu'un chasseur léger et un transporteur de fret léger. Ce sont de fantastiques petits vaisseaux avec lesquels les nouveaux joueurs peuvent commencer leur périple de citoyen des étoiles et qui leur permettent de s'attaquer à un large éventail de missions et d'explorer les profondeurs du "verse". Missiles et contre-mesures Le jeu de missiles et de contre-mesures a été dans différents états au cours des années et n'a jamais été vraiment agréable du côté de l'agresseur ou du défenseur. Nous avons l'intention de corriger cela avec le mode opérateur de missiles, mais en attendant, nous avons décidé de passer du temps à mettre en place des corrections et des itérations du gameplay pour donner un avant-goût de ce que cette fonctionnalité apportera. Les principaux problèmes rencontrés avec les missiles avant Alpha 3.11 étaient les suivants : Les contre-mesures n'agiraient que sur les missiles IR (fusées éclairantes) et les missiles EM (paillettes) Seules les fusées éclairantes ont fonctionné (parfois et fortement dépendantes du serveur) Il n'y avait pas de contre-mesures disponibles pour détourner les missiles CS Il était extrêmement facile de tirer des missiles, la défense contre les missiles était extrêmement difficile Tout d'abord, nous avons cherché à savoir pourquoi seules les fusées éclairantes fonctionnaient et pas les paillettes. Le problème était une combinaison de données de configuration incorrectes dans certains vaisseaux, de données incorrectes dans certaines contre-mesures et missiles, et d'une solution de contournement maintenant redondante, créée à l'origine pour un niveau SQ42 spécifique qui avait des répercussions sur l'ensemble du jeu. Une fois ces problèmes résolus, nous avons reconnu que le système de signature avait deux façons distinctes de modifier les signaux : soit en créant un signal fort, soit en atténuant tous les signaux environnants. Nous avons décidé d'adopter cette différence au lieu d'exiger des pilotes qu'ils jouent au "whack-a-mole" en choisissant la "bonne" contre-mesure pour le "bon" type de missile tout en ayant le stress de disposer de quelques secondes pour décider avant l'impact. C'est dans cet esprit que nous avons effectué des tests de jeu avec les changements suivants : Les fusées éclairantes agiraient sur tous les types de missiles Les paillettes seraient transformées en un champ de bruit, ce qui atténuerait toutes les signatures autour du champ D'emblée, les premiers tests de gameplay ont prouvé qu'il s'agissait d'un moyen de défense contre les missiles beaucoup plus engageant. Nous avons ensuite mis à jour les éléments HUD du système d'alerte aux missiles, ajouté un gadget de contre-mesure et mis à jour les raccourcis clavier pour permettre le lancement direct de chaque type de contre-mesure. Les équipes de l'interface utilisateur et des effets spéciaux ont ensuite tout embelli, remplaçant les effets et corrigeant également quelques bugs liés aux effets spéciaux (comme le fait que les contre-mesures soient invisibles dans l'unité centrale). Un ajout futur que nous n'avons pas pu faire à temps pour Alpha 3.11 a été de changer les noms des "flares" et "chaff". Ces deux noms sont très courants dans les communautés de simulateurs de vol, mais nous voulons quand même les renommer pour bien montrer que Star Citizen utilise des concepts différents pour la défense contre les missiles. Cela nous obligera à enregistrer de nouvelles lignes VO pour mettre à jour les voix des ordinateurs des vaisseaux. Chaque véhicule n'a droit qu'à quatre verrouillages à la fois Un seul missile peut être lancé par rack à la fois Un seul type de missile (IR/EM/CS) peut être lancé à la fois Les missiles perdent leur verrouillage en dehors de leur angle de verrouillage Une fois ces mesures en place, l'expérience des missiles s'est considérablement améliorée lors des premiers essais. Le spamming des missiles a été considérablement réduit, et le méta a évolué vers des vaisseaux se rapprochant très près les uns des autres et tirant des missiles à des distances où le défenseur n'aurait même pas reçu d'avertissement de missile avant l'impact. À la suite de ce changement indésirable, nous avons introduit des portées de verrouillage minimales et maximales. Cela a considérablement étendu le gameplay des missiles hors de portée des canons, permettant aux vaisseaux équipés de missiles de flâner à la limite du combat comme prévu tandis que les chasseurs spécialisés se rapprochaient. Cela nous a également permis d'augmenter l'angle de verrouillage des petits missiles, de sorte que des vaisseaux comme le Constellation (qui ne tirent pas de missiles vers l'avant mais légèrement en dehors de l'angle de tir) pouvaient à nouveau utiliser des missiles. Un grand nombre de ces changements (en particulier pour les missiles) sont temporaires pour donner une meilleure expérience jusqu'à ce que le mode opérateur de missiles soit prêt, ce qui modifiera à nouveau le comportement et/ou supprimera certains aspects lorsqu'il sera mis en œuvre. Réflexions finales L'objectif général que nous voulons atteindre dans la boucle de jeu des missiles est de rendre l'utilisation des missiles et la défense contre les missiles plus profonde et plus gratifiante, avec son propre "créneau" dans l'environnement de combat. Les missiles ne sont pas censés être une alternative aux armes à feu, mais des armes tactiques, et leur utilisation devrait être une décision consciente avec des conséquences. Nous voulons également donner aux navires lance-missiles spéciaux, comme le Talon Shrike ou le Freelancer MIS, un avantage lorsqu'il s'agit d'utiliser des munitions pour la même raison. Ces vaisseaux excelleront dans le jeu des missiles offensifs, bien qu'ils présentent des inconvénients évidents dans d'autres catégories. Il y aura donc plus d'itérations sur les contre-mesures et la jouabilité des missiles dans les deux prochaines versions. Pour l'instant, nous sommes heureux que l'expérience des missiles nous ait permis de nous éloigner des frustrations des versions précédentes. John Crewe Directeur Véhicules Technologie Système de marquage en toile Pour Alpha 3.11, l'équipe graphique a fourni la technologie de rendu sous-jacente pour aider à alimenter le système de " stickers sur toile ", qui utilise le système Building Blocks pour créer des textures de stickers au moment de l'exécution. Ces autocollants peuvent être utilisés pour la signalisation, sur les vêtements, ou même sur les véhicules. L'avantage des stickers créés au moment de l'exécution est que nous pouvons utiliser les données du jeu telles que le nom du joueur ou même faire traduire le contenu dans la langue dans laquelle le jeu est joué. Afin de rendre cette fonctionnalité évolutive pour une utilisation plus large dans le PU, le système est étroitement couplé avec le système de diffusion des textures, de sorte que les textures dynamiques sont "diffusées" en utilisant la même logique que les textures standard, ce qui garantit que nous maintenons toujours un budget mémoire fixe. Cette logique de streaming nous permet d'exécuter automatiquement les mêmes fonctionnalités sur des machines à faible spécification en équilibrant soigneusement les résolutions de texture à la volée, mais nous permet également de pousser la résolution de texture aussi haut que possible sur des machines plus puissantes. L'intégration des stickers sur toile dans la diffusion de textures a entraîné plusieurs crashs dans le PTU qui ont été très difficiles à repérer et ont pris beaucoup de temps à résoudre. En conséquence, nous avons rédigé une documentation pour aider les futurs programmeurs à comprendre les complexités du système de textures en continu, ce qui sera particulièrement important car nous prévoyons de généraliser le code et de l'utiliser également pour le mesh streaming. Planet Tech Du côté de la technologie planétaire, nous avons ajouté plusieurs fonctionnalités, notamment des améliorations aux outils planétaires. Il s'agit notamment de nouveaux pinceaux, d'une interface utilisateur remaniée et de la fusion de la couche de fond et des préréglages d'objets pour accélérer encore la peinture des planètes. En utilisant les nouveaux outils de peinture planétaire, l'équipe artistique de l'environnement a passé en revue toutes les planètes et les lunes du système Stanton et a repeint les surfaces du sol et les présélections d'objets. Cela nous permet également de nous projeter dans l'avenir et de tirer parti des nouvelles technologies dans les endroits existants. Nous sommes maintenant en mesure de prendre en charge le déplacement de la tessellation des HW sur la géologie répartie sur le terrain pour lui donner un aspect plus détaillé et plus organique. Il y a également eu plusieurs améliorations liées à l'océan et à l'eau, notamment la flottabilité de la couverture végétale, que nous continuerons à développer à l'avenir, car il n'y avait pas assez de temps pendant ce cycle de développement pour introduire des objets flottants plus grands. Ces derniers mois, beaucoup de temps a été consacré à la recherche et au développement de l'analyseur d'atmosphère et de nuages, y compris le raymarcher unifié planète-atmosphère. Nous entrerons dans les détails lorsque le système sera disponible. Pour l'instant, disons que nous avons travaillé sur divers algorithmes pour permettre le raymarching à une résolution inférieure à celle de l'écran et dé-bruiter et sur-échantillonner les résultats à pleine résolution pour améliorer les performances des opérations de raymarching coûteuses. Ces algorithmes sont combinés à des techniques de reprojection et au regroupement des demandes de recherche de pixels pour mettre à jour chaque image afin d'améliorer encore les performances. En outre, notre solution multidiffusion existante prend désormais en charge un nombre nettement plus élevé d'ordres de diffusion, ce qui sera important pour les atmosphères très denses. En outre, nous en sommes maintenant aux tout premiers jours de la recherche et du développement sur le rendu volumétrique des nuages... Presque un sous-produit de ce travail, nous avons apporté diverses améliorations à la technologie existante de rendu de l'atmosphère. Tout d'abord, plusieurs artefacts de longue date, tels que le rendu de fausses couleurs dans le crépuscule près du sommet de l'atmosphère ainsi que des halos très proéminents autour de la silhouette du côté obscur d'une planète, ont été traités. La génération de tables de recherche utilise maintenant une méthode mieux adaptée pour générer des échantillons de lieux pour l'intégration numérique sur des (hémi)sphères. Cette amélioration et d'autres améliorations de la précision numérique ont permis d'obtenir des résultats plus précis dans ces tables, avec des frais généraux de calcul réduits. Nous ne nous sommes pas arrêtés là, cependant, et avons mis en œuvre des améliorations visuelles supplémentaires dont vous pourrez bientôt profiter, nous l'espérons. L'une d'elles consiste à évaluer la quantité de disque solaire visible en calculant la quantité de lumière solaire qui atteint le point x dans l'atmosphère. Cette évaluation est entièrement intégrée dans l'ensemble du système d'éclairage de l'atmosphère et a un impact sur l'éclairage direct et indirect. De plus, nous avons ajouté un support pour une couche d'absorption. Cela nous permet, entre autres, d'ajouter une couche d'ozone aux planètes semblables à la Terre qui souligne le bleu du ciel et permet une meilleure ombre au crépuscule (en supprimant la teinte jaune). Nous incorporons maintenant également des données de radiométrie solaire extraterrestre IRL lors de la simulation de la lumière au lieu de supposer une source de lumière "blanc pur" ainsi qu'une conversion approximative de la radiance spectrale (résultat de la simulation de l'éclairage de l'atmosphère) en luminance (utilisée pour éclairer la scène au sens traditionnel). Enfin, nous avons amélioré l'évaluation de la radiance solaire reçue par les points situés en dehors de l'atmosphère de la planète. Elle projette maintenant le crépuscule en raison de la diffusion atmosphérique et de l'impact du rayon angulaire du soleil sur les objets dans la région de la pénombre d'une planète. Cela devrait ajouter une touche de charme aux vaisseaux capitaux ou aux lunes en orbite autour des planètes. Moteur Côté moteur, plusieurs améliorations ont été apportées. Nous avons mis à jour notre chaîne d'outils de compilation à la VS 2019, ce qui permettra d'accélérer les temps de compilation et de liaison. De plus, nous avons ajouté la prise en charge du compilateur de programmes Intel SPMD (ISPC). Cela nous permettra d'écrire un code optimisé pour l'ESS (pensez HLSL) pour les tâches de calcul sur les processeurs lourds et d'utiliser pleinement les capacités du processeur sur chaque machine sur laquelle le code s'exécute. Plusieurs chemins de code de la physique, du moteur 3D et du système de zones sont en cours de portage. Et nous avons une autre optimisation du compilateur en réserve pour vous. La prise en charge de la génération de code AVX pour les clients était auparavant activée et devrait toucher les serveurs publics dans la prochaine version Alpha 3.12. En ce qui concerne l'utilisation de la mémoire des serveurs et des clients, nous avons passé beaucoup de temps à affiner nos outils de suivi pour nous assurer que nous avons une bonne visibilité sur l'endroit où nous dépensons la mémoire. Nous sommes maintenant également en mesure de suivre correctement l'utilisation de la mémoire dans les bibliothèques tierces qui ne nous permettent pas de rediriger l'allocation de mémoire par notre système ou qui n'ont pas encore été mises à jour pour le faire. Nous prévoyons toujours d'obtenir un peu plus de visibilité sur les allocations de mémoire vidéo côté client au niveau du pilote (en dessous du niveau que nous pouvons actuellement suivre en tant qu'application utilisant le GPU). Grâce à ces améliorations, aux enquêtes en cours et au suivi, quelques fuites de mémoire critiques ont été corrigées pour la publication. Tout au long de la production d'Alpha 3.11, l'équipe du moteur central s'est surtout concentrée sur les fonctionnalités des versions ultérieures, comme le moteur de rendu Gen12. Cependant, un très gros bogue a été corrigé, qui faisait que tous nos objets sur les clients se déchargeaient bien plus tôt que prévu. Les objets sur les clients devraient maintenant rester en ligne sur des distances nettement plus grandes. Audio Pour les techniciens de l'audio, nous avons mis à jour la version de Wwise à 2019.2.4, ce qui a permis de corriger plusieurs problèmes. Dans ce cadre, nous avons retravaillé la gestion de la mémoire au sein du système audio, passant d'un groupe de pools de mémoire à un seul pool. Cela nous permet de gérer plus facilement les nombreuses situations différentes que présente Star Citizen en allouant la mémoire là où elle est nécessaire, quand elle est nécessaire. Nous avons passé beaucoup de temps à revoir nos budgets voix afin d'améliorer l'expérience globale et de permettre aux joueurs d'entendre davantage de ce qui se passe dans le jeu. L'appui-feu des armes, en particulier à longue distance, a été amélioré et plusieurs problèmes concernant les taux de tir audio et les volumes des armes ont été réglés. Canevas de découpe Ce trimestre, l'équipe UI-Tech a travaillé sur un système appelé "Canvas Slicer". Il s'agit d'un sous-système de blocs de construction qui permettra aux concepteurs de l'interface utilisateur de placer des tranches d'interface utilisateur en 2D dans un espace en 3D. Normalement, lorsque nous dessinons une interface utilisateur en 2D, elle est rendue sous forme de texture et cette texture est ensuite appliquée à une géométrie telle qu'un panneau de moniteur ou un bloc de données. Avec le Canvas Slicer, nous créons la géométrie à n'importe quelle position dans l'espace 3D au moment de l'exécution et nous dessinons l'interface utilisateur 2D directement sur celle-ci. Cela signifie que nous serons en mesure de produire des interfaces utilisateur en couches intéressantes, telles que des HUD de vaisseaux holographiques et des écrans de casque. Infos pratiques Nous avons également commencé à concevoir notre système d'info-bulles pour les Building Blocks. À première vue, ce système semblait simple à mettre en œuvre, mais les exigences pour garantir sa grande flexibilité ont fait que nous avons beaucoup à réfléchir avant de commencer la mise en œuvre. Marco Corbetta Vice-président de la technologie Gameplay de base Inventaire externe L'inventaire externe est la première itération de notre interface d'inventaire à base de grille qui permet aux joueurs de gérer leurs marchandises de SPE entre leur sac à dos, leur poitrine et leurs poches de jambe. Comme son nom l'indique, l'inventaire externe permet également aux joueurs d'interagir directement avec d'autres conteneurs de stockage dans le monde et de glisser et déposer des objets entre eux. Dans Alpha 3.11, cette fonction n'est activée que pour le compartiment de stockage Greycat ROC, afin que les joueurs puissent gérer leurs objets miniers du FPS. Mais, à l'avenir et une fois que nous aurons réalisé un véritable stockage d'objets (étayé par iCache), cela permettra aux joueurs de stocker des objets dans des compartiments, des caisses et d'autres inventaires externes de ce type. Même si, à première vue, un nouvel inventaire UI et la possibilité de glisser et de déposer des objets entre les conteneurs de stockage peuvent sembler simples, nous avons dû surmonter plusieurs défis créatifs et techniques. Les principaux défis créatifs concernaient la mise en place d'une interface tactile et accessible à tous, sans se contenter d'une interface 2D standard comme celle que l'on trouve dans la plupart des RPG. Ce n'est pas parce que ces inventaires sont mauvais, mais plutôt parce que nous ne voulions pas que les joueurs qui effectuent des inventaires Tetris gèrent leurs objets. Nous voulions que les joueurs puissent déplacer librement les objets entre les conteneurs de stockage sans avoir à se soucier de l'endroit où ils ont laissé tomber l'objet ou si un autre objet les gênait. Nous avons réussi à réaliser la première itération de ce système en utilisant notre technologie Building Blocks, qui stocke les objets sous forme de liste plutôt que de grille en 2D. Cela signifie que les objets se déplacent de manière fluide autour de votre curseur lorsque vous faites glisser des objets entre des conteneurs. Nous voulons encore améliorer l'impression générale, mais l'équipe est heureuse de cette première sortie. Si les Building Blocks nous ont permis de réaliser les aspects créatifs de la conception, ils ont également constitué le principal défi technique. Comme la technologie est encore en cours de développement, elle ne prend pas toujours en charge les éléments nécessaires à la réalisation d'une fonctionnalité. Dans le cas de l'inventaire externe, nous voulions que l'interface utilisateur soit diélectrique et en 3D, même si ce n'est pas le cas. Cela signifie que nous voulions que toutes les icônes soient holographiques, comme si elles étaient affichées en RA directement devant vos yeux. Malheureusement, nos icônes 3D ne pouvaient supporter qu'un shader limité, ce qui signifiait que nous perdions beaucoup de détails matériels des objets affichés. À ce stade, nous aurions pu retarder la fonction, mais l'équipe et moi avons estimé qu'il était important pour nous de passer en live et d'obtenir autant de retours que possible d'ici à un véritable inventaire physique. Nous allons certainement améliorer ce shader dans un prochain patch. Réactions de force La réaction de force est un système développé pour simuler ce que ferait un personnage lorsqu'il est touché par une force, qu'il s'agisse d'une forte rafale de vent ou d'une balle pénétrant dans son épaule. Il peut être divisé en trois niveaux d'impacts : Faible impact : secousses, tressaillements et inclinaisons Impact moyen : décalage Un impact important : renversements et évanouissements Dans Alpha 3.10, nous avons livré la première itération de réactions à faible impact avec les secousses procédurales en combat FPS et l'inclinaison en cas de vents soutenus. Dans Alpha 3.11, nous avons ajouté plus de "sensations" aux secousses avec des réactions supplémentaires de la caméra et de l'arme et notre première itération de renversements, avec l'intention d'échelonner l'ensemble plus tard. Le plus grand défi pour ce système était qu'il devait être vraiment systémique car les forces peuvent provenir de nombreux endroits différents, et pas seulement des balles. Pour cela, nous avons réparti les forces en trois catégories principales : Les forces directes : tout ce qui a un impact physique sur le personnage, comme une boîte ou une balle Forces indirectes : la force que vous recevez lorsque votre vaisseau est éperonné ou à la suite d'une rafale de vent Forces soutenues : lorsqu'une force est constamment appliquée, comme la force g ou le vent Cela signifie que nous avons pu compartimenter différentes forces à différentes échelles et permettre aux concepteurs d'équilibrer la réaction du personnage en conséquence, car les forces exercées par le choc d'une boîte par rapport à l'accélération d'un vaisseau dans l'espace à 1000m/s sont très différentes. Bien que les réactions à faible impact n'enlèvent aucun contrôle au joueur, nous étions très conscients du fait que les renversements en produiraient. Nous avons passé beaucoup de temps à nous assurer que les animations de knockdown étaient très réactives au contrôle du joueur dès que leur personnage touchait le sol. Nous avons également mis en place un système basé sur les compétences, ce qui signifie que si vous essayez d'utiliser l'ADS avant de toucher le sol, vous déclenchez une animation de récupération plus rapide, ce qui signifie que vous pouvez revenir dans l'action plus vite. Les réactions de force dans Alpha 3.11 ont été notre deuxième livraison et ne seront en aucun cas notre dernière. Nous travaillons activement sur des réactions à impact moyen et nous allons constamment revoir et ajuster l'équilibre à l'avenir, en particulier dans le combat FPS. Lancer T1 Lancer des grenades ou d'autres objets a toujours été un peu incohérent et est encore plus décevant lorsqu'on pense que l'on a cette occasion parfaite de tuer plusieurs cibles et que la grenade finit à seulement quelques mètres de vous. Donc, la première chose que nous voulions réaliser avec T1 était de rendre le lancer beaucoup plus fiable, de sorte que l'objet que vous lancez (que ce soit une grenade ou un autre objet) aille là où vous vous attendez à ce qu'il aille. Le deuxième objectif, qui est une condition préalable essentielle à l'inventaire physique, était que le système de lancement puisse interagir et coexister avec le système transportable. Dans Alpha 3.10, si vous ramassiez une grenade sur le sol et essayiez ensuite de la lancer, vous n'aviez aucun moyen de tirer la goupille. De plus, si vous appuyiez sur la touche de raccourci "Lancer la grenade", vous laissiez tomber la grenade dans votre main et en retiriez une nouvelle de votre combinaison. De toute évidence, ce n'est pas le comportement prévu et c'est la raison principale pour laquelle nous avons modifié le lancement pour qu'il se fasse à partir d'un état équipé (c'est-à-dire en tenant la grenade dans votre main) plutôt que directement à partir de votre combinaison. Ce système nous permettra également de fournir des gadgets et des objets déployables à l'avenir. Dans le cadre de T1, nous avons également ajouté un "arc de lancement" qui vous permet de voir la trajectoire de la grenade. Bien que cette fonction soit actuellement activée pour tous les casques, elle ne sera accessible à partir des casques de combat que lorsque nous commencerons à définir différents archétypes d'armure dans le "verse". Lance-grenades Behring et fusil de chasse Behring BR2 Depuis que je dirige les équipes des armes, nous essayons de faire en sorte que chaque arme que nous ajoutons au jeu ait un but ou un style de jeu unique qui lui convienne. Actuellement, nous avons déjà plusieurs fusils de chasse qui sont mortels lorsqu'ils sont utilisés de près mais inefficaces au-delà. Behring étant un fabricant que nous avons identifié comme étant au milieu du chemin en ce qui concerne les dégâts, la cadence de tir et la précision, nous avons pensé que le BR2 était notre première opportunité de pousser la portée d'un fusil de chasse pour fournir un peu plus de puissance de feu en milieu de combat sans qu'il ne domine au corps à corps. Si nous étions satisfaits du BR2, nous ne le sommes pas forcément des fusils de chasse dans leur ensemble, car ils sont surpassés par les SMG et les fusils d'assaut. Nous allons faire une mise à jour de tous les fusils de chasse dans un prochain patch pour leur donner une plus grande identité. Le lance-grenades Behring, en revanche, présente des problèmes tout à fait différents. Une grenade de 40 mm dans la vie réelle a un rayon d'environ 5 m pour tuer et 15 m pour blesser. Ce sont des chiffres importants lorsque vous regardez nos espaces intérieurs et, étant donné que vous pouvez en tirer plusieurs en peu de temps, vous vous retrouvez avec une arme assez puissante. D'une part, nous voulions livrer une arme lourde et conçue pour faire pleuvoir la destruction, mais d'autre part, nous ne voulions pas détruire massivement l'équilibre du combat FPS. Dans ce but, nous avons fait en sorte que le nombre de victimes soit légèrement inférieur à celui d'une grenade à fragmentation normale, tant pour le nombre de morts que pour le nombre de blessés. Mais pour être tout à fait honnête, je dirais que le lance-grenades est un peu trop puissant dans le jeu actuel. La raison principale est que les joueurs ont accès à une quantité infinie de munitions en utilisant le PMA, donc nous avons dû choisir entre livrer l'arme comme prévu ou la nerfer massivement jusqu'à ce que l'inventaire physique soit mis en ligne. En tant qu'équipe, nous avons estimé qu'il était plus représentatif d'une expérience de libérer l'arme comme elle est censée fonctionner et d'attendre que les autres systèmes, tels que l'inventaire physique et les dommages physiques, équilibrent sa puissance pure. Ensuite, les joueurs devront considérer l'espace qu'ils allouent aux munitions et les dommages physiques feront perdre leur intégrité aux armes et aux armures lorsqu'elles seront touchées. Cela signifie que si quelqu'un se fait exploser par une explosion, une grande partie de son équipement sera endommagé, ce qui diminue la valeur globale. J'ai également vu les réactions concernant la distance d'armement et c'est quelque chose sur laquelle nous allons travailler. Réflexions finales Si je regarde toutes les fonctionnalités que le pilier Core Gameplay a fourni pour Alpha 3.11, je suis heureux des résultats. Cependant, cela ne veut pas dire que tout s'est bien passé ou que si j'avais à nouveau ce temps, je ferais tout de la même manière. La principale chose que je pense que je changerais serait la façon dont nous avons mis en place les Réactions de Force dans les vaisseaux. Plutôt que de la traiter comme toutes les autres forces du jeu (vent, balles, etc.) - ce qui à première vue est logique - je l'aurais conçue spécifiquement autour du générateur de gravité à l'intérieur des vaisseaux. Actuellement, nous prenons la force qui est appliquée au vaisseau et nous l'appliquons directement à l'acteur à travers des filtres dépendant de la force afin qu'il réagisse en conséquence. J'aurais plutôt préféré que la gravité elle-même réagisse à la force, ce qui aurait ensuite fait réagir l'acteur. Même s'il n'y aurait pas de différence pour l'acteur, je pense que cela aurait été une mise en œuvre plus propre et qu'il aurait été plus facile d'étendre le système à l'avenir. Par exemple, lorsque nous ajoutons des éléments générateurs de gravité, etc. Au cours des deux derniers trimestres, nous avons également livré deux fonctionnalités (Body Dragging et Knockdowns) qui auraient vraiment bénéficié d'un ragdoll motorisé. Malheureusement, cette fonction n'est pas fournie par un membre de mes équipes, donc je n'aurais pas nécessairement pu changer quoi que ce soit. Mais en y repensant, j'aurais donné plus de visibilité aux avantages qu'il y a à essayer de faire avancer cette fonctionnalité. C'est évidemment un défi de travailler au sein d'une équipe de 600 personnes réparties sur plusieurs continents et ayant des priorités différentes pour de multiples projets. Chacun essaie de fournir les meilleures fonctionnalités/contenu/technologies possibles avec la meilleure qualité possible et parfois les étoiles ne s'alignent pas lorsqu'il s'agit de priorités. Dans ce cas, c'est purement sur mes épaules en raison d'un manque de communication. En tant que développeurs, nous ne faisons pas toujours les choses correctement lorsque nous sommes dans le feu de l'action, mais j'espère que cela vous donnera un aperçu de nos processus et de la façon dont nous nous donnons toujours à 100% pour essayer de créer les meilleures expériences pour votre plaisir. Richard Tyrer Directeur du Core Gameplay Environnements Ponts cargos Pour cette version, nous avons pu présenter la prochaine étape dans l'ajout de complexité à nos stations spatiales. L'idée pour les grandes stations situées autour des planètes est qu'elles seraient plus que de simples aires de repos ; elles auraient leurs propres installations dédiées à d'autres services, comme le fret. Pour l'extérieur, nous avons introduit de nouveaux éléments supplémentaires qui décrivent l'infrastructure et de grands racks de conteneurs impliquant la capacité de l'emplacement (qui est pour l'instant purement visuel, à l'avenir nous aimerions inclure des éléments plus interactifs). À l'intérieur, nous voulions étendre les itinéraires de traversée. Pour cela, nous avons introduit l'idée d'une station ayant un réseau de transit principal qui relie entre eux les différents éléments de la station - ponts commerciaux, ponts de fret, etc. Pour l'intérieur du pont cargo, nous voulions inclure quelques éléments. Tout d'abord, pour la zone du hub, nous voulions décrire une expérience logistique thématique pour le joueur. Il s'agit d'une section d'un entrepôt de stockage qui, à l'avenir, sera un bac à sable pour du contenu de mission. Pour l'espace commercial principal, nous voulions intégrer quelques éléments dans un magasin plus grand. Maintenant, nous pouvons voir le comptoir de dépôt et de ramassage des cargaisons situé dans un mini bureau de tri logistique, l'espace de location de vaisseaux est situé sur le côté, et la zone de guilde et d'approvisionnement est dans le coin. Dans l'ensemble, cela donne une expérience plus diversifiée pour le joueur plutôt que de séparer tous ces éléments dans des magasins distincts.. Contenu planétaire Au cours de ce trimestre, nous avons pu continuer à mettre à jour les planètes et les lunes du système Stanton avec les derniers outils et technologies que nous utilisons pour construire le système Pyro. Nous avons commencé par effectuer une passe globale sur toutes les planètes et les lunes. Fondamentalement, ce processus de peinture est à l'origine d'un grand nombre des dernières caractéristiques de la manière dont nous unifions les objets, donc pour que cela entre dans le jeu, nous avons dû mordre la poussière et faire la première passe sur tout. Dans le dernier patch, nous avons introduit les nouvelles topographies, et maintenant la nouvelle passe de peinture va tirer parti de toutes ces nouvelles données. Le deuxième élément que nous avons pu introduire est une amélioration globale de tous nos packs géologiques. Nous avons maintenant la possibilité de spécifier la couleur du terrain pour les ressources, ce qui leur permettra de correspondre, du point de vue procédural, à la couleur du terrain ou du substratum rocheux. De plus, nous avons pu ajouter la tessellation et le déplacement des assets sur une base par objet, ce qui signifie que nous pouvons assigner des cartes de hauteur aux assets qui déterminent les paramètres de déplacement. En bref, cela signifie que lorsque le joueur s'approche d'un objet, sa résolution géométrique doit être considérablement plus élevée, ce qui permet de lire une silhouette complexe. Enfin, nous avons remplacé tous nos shaders de terrain par des données scannées. C'est un point sur lequel nous nous sommes penchés pendant un certain temps, car la qualité des résultats était extrêmement élevée, mais grâce à certaines des dernières technologies, nous avons pu l'intégrer dans notre pipeline. Nous avons recréé plus de 70 shaders de base en combinant et en mélangeant les données scannées pour obtenir les résultats que nous voulions. À l'avenir, nous avons l'ambition de mettre en place un équipement de balayage dédié pour traiter nos propres données, que nous recueillerons lors de nos visites sur le terrain. Nous voulons nous assurer que nous pouvons créer une palette variée et merveilleuse pour les futurs emplacements de Star Citizen. Conclusions Nous avons pu introduire beaucoup de nouvelles technologies dans cette version, ainsi que commencer à montrer la deuxième série de mises à jour de polissage sur les surfaces planétaires. De plus, avec l'introduction de données scannées pour nos surfaces, nous avons vu un saut de qualité substantiel. Cependant, certains passages de peinture globale n'étaient pas aussi détaillés et approfondis que nous l'aurions souhaité. Cela est principalement dû à des contraintes de temps au cours du trimestre. Certaines des surfaces géologiques des nouvelles bibliothèques pourraient également être plus appropriées à la biomasse/région. Pour les ponts de cargos, nous aurions dû prévoir la déconnexion entre l'intérieur et l'extérieur lors de la séparation des ponts commerciaux. Pour améliorer l'expérience et aider à donner un contexte à l'acteur, nous aimerions que ce réseau de transit soit matérialisé à l'avenir. Cela permettra d'avoir une visibilité depuis la cabine de transit jusqu'à l'extérieur de la gare, alors que celle-ci se déplace vers sa destination. Ian Leyland Star Citizen Art Directo Design Zones d'armistice Les assouplissements de la zone d'armistice sont la première étape vers la suppression de toutes les restrictions arbitraires du jeu, au fur et à mesure que nous avons la capacité de défendre et de contrôler correctement les différentes zones du jeu. Cela a été possible sur les aires de repos car, en plus de réutiliser les tourelles de taille 4 et les sentinelles de taille 6 existantes, nous avons créé une toute nouvelle tourelle de taille 10. Ensemble, elles sont capables de s'occuper de n'importe quel vaisseau qui sera dans le jeu. Et plutôt que d'imposer encore une autre restriction arbitraire, nous avons rendu les défenses entièrement destructibles, bien que leur temps de réapparition soit très rapide, à savoir 5 minutes. Ce système de réapparition sera développé à l'avenir pour pouvoir compter sur des réparations. De concert avec les défenses, nous avons ajouté la première itération d'un système de réponse de sécurité qui, bien qu'encore assez simpliste, additionne les CrimeStats de tous les acteurs de la zone (connu en interne sous le nom de "Fièvre") et engendre des vaisseaux de sécurité de plus en plus nombreux et performants en réponse. Le système réagit rapidement à l'augmentation de la menace dans une zone donnée en créant de nouveaux vaisseaux et en détruisant les vaisseaux plus faibles qu'ils remplacent. Le système réagit plus lentement à la mort de ses membres (si la fièvre n'augmente pas) et encore plus lentement à la diminution de la fièvre. Nous développerons ce système à l'avenir pour tenir compte également des vaisseaux utilisés par les joueurs et de l'agressivité dont ils font preuve. Nous le déploierons dans d'autres endroits comme les avant-postes, bien que Grim HEX nécessitera une solution plus complexe car les défenses qui y seront mises en place ne devront répondre qu'aux crimes commis dans sa juridiction et non dans d'autres. Olisar restera une aberration car il s'agit d'un site ancien qui ne peut pas supporter une zone d'armistice du rayon requis. L'équipe Live Team a dû être extrêmement vigilante et réagir rapidement aux problèmes étant donné le peu de temps qu'Alpha 3.11 a passé dans le PTU. Un exemple de problème que nous avons remarqué est celui des joueurs qui volent les sentinelles en les avalant dans la soute de leur 890 Jumps et qui s'envolent avec elles. Nous avons remédié à ce problème en autodétruisant les sentinelles enlevées de la zone et en les faisant renaître. Un autre exemple est que si la réponse de sécurité était capable de reproduire rapidement les vaisseaux sur les serveurs locaux, ce n'était pas le cas sur un serveur live. Pour essayer d'améliorer la situation, nous avons réduit les seuils auxquels le système répondait afin de réduire le nombre de spawns demandés. Nous avons vu des vidéos de nombreux joueurs faisant équipe pour dépasser une aire de repos et la tenir longtemps malgré les défenses et la réponse de sécurité. C'est pourquoi, dès que l'Idris est devenu disponible, nous l'avons ajouté au niveau supérieur du système de réponse. Nous espérons donc que ces joueurs auront du mal à faire de même dans un avenir pas trop lointain. Réflexions finales Pour aller de l'avant, nous prévoyons également d'assouplir les limites arbitraires que l'on trouve à l'intérieur des bâtiments, en commençant à nouveau par les aires de repos. Nous sommes déjà bien avancés avec un système de cagibis qui nous permettra de générer les gardes nécessaires à la surveillance de la zone. En outre, nous travaillons sur un réseau de sécurité qui saura si les joueurs ont le droit d'être dans certaines zones et permettra aux caméras, aux tourelles et aux gardes de réagir aux intrus, à ceux qui ont du CrimeStat, ou à ceux qui sont en train de commettre des crimes. Luke Pressley Concepteur principal 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

Alpha 3.10 Postmortem Le 5 août, nous avons lancé Alpha 3.10 Flight & Fight, qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, tels que les mises à jour de lieux dans Grim HEX et New Babbage, le traînage de corps, les nouvelles armes FPS, l'échange entre joueurs, et plus encore. Plus particulièrement, Alpha 3.10 a apporté des changements majeurs au HUD des vaisseaux et au modèle de vol. Ce qui suit est un compte-rendu de nos réflexions de fond sur ce qui a bien fonctionné, ce qui n'a pas fonctionné et ce que nous avons appris pour la prochaine fois. Nous pensons qu'il est très utile de donner un aperçu de notre processus de réflexion et, comme nous l'avons mentionné la dernière fois, nous continuerons à fournir des post-mortems trimestriels. ALPHA 3.10 POSTMORTEM Équipe de véhicules Le pilier véhicules est composé de cinq équipes, qui ont toutes travaillé avec Alpha 3.10, en mettant en place pas moins de sept fonctionnalités, ce qui en fait l'une de nos distributions les plus percutantes à ce jour. En résumé, les principales caractéristiques sur lesquelles le pilier a travaillé sont les suivantes Courbes d'efficacité des propulseurs et aérodynamique Améliorations de la tourelle et de l'artillerie Nouvelle méthode de ciblage Rénovation du HUD des vaisseaux Retravailler les zones restreintes Combat à grande vitesse Greycat Industrial ROC & Gathering Beam Je vais entrer dans les détails pour chacune de ces caractéristiques (dont certaines contiennent de multiples petits éléments qui ne figurent pas sur la feuille de route) et détailler ce que nous avons fait, ce qui a bien fonctionné, ce qui n'a pas fonctionné et comment nous pouvons nous améliorer à l'avenir. Courbes d'efficacité des propulseurs et l'aérodynamique Les joueurs qui nous accompagnent depuis un certain temps se souviendront du "mode vol stationnaire", un concept que nous avons testé dans Alpha 3.6 pour essayer de rendre les vaisseaux plus crédibles en vol atmosphérique en les poussant vers un maniement de type "hélicoptère". En fin de compte, nous n'avons pas poursuivi l'idée au-delà de la version initiale, car elle entraînait des bizarreries de manipulation et rendait les joueurs perplexes lorsque leurs vaisseaux changeaient automatiquement de mode de contrôle. Les courbes d'efficacité des propulseurs ont été conçues comme une solution de rechange en réduisant la quantité maximale de propulseurs disponibles en fonction de la densité atmosphérique, ce qui réduit l'agilité des vaisseaux plus ils sont proches du sol. Parallèlement, nous avons également introduit des surfaces aérodynamiques sur les vaisseaux afin qu'ils se comportent de manière plus proche des avions traditionnels avec des surfaces de portance. Par rapport à certaines des autres caractéristiques d'Alpha 3.10, la mise en service de ces caractéristiques s'est déroulée de manière relativement harmonieuse, avec un délai prévu pour réagir à tout retour d'information des tests Evocati et PTU. L'équipe a effectué de nombreuses mises à jour et ajustements de la manipulation des vaisseaux pendant ces périodes, car des bugs ont été découverts dans les configurations spécifiques des vaisseaux. Le déploiement de cette fonctionnalité a nécessité un investissement en temps important de la part de l'équipe chargée des caractéristiques des véhicules ( Vehicle Feature Team - VFT) et de l'équipe chargée de l'expérience des véhicules ( Vehicle Experience Team - VET), car il s'agissait simplement de refaire l'équilibre et le réglage des plus de 120 véhicules pouvant actuellement voler dans le PU aux côtés de ceux de Squadron 42. Il était donc naturel que quelques uns se glissent dans les premières phases d'Evocati avec quelques problèmes (en te regardant Hornet avec tes ailes à l'envers...). En résumé, nous sommes satisfaits de la façon dont la première version a été diffusée et il y a un minimum de plans pour l'avenir du côté de la VFT, à l'exception de l'équilibre de vol en cours et des ajustements à la manœuvrabilité des vaisseaux selon les besoins. Le seul point restant est l'ajout de contrôles de gouvernes , comme les flaps et les ailerons, afin d'apporter des modifications visuelles et physiques à la manipulation. L'équipe VFX cherche également des moyens d'améliorer le visuel des propulseurs pour qu'il soit clair qu'ils sont utilisés lorsqu'on les regarde de loin. Cela permettra d'éviter que les vaisseaux n'apparaissent dans des positions bizarres, même avec tous les changements récents. Améliorations des tourelles et de l'artillerie L'une des questions récurrentes que nous nous sommes posées au cours du développement était la suivante : "Pourquoi devrais-je avoir un joueur dans ma tourelle alors qu'il serait plus efficace pour eux d'amener un second vaisseau ? Avec Alpha 3.10, nous voulions répondre à cette question une fois pour toutes. Grâce à une série d'améliorations et à une base de code fortement réécrite, les tourelles sont désormais une option extrêmement meurtrière lorsqu'elles sont utilisées par un équipage et fournissent un multiplicateur de puissance pour le vaisseau. Grâce à la combinaison des travaux de VET et de VFT, qui ont permis de créer un nouveau HUD pour les tourelles, l'expérience globale a été améliorée sous tous les angles mesurables. Le deuxième volet consistait à tirer parti de certaines des améliorations appliquées aux tourelles et à les appliquer aux armes fixes, qui avaient pris un retard considérable dans leur utilisation par rapport aux armes sur rotule et aux auto-gimbales. Les premiers essais ont montré les promesses de la méthode de mouvement basée sur la vJoy combinée à l'assistance fixe. Cependant, cela a eu pour conséquence de rendre les tourelles vraiment surpuissantes et nous avons dû revoir certains des réglages de la version initiale. Nous avons relevé quelques défis en raison de la variété des configurations des tourelles dans le jeu, en particulier les tourelles inversées, qui ont nécessité un travail supplémentaire pour qu'elles se comportent comme prévu. Les tourelles inversées, comme le deuxième siège du Super Hornet, ont également bénéficié des changements, mais nous avons trouvé quelques autres problèmes concernant la synchronisation des projectiles que nous améliorerons encore dans les prochains patchs. Avec ces changements, les armes fixes sont à nouveau revenues en tête de liste, montrant une augmentation significative de la létalité depuis Alpha 3.9. Nouvelle méthode de ciblage L'objectif de la nouvelle méthodologie de ciblage était de simplifier le processus de sélection des cibles et de remédier à l'encombrement de l'écran qui s'était accru au fil des versions. De toutes les fonctionnalités sur lesquelles le Pilier véhicule a travaillé pour Alpha 3.10, c'est celle qui a posé le plus de problèmes pour diverses raisons. En fin de compte, nous pensons que le système publié dans Alpha 3.10.0 (et qui a fait l'objet de mises à jour mineures dans la version 3.10.1) offre une meilleure solution pour cibler les objets. Cependant, le chemin vers cette solution a été particulièrement difficile et intense, avec de nombreux retours d'informations provenant de la phase Evocati qui nous ont fait dévier de manière significative du plan initial. L'objectif principal était de ramener le système à ce qu'il était dans les premiers jeux Wing Commander, où les joueurs pouvaient simplement cibler et verrouiller les menaces avec deux entrées. Cela nous permettrait également de supprimer la mer de triangles qui devenait un spectacle courant dans Star Citizen. Les premiers prototypes ont mis en évidence des problèmes de manque de connaissance de la situation mais, grâce à la prévoyance interne liée à une exposition répétée au système, nous avons pu constater que les changements à venir des écrans radar 3D des véhicules allaient améliorer la situation. Parmi les autres options que nous avons testées au cours du développement, nous avons essentiellement divisé le ciblage en quatre états distincts : Sélectionner - La cible est mise en évidence mais ne comporte pas d'informations sur l'artillerie. La sélection est perdue lorsqu'elle n'est pas affichée à l'écran Marqué - La cible est stockée dans une liste pour une sélection ultérieure, quel que soit le poste occupé par le joueur Verrouillé - La cible dispose d'informations sur l'artillerie et n'est pas perdue lorsqu'elle est hors champ Épinglé - La cible est enregistrée dans une liste avec des informations et partagée avec l'équipage En fin de compte, nous avons trouvé que l'état marqué était une étape inutile dans la mise en œuvre initiale ; bien qu'il puisse être utile à long terme dans le cadre de rôles à plusieurs équipes, il a entravé la convivialité à court terme. L'effort initial pour Evocati s'est fait avec les trois autres états, mais le retour d'information a été très important, l'état sélectionné étant une étape inutile. Nous avons donc, par la suite, simplifié le processus pour arriver à une sélection essentiellement automatique avec la possibilité de verrouiller et d'épingler. Un autre point litigieux qui a été mis en lumière lors des tests Evocati a été la suppression des touches de défilement. Comme indiqué, nous voulions essayer de simplifier le processus de sélection par la saisie de la direction de visée mais, parallèlement à la suppression des marqueurs à l'écran, les joueurs utilisaient le défilement des cibles comme moyen rapide d'obtenir une connaissance de la situation. À long terme, nous allons améliorer cette méthode en fournissant de meilleures informations sur l'écran radar 3D et en affichant les cibles sélectionnées sur le MFD de l'état des cibles. Les joueurs qui souhaitent utiliser uniquement la sélection automatique peuvent toujours le faire et ceux qui souhaitent faire du défilement manuel pour tout trouveront une multitude d'options dans la section des touches de contrôle, il devrait donc y en avoir pour tous les goûts. Le dernier élément de la fonction a été tous les changements visuels qui ont été mis en œuvre pour résoudre la mer de triangles susmentionnée et aider à apporter de la clarté et de la précision aux cibles verrouillées. Les premiers blocages de la fonction comportaient un élément 2D pour les cibles éloignées qui est passé à un support 3D à mi-distance avant de passer finalement à un shader de silhouette. Au cours du développement, nous avons testé des combinaisons et des variations de cette fonction, y compris un contour purement basé sur la silhouette qui figurait dans les premiers patchs Evocati. Les réactions ont montré clairement que cela n'était pas visible, nous sommes donc revenus à la géométrie 3D et avons réimplémenté le cône de direction avant en plus des affichages contextuels, y compris la distance et le taux de rapprochement. Nous avons ajouté très tard les marqueurs en chevron "contact connu" que nous essayions à l'origine d'éviter afin de réduire l'encombrement visuel. En fin de compte, nous avons décidé qu'ils étaient utiles dans une lutte pour la conscience de la situation. Zane Bien a proposé une implémentation 3D plus élégante que les précédents triangles 2D, qui a également permis d'attirer l'attention sur les nouveaux contacts à portée, nous étions donc satisfaits du résultat. À l'avenir, nous améliorerons la visibilité de ces éléments 3D sur le HUD en leur permettant d'utiliser la même fonction de luminosité dynamique que celle que nous avons sur les éléments 2D du HUD pour les aider à être plus appropriés au scénario. Refonte du HUD des vaisseaux L'objectif principal de cette fonctionnalité était de remplacer l'élément central HUD basé sur flash dans les véhicules par notre interface utilisateur modulaire, en améliorant certaines des fonctionnalités du processus. La conversion des vaisseaux a été une tâche relativement rapide, même si quelques uns ont glissé à travers les mailles du filet malgré des tests répétés et ont été nettoyés dans les patchs PTU ultérieurs. Entre cette méthode et la nouvelle méthode de ciblage, il y a eu beaucoup d'ajustements et de changements qui peuvent être considérés comme étant dans l'une ou l'autre de ces deux caractéristiques, comme par exemple Amélioration de l'affichage Autogimbal - Affiche maintenant la progression des armes à cardan vers la cible pour donner un retour d'information sur le degré de "verrouillage" des joueurs. Nouveaux réticules et pips 3D - Fournit des visuels plus intégrés aux autres éléments de la visière. Les animations fournissent un retour d'information sur l'état des armes, comme "sur la cible" ou "hors de portée". Ajustements de l'indicateur de vitesse et du mesureur de poussée - La barre du ruban de vitesse est maintenant affichée de façon logarithmique plutôt que linéaire. Ajout d'un mesureur de poussée pour refléter la capacité de poussée du vaisseau du joueur. Pendant les phases Evocati et PTU, nous avons testé divers éléments du HUD et nous avons pris en compte les réactions à bord concernant l'échelle et la quantité de bruit visuel, en les ajustant jusqu'à ce que nous soyons satisfaits de la clarté et de l'identité visuelle. Comme pour les éléments du nouveau ciblage, nous voulons améliorer la lisibilité dans les environnements lumineux. Pour y parvenir, il faut activer la luminosité dynamique des éléments de la visière/l'objectif. Réaménagement de la zone restreinte Rétrospectivement, c'était probablement la caractéristique la plus controversée du patch et celle qui a failli faire partie d'Alpha 3.9. Cependant, la mise au point a été retardée en raison de problèmes techniques qui ont nécessité des tests supplémentaires. L'objectif était de fournir une méthode d'entrée plus réaliste aux lieux d'atterrissage (comme un système de contrôle aérien réel), de supprimer l'imposant élément visuel mettant en évidence la zone, et de fournir un balisage plus simple pour l'art et le design afin de le contrôler par rapport à la configuration précédente. Par rapport à la version précédente, le balisage est beaucoup plus simple et plus souple. Désormais, outre les maillages simples qui donnaient souvent lieu à des brosses énormes et complexes, il peut utiliser des formes primitives et leur appliquer des priorités pour dicter les zones à restreindre (ou zones de mort) et les relier à des cannelures si nécessaire. L'ajout de splines de navigation a posé des problèmes comme d'autres éléments HUD de lisibilité dans différents états d'éclairage. Contrairement à d'autres aspects, il utilise un shader différent pour le contrôler, qui est actuellement incapable de réagir en fonction de la luminosité globale de l'écran. Nous avons l'intention d'y remédier dans un prochain patch et de "thématiser" la géométrie pour les fabricants de vaisseaux car, dans la tradition, la projection se fait depuis l'intérieur du vaisseau plutôt que depuis le lieu d'atterrissage. Lors de la sortie initiale d'Evocati, il était clair que les joueurs utilisaient le système de manière beaucoup plus agressive que les testeurs internes, en volant souvent jusqu'à la zone avant d'appeler l'ATC. Les tunnels étaient donc dessinés derrière eux et l'icône d'atterrissage les attirait dans les zones de destruction. Avec le changement de luminosité, l'amélioration des indications et des conseils à l'écran, et l'ajout du marqueur affiché à l'entrée du tunnel, nous pensons que ce système est dans un bien meilleur état bien que nous ne soyons pas satisfaits de son état actuel en termes de gameplay. Nous envisageons de faire un nouveau passage au système pour essayer de supprimer certaines des restrictions lourdes et de laisser les joueurs aller où ils veulent, et de sanctionner les mauvais comportements avec le système juridique (mise en fourrière, amendes, crimes, etc.) plutôt qu'avec le pilotage automatique et la destruction de biens. Combat à grande vitesse C'est une erreur d'appeler cette fonction "High-Speed Combat", car il s'agit en fait de décourager les combats à grande vitesse. Nous avons effectué de nombreux travaux préliminaires sur ce sujet au cours du cycle de patchs Alpha 3.9.0, mais, en raison de divers facteurs, nous avons décidé de le faire en même temps que d'autres changements dans Alpha 3.10. L'objectif était de réduire la capacité des joueurs à s'engager dans des combats faciles à grande vitesse grâce à une combinaison de restrictions qui deviennent lentement plus fortes au-dessus des vitesses de manœuvre de combat spatial (MCS) : Augmentation du temps de verrouillage du missile Diminution de la vitesse de balayage de l'auto-gimbal Restrictions sur le tir de missiles au-delà de certaines vitesses Diminution de la précision des armes Diminution de la force du bouclier Après des tests internes et au début de la phase Evocati, nous avons décidé que seuls les deux premiers de la liste pouvaient être publiés. Les autres options n'ont pas été retenues, car l'interface utilisateur n'était pas en mesure de communiquer clairement ce qui se passait et nous avons eu l'impression d'une limitation arbitraire du jeu. À l'avenir, nous prévoyons d'imposer d'autres restrictions de ce type en utilisant des condensateurs sur les armes, les propulseurs et les boucliers afin que les joueurs puissent choisir les trois "ressources" qu'ils souhaitent utiliser pour obtenir un effet maximal. Le triangle de priorité de la puissance y parviendra. Greycat Industries ROC & Gathering Beam Le premier véhicule d'Alpha 3.10 était le Greycat Industrial ROC, notre premier véhicule minier terrestre. Nous avons également prévu deux caractéristiques pour l'accompagner, dont l'une a fait le lancement. La première était le Gathering Beam, qui, en surface, ressemblait au mode d'extraction de tous nos véhicules miniers existants. Cependant, elle était différente en ce sens qu'elle déplaçait physiquement les morceaux de roche fendus plutôt que de jouer un effet de particule pour la simuler. Nous voulons étendre cette fonction aux autres véhicules miniers, car elle prépare le terrain pour d'autres techniques de véhicules, telles que les faisceaux tracteurs et la récupération. La mise en place du faisceau de collecte est le résultat d'un élément identifié dès le début de la planification par l'équipe technique des véhicules (VTT) : les dépôts exploitables étaient physiques et ne pouvaient pas simplement disparaître lors de la collecte. Le ROC avait donc besoin de nouvelles roches entre les gisements exploitables à la main existants et ceux que les plus grands vaisseaux pouvaient extraire. L'équipe artistique s'est appliquée à créer de nouveaux assets qui se sont divisés en assets exploitables, généralement extraits des plus petits objets exploitables à la main, plutôt que de simples gros morceaux de roche que le Prospector et le MOLE utilisent. Le plus gros problème auquel le dispositif a été confronté est un bogue apparu tardivement dans la diffusion d'Alpha 3.10.0 Live. La vitesse à laquelle les objets pouvaient être traités (les roches étaient transférées à l'inventaire physique du vaisseau comme la nourriture dans une combinaison spatiale) était limitée en raison d'une correction d'un autre problème, ce qui fait que le ROC ne pouvait récupérer qu'environ 20 % des assets d'une roche. Ce problème a ensuite été réglé en 3. 10. 1 en raison du temps supplémentaire nécessaire pour assurer la qualité du changement. La deuxième caractéristique avec laquelle le ROC devait être lancé était un inventaire externe, car il était toujours prévu que la caisse au dos accepte les roches de l'inventaire d'un joueur, permettant au ROC de se comporter comme un sac à dos étendu. Cette fonctionnalité n'était pas tout à fait prête pour Alpha 3.10 et sera mise en ligne dans la version 3.11. J'espère que ce qui précède vous a donné un aperçu du développement des fonctionnalités que le Pilier véhicule a fourni pour Alpha 3.10. Nous sommes impatients de partager nos travaux à venir avec les prochains patches. John Crewe Directeur Véhicules PU Live Gameplay Utilisation de la couverture V1 Lorsque nous avons commencé à développer la couverture et la façon dont nous fixons les environnements, il est devenu très clair que nous avions besoin de plus de flexibilité dans le système. Avant, la couverture de l'IA était limitée à 1,25 mètre et plus, donc la façon dont l'environnement était construit avait un grand impact sur la façon dont l'IA agissait et naviguait. Dans la plupart des cas, cela a donné lieu à un scénario non réaliste. Nous ne voulions pas toujours avoir des objets de 1,25 mètre répartis dans la pièce, donc l'équipe d'IA a fait des ajustements clés qui ont permis de faciliter la mise en place de la couverture, et a ajusté les PNJ pour utiliser une gamme de couverture de 0,5 à 1,25 et plus. Cependant, il reste quelques problèmes mineurs qui surgissent dans des situations spécifiques que nous sommes en train de régler. L'IA de type "Shotgun C'était notre troisième type d'arme ajouté à l'IA de combat, après les fusils d'assaut et les pistolets. Avec cet ajout, nous voulions créer quelques changements comportementaux dans la façon dont l'IA agissait envers le joueur en fonction de l'arme dont il disposait. Nous avons également revu les mécanismes d'interruption de l'IA et l'avons rendue plus réactive par rapport à la version précédente. L'IA a également une meilleure compréhension de l'environnement et de la situation de combat grâce à des ajustements de comportement. Un des ajouts les plus remarquables que nous avons fait pour le fusil de chasse est que l'IA sera plus agressive en se rapprochant du joueur, ce que nous appelons " repousser ". Des ajustements ont également été apportés à l'IA, qui sera parfois un peu plus prudente en fonction de l'arme et de la distance de la cible. Nous avons fait un bon travail de polissage et avons mis à jour les animations et les comportements pour les rendre plus meurtriers. Et avec l'ajout prochain de la Réaction aux Forces sur le joueur, si vous êtes près de l'IA Shotgun, vous serez mis à terre et pourriez être mis dans une situation compromettante. Comme toujours avec l'ajout de nouvelles fonctionnalités, il faudra un autre passage de polissage sur l'IA qui nous permettra de régler le temps pour tuer et les comportements encore plus. Todd Papy Directeur Star Citizen Live Art de l'environnement GrimHEX V2 Nous avons pu revenir à l'un des plus anciens endroits du jeu et introduire certains des éléments clés nécessaires pour en faire une zone d'atterrissage à part entière, le plus important étant l'introduction de hangars, donnant au joueur la possibilité de demander des vaisseaux de toutes tailles. De plus, dans le cadre de ce processus, nous avons réaménagé une partie de l'intérieur pour y intégrer les futures courses et paris, ce qui comprend une généreuse galerie d'observation vers l'extérieur, un bar de fortune et une zone de fauteuils, et plus particulièrement le futur espace pour le donneur de mission Luca Brunt. L'équipe a travaillé sur ces mises à jour assez rapidement et nous avons été heureux d'apporter plus de convivialité et de saveur à cet endroit. À l'avenir, nous aimerions que les contenus soient diffusés en parallèle avec le gameplay des missions spécifiques pour une expérience complète, mais pour l'instant, nous jetons les bases des futurs contenus de mission. Les hangars d'Aeroview Lorsque nous avons sorti New Babbage, nous n'avons pas pu terminer à temps les hangars dans le nouveau style artistique Hi-Tech. Donc, plutôt que de sacrifier la qualité, nous avons décidé de sortir avec les hangars existants de style utilitaire avec la marque microTech. Pour cette sortie, nous étions ravis de pouvoir présenter les nouveaux styles de hangars, qui s'adaptent beaucoup mieux à leur environnement. De plus, avec la marque Aeroview, c'est la première fois que nous voyons ce look à l'extérieur du module du hangar et dans le PU. Attendez-vous à voir d'autres marques de hangars à l'avenir. Ajouts de magasins à New Babbage Une fois les principales sorties de New Babbage terminées, il restait quelques éléments que nous voulions inclure avant de passer à l'emplacement suivant, le plus grand étant le magasin phare de microTech - The Factory Line. La vision pour le magasin était quelque chose de très élégant et exclusif ; quelque chose qui reflétait la vision du campus que l'on pouvait voir dans d'autres zones de New Babbage. Plusieurs éléments ont été testés et résolus, tels que les grands écrans animés en Building Block, la façon dont l'IA et le joueur interagissaient avec les escaliers courbes, et la façon dont le mobiGlas pouvait être changé en tant qu'objet d'inventaire. Pour l'instant, tout ce qui se trouve dans la boutique n'est pas interactif pour le joueur. Cependant, nous avons voulu construire l'espace avec tous les articles en tête pour donner une idée de ce qui va arriver dans le futur, alors attendez-vous à voir l'expérience d'achat mise à jour au fur et à mesure que les produits seront mis en ligne. De plus, gardez l'œil ouvert pour les futurs donneurs de mission de microTech Field Rep qui seront présents dans cet endroit. Nous avons également présenté le nouveau magasin d'articles de nouveauté à l'intérieur du port spatial New Babbage. L'idée est d'avoir des magasins qui vendent des objets uniques à des endroits spécifiques que les joueurs peuvent collectionner et avec lesquels ils peuvent personnaliser leur propre espace. Pour New Babbage, nous avons introduit Pico le pingouin. C'est un concept que nous voulons développer, alors attendez-vous à d'autres éléments de ce type à l'avenir. Nouvelles cartes des reliefs planétaires Dans le cadre des améliorations technologiques apportées aux planètes, nous avons pu augmenter la résolution des cartes de hauteur utilisées sur les planètes et les lunes. Auparavant, il s'agissait simplement d'augmenter la résolution des cartes originales. En redéfinissant les cartes de hauteur dans la nouvelle résolution, nous avons pu utiliser chaque pixel plus efficacement, créant ainsi plus de détails et de données dont nous pouvons tirer profit. Dans le cadre de ce processus, nous avons dû repositionner tous les lieux au sol actuellement en jeu, depuis les zones d'atterrissage jusqu'aux épaves. C'est la première étape d'une initiative en plusieurs étapes visant à mettre en œuvre les caractéristiques de la technologie planetaire au fur et à mesure de leur mise en ligne. D'autres améliorations intéressantes sont attendues prochainement. Nouveaux minéraux Avec le lancement du véhicule minier ROC, nous avons créé une nouvelle taille de minerai à utiliser. Nous avons essentiellement pris la fonctionnalité de l`objet minable à l`échelle du FPS et avons augmenté la taille en fonction des besoins du véhicule. De plus, avec le minerai Quantainium pour vaisseaux, nous voulions créer un nouveau shader qui améliore la lisibilité et donne une apparence plus dangereuse et plus volatile, reflétant les propriétés de ce matériau. Ian Leyland Directeur artistique de Star Citizen Equipe de Fonctionnalités des Acteurs Traînement de corps Le Body Dragging est un ajout systémique important au jeu car c'est l'une des caractéristiques qui sous-tendent tellement de futures boucles de jeu de base, y compris le déplacement d'une prime capturée vers votre vaisseau, le déplacement d'un cadavre hors du chemin d'une patrouille d'IA, et même le moment héroïque où vous traînez hors de la ligne de tir un coéquipier tombé au combat. À la base, cette fonction vous permet de déplacer des corps morts ou inconscients dans l'espace de jeu. Bien que cela puisse paraître simple, la mise en œuvre est assez complexe. Nous ne voulions pas que Body Dragging soit trop contraignant et nous nous sommes efforcés de faire en sorte que lorsque vous traînez un corps, les commandes et les actions du personnage restent les mêmes, de sorte que vous puissiez toujours regarder autour de vous et marcher dans la direction que vous regardez et que le corps vous suive. Cela signifie que nous avons dû utiliser une solution hybride de ragdoll pour permettre au corps de réagir à d'autres objets dans le monde tout en étant contraint à la main gauche. Cela signifiait également que nous pouvions laisser la main droite libre afin que vous puissiez utiliser des objets à une main, comme des pistolets, ou interagir avec le monde du jeu. Certains d'entre vous se demandent peut-être pourquoi nous avons ajouté le "Body Dragging" avant les boucles de jeu ci-dessus. La réponse est que nous voulions le mettre à disposition LIVE entre vos mains afin de pouvoir obtenir des réactions dans un environnement réel. Cela signifie que nous pouvons aborder tous les problèmes, comme le fait que le corps se détache trop souvent (ce sur quoi nous avons fait des analyses), avant que les choses vraiment amusantes ne soient mises en ligne. L'équipe est heureuse de la première mise en œuvre du Body Dragging, mais cela ne signifie pas que nous avons fini de travailler dessus. Nous voulons encore améliorer plusieurs aspects, notamment l'adhérence du corps à la main et l'ensemble des visuels, car l'ensemble de l'animation a été réalisé à la main au lieu d'utiliser la capture de mouvements en raison du verrouillage de la pandémie. Dommages Electron Electron Damage est le premier des nombreux types de dégâts exotiques que nous voulons ajouter au verse, et nous avons mis en ligne la Lightning Bolt Co. Aztkav et le pistolet Yubarev. Ce type de dégâts est un mélange de dégâts électriques, de distorsion et d'étourdissement. Les dommages électriques en eux-mêmes s'expliquent d'eux-mêmes - ils causent des dégâts. La distorsion et l'étourdissement, par contre, consistent plutôt à désactiver leurs cibles en utilisant des dégâts non létaux, la distorsion affectant les machines et l'étourdissement les matières organiques. La répartition des dommages n'est pas de 1:1:1 entre les trois types et peut être modifiée pour obtenir des résultats différents. Les deux armes avec lesquelles nous avons réalisé les dégâts Electron sont des armes spécifiquement létales et ont un gameplay coopératif unique. L'Aztkav est un fusil de sniper à haute puissance et à action rapide qui libère une énorme décharge électrique qui peut sauter sur les ennemis proches, donnant aux snipers leur première arme à zone d'effet dans le jeu. L'Aztkav et le Yubarev laissent également leurs cibles chargées électriquement pendant une courte période, ce qui permet aux joueurs de poursuivre avec un second tir pour provoquer une petite détonation de la zone d'effet. Nous avons été ravis de voir les nouvelles armes en service, mais ce n'est que le début pour le type de dégâts Electron, avec des ajouts futurs déjà en cours de préparation pour un jeu non létal. Richard Tyrer Directeur du jeu de base Rendez-vous dans le "Verse" ! Comme nous l'avons mentionné dans le dernier post-mortem, vous pouvez continuer à vous attendre à des post-mortems similaires sur Alpha 3.11 et sur d'autres patches à venir, car nous vous invitons à écouter nos directeurs vous parler des succès, des défis et des enseignements à la suite de chaque mise à jour. Il s'agit d'une de nos initiatives visant à donner un aperçu plus transparent de notre processus de développement ouvert. Trad : @Maarkreidi SwissStarships.org

Semaine de lancement d'Invictus et Alpha 3.9.X Postmortem Le 29 avril, nous avons lancé Alpha 3.9 - Locked Up & Loaded, puis le 22 mai, Alpha 3.9.1 et Invictus Launch Week (notre version de la Fleet Week dans le "verse"). Ce qui suit est une autopsie qui présente nos réflexions de haut niveau sur ce qui a bien fonctionné, ce qui n'a pas fonctionné, et ce que nous avons appris pour la prochaine fois. Nous pensons qu'il est très utile de vous donner un aperçu de notre processus de réflexion et nous prévoyons de vous fournir des autopsies trimestrielles par la suite. Ceux-ci devraient suivre plusieurs semaines après le lancement de notre patch. Semaine de lancement d'Invictus Postmortem Bonjour à tous les citoyens, Le mois dernier, le 2 juin, nous avons clôturé notre premier événement de la semaine de lancement de l'Invictus (également connue sous le nom de Fleet Week). Drake Interplanetary a fait échouer la fête (bien sûr), et bien que cet événement existe depuis des décennies dans le verse, dans le monde réel, c'était notre tout premier. À bien des égards, ce fut un succès incroyable qui a massivement dépassé toutes nos attentes. Nous avons décidé de vous donner un aperçu du type d'événements que nous prévoyons d'organiser à l'avenir. L'univers de Star Citizen est censé être vivant et dynamique, plus que tout autre MMO avant lui. Et bien que nous soyons encore en alpha et que nous ayons encore du chemin à parcourir, nous sommes déjà un jeu actif. C'est pourquoi nous voulions à la fois démontrer un peu ce que pourrait être un événement en direct dans notre jeu et tester un certain nombre de premières, notamment l'introduction de nos énormes vaisseaux capitaux, les déclencheurs d'événements et une intégration beaucoup plus étroite entre les événements en jeu et hors jeu. La combinaison d'Invictus, d'un Free Fly et du lancement d'Alpha 3.9 a permis d'obtenir non seulement le meilleur mois de mai jamais enregistré, mais aussi le meilleur mois de tous les paramètres que nous utilisons pour mesurer le succès. Notre financement est public et beaucoup d'entre vous ont déjà pu constater que le mois de mai a été notre meilleur mois pour les recettes. Mais ce qui est encore plus gratifiant pour nous, c'est l'engagement et la croissance sans précédent des joueurs que nous avons constatés dans la création de nouveaux comptes, l'afflux de nouveaux et d'anciens joueurs et les records de simultanéité. Grâce à l'attrait des vaisseaux capitaux et du Free Fly, le mois de mai 2020 a battu de 50 % notre record de joueurs uniques actifs par mois. Pendant Invictus, nous avons atteint nos plus hauts totaux en termes de joueurs uniques, d'actifs quotidiens et de simultanéité maximale. Le premier jour de la semaine de lancement d'Invictus, le 22 mai, nous avons atteint notre plus grand nombre d'utilisateurs actifs quotidiens (DAU). Et chaque jour suivant, pendant toute la semaine, était encore plus élevé, car nous avons enregistré plus d'une semaine de DAU records. En fait, tant de joueurs se sont connectés à Star Citizen pendant la semaine que le nombre d'utilisateurs uniques pour les 12 jours de l'événement a été supérieur à celui de chaque mois jusqu'à ce point dans notre histoire. Comme pour de nombreux jeux et services qui connaissent des records de trafic et de simultanéité, la cohue des utilisateurs a mis nos services à rude épreuve. Au début de l'événement, nous avons connu des pannes de serveur et une dégradation des performances en raison de la surcharge des utilisateurs. Alors que nos équipes de backend travaillaient 24 heures sur 24 et tout le week-end pour résoudre les problèmes et remettre le jeu en marche, il était encore décevant pour nous d'avoir une telle interruption de service. Au début de la semaine de lancement d'Invictus, nous pensions pouvoir faire face à l'afflux de nouveaux joueurs. D'une part, le mois de mai est généralement un mois à faible trafic pour nous, ce qui a été l'une des raisons pour lesquelles nous l'avons utilisé pour notre premier événement Invictus. Deuxièmement, en utilisant quatre années de données de service en direct remontant à Alpha 2.0, nous avons estimé une assez forte poussée de joueurs supérieure à celle d'Alpha 3.5 Free Fly de l'année dernière (mai 2019), mais toujours légèrement inférieure à nos chiffres de novembre et décembre (nos mois les plus chargés en raison du trafic des fêtes et de l'événement Intergalactic Aerospace Expo). Mais comme vous le savez maintenant, la semaine de la flotte a brisé toutes les attentes. L'excitation de voir (et de détourner ou détruire) des Lightning, des Idris et des Javelins, une promotion de type IAE et un Free Fly ont convergé pour créer notre meilleur mois d'engagement à ce jour. Invictus a plus que doublé le nombre total d'utilisateurs uniques, de nouveaux utilisateurs et de DAU de notre événement Alpha 3.5 Free Fly en mai dernier. Et pendant le premier week-end de la semaine de lancement d'Invictus, le nombre de connexions simultanées et de connexions uniques quotidiennes a été dix fois supérieur à la normale. Au lieu d'être un événement qui rivalise avec l'IAE de novembre ou la sortie du patch Alpha 3.8 de décembre, la semaine de lancement d'Invictus a dépassé ces deux événements, puisque mai 2020 est devenu le plus grand mois de notre histoire. En nous basant sur ce que nous savions au début de la semaine, et sur une partie du travail que nous avons fait sur Alpha 3.8, nous pensions pouvoir gérer la charge à court terme pendant l'événement, mais nous avons sous-estimé le nombre de personnes qui se sont connectées pour jouer. La réalité est que nous savions que notre technologie de première génération (qui abonde en singletons) et les formats de données et schémas d'utilisation inefficaces (du côté client/serveur) auraient des problèmes d'extensibilité au-delà d'un certain nombre d'utilisateurs. C'est pourquoi, depuis quelques années, l'équipe chargée du backend travaille d'arrache-pied pour remédier à ces problèmes, et les premiers fruits de ce travail devraient arriver au quatrième trimestre 2020. La principale erreur de notre part a été de penser que notre technologie de première génération pourrait tenir encore quelques trimestres. En outre, nous n'avons pas réalisé l'impact que la première version de la persistance à long terme, activée dans Alpha 3.8.1, aurait sur la taille des extractions de la base de données alors que nous avons augmenté le nombre de joueurs à un niveau sans précédent. Comme nous ne réinitialisons pas tous les comptes des joueurs à chaque nouveau patch (sauf si nous y sommes obligés), et que nous n'avons pas actuellement de limites sur le nombre d'objets que les gens peuvent avoir, de nombreux joueurs avaient des milliers d'objets contre seulement quelques dizaines. La charge des joueurs et les solutions provisoires de persistance ont toutes provoqué une tempête parfaite, entraînant des problèmes de serveur pour un certain nombre de joueurs. Bien que le malheureux inconvénient de cette situation ait été la dégradation des performances et de la stabilité que nous avons dû rapidement corriger, il y a eu un réel avantage à ce trafic sans précédent, aussi douloureux et décevant que les problèmes aient été. Seul un événement de cette ampleur, avec la charge massive de la semaine de lancement d'Invictus, aurait pu mettre en évidence ces faiblesses à court terme. Nous développons aujourd'hui des systèmes, tels que iCache et l'inventaire physique, qui seront capables de gérer le trafic accru des joueurs ; cependant, ils ne sont pas encore déployés. Mais grâce à ce que nous avons vu pendant Invictus, nous mettons en ligne plus tôt que prévu certains éléments de notre technologie évolutive en cours de développement. Cela nous permettra de faire face à l'augmentation de la charge que notre engagement croissant et notre persistance à long terme ont entraînée. Les solutions à nos goulets d'étranglement les plus flagrants devraient commencer à être mises en place dans le courant de l'année, mais il y aura encore du travail à faire dans les trimestres à venir. Bien qu'il puisse être frustrant d'éprouver ces difficultés de croissance avec nous, c'est exactement la raison pour laquelle les tests de jeu en direct que la communauté effectue maintenant sont essentiels ; nous ne voyons tout simplement pas les mêmes charges et les mêmes comportements de joueurs en interne, dans les Evocati, ou même dans le PTU. Ce n'est que lorsque le jeu est joué dans notre environnement live à l'échelle que nous obtenons les véritables tests en situation réelle dont nous avons besoin pour améliorer notre service. Donc, même si nous savons qu'il est frustrant de rencontrer ces problèmes, l'exposition à ce stade nous donne la possibilité de rendre nos systèmes plus robustes et évolutifs plus tôt que ce ne serait normalement le cas. Notre popularité lors de la semaine de lancement d'Invictus et la croissance sans précédent du jeu au cours des huit derniers mois nous ont montré que de plus en plus de joueurs viennent découvrir Star Citizen. Et cela a fait de l'évolutivité une priorité encore plus grande pour nous qu'avant la semaine de lancement d'Invictus. Nous voulons que les gens puissent tester, jouer et vivre l'expérience Star Citizen. Après tout, notre vision est d'avoir, à terme, non pas des centaines de milliers mais des millions de joueurs dans le " verse ". Ainsi, bien que les problèmes techniques rencontrés lors d'Invictus aient été effectivement douloureux, nous en sommes sortis avec un effort renouvelé et des actions immédiates pour nous préparer à nous adapter à des choses plus grandes et meilleures plus tard dans l'année et au-delà. Et cela signifie que des millions de personnes supplémentaires pourront profiter d'une meilleure expérience Star Citizen grâce aux enseignements tirés de la semaine de lancement d'Invictus. -CIG ALPHA 3.9.X POSTMORTEM Alpha 3.9 a introduit une bonne quantité de nouveaux contenus, de nouvelles fonctionnalités et d'améliorations aux fonctionnalités existantes. Nous avons non seulement ajouté le centre de réadaptation de Klescher et le jeu d'évasion de prison, mais nous avons également dévoilé la zone d'atterrissage de New Babbage, les lunes de MicroTech, la liste d'amis unifiée pour une meilleure initiation au jeu de groupe, la nouvelle mission Caterpillar "Price of Freedom", et bien d'autres choses encore. Pour cette première autopsie, nous examinons les caractéristiques les plus importantes d'Alpha 3.9.X de manière plus large et plus approfondie. Nous ne sommes pas aussi exhaustifs et nous pourrions modifier le format tout en trouvant le bon équilibre entre le fait de donner un aperçu significatif et de ne pas s'enliser dans les détails. Ici, nous avons demandé à nos réalisateurs d'évaluer ce qui a bien fonctionné, ce qui n'a pas fonctionné et ce que nous avons appris. Les prisons Le premier trimestre de 2020 a vu une amélioration majeure du système juridique de Star Citizen sous la forme de prisons, qui permet de punir les comportements criminels. La première itération comprend un autre niveau de travail de base mais reste assez sommaire par rapport à ce que nous avons l'intention de faire. Par exemple, nous savions dès le départ qu'être enfermé n'allait pas être particulièrement amusant ; à part quelques mines de FPS, il n'y avait pas encore assez de variété pour divertir la plupart des joueurs pendant une longue période. Il était néanmoins important de mettre en place cette fonctionnalité, car elle améliore la jouabilité des autres jeux. En effet, il y a maintenant un risque réel - sous la forme de temps, par opposition à la perte d'aUEC et d'un respawn - de crimes graves comme le meurtre et la contrebande qui n'existaient pas auparavant, et cela poursuit la tendance à laisser aux joueurs une liberté totale mais à la repousser de manière logique et appropriée. Il était également important pour nous de commencer à rassembler des informations sur la manière dont ces mécanismes affectent le comportement des joueurs, de savoir si le risque d'emprisonnement dissuade certains types de comportement et dans quelle mesure. Au cours du deuxième trimestre, nous avons trouvé et corrigé plusieurs bogues importants, dont le plus connu est celui où, à la sortie de prison, l'écran s'éteint et ne se rallume jamais. Les machines des kiosques vont maintenant se briser de temps en temps et générer une mission de réparation, ce qui devrait attirer pas mal d'intérêt étant donné le nombre de mérites qu'elle attribue par rapport à ce que vous pouvez réaliser dans l'exploitation minière. Nous ajouterons un certain nombre d'autres missions de prison dans le futur. Le troisième trimestre sera marqué par plusieurs petites améliorations notables, notamment la possibilité de se rendre aux forces de l'ordre à tout moment pendant une bataille, une exploitation supplémentaire de la mécanique de mise en fourrière des vaisseaux, et des kiosques d'économat en état de marche qui permettent aux prisonniers d'acheter des choses avec les mérites qu'ils ont gagnés. Les portes verrouillées, les cartes d'accès et les codes vont commencer à jouer un rôle de plus en plus important. La voie d'évacuation de la prison sera modifiée de telle sorte que l'accès aux tunnels nécessite de trouver d'abord un code de sécurité, et nous compléterons cela dans une prochaine version en rendant le processus d'extraction considérablement plus difficile. Quelques rovers verrouillés à l'extérieur de la prison récompenseront les joueurs qui ont eu la prévoyance de voler les codes d'accès par une fuite rapide. Le départ de la prison sera finalement plus étroitement intégré dans le jeu, de sorte qu'après avoir purgé votre peine, vous serez transporté par vaisseau vers une zone d'atterrissage pour être libéré, plutôt que de compter, comme c'est le cas actuellement, sur un fondu enchaîné et une téléportation. Il y a également beaucoup de travail à faire du côté de l'IA pour que les gardiens et les détenus contribuent à donner à la zone l'apparence et l'impression d'être une prison. Pour éviter que les lacunes initiales du système ne soient trop prononcées, nous avons limité temporairement la durée des peines et veillé à inclure un moyen d'échapper prématurément à votre détention, au risque toutefois d'un niveau de recherche plus élevé et - en cas de récupération - d'une peine encore plus longue. C'est assez simpliste pour l'instant (essentiellement un labyrinthe dans lequel il faut naviguer avant de manquer d'oxygène) et un autre bon exemple des domaines dans lesquels nous avons l'intention d'apporter de sérieuses améliorations. L'une des principales améliorations prévues pour l'année prochaine consistera à injecter beaucoup de furtivité, de timing et de diversion dans le processus d'évasion afin que celui-ci soit beaucoup plus amusant et stimulant. L'année prochaine, nous offrirons également de nombreuses possibilités de combats de mêlée dans les prisons - notamment le concept de gangs - et nous introduirons certains personnages clés qui donnent des missions. Il s'agira notamment d'un gardien véreux et d'un boss criminel puissant avec qui vous pourrez commencer à forger une relation, qui pourrait s'avérer très précieuse à l'extérieur, à condition que vous n'ayez pas tiré de leçon de votre incarcération et que vous cherchiez à poursuivre une vie de criminel. L'objectif ultime des prisons au sein de Star Citizen est en fait un peu ironique dans la mesure où, alors qu'elles sont destinées à servir de punition et que la plupart des joueurs feront de leur mieux pour l'éviter, nous voulons nous assurer qu'elles sont si amusantes et intéressantes que les joueurs les considéreront simplement comme un ensemble différent d'opportunités à exploiter et de défis à résoudre. -Tony Zurovec, directeur de l'Univers Persistant Statut de l'acteur Le système de statut de l'acteur (appelé à l'origine statut du joueur) est un objectif depuis le tout début du projet et vit maintenant dans Alpha 3.9, avec le système et une majorité de fonctionnalités en place. Il s'agit d'un système incroyablement impliqué qui couvre l'ensemble du jeu et qui vise à relier entre eux de nombreux aspects des personnages, de l'animation, des environnements, des objets et plus encore, pour des résultats différents, qu'il s'agisse de la faim, de la soif, de la chaleur, du froid, du vent, de la vision ou du mouvement. Il remplace ce qui était un système très simple où le joueur suffoquait (et se faisait tuer) lorsqu'il était exposé à l'espace. Le personnage du joueur est désormais notamment affecté par l'environnement de multiples façons. Et grâce à ce système, non seulement les environnements varient considérablement sur le plan visuel, mais ils comportent désormais des éléments de jeu significatifs qui permettent de créer des identités spécifiques. Par exemple, une planète peut être froide, ce qui ne permet de survivre que dans certains vêtements pendant un temps donné, mais peut comporter des geysers pour créer des poches de chaleur. Le système lui-même a été achevé ; cependant, il existe une conception robuste dont les aspects étroitement liés restent à venir dans Star Citizen, notamment le poids, les effets de la drogue et les dangers plus exotiques qui dépendent d'autres caractéristiques à venir, comme l'inventaire physique. Ce système a été assez difficile à concevoir, tout d'abord en raison de la simple interconnexion entre ce qui, à la surface, pourrait sembler être des éléments disparates, et ensuite en raison de l'approximation du comportement du monde réel, comme la convection de chaleur dans des environnements extrêmes. En outre, la mise à l'épreuve du système pour des caractéristiques qui n'ont pas encore été ajoutées a ajouté à ce défi. Enfin, le soutien de nombreuses équipes internes différentes a constitué une entreprise de production sérieuse, qu'il s'agisse des graphismes et des effets visuels pour les effets sur la vision du joueur, de l'audio pour une audition silencieuse pendant l'hypothermie, des personnages pour l'armure/les vêtements pour la température et la protection contre les intempéries (ou non !), de l'interface utilisateur pour le feedback au joueur, du design FPS pour l'endurance et le rééquilibrage du cœur, de l'animation pour l'ensemble de l'effort et le lever de la main dans les vents violents sans casque, et des accessoires pour l'animation complexe et l'interaction avec les aliments et les boissons. Tout cela a été rendu encore plus difficile à développer car les environnements, les planètes et les vaisseaux devaient avoir des données gérées de manière rigide et correctement équilibrées, sinon cela poserait des problèmes avec tous ces systèmes. Nous n'aurions pas pu simplement laisser le déclencheur de la mise à mort pour "dans l'atmosphère" ; Star Citizen exige une immersion plus profonde que cela. Maintenant, la conception, par le biais de l'environnement dans lequel le joueur existe, peut créer des effets complexes et prévoir que les joueurs devront s'approvisionner de manière appropriée, comme ne pas aller dans le désert sans eau ou ne pas plonger dans une grotte glacée sans combinaison environnementale. En fin de compte, nous sommes assez satisfaits de la manière dont cette fonctionnalité et ce système ont été intégrés et nous espérons y connecter d'autres systèmes. Service unifié des Amis L'unification de notre service des amis a été considérée comme la plus grande priorité pour l'une de nos équipes internes du PU, l'objectif principal étant de faciliter au maximum le regroupement et la participation aux jeux au sein de Star Citizen. Bien que cela ait toujours été possible, il est maintenant beaucoup plus facile de voir ses amis, de voir où ils jouent, de se joindre à un groupe et de se lancer dans le jeu ensemble. Cela a créé beaucoup plus de travail que prévu, car il fallait un nouveau service pour unifier les éléments disparates et assurer un lien en temps réel entre les contacts de Spectrum et le jeu. Cela se répercute également sur le jeu lui-même, qui a mis à jour la notification des demandes d'amis et la formation automatique de groupes dans le jeu, un concept au sein du PU pour le chat, la VOIP (Voice Over IP) et la FOIP (Face Over IP). La liaison de Spectrum avec le front-end puis avec le jeu semble évidente, mais elle a souffert du fait que différents systèmes ont été mis en place à des moments très différents, et il était grand temps de faire le ménage. Le front-end UI présente ses propres défis car, techniquement, il est un mélange de notre nouvelle technologie Building Blocks et de l'ancien Flash. Comme cela peut rompre le flux complet, notre équipe a évité de changer complètement le frontal et a plutôt choisi de faire de nouveaux éléments à partir des Building Blocks mais de laisser le reste tel quel. Cela a été très restrictif et a eu pour effet de nous laisser avec une interface utilisateur fonctionnelle qui n'est pas aussi lisse qu'on pourrait le penser. Bien que nous soyons satisfaits des fonctionnalités que nous offre la liste de contacts/amis, en tant que jeu très social, nous continuerons à travailler dans ce domaine afin de garantir une interface et un ensemble de fonctionnalités que vous attendez d'un jeu multijoueur moderne et de rendre le jeu aussi facile que possible pour vos amis. Support AC/SM Party et Chat en jeu/VOIP/FOIP Arena Commander et Star Marine n'ont jamais eu un système de chat à part entière. Pendant un certain temps, il y avait des commandes obtuses (appuyer sur différentes combinaisons de touches connues de quelques-uns seulement) qui déclenchaient une commande du serveur pour "dire" à tous, mais ce n'était pas quelque chose qui était utilisé par la plupart et il était inaccessible aux nouveaux joueurs. Bien qu'acceptable dans les tout premiers temps de Star Citizen, en tant que premier module de jeu, il n'avait pas suivi le système de groupes développé pour l'Univers Persistant. Aujourd'hui, AC et SM partagent le même système d'amis et un système de groupe similaire à celui du service mentionné plus haut. Vous pouvez maintenant vous regrouper et vous lancer dans Arena Commander ou Star Marine tout comme vous pouvez le faire dans l'Univers Persistant, ce qui permet de jouer en groupe et en coopération. Ceci a été encouragé par les besoins du mode de jeu Star Marine et de Theaters of War (titre provisoire), qui encourage les groupes à bord des véhicules (les artilleurs et les chauffeurs se parlant) ainsi que les rassemblements et les regroupements pour les matchs. Les principaux défis sont le nombre variable de joueurs que chaque mode de jeu peut supporter et les différentes configurations de serveur qui fonctionnent pour les modes par session par rapport à un jeu persistant et perpétuel. D'autres difficultés sont similaires à celles mentionnées pour le front-end et une immense quantité de Flash a été mise en place en attendant et conçue pour un concept de lobby très différent. Dans le PU, bien qu'il y ait du matchmaking, les exigences ne sont pas les mêmes que dans l'AC/SM. Une victime malheureuse de la mise à jour actuelle est le lobby privé des matchs, qui n'a pas pu être mis à jour à temps. Nous aurions préféré ne pas le désactiver. Bien que vous puissiez toujours vous regrouper et lancer des matchs, il n'est actuellement pas possible de les verrouiller, mais nous allons aborder cette question dans les prochaines mises à jour. Cycle AC/SM Dans les versions précédentes d'Arena Commander et de Star Marine, les joueurs étaient expulsés au menu lorsque les matchs se terminaient. Il y avait des défis et des problèmes techniques pour avoir fait cela dans le passé, car lorsque Arena Commander a été lancé à l'origine, ce n'était pas le cas. Arena Commander et Star Marine rechargeaient leurs cartes sur le serveur, ce qui est totalement différent de l'Univers Persistant, qui n'a jamais besoin de recharger les cartes. C'était incroyablement important pour Arena Commander et Star Marine, car la durée des sessions de jeu était réduite et les joueurs étaient sans doute encouragés à quitter le jeu à la fin du tour, car ils étaient expulsés et devaient retourner dans les différents menus pour revenir. Nous avons réussi à contourner certains des obstacles techniques et nous avons mis en place un cycle de rondes, de sorte que les joueurs bénéficient désormais d'une expérience de jeu correcte et perpétuelle. Cependant, les questions fondamentales n'ont pas été abordées, à savoir les recharges propres tout en gardant les joueurs groupés avec leurs amis et le match fait dans un nouveau tour. Cela a considérablement augmenté la durée des sessions de jeu et la simultanéité des joueurs dans les deux modes. Un autre changement a été la mise à jour de nos règles de joint-in-progress, qui au fil du temps sont devenues inadaptées à la plupart des modes et qui évitent aux joueurs de jouer des matchs déjà commencés. Pensée intérieure personnelle Radial Le système de pensée intérieure personnelle était techniquement en jeu dans un état très rudimentaire derrière une cvar ; certaines versions l'avaient exposé et d'autres non. Il ne permettait pas d'atteindre pleinement l'objectif de pouvoir cartographier n'importe quelle touche pour n'importe quelle interaction à la volée, et plus important encore, de pouvoir effectuer des actions dans tous les contextes. Les équipes de programmation et de conception ont fait un travail incroyable sur cette fonctionnalité car Star Citizen a des centaines d'actions potentielles en fonction du contexte dans lequel vous vous trouvez et les mappages de touches par défaut deviennent de plus en plus complexes et beaucoup moins accessibles. Cette fonctionnalité a même permis à certains développeurs de découvrir des actions dont ils ignoraient l'existence ou qui n'étaient pas partagées dans les mappages de touches par défaut, qu'il s'agisse d'allumer une lampe sur une arme ou de déployer des rampes et des portes de chargement. Il expose également les émotes et les activités des autres joueurs lorsqu'ils sont à pied. Il ne faut cependant pas confondre ce système avec le système d'interaction des joueurs, qui sera également traité à l'avenir en fonction d'interactions spécifiques et contextuelles avec des objets. Une fois de plus, le défi était de taille, non seulement pour mettre à jour et remplacer l'ancienne implémentation de base, mais aussi pour mettre en œuvre l'interface utilisateur et la cartographie des touches en temps réel sur les centaines d'actions, mais cela en valait vraiment la peine. -Sean Tracy, Directeur technique, Contenu -Richard Tyrer, directeur du pilier de combat New Babbage v2 C'est sans doute l'une des zones d'atterrissage les plus vastes et les plus complexes que nous ayons réalisées jusqu'à présent. Par rapport aux zones d'atterrissage précédentes, nous avons essayé de donner plus de liberté au joueur pour explorer l'endroit et d'améliorer l'accessibilité du joueur à la planète par l'introduction d'entrées de surface. Pour l'avenir, nous souhaitons continuer à améliorer cette expérience pour qu'elle soit aussi fluide que possible. New Babbage présente une extension du style architectural Hi-Tech, qui est présenté pour la première fois depuis que nous avons conçu les avant-postes. L'équipe s'est beaucoup amusée à développer le langage architectural et la façon dont il s'adapte à l'histoire du lieu et du climat. New Babbage a également utilisé nos nouvelles caractéristiques d'éclairage, ce qui signifie que nous pouvons concevoir des scénarios d'éclairage en fonction de l'heure de la journée. Pendant le développement de The Promenade, nous nous sommes beaucoup amusés avec cette fonction car elle nous permet de créer de multiples ambiances et expériences dans un même espace. En ce moment, nous mettons en œuvre des conceptions d'éclairage de jour et de nuit dans certains lieux existants, alors gardez l'œil ouvert. À l'intérieur des dômes de New Babbage, nous avons divers éléments botaniques exotiques et artificiels, avec des écrans d'affichage qui donnent un aperçu de l'histoire. C'est le premier pas vers l'intégration de l'histoire riche et complexe d'un lieu dans l'environnement du jeu pour que les joueurs puissent la découvrir. Stations orbitales basses autour des planètes L'expérience de pouvoir se tenir sur un pont d'observation dans une station spatiale et de regarder un lever de soleil planétaire est une chose que nous voulions mettre dans le jeu depuis un certain temps. De plus, pouvoir voir la même station depuis le sol, c'est ce que représente l'échelle dans Star Citizen. La prison automatisée de Klescher Comme contraste parfait avec le climat intérieur chaud, nous avons introduit dans le jeu le premier emplacement de prison. C'était la première sortie où nous avons livré deux emplacements terrestres majeurs en même temps. Nous voulions maximiser le travail de développement des grottes que nous avons déjà fait, nous avons donc conçu le centre de distribution pour qu'il se nourrisse d'un réseau de grottes tentaculaire. Cela a donné l'espace parfait pour essayer de travailler sur votre peine. Le parcours d'évasion comportait une variété de traversées avancées ainsi qu'un thème visuel donnant l'impression que vous traversez les différentes couches de l'infrastructure. À l'avenir, nous aimerions étendre cette expérience et introduire plus de complexité pour mettre au défi l'évadé. Les lunes de microTech Calliope, Clio et Euterpe nous ont permis de voir à quel point la nouvelle technologie Planetary v4 serait flexible pour nous. L'idée était de voir à quelle vitesse nous pourrions définir une identité visuelle unique pour ces lunes en utilisant les packs d'assets du biome existants que nous avions déjà créés. Avec l'introduction du statut de joueur, nous avons également pu définir des climats extrêmement froids et hostiles pour compléter les paysages arides. -Ian Leyland, directeur artistique de Star Citizen Mission "price of Freedom" Nous l'avons construite assez rapidement, car elle a permis de mettre à profit une grande partie de ce que nous avons appris lors de la création de la mission 890 Jump (URGENT : Boarding Action in Progress). L'objectif était de fournir une variante illicite de la mission 890 Jump qui ferait partie de l'expérience d'un donneur de mission. Cela signifie qu'elle est partiellement sur mesure, plus approfondie dans sa conception, et qu'elle a une boucle de jeu globale pour le type de mission. Lors de la conception de cette mission, nous savions que nous voulions nous appuyer sur le mélange de navigation de base, à savoir le vol, les EVA et la traversée au sol. Ensuite, nous avons saupoudré un scénario de combat unique dans un vaisseau spatial que le joueur doit résoudre de multiples façons différentes. Chaque fois que nous construisons une nouvelle mission, nous nous heurtons toujours à des difficultés, que ce soit du côté du développement ou des bogues dans nos systèmes. En voici quelques exemples : Le concepteur devait apprendre la nouvelle technologie des blocs de construction de l'interface utilisateur Le premier passage de collision sur le Caterpillar n'était pas prévu pour le tir du FPS À l'origine, l'ordinateur portable était censé être un bloc de données que le joueur devait faire défiler pour trouver les bons contacts. Cependant, en raison de contraintes de temps, nous avons dû utiliser l'ordinateur portable L'équipe a dû faire face à des obstacles techniques dans les zones de VIS du Caterpillar. Dans l'ensemble, nous sommes extrêmement satisfaits du résultat de la mission et nous espérons que tout le monde aura la chance d'y participer. -Todd Papy, réalisateur de Star Citizen Live À l'avenir, attendez-vous à lire des articles similaires sur Alpha 3.10 et les correctifs à venir, car nous vous invitons à entendre nos directeurs vous parler des succès, des défis et des enseignements à la suite de chaque mise à jour. Parallèlement à notre objectif de remanier notre feuille de route pour qu'elle reflète davantage les progrès réalisés (restez à l'écoute pour plus de nouvelles à ce sujet prochainement), il s'agit d'une de nos initiatives visant à fournir un regard plus transparent sur notre processus de développement ouvert. Trad : @Maarkreidi SwissStarships.org