Autopsie de l'Alpha 3.11
Rapports et Synthèses

Le 8 octobre 2020, CIG a lancé l'Alpha 3.11 High Impact qui a introduit un certain nombre de nouvelles caractéristiques 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 une analyse 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é.

Le compte-rendu est divisé en cinq chapitres :

• Compte-rendu de l'équipe Véhicules, par John Crewe, Vehicle Director.
  Plus léger que le compte-rendu de la 3.10, Jhon Crewe fait un point sur la série 100 d'Origin et la mise en place de la refonte des missiles et contre-mesures.

• Compte-rendu de l'équipe des Technologies, par Marco Corbetta, VP of Technology.
  C'est l'occasion de faire le point sur les aspects techniques du développement de Star Citizen. Si cette 3.11 n'a pas la réputation d'être "riche en contenu" aux dires des joueurs, il n'en reste pas moins qu'elle est riche en contenu technique et que cela mérite de s'y attarder.

• Compte-rendu sur le Core Gemaplay, par Richard Tyrer, Core Gameplay Director.
  Un gros chapitre sur les améliorations du Gameplay, avec les débuts de la gestion de l'inventaire externe FPS et du Greycat ROC, la mise en place des réactions de force, la première itération du lancé et l'arrivée du lance-grenade et du fusil de Berhing.

• Compte-rendu de l'équipe Environnement, par Ian Leyland, Star Citizen Art Director.
  Rapide réflexion sur le seul contenu visuel de ce patch qui n'est autre que les ponts de cargaison, ainsi qu'un regard sur l'amélioration visuel des surfaces des planètes.

• Compte-rendu de l'équipe Design, par Luke Pressley, Lead Designer.
  Un dernier point sur la suppression des zones d'armistices.

Équipe des véhicules

Le pilier véhicules a eu un trimestre beaucoup plus calme avec l'Alpha 3.11 par rapport à la prestation du butoir de l'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 navire de départ alternatif au jeu ainsi qu'un chasseur léger et un transporteur de fret léger. Ce sont des petits vaisseaux fantastiques avec lesquels les nouveaux joueurs peuvent commencer leur voyage de citoyen des étoiles et qui leur permettent de s'attaquer à un large éventail de missions et d'explorer les confins du Verse.

Missiles et contre-mesures

Le jeu de missiles et de contre-mesures a été utilisé dans divers pays au fil des ans 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 l'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 usurper 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 certains missiles, et une solution de contournement maintenant redondante, créée à l'origine pour un niveau spécifique de SQ42 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 à "frapper-une-taupe" 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 le PU).

Un ajout futur que nous n'avons pas pu faire à temps pour l'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 informatiques des navires.

• Chaque véhicule n'a droit qu'à quatre verrous à 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 pollupostage des missiles a été considérablement réduit, et le méta a évolué vers des navires 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 navires é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 navires 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 navires 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, Vehicle Director

Technologie

Système de "décalcomanie en toile"

Pour Alpha 3.11, l'équipe graphique a fourni la technologie de rendu sous-jacente pour aider à alimenter le système de "décalcomanie sur toile", qui utilise le système Building Blocks pour créer des textures de décalcomanie à 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 décalcomanies créées au moment de l'exécution est que nous pouvons utiliser des données de 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é au 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 décalques de toile dans le streaming de texture a entraîné plusieurs crashs dans le PTU qui étaient 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 largage 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 intégrons maintenant également les données de radiométrie du soleil 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 agréable aux vaisseaux capitaux ou aux lunes en orbite autour des planètes.

Engine

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é SSE (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 en physique, le moteur 3D et le 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'avoir 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 de l'Alpha 3.11, l'équipe du Core Engine 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.

"Canvas Slicer"

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 holographiques de navires 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, VP of Technology

Core Gameplay

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 FPS entre leur sac à dos, leurs poches de poitrine et 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 l'Alpha 3.11, cette fonction n'est activée que pour le compartiment de stockage du Greycat ROC, afin que les joueurs puissent gérer leurs objets miniers FPS. Mais, à l'avenir et une fois que nous aurons réalisé un véritable stockage d'objets (étayé par l'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 UI d'inventaire 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 pour gérer 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 AR 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 direct et d'obtenir autant de commentaires 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 : les démolitions.

Dans l'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 lors de vents soutenus. Dans l'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 d'abattages, avec l'intention d'échelonner les combats 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 navire 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 avec différentes échelles et permettre aux concepteurs d'équilibrer la réaction du personnage en conséquence, car les forces d'être frappé par 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 coups de poing seraient inévitables. Nous avons passé beaucoup de temps à nous assurer que les animations d'abattage étaient très réactives au contrôle du joueur dès que son 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 l'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 quand on pense qu'on a cette occasion parfaite d'effectuer un multi-kill pour que la grenade ne se matérialise qu'à quelques mètres de vous. Donc, la première chose que nous voulions réaliser avec la 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 l'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 la 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 et fusil BR2 de Behring

Depuis que je dirige 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 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 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 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 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 libérer 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 tuer 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 lequel nous allons travailler.

Dernières réflexions

Si je regarde toutes les fonctionnalités que le pilier Core Gameplay a fourni pour l'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 œuvre 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'ils réagissent 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 fonctionnalité 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, Core Gameplay Director

Environnements

Ponts de cargaison

Pour ce communiqué, 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. Cela comprend une section d'un entrepôt d'expédition qui, à l'avenir, sera un bac à sable pour le contenu des missions. 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 navires est situé sur le côté, et la zone de guilde et de fournitures 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 de la planète

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 un repeinturage global de toutes les planètes et de toutes 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 heightmaps, 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 de la procédure, à la couleur du terrain ou du substratum rocheux. De plus, nous avons pu ajouter la tessellation et le déplacement des actifs sur une base par objet, ce qui signifie que nous pouvons attribuer des cartes de hauteur aux actifs qui déterminent les paramètres de déplacement. En bref, cela signifie que lorsque le joueur s'approche d'un actif, il devrait avoir une résolution géométrique 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 diverse et merveilleuse pour les futurs emplacements de Star Citizen.

Réflexions finales

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 de la planète. 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 impliqués 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 cargaison, 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 Director

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 traiter n'importe quel navire prévu 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'il soit encore assez simpliste, additionne les statistiques criminelles de tous les acteurs de la zone (connu en interne sous le nom de "chaleur") et engendre des navires de sécurité de plus en plus nombreux et puissants en réponse. Le système réagit rapidement à l'augmentation de la chaleur dans une zone en créant de nouveaux navires et en détruisant les navires plus faibles qu'ils remplacent. Le système réagit plus lentement à la mort de ses membres (si la chaleur n'augmente pas) et encore plus lentement à la diminution de la chaleur. Nous développerons ce système à l'avenir pour tenir compte également des navires 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 en direct a dû être extrêmement vigilante et rapide à réagir aux problèmes étant donné le peu de temps que l'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 faire frayer rapidement des navires sur des serveurs locaux, ce n'était pas le cas sur un serveur en direct. 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 frayères demandées.

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 à le reproduire dans un avenir pas trop lointain.

Réflexions finales

Pour l'avenir, nous prévoyons également d'assouplir les limitations 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 placards à frai qui nous permettra de former 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épondre aux intrus, à ceux qui ont des statistiques criminelles ou à ceux qui sont en train de commettre des crimes.

-- Luke Pressley, Lead Designer