Autopsie de l’alpha 3.11

Traduction: Hotaru, insosama, odysseus1992
Relecture: insosama, odysseus1992, Ra'Zacs
Intégration: odysseus1992

3.10 | 3.12

Le 8 octobre 2020, nous avons sorti l’alpha 3.11 “Impact fort” qui a introduit un certain nombre de nouvelles fonctionnalités et de changements, notamment les quais de chargement, les réactions aux contraintes de force, et la première étape de la suppression des zones d’armistice. Ce qui suit est une “autopsie” réalisée par les développeurs “seniors” eux-mêmes, détaillant ce qui a été livré et leurs réflexions sur la façon dont cela s’est déroulé.


AUTOPSIE DE L’ALPHA 3.11

Équipe chargée des véhicules

Le bloc véhicules a eu un trimestre plus léger avec l’alpha 3.11 par rapport à la riche livraison 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 dans l’alpha 3.11, comprenant le 100i, le 125a et le 135c. La série 100 ajoute un vaisseau starter 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[1] et qui leur permettent de s’attaquer à un large éventail de missions et d’explorer les profondeurs du ‘verse.

Missiles & contre-mesures

Le gameplay de missiles et de contre-mesures a été dans divers états au fil des ans et n’a jamais été vraiment agréable, que ça du côté des agresseurs ou des défenseurs. Nous avons l’intention de corriger cela avec le mode d’opérateur des missiles, mais en attendant, nous avons décidé de passer du temps à mettre en place des correctifs et des itérations sur ce gameplay afin de 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 :

  1. Les contre-mesures n’agissaient que sur les missiles infrarouges (leurres) et les missiles électromagnétiques (paillettes).
  2. Seules les fusées éclairantes fonctionnaient (parfois et fortement dépendant de l’état du serveur).
  3. Il n’y avait pas de contre-mesures disponibles pour leurrer les missiles à surface équivalente radar[2].
  4. Le tir de missiles était extrêmement facile, la défense contre les missiles était extrêmement difficile.

Tout d’abord, nous avons cherché à savoir pourquoi seules les leurres 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 désormais 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 a 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 “jeu de la taupe”[3] en choisissant la “bonne” contre-mesure pour le “bon” type de missile tout en ayant le stress de devoir prendre une décision quelques secondes avant l’impact. C’est dans cet esprit que nous avons effectué des tests de jeu avec les changements suivants :

  1. Les leurres agissent sur tous types de missiles.
  2. Les paillettes sont transformées en un “champ de brouillage” qui atténue 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 intéressant. Nous avons ensuite mis à jour les éléments ATH du système d’alerte aux missiles, ajouté un widget 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 visuels (comme le fait que les contre-mesures soient invisibles dans le PU).

Un ajout ultérieur que nous n’avons pas pu faire à temps pour l’alpha 3.11 a été de changer les noms de “flares” et “chaff”. Ces deux noms sont très courants pour 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 en VO pour mettre à jour les voix de l’ordinateur des vaisseaux.

  1. Chaque véhicule n’a droit qu’à quatre verrouillage à la fois.
  2. Un seul missile peut être lancé par rack à la fois.
  3. Un seul type de missile (IR/EM/CS) peut être lancé à la fois.
  4. 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 spam de missile a été considérablement réduit, et la 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 axés sur les missiles de rester à la limite du combat comme prévu tandis que les chasseurs spécialisés se rapprochent. 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) puissent à nouveau utiliser des missiles.

Beaucoup de ces changements (en particulier pour les missiles) sont temporaires afin de proposer une meilleure expérience jusqu’à ce que le mode d’opérateur de missiles soit prêt, ce qui modifiera à nouveau le comportement et/ou supprimera certains aspects lorsqu’il sera implémenté.

Remarques finales

L’objectif général que nous voulons atteindre dans la boucle de gameplay des missiles est de rendre l’utilisation des missiles et la défense contre les missiles plus profonde et plus gratifiante, avec sa propre “place” dans l’environnement de combat. Les missiles ne sont pas censés être une alternative aux armes, mais des armes tactiques, et leur utilisation devrait être une décision consciente avec des conséquences. Nous voulons également donner aux vaisseaux lance-missiles spéciaux, comme le Talon Shrike ou le Freelancer MIS, un avantage lorsqu’il s’agit d’utiliser les munitions pour la même raison. Ces vaisseaux excelleront dans le gameplay offensif des missiles, 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 défaire des frustrations des versions précédentes.

John Crewe
Directeur des véhicules

Technologie

Système de décalcomanie sur grille de support (canvas)

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 grille de support de motif (canvas)” qui utilise le système Building Blocks pour créer des textures de décalcomanie à la volée. Ces décalcomanies peuvent être utilisées pour la signalisation, sur les vêtements ou même sur les véhicules. L’avantage des décalcomanies créées à la volée est que nous pouvons utiliser les données du jeu telles que le nom du joueur ou même 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 associé au système de streaming de textures, de sorte que les textures dynamiques sont “streamées” en utilisant la même logique que les textures standards, ce qui garantit que nous maintenons toujours un budget de mémoire fixe. Cette logique de streaming nous permet de faire fonctionner automatiquement la même fonctionnalité 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écalcomanies sur grille de support de motif (canvas) dans le streaming de texture 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 streaming de textures, ce qui sera particulièrement important car nous prévoyons de généraliser le code et de l’utiliser également pour le streaming de mesh[4].

Technologie planétaire

Du côté de la technologie planétaire, nous avons ajouté plusieurs fonctionnalités, notamment des améliorations aux outils planétaires. Parmi ces améliorations, citons de nouveaux pinceaux[5], une interface utilisateur remaniée et la fusion de la couche au sol et des préréglages d’objets[6] afin d’accélérer encore plus la peinture des planètes. En utilisant les nouveaux outils de peinture planétaire, l’équipe artistique environnementale a passé en revue toutes les planètes et les lunes du système Stanton et a repeint les surfaces au sol et les présélections d’objets. Cela nous permet également de nous projeter vers 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 HW[7] 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, y compris 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 mise à jour pour introduire des objets flottants plus grands.

Ces derniers mois, beaucoup de temps a été consacré à la recherche et développement du rendu des atmosphères et des nuages, y compris le raymarcher[8] unifié des atmosphères planétaires. 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 pour débruiter[9] et sur-échantillonner[10] les résultats à pleine résolution afin d’améliorer les performances des coûteuses opérations de raymarching. Ces algorithmes sont combinés à des techniques de reprojection et au regroupement des demandes par le raymarch de recherche de pixels[11] 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. À propos, nous en sommes actuellement aux tout premiers jours de la recherche et 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é sombre 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 coûts de calcul réduits. Nous ne nous sommes pas arrêtés là, cependant, et avons implémenté des améliorations visuelles supplémentaires dont, nous l’espérons, vous pourrez bientôt profiter.  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 désormais également des données de radiométrie solaire extraterrestre IRL lors de la simulation de la lumière au lieu de prendre simplement en hypothèse systématique 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.

Moteur

Côté moteur, plusieurs améliorations ont été apportées. Nous avons mis à jour notre chaîne d’outils de compilation pour VS 2019 (Visual Studio 2019, une suite logiciel servant au développement logiciel), ce qui permettra d’accélérer les temps de compilation (étape permettant de passer d’un “code”, c’est à dire du texte, à un fichier interprétable par l’ordinateur, et donc, exécutable) et de liaison. De plus, nous avons ajouté la prise en charge du compilateur de programmes Intel SPMD[12] (ISPC[13]). Cela nous permettra d’écrire un code optimisé pour l’ESS[14] (pensez HLSL[15]) 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 ensembles de code en 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[16] 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 les endroits où nous utilisons de la mémoire. Nous sommes maintenant également en mesure de suivre correctement l’utilisation de la mémoire dans les bibliothèques tierces[17] 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 sortie de la 3.11.

Tout au long de la production de l’alpha 3.11, l’équipe chargée du moteur s’est surtout concentrée sur les fonctionnalités des versions ultérieures, comme le moteur de rendu Gen12. Cependant, un très gros bug qui faisait que tous nos objets sur les clients se déchargeaient plus tôt que prévu a été corrigé. Les objets sur les clients devraient maintenant rester chargés sur des distances nettement plus grandes.

Audio

Pour la tech audio, nous avons mis à jour Wwise vers la version 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 zones mémoire à une seule zone. 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. Le support des tirs d’armes, en particulier à longue distance, a été amélioré et plusieurs problèmes concernant les taux de l’audio des tirs et le volume des armes ont été réglés.

Séparateur de grille de support (canvas)

Ce trimestre, l’équipe chargée de la tech de l’IU a travaillé sur un système nommé “séparateur de grille de support de motif (canvas)”.  Il s’agit d’un sous-système de Building Blocks qui permettra aux concepteurs de l’interface utilisateur de placer des ensembles d’interfaces 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 écran ou un datapad. Avec le “séparateur de grille de support de motif (canvas)”, nous créons la géométrie à n’importe quelle position dans l’espace 3D à la volée et nous dessinons l’interface 2D directement sur celle-ci. Cela signifie que nous serons en mesure de produire des IU par couches intéressantes, telles que des ATH holographiques pour les vaisseaux et des affichages pour les casques.

Info-bulles

Nous avons également commencé à concevoir notre système d’info-bulles pour 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 pas mal de choses auxquelles réfléchir avant de commencer son implémentation.

Marco Corbetta
Vice-président chargé de la technologie

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 FPS entre leur sac à dos ainsi que 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 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 (soutenu 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, une nouvelle IU 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 de ressembler à 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 gèrent leurs objets en faisant du Tetris. 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 itération.

Si la technologie Building Blocks nous a 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égétique 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 réalité augmentée 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 fonctionnalité, mais l’équipe et moi avons estimé qu’il était important pour nous de le sortir et d’obtenir autant de commentaires que possible d’ici à un véritable inventaire physique. Nous allons mettre à jour ce shader dans un prochain patch.

Réactions aux contraintes de force

Les réactions aux contraintes de force constituent essentiellement un système qui simule ce qu’un personnage doit faire lorsqu’il est soumis à une force quelconque, qu’il s’agisse d’une puissante bourrasque de vent ou d’une balle pénétrant son épaule. Ce système peut être divisé en trois niveaux d’impact :

  • Impact faible : tressaillements, sursauts et inclinaisons ;
  • Impact modéré : chancellements ;
  • Impact fort : renversements.

Dans l’alpha 3.10, nous avons déployé la première itération des réactions aux impacts faibles avec les tressaillements procéduraux lors de combats FPS et les inclinaisons face à des vents soutenus. Dans l’alpha 3.11, nous avons ajouté plus de “sensations” aux tressaillements en étoffant les réactions de caméra et d’armes ainsi que notre première itération des renversements, avec pour objectif d’intégrer ultérieurement les chancellements.

Le plus grand défi pour ce système résida dans la nécessité de le rendre véritablement systémique dans la mesure où les forces peuvent avoir de nombreuses origines différentes, et pas simplement provenir de balles. Pour cette raison, nous avons décomposer les forces en trois catégories principales :

  • Forces directes : tout ce qui impacte physiquement le personnage, comme une boîte ou une balle ;
  • Forces indirectes : la force reçue lorsque votre vaisseau est percuté ou à la suite d’une bourrasque de vent ;
  • Forces soutenues : lorsqu’une force est appliquée constamment, comme les g ou le vent.

Cela signifiait que nous pouvions compartimenter différentes forces selon différentes intensités et permettre aux concepteurs d’équilibrer la réaction du personnage en conséquence, puisque les forces résultant d’un impact avec une boîte n’ont rien à voir avec l’accélération d’un vaisseau dans l’espace à 1000 m/s. Bien que les réactions aux impacts faibles n’altèrent pas le contrôle du joueur, nous étions bien conscients que ce serait le cas des renversements. Nous avons passé beaucoup de temps à nous assurer que les animations de chutes étaient très réactives aux contrôles du joueur dès lors que le personnage touche le sol. Nous avons également intégré un système basé sur la compétence qui consistait à déclencher plus rapidement l’animation de rétablissement si vous essayiez de viser dans la mire juste avant de toucher le sol, vous permettant alors de vous replonger dans l’action plus vite.

Les réactions aux contraintes de force dans l’alpha 3.11 ont constitué notre deuxième déploiement qui ne sera certainement pas le dernier. Nous travaillons activement sur les réactions aux impacts modérés et nous passerons en revue et corrigerons constamment l’équilibrage à l’avenir, en particulier pour le combat FPS.

Lancer Tier 1

Lancer des grenades et d’autres objets a toujours manqué de panache et s’avère encore plus décevant quand vous vous dites que vous aviez l’occasion idéale pour tuer plusieurs personnes avec une seule grenade à quelques mètres de vous. La première chose que nous voulions obtenir avec le tier 1 était donc d’avoir des lancers plus fiables, afin que les objets que vous lancez (qu’il s’agisse d’une grenade ou d’autre chose) aillent là où vous voulez qu’ils aillent. Le deuxième grand objectif, qui était un pré-requis critique pour l’inventaire physique, était que le système de lancer soit capable d’interagir et d’être en symbiose avec le système de port d’objets.

Dans l’alpha 3.10, si vous ramassiez une grenade au sol et que vous essayiez de la lancer, il n’était pas possible de retirer la goupille. De plus, si vous appuyiez sur le raccourci clavier pour lancer la grenade, vous lâchiez la grenade pour en sortir une autre de votre équipement. De toute évidence, ce n’est pas le résultat attendu et c’est la raison principale pour laquelle le lancer de grenade se fait désormais à l’aide d’un état d’objet équipé (c’est-à-dire dans votre main) plutôt que directement avec un objet sur votre combinaison. Ce système nous permettra également de fournir des gadgets et des objets déployables à l’avenir.

Intégré au tier 1, nous avons également ajouté un “arc de lancer” à l’IU qui vous permet de voir la trajectoire de la grenade. Bien que disponible pour tous les casques, il ne sera accessible qu’avec des casques de combat lorsque nous aurons commencé à définir les archétypes d’armure dans le ‘verse.

Lance-grenade et fusil à pompe BR2 de Behring

Depuis que je dirige le département des armes, nous avons fait tout notre possible pour nous assurer que chaque arme ajoutée au jeu ait un but unique ou une façon de la jouer qui lui corresponde. Actuellement, nous avons déjà plusieurs fusils à pompe disponibles qui sont mortels à bout portant mais inefficaces au-delà. Behring étant un fabricant que nous avons défini comme moyen au niveau des dégâts, de la cadence de tir et de la précision, nous estimions que le BR2 était notre première occasion d’étendre la portée d’un fusil à pompe afin de fournir plus de peps en combat à moyenne portée sans qu’il ne domine à bout portant. Bien que nous étions satisfaits du BR2, nous ne sommes pas satisfaits des fusils à pompe dans leur globalité puisqu’ils sont dépassés en puissance de feu par les mitraillettes et en portées par les fusils d’assaut. Nous réévaluerons tous les fusils à pompe dans un prochain patch pour leur apporter une identité plus marquée.

D’autre part, le lance-grenade Behring présentait des problèmes tout à fait différents. Dans la réalité, une grenade de 40mm tue dans un rayon d’environ 5m et blesse jusqu’à 15m. Ce sont des distances importantes lorsque vous considérez nos espaces fermés et, dans la mesure où vous pouvez tirer cinq de ces munitions en un court laps de temps, cela vous donne une arme assez puissante. D’un côté, nous voulions fournir une arme qui semblait lourde et conçue pour faire pleuvoir la destruction, mais d’un autre côté nous ne souhaitions pas complètement déséquilibrer le combat FPS.

Dans cet objectif, nous nous sommes assurés que les valeurs susmentionnées étaient légèrement plus faibles que celles d’une grenade à fragmentation classique. Mais pour être tout à fait honnête, je dirais que le lance-grenade est un petit peu trop puissant actuellement en jeu. La raison principale est que les joueurs ont accès à une quantité infinie de munitions grâce à l’application de gestion de l’équipement[18], donc il nous fallait choisir entre sortir l’arme comme prévu ou la nerfer au maximum jusqu’à ce que l’inventaire physique soit mis en ligne. L’équipe pensait qu’il serait plus représentatif en termes d’expérience de sortir l’arme comme elle devrait fonctionner et d’attendre d’autres systèmes, comme l’inventaire physique et les dégâts physiques, afin d’équilibrer sa puissance brute. À ce moment-là, les joueurs devront prendre en compte l’espace qu’ils allouent aux munitions et les dégâts physiques feront perdre leur intégrité aux armes et aux armures lorsqu’elles seront touchées. Cela signifie que si quelqu’un se fait souffler par une explosion, une grande partie de son équipement sera endommagé, ce qui diminue la valeur globale. J’ai également vu les retours concernant la distance d’armement et c’est quelque chose sur lequel nous allons travailler.

Remarques finales

Si j’examine toutes les fonctionnalités que le département de gameplay a livré dans l’alpha 3.11, je suis heureux du résultat. Cependant, cela ne veut pas dire que tout s’est bien passé ou que je referais tout de la même façon si j’en avais l’opportunité.

Je pense que la principale chose que je changerais serait la façon dont nous avons intégré les réactions aux contraintes de force à l’intérieur des vaisseaux. Plutôt que de les traiter de la même façon que toutes les autres forces du jeu (le vent, des balles, etc) – ce qui aurait dû faire sens en surface – j’aurais pris en compte le générateur de gravité des vaisseaux dans la conception. Actuellement nous prenons la force appliquée au vaisseau et la transmettons directement au personnage à travers des filtres qui dépendent de la dite force afin que ce dernier réagisse en conséquence. Au lieu de ça, j’aurais plutôt laissé la gravité réagir à cette force, ce qui ensuite aurait fait réagir le personnage. Bien que le joueur n’y verrait aucune différence, je pense que l’implémentation aurait été plus propre et qu’il aurait été plus facile d’étendre le système à l’avenir. Par exemple, lorsque nous ajouterons les entités physiques des générateurs de gravité, etc.

Au cours des deux derniers trimestres, nous avons également apporté deux fonctionnalités (la traction de corps et les renversements) qui aurait vraiment pu tirer profit d’un système basé sur le ragdoll. Malheureusement, cette fonctionnalité ne dépend pas de mon équipe, donc je n’aurais peut-être pas pu y faire quoi que ce soit. Mais avec le recul, j’aurais pu apporter plus de visibilité sur les bénéfices qu’une telle fonctionnalité apporterait une fois qu’elle aurait progressé. C’est de toute évidence un défi de travailler dans une équipe de 600 personnes réparties sur plusieurs continents et dont les priorités dépendent de différents projets. Tout le monde essaie de livrer les meilleures fonctionnalités/le meilleur contenu/les meilleures technologies qui soient avec les qualités les plus élevées possibles, et parfois les astres ne s’alignent pas quand il est question de priorités. Dans ce cas précis, la faute repose sur mes épaules suite à un manque de communication. En tant que développeurs, nous ne faisons pas toujours les choses correctement lorsqu’on est dans le feu de l’action, mais j’espère que cela vous donnera un aperçu de notre processus de création et de notre dévotion totale pour créer les meilleures expériences pour vous.

Richard Tyrer
Directeur du Gameplay

Environnements

Quais de chargement

Pour cette mise à jour nous avons été en mesure d’introduire la prochaine étape dans l’ajout de la complexité à nos stations spatiales. L’idée pour les principales stations localisées autour des planètes consiste à en faire plus que de simples relais routiers ; celles-ci auront leurs propres complexes dédiés à d’autres services, comme les cargaisons.

Pour l’extérieur, nous avons introduit de nouveaux composants qui décrivent l’infrastructure et de larges rangées de conteneurs qui suggèrent la capacité du lieu (qui est purement visuelle pour l’instant, nous aimerions inclure des éléments plus interactifs à l’avenir).

À l’intérieur, nous voulions étendre les itinéraires à emprunter. Pour ce faire, nous avons mis en place un nouveau système reposant sur un réseau de transit principal qui connecte les différents éléments d’une station ensemble – galerie marchande, quai de chargement, etc.

Pour l’intérieur du quai de chargement, il y avait quelques éléments que nous souhaitions inclure. Premièrement, nous voulions dépeindre pour la zone de hub une expérience logistique pour le joueur. Cela comprend une section de l’entrepôt de correspondance qui, prochainement, sera une source sandbox à contenu de mission. Pour l’espace d’achat principal, nous voulions incorporer quelques éléments au sein d’une grosse boutique. Désormais nous pouvons voir le guichet de dépôt et récupération de fret localisé au sein d’un petit bureau de tri logistique, l’espace de location de vaisseau est situé sur le côté, et la zone de guilde et de fournitures se trouve dans le coin. Globalement, cela donne une expérience plus diversifiée pour le joueur plutôt que de séparer tous ces éléments dans plusieurs magasins.

Contenu planétaire

Pour ce trimestre nous avons été en mesure de maintenir notre lancée concernant la mise à jour des planètes et des lunes dans le système Stanton à l’aide des outils et des technologies les plus récentes dont nous nous servons pour construire le système Pyro. La première étape de ce travail a consisté à repeindre[19] entièrement les planètes et les lunes. Globalement, ce processus de peinture est à l’origine d’un bon nombre des dernières fonctionnalités qui nous servent à homogénéiser les objets. Pour l’intégrer en jeu, nous avons donc dû prendre le taureau par les cornes et faire une première passe sur absolument tout. Dans le dernier patch, nous avons introduit les nouvelles heightmaps[20], et désormais la nouvelle passe de peinture bénéficiera de toutes ces nouvelles données.

Le second élément que nous avons pu introduire est une amélioration globale de tous nos groupements géologiques. Nous sommes désormais en mesure de spécifier la couleur du terrain pour les assets[21] qui leur permettront de se fondre de manière procédurale dans un terrain ou sur une roche mère. Nous avons également pu ajouter la tessellation[22] des assets et le déplacement par objet, ce qui signifie que nous pouvons assigner une heightmap à des assets qui déterminent les paramètres de déplacement. Pour faire simple, cela signifie que lorsqu’un joueur se rapproche d’un asset, celui-ci devrait avoir une résolution géométrique bien plus importante, ce qui permet de visualiser une silhouette complexe.

Pour finir, nous avons remplacé tous nos shaders[23] de terrain avec des données scannées[24]. C’est une chose à laquelle nous nous intéressons depuis un moment puisque la qualité des résultats est extrêmement élevée, mais avec certaines des dernières technologies, nous avons pu l’implémenter dans notre pipeline[25]. Nous avons recréé plus de 70 shaders de base en combinant et mélangeant des données scannées ensemble afin d’obtenir les résultats que nous souhaitions. Nous avons pour ambition future de monter un équipement dédié au scan pour traiter nos propres données, que nous collecterons lors de sorties sur le terrain. Nous voulons nous assurer que nous pouvons créer une incroyable palette diversifiée pour les futurs lieux de Star Citizen.

Remarques finales

Nous avons été en mesure d’introduire beaucoup de nouvelles technologies dans cette mise à jour, tout en commençant à présenter la seconde salve de polissage sur les surfaces planétaires. De plus, avec l’introduction des données scannées pour nos surfaces, nous avons assisté à une hausse significative de la qualité visuelle. Cependant, certaines des passes de peinture globales n’ont pas été aussi détaillées ni appliquées que nous l’aurions voulu. Ceci s’explique principalement par les contraintes de temps du trimestre. Certains surfaçages de la géologie avec les nouvelles bibliothèques pourraient également mieux correspondre aux différents biômes/régions.

Pour les quais de chargement, nous aurions dû prévoir l’absence de lien entre l’intérieur et l’extérieur lorsque nous avons compartimenté les galeries marchandes. Pour améliorer l’expérience et aider à donner du contexte au joueur, nous aimerions que ce réseau de transit soit matérialisé physiquement à l’avenir. Cela apportera de la visibilité depuis la cabine de transit vers l’extérieur de la station à mesure qu’elle se rapproche de sa destination.

Ian Leyland
Directeur artistique de Star Citizen

Design

Zones d’armistice

Les assouplissements des zones 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[26] 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 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 afin de pouvoir probablement 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, tout en restant assez simpliste, additionne les CrimeStats[27] de tous les joueurs dans la zone (connu en interne sous le nom de “chaleur”) et engendre des vaisseaux 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 vaisseaux et en déchargeant les vaisseaux 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 vaisseaux utilisés par les joueurs et de l’agressivité dont ils font preuve.

Nous allons étendre ce système à d’autres endroits, comme les avant-postes, bien que GrimHEX aura besoin d’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 lieu ancien qui ne peut pas supporter une zone d’armistice du rayon requis.

L’équipe Live a dû être extrêmement vigilante et réagir rapidement aux problèmes, étant donné le peu de temps passé par l’alpha 3.11 dans la phase PTU. Un exemple de problème que nous avons constaté est celui des joueurs qui volaient les sentinelles en les avalant dans la soute de leur 890 Jump et qui repartaient avec elles. Nous avons remédié à ce problème en auto-détruisant les sentinelles enlevées de la zone et en les faisant réapparaître. Un autre exemple est que si la réponse de sécurité était capable de faire apparaître rapidement les vaisseaux sur des 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 d’apparitions demandées.

Nous avons vu des vidéos de nombreux joueurs faisant équipe pour envahir une aire de repos et la tenir longtemps malgré les défenses et la réponse des services 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 à reproduire cette situation dans un avenir pas trop lointain.

Remarques finales

À 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 à spawn” qui nous permettra de charger 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 du CrimeStat ou à ceux qui sont en train de commettre des crimes.

Luke Pressley
Concepteur en chef

À bientôt 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 et les enseignements directement de nos principaux développeurs. Comme nous l’avons mentionné la dernière fois, nous nous engageons à un développement transparent et nous continuerons à fournir des “autopsies” trimestrielles.

PULSAR42 Association à but non lucratif de droit français régie par la loi du 1er juillet 1901, N° RNA : W923006718. SIRET 839 734 175 00012 - APE 9499Z

Design By June Lottin

This site is not endorsed by or affiliated with the Cloud Imperium or Roberts Space Industries group of companies. All game content and materials are copyright Cloud Imperium Rights LLC and Cloud Imperium Rights Ltd.. Star Citizen®, Squadron 42®, Roberts Space Industries®, and Cloud Imperium® are registered trademarks of Cloud Imperium Rights LLC. All rights reserved.