Pulsar42

RAPPORT MENSUEL : MAI 2015

Salutations citoyens,

C’est difficile à croire, mais Juin est déjà à nos portes ! Le travail sur Star Citizen se poursuit à un rythme effréné, que ce soit dans nos studios ou ceux de nos partenaires externes du monde entier. Ce mois-ci, nous sommes ravis de présenter dans ce rapport notre dernier studio en date : Foundry 42 Allemagne. Au cours des prochains mois, vous aurez souvent des nouvelles de ce studio : ils ont pour mission de résoudre tous les problèmes de programmation qui se mettront en travers de notre route vers l’univers persistant de Star Citizen. Le travaille se poursuit dans ces domaines, ainsi que sur nos nombreux modules et autres fragments importants du jeu, de Star Marine (en préparation pour un lancement sur l’UTP) à Squadron 42 (le tournage des cinématique est actuellement dirigé par Chris Roberts à Londres !). Retrouvez ci-dessous le rapport détaillé de tout ce que nous avons fait ce mois-ci.

 

SANTA MONICA

Bienvenu pour une autre édition du rapport du mois ! Celui-ci a été chargé d’événements et est accompagné de beaucoup de nouvelles de développement à couvrir. Comme toujours, nous sommes super-excités de partager avec vous ce sur quoi nous avons travaillé durant ce dernier mois. Prenez donc place confortablement puisque voici les mises à jour du développement.

 

Conception

L’un des plus grands développements de Mai a été la révélation et le concept de vente pour le MISC Reliant. Cette vente à été un énorme accomplissement pour nous, et on aurait dit que tous les studios tiraient sur la même corde afin d’arriver à la mise en place de la vente. Tous ceux qui étaient impliqués dans la vente ont poussé pour être certains qu’elle ne soit pas disponible juste à temps, mais qu’elle le soit plus tôt. Cela a été un bel exemple de nos différents départements travaillant ensemble afin d’amener un autre de ces incroyables vaisseaux à la vie. Nous somme presque certains que la communauté l’a apprécié aussi, avec plus de 19000 achats durant la vente du concept. Merci beaucoup à vous tous, aussi bien pour avoir soutenu ce nouveau vaisseau de MISC que pour le développement actuel de Star Citizen.

Nous avons pris des mesures d’équilibrage de la liste actuelle des missiles, spécifiquement en augmentant la vulnérabilité de tous les missiles CS-Lock (Tempest, Stalker, StrikeForce) aux bruits fait par les leurres, donnant une meilleure chance à ceux qui sont visés par la colère de ces puissantes munitions, de s’échapper. De plus, le temps d’acquisition des cibles a été augmenté (de 2 à 5 secondes), donc, pilotes, entraînez vos compétences à l’évasion ! Garder un œil sur la cible devient d’un coup bien plus important. Les missiles Fire-and-Forget sont également plus pratiques avec ce changement. Bonne chasse !

L’un des vaisseaux sortant du pipeline est le Starliner de la Crusader Industries Genesis. Le Starliner est un gros vaisseau, devenu un peu plus grand qu’un 747. Il est unique en ceci que c’est un des premiers vaisseaux de transports de civiles auquel s’est attaqué l’équipe de Star Citizen. Celui-ci était le premier vaisseau de ce genre, il nous à fait nous questionner sur notre conception en regard des passagers dans l’espace. Par exemple, il reste à trouver des réponses pour les questions de capacité en passagers, leur sécurité, et les temps de vol maximum. Le concept de l’extérieur est en bonne voie, mais l’intérieur est toujours en travaux. Nous sommes impatients de vous montrer tout ce avec quoi nous sommes venu. Bientôt, le Starliner va voguer sur les étoiles avec vous à sa tête, ou comme passager, durant un voyage vers cette destination balnéaire que vous voulez voir.

Initialement mentionnés dans la mise à jour de mars, nous continuons à faire des progrès avec notre nouveau système de dégât basé sur la physique. Ce nouveau système va être d’une grande aide sur plusieurs fronts pour ce qui est du gameplay de l’Arena Commander, mais aussi à configurer de solides fondations dont SQ42 et l’UP émergeront. L’une de nos préoccupations majeures a été la refonte complète des dégâts et de la façon de tenir pour toutes les armes en se concentrant afin d’assurer que celles qui sont balistiques ou à énergie peuvent avoir une façon d’être jouées et des caractéristiques uniques. Mais lorsque vous modifiez les dégâts, ce n’est qu’une pièce du puzzle, vous pouvez donc vous attendre à une mise à jour comparable pour chaque partie majeure des vaisseaux afin d’aider à supporter ce nouveau système : Santés du vaisseau et du bouclier, production d’énergie du générateur central, capacité de refroidissement, les travaux.
Lautre chose notable en Mai pour le bureau de Santa Monica a été la venue de John Pritchett et Pete Mackay alors que nous étions en train de nous occuper de régler certains détails du vol et des propulseurs pour le jeu. Tandis qu’ils ont parlé d’une partie de leur travail durant une apparition dans un Around the Verse récent, il y a beaucoup de travail à faire en coulisses, que leur visite nous à aidé à rationaliser. À présent, nous avons d’encore meilleurs outils et données de paramétrage pour rendre la construction de nouveaux vaisseaux et composants plus lisse et plus cohérente qu’auparavant. Ce travail à déjà aidé en tête de la vente du Reliant et nous permet, plus rapidement que jamais, de régler les exigences de masses et de poussée pour les vaisseaux.

 

Art

Pour le HUD et l’UI, nous avons travaillé sur l’optimisation des performances de rendu par le processeur en optimisant le nombre d’appels d’images avec la contribution de la forme en écaille de l’aspect du HUD mais aussi une modification des objets holographiques qui devraient aller vers une amélioration des performances du rendu des objets et entités holographiques. En général, la quantité de ressources du processeur qu’utilisent le HUD et l’UI devrait être nettement moindre, et nous continuerons à l’optimiser pour obtenir les meilleures performances possibles.

Ce mois, Josh Coons et Mark McCall ont créé et implémenté de nouveaux intérieurs des casques qui seront utilisés pour tous les personnages du FPS. Cette nouvelle direction pour les casques est un grand pas dans la réalisation de la vision globale de Chris Roberts concernant les personnages de Star Citizen. La nouvelle conception intérieure de casque donnera à l’équipe du HUD plus de flexibilité et ajoutera au réalisme de notre univers.

Ce qui rend nos casques uniques, c’est qu’ils ont un effet sur le champ de vision du joueur, améliorant “l’universimilitude” (NDT : Au secoure) de notre expérience de jeu pour le FPS. L’équipement dans notre jeu devrait être ressenti comme réel et ayant de la substance, ce ne doit pas être simplement un ensemble de données et de nombres à augmenter ou baisser durant le gameplay, avec des caractéristiques offrant différents choix aux joueurs basés sur leurs propres préférences subjectives et ajouter à la diversité des choix des joueurs.

Pour le département “Technical Art”, ce mois, nous nous sommes concentrés sur la destruction, le sauvetage et l’optimisation des vaisseaux. Nous avons reçu pour tâche de trouver le juste milieu entre l’approche des dégâts le mieux optimisés et s’assurer en même temps que notre conception du gameplay reste intacte.

Dans le passé, pour ce qui est des dégâts sur les vaisseaux, nous aurions fait cinq versions de chaque partie d’un vaisseau. Celles-ci auraient été les versions au niveau des dégâts de 0, 25, 50, 75 et 100%. Exploser les vaisseaux en pièces semble très cool, mais cette solution était extrêmement coûteuse en matière de volume de travail, utilisait beaucoup de ressources du système et n’était pas ajustable afin de permettre au CryEngine de rendre l’armada épique de vaisseaux de combats que Chris à prévu.

Nous avions besoin d’une nouvelle solution pour les dégâts. Donc, Ali Brown, Okka Kyaw, Geoff Birch et Mark Abent ont tous aidé à créer notre nouveau shader de dégât et d’explosion permettant que la destruction de nos nouveaux vaisseaux se fasse sans un haut coût en ressources. Mais au moment où nous avons accompli ce grand exploit d’optimisation, nos concepteurs planifiaient la nouvelle mécanique de jeu comme le ramassage de débris et la réparation de vaisseau, qui, chacune, ajoute des coûts aux demandes de traitement globales de notre modèle de vaisseau.

Le véritable ennemi de la performance dans Star Citizen, avec un aussi grand nombre de choses en haute fidélité dont le rendu doit être fait, c’est le “Draw Call”. Pour ceux qui n’y seraient pas familiers, le “Draw Call” c’est le montant de passage du rendu sur chaque pièce de géométrie pour créer l’image finale. Si la coque de votre vaisseau de combat à des textures, diffuses, normales et spéciales, alors cela équivaut à trois “Draw Calls”. Et si votre vaisseau est divisé en cinquante pièces, cela devrait être cinquante fois trois, étant égal à cent-cinquante “Draw Calls” ! Nos vaisseaux étant rendus en se basant sur la physique (NDT : utilisation de la technique PBR), avec le shader de dégât, les variations de peintures et de calques requièrent quelque chose comme quinze à trente “Draw Calls” par pièce. Ainsi, pour optimiser les “Draw Calls”, nous avons besoin de réduire le nombre de pièce différente. Mais, cela signifie que, pour être réellement optimisé, nous aurions besoin d’avoir un nombre plus faible de pièces animées et de débris provenant du vaisseau ! Un vrai casse-tête, car nous voulons ces trucs !

En parlant avec Ali à propos des problèmes d’optimisation, il a suggéré une nouvelle approche pour les débris sur laquelle nous planchons actuellement. Au lieu de couper le vaisseau en zone de dégâts séparée et éjecter les débris du vaisseau, nous pourrions cacher des parties du vaisseau utilisant notre shader de dégâts et faire apparaître des débris qui flotteront alors loin de celui-ci, mais nous permettant la réduction du nombre de mailles de la coque du vaisseau qui réduira également les “draw Calls” significativement. Mais de plus, cette solution nous permet de créer des débris qui contiendront des composants récupérables ! Donc, cette arme que vous venez juste de détacher avec un tir sur ce Cutlass dans l’UP ? C’est la vôtre maintenant. De rien.

Il y a eu de nombreux autres soucis comme celui-ci. Et ce mois nous a emmené plus loin que jamais vers la réalisation du space opera de nos rêves. Maintenant, notre travail est d’implémenter l’optimisation complète sur tous nos vaisseaux dans le jeu, le but étant que nous mettions Squadron 42 à disposition accompagné d’un amusant gameplay et d’un nombre fluide d’images par seconde.

 

Ingénierie

Le travail sur le radar 2.0 à été terminé. Tout peut être enregistré pour être montré sur le radar aussi longtemps qu’il y a une structure réagissant à celui-ci. Ce qui signifie qu’en termes profanes, aussi longtemps qu’un objet possède les bonnes informations en lui, cet objet sera pris en compte et affiché sur le radar en se basant sur ses propriétés physiques. Oui, nous pouvons même donner une signature electro magnétique à une grenade EM et que celle-ci soit montrée par le radar sur celui-ci est configuré pour détecter les EM.

Nous avons aussi fait en sorte que les radars soient capables de filtrer tout type de signature et les objets détectés ont maintenant une instance d’eux-même qui se crée. La création de cette instance nous permet de faire des choses comme la mise à jour des positions de stutter et/ou montrer l’usure sans affecter l’objet actuellement détecté. Ceci laisse les départements conception et art faire des choses cool et intéressantes à l’instance de la version qui est montrée sans casser la logique sous-jacente qui détermine les radars et signatures. Dans le même temps nous avons aussi amélioré les performances des vérifications d’occlusion.

Pour conclure, nous avons ajouté le support pour les décibels en tant que type de signature. Une fois à pieds dans Star Citizen, votre radar affiche les sons ambiants de votre environnement comme les pas ou les tirs d’armes à feu. Ces événements sont maintenant correctement attachés au système de signature faisant que vos pas ou tirs créeront des décibels, qui seront alors scannés pour et par le radar du joueur. Vous en verrez le début avec le FPS.

Notre équipe d’ingénierie de Lors Angeles a aussi aidé à gérer les personnalisations, vêtements et points utilisant le système d’attache que nous avons développé. Le système de point d’attache permet d’attacher les objets aux squelettes définis sur un objet 3D. C’est ainsi que nous attachons toutes les parties et objets de nos vaisseaux. Ce système à été appliqué pour les personnages afin de gérer dynamiquement l’extension des squelettes en utilisant des points d’attache de la peau.

Ce que cela signifie en termes réels c’est que nous avons des parties du corps qui sont à même d’être équipées d’objets. Pieds, mains, main gauche, main droite, torse etc. marqué pour des os spécifiques qui définissent ou les objets attachés le sont. De là, si vous devez équiper une pièce pour la poitrine qui permet d’y attacher une lampe tactique, un réservoir d’oxygène et un holster, chacun de ces points d’attachement requièrent des os additionnels. Le système permet à tout os supplémentaire d’être vu comme un attachement de peau (objet transformé en peau, pas la peau actuelle) pour étendre la base du squelette en mettant à jour dynamiquement ce squelette avec les os additionnels.

Cela conclus la mise à jour pour le studio Santa Monica ! Merci à vous comme toujours d’avoir pris le temps de lire notre histoire et merci de votre soutien au jeu ! Nous ne pourrions pas faire cela sans chacun d’entre vous et votre soutien est de haute valeur pour chacun d’entre nous à Cloud Imperium. Merci encore et nous vous reverrons pour la mise à jour du mois prochain.

 

CIG AUSTIN

Au Texas, les averses d’avril ont laissé leur place aux inondations de mai ! Nous avons encaissé de très mauvaises conditions météo et d’importantes inondations, comme vous avez pu le voir aux infos. Fort heureusement notre studio a été épargné par cette catastrophe et nous avons, comme à notre habitude, continué d’avancer dans notre travail. Nous avons testé de nouvelles versions de Star Marine et avons travaillé d’arrache-pied sur l’Univers Persistant ainsi que sur de nombreux aspects techniques. Retrouvez ci-dessous les rapports détaillés des chefs de chaque équipe.

 

Équipe en charge de l’Univers Persistant

Département artistique

L’équipe artistique de l’UP a, comme d’habitude, bossé sur de nombreux aspects du projet ce mois-ci. L’un de nos principaux soucis a été d’achever le travail artistique sur la zone d’atterrissage Levski sur Delamar, dans le système Nyx. Nous sommes passés au stade du greyboxing (ndt : modèles 3D fonctionnels) et l’environnement est incroyablement beau. Mark Skelton, Patrick Thomas et Ian Leyland, respectivement directeur artistique, artiste en chef et chef des environnements planétaires, ont travaillé en étroite collaboration avec BHVR pour que cet environnement offre un spectacle stupéfiant. Lee Amarakoon, artiste en charge des effets visuels, et Marc Toscano, qui s’occupe des éclairages, se sont affairés à ajouter une petite pointe de brouillard, de fumée et de lumière pour apporter du dynamisme à cet environnement. Nous sommes impatients de vous voir trafiquer dans des ruelles sombres, vendre des choses sur le marché noir et emprunter les tunnels qui serpentent à travers les astéroïdes que ce lieu peut offrir.

Une autre de nos priorités a été d’optimiser la zone d’atterrissage Area 18, sur ArcCorp dans le système Stanton, pour s’assurer d’avoir de meilleurs rendus au lancement du module Social. Le niveau très élevé de détails et le soin apporté font que nos environnements si magnifiques demandent beaucoup de ressources, mais avec les nouvelles technologies mises en place par notre équipe en charge des graphismes, nous sommes en mesure d’améliorer grandement nos performances selon plusieurs méthodes.

L’artiste conceptuel Ken Fairclough a fini de travailler sur un concept de tourelle de sécurité que l’on pourra par exemple trouver au niveau des zones d’atterrissage d’ArcCorp. Ces tourelles de sécurité seront là pour sanctionner les joueurs qui sortiront leurs armes dans des zones où elles ne sont pas autorisées. Elles décourageront également les trolls et les griefers (ndt : de mignons petits adeptes de l’anti-jeu irrités par la douleur tant physique qu’affective que leur inflige leur hypogonadisme suraiguë) qui pensent que c’est une super idée d’ouvrir le feu au hasard sur des civils.

Notre équipe en charge des personnages a fini d’apporter son aide sur les personnages du module FPS. Les Marines et les Hors-la-loi sont tellement avancés que nous leur avons dit adieu, et désormais nous portons toute notre attention sur la création de personnages qui seront vus en train de jouer au SATABall dans le mode Astro Arena. Nous avons de nouveaux concepts plutôt bien faits à partir desquels nous travaillons et nous devrions avoir fini de bosser dessus dans les prochaines semaines. Notre équipe en charge des personnages a également réalisé un travail de recherche et développement sur les cheveux et sur les vêtements interchangeables pour la sortie du module Social à venir.

L’équipe d’Austin en charge des animations a également apporté son aide dans de nombreux domaines. Nous avons eu fort à faire en recalibrant les anciennes animations de l’UP, du FPS et d’Arena Commander sur notre nouveau squelette d’animation. Et avons également contribué à l’amélioration des animations liées aux accélérations ainsi qu’aux tests effectués sur le systèmes de mains agrippantes. L’animateur expert David Peng s’est entièrement consacré à la révision des modèles de cockpit et de tourelles pour que ceux-ci soient adaptés aux nouvelles proportions de l’avatar. Nous avons désormais 7 types de cockpits et 20 combinaisons de boutons parmi lesquelles nos artistes peuvent choisir lorsqu’ils créent une cabine de pilotage.

 

Conception

L’équipe de conception a consacré le plus clair de son temps à développer certains métiers que pourront exercer les joueurs dans l’UP. Tony Zurovec a passé une bonne partie de son temps à travailler sur les tenants et du métier de pionier (anciennement appelé explorateur) et comment celui-ci s’accorde avec les fonctionnalités d’un vaisseau à venir. Rob Reininger a terminé un premier jet sur le fonctionnement des métiers de mercenaire/escorte, alors que Nate Blaisdel et Evan Manning se sont respectivement attaqués aux métiers de chasseur de primes et de contrebandiers. Ces concepts sont désormais étudiés par Tony Z et une fois qu’ils seront approuvés, ils seront dans la liste d’attente d’Andrew Nguyen pour qu’il les intègre dans les mécaniques de jeu.

Tony Z a également achevé sa première version du simulateur d’univers (anciennement appelé “simulateur d’économie”) et l’a adressé à l’équipe de Wyrmbyte. Le nouveau concept contient bien plus que le système économique de l’UP, puisqu’il comprend désormais la possibilité de créer des éléments chimiques et des matériaux composites, la possibilité de créer une planète dans un système stellaire et de lui attribuer des données, ainsi que la possibilité de créer des activités pour les PNJ et de créer des schémas d’exécution pour chaque activité.

Mark Skeleton et Tony Z, accompagnés de l’auteur principal David Haddock, se sont réunis avec BHVR pour passer en revu des concepts et des agencements pour les lieux planétaires à venir. Ce mois-ci, notre attention s’est particulièrement portée sur la zone d’Odyssa, sur Borea dans le système Magnus, et sur la zone de Mariana, sur Tangaroa dans le système Hélios. Ces deux lieux offriront d e nouvelles expériences excitantes et apporteront de la diversité à notre lot déjà impressionnant de zones d’atterrissage. Nous vous présenteront l’évolution passionnante de son développement lorsque cette section sera mise en ligne. Le mois prochain, notre attention sur portera sur d’autres zones d’atterrissage dans le système Stanton : celles de Crusader, Hurston et MicroTech.

 

Ingénierie

Le mois de mai fut sacrément chargé pour l’équipe d’ingénierie d’Austin et pour celle de Wyrmbyte. Beaucoup de fonctionnalités importantes ont fini d’être travaillés et sont prêtes à être testées.
L’un d’entre elle, que tout le monde attend, est notre nouveau gestionnaire d’instance générique, qui garantit de sérieuses améliorations aux systèmes tels que celui de matchmaking et celui de jeu en groupe. Cette fonctionnalité a été pensée par Jason Ely, et il l’a conçue avec l’aide de Tom Sawyer. Nous allons démarrer les phases de test pour ce nouveau système qui sera ajouté dans le module FPS à venir.

Pendant ce matin… du côté de Wyrmbyte… Scott Brown, Nathan Gray et Ryan Seabury ont travaillé sur notre simulateur d’univers et sont sur le point de livrer une version qui servira de preuve de concept, puisqu’elle comprend les fonctionnalités de base. La prochaine étape consiste à étoffer ceci jusqu’à ce que l’on puisse créer une démo fonctionnelle à faire circuler en interne pour continuer de réfléchir sur les façon de l’améliorer. En parallèle, Ian Guthrie a travaillé sur la première version de notre serveur de système solaire et la terminera bientôt. L’équipe de Wyrmbyte nous a également réécrit en may notre serveur d’informations de joueurs et notre serveur de présence, et ses membres continuent de travailler sur leur système prédiction de mouvements de vaisseaux et de missiles.

Nos autres ingénieurs ont également été occupés… Tom Davies a fini de travailler sur la version 1.0 de notre éditeur bac-à-sable pour les besoins de nos PNJ contrôlés par l’IA, et Jeff Uriarte avance vraiment bien sur l’éditeur d’archétypes de personnages, un autre outil destiné à notre équipe de conception. Andrew Nguyen a préparé le terrain en menant un travail de recherche et développement pour le prototypage d’un autre métier (provisoirement appeler le métier de “découvreur”), et il vient tout juste de terminer une première version du métier de mineur.

Brian Mazza s’est pleinement consacré a un travail requis par le studio de façon générale, comme l’ajout de Google Breakpad pour mieux reporter les crash, effectuer le portage en amont de notre univers et corriger les bugs de serveur qui empêchaient l’équipe de progresser et qui perturbaient la configuration actuelle. À l’opposé du bureau de Brian, James Wright a travaillé en collaboration avec l’AQ (ndt : Assurance Qualité) sur le profilage et l’analyse de performances de nos différentes configurations, dont une version récente de l’UTP et nos futures versions du FPS. Ces données nous aident à déterminer quels types de problèmes requièrent notre attention afin d’améliorer les performances globales. Et James a appelé en renfort Clive Johnson (qui est sur le point de finir de travailler sur l’implémentation de notre système d’ID d’identité globale unique) et George Kidd de l’équipe britannique afin qu’ils l’aident à examiner les problèmes majeurs de performance exposés dans ses résultats de profilage.

Du côté de la création d’outils, Benjamin Bechtel a lancé une nouvelle version de son outil de validation des assets qui bénéficie d’une nouvelle interface utilisateur. Cet outil est utilisé quotidiennement par nos artistes. Benjamin attend également la visite en juin de l’ingénieure d’outils britannique Ashly Canning pour qu’ils travaillent ensemble sur notre logiciel Dataforge. Sean Tracy et Jeffery Zhu ont déployé leur première phase de restructuration de flux, ce qui facilitera grandement la mise en ligne de données depuis nos serveurs jusqu’aux clients. Pour finir, ces deux gentlemen ont consacré beaucoup de temps et d’énergie à Cort Soest sur une tâche bien plus importante et qui demande plus de temps de travail : le nettoyage des données réunies par Perforce. Les deux premières étapes de cette tâches ont été achevées en mai.

L’équipe se prépare pour juin et attend avec impatience d’apporter son aide en vue de la sortie du module FPS, mais également de continuer le travail sur le module Social à venir.

 

Opérations en ligne

AQ

Pour l’équipe d’AQ, le mois de mai a commencé avec les tests et la sortie de la version 1.1.2, étapes réitérées ensuite pour la version 1.1.3.
Avec l’aide de notre programmeur de moteur expert James Wright, nous avons mené un test spécial pour l’UTP au cours duquel les capacités de traitement d’opération d’un serveur séparé ont été requises pour calculer la physique. Les résultats ont démontré des améliorations significatives des performances au cours des parties.

Des changements ont été apportés sur notre façon d’utiliser différents flux et branches sur Perforce, notre logiciel de gestion de versions. Cela permettra d’avoir un processus d’intégration des fonctionnalités et de sorties des patchs plus structuré et plus fluide. Cela a également entraîné une plus grande charge de travail pour l’équipe d’AQ pour qu’ils s’assurent que les flux ou ces branches de code et d’éditeur supplémentaires soient correctement testés. En tout cas, l’équipe fait un travail remarquable et se mobilise pour être sûre que l’on réponde à ces exigences de tests supplémentaires.

Nos spécialistes du FPS ont eu fort à faire pour s’assurer que Star Marine soit correctement testé quotidiennement. L’équipe a eu la chance de pouvoir faire directement part de ses remarques au directeur de conception Todd Papy. Todd fut très attentif à chaque point soulevé. Après en avoir discuté, Todd a réparti les tâches à faire et a passé en priorité les changements à effectuer sur lesquels tout le monde s’est mis d’accord. Pour l’AQ, avoir la possibilité de faire partie de la direction du développement de cette façon est une expérience enrichissante.

En parallèle, Todd Raffray s’est assuré que le module Social était correctement testé. Todd a fait un super travail en s’assurant que toutes les fonctionnalités étaient référencées sur une check-list complète et continuellement testées à mesure qu’elles sont mises en ligne.

Félicitations à Miles Lee qui est officiellement passé au poste d’ingénieur associé à notre équipe DevOps ! Miles a effectué un super boulot en aidant à créer le système d’automatisation des tests. Nous pouvons désormais enregistrer les données de performance et automatiser la majorité des opérations à faire pour vérifier la stabilité de chaque version dès que celles-ci sont disponibles.

L’équipe a tourné avec l’équipe communautaire le premier épisode d’une rubrique consacrée à l’AQ, dans laquelle ils présentent leurs bugs préférés.

L’équipe a également eu l’occasion de participer à la soirée de lancement du premier jeu de la Denius-Sams Gaming Academy, à l’Université du Texas, intitulé “The Calm Before” (ndt : le calme avant… je sais pas trop en fait, à vous de choisir). Nous nous sommes beaucoup amusés en y jouant ! Leur équipe est vraiment douée. N’hésitez pas à aller jeter un oeil à leur jeu en téléchargement gratuit !

Ce fut un mois chargé pour nous, membres de l’AQ. Le mois prochain, nous concentreront toute notre attention sur le test de la v1.2 de l’alpha qui s’apprête à sortir très prochainement.

 

Support technique

Ce mois-ci fut assez chargé pour l’équipe du support technique, puisque nous avons poursuivi certains travaux entamés en mars et en avril.

Au cours du mois de mai sont sorties deux mises à jour d’Arena Commander (1.1.2 et 1.1.3). La version 1.1.2 a grandement aidé les joueurs victimes de la “partie non trouvée”, du “retour dans la salle d’attente”, et les problèmes d’écran de chargement infinis, et la version 1.1.3 a poursuivi sur cette lancée en réglant les problèmes “d’effet élastique” qui faisaient que les joueurs sautillaient d’un bout à l’autre de la carte. Ce n’est que le début des optimisations que nous réalisons, et nous savons que vous serez ravis de voir comment les informations que vous nous fournissez nous aident à améliorer l’expérience de jeu.

Toujours à ce propos, nous avons effectué des phases de tests incroyablement réussies sur l’UTP en utilisant la version 1.1.2. Les joueurs se sont amassés sur l’UTP pour nous aider à tester la capacité des serveurs et à rassembler des statistiques importantes sur les serveurs, et à cette occasion nous nous sommes adonnés à des parties à 8 contre 8, après quoi nous avons longuement échangé et travaillé en interne sur ce que nous pouvons faire pour commencer à augmenter le nombre de joueurs.

En ce qui concerne le fait d’entretenir et étendre nos opérations de support avec vous, l’un de nos principaux objectifs ce mois-ci fut de créer un schéma d’ordonnance des tâches et de traitement d’informations qui nous permettent de mieux vous aider. En publiant en interne une matrice intégrale des problèmes éventuels, des méthodes de dépannage et des résolutions, nous avons été en mesure de former davantage de personnes dans l’entreprise pour répondre à vos problèmes techniques. Cela signifie que nous pouvons aider plus de personnes en moins de temps, et cela fournit les bases nécessaires à l’agrandissement de notre équipe en vue de la sortie de Star Marine, du module Social, de Squadron 42 et enfin de l’Univers Persistant.

Nous avons également commencé à travailler avec Turbulent qui mène deux gros projets pour le support technique : le Conseil de Bug Communautaire (une solution BEAUCOUP plus pratique pour que les joueurs rapportent des bugs et voient lesquels se trouvent dans la version actuelle) et une version revue et corrigée de la page de notification du service en ligne, comprenant le tant attendu état des serveurs.

Vous en verrez davantage à propos de ces fonctionnalités au cours des semaines à venir, mais les deux sont en accord avec nos objectifs à plus long terme qui consistent à vous fournir des informations plus précises et le plus rapidement possible concernant l’état de notre service.

 

IT/Opérations

Le mois de mai fut synonyme de vitesse pour le département informatique. L’équipe IT a travaillé dur pour suivre les besoins croissants en infrastructure des équipes de développement, et les capacités des systèmes de stockage centraux de chaque studios restent l’une de nos priorités. Le mois dernier nous nous sommes occupés de distribuer aux autres studios des copies du système de production de version utilisé à Austin. Ce mois-ci nous avons tourné notre attention vers le comportement du matériel informatique qui se cache derrière le système d’Austin. L’objectif de ce projet est de réduire significativement le temps que cela prend pour générer des versions. Réduire le temps de production permet d’accélérer le développement et les tests en interne, mais la ligne de production est longue et complexe, donc nous l’avons abordée sous plusieurs angles.

La première étape sur la liste a été de tester les capacités du système de stockage sur lequel repose le système de production. Le système de production compile bien sûr le code et les assets pour le jeu, et la majeure partie de ce travaille pousse les disques dans leurs retranchements. Les temps de latence grimpent en flèche sur les systèmes lambdas, et puisque notre système de production compile de nombreuses configurations en parallèle, nous avons perdu beaucoup de temps rien qu’à attendre que les disques rattrapent leur retard. Pour résoudre ce problème, nous avons monté un serveur personnalisé avec des SSD en utilisant des contrôleurs spéciaux pour augmenter le nombre d’IOPS (ndt : “opérations d’entrée-sortie par seconde” en français) bien au-delà de nos besoins. Cette première amélioration apportée à notre système de production a démontré des résultats impressionnants avec 66% de réduction du temps de production de configuration.

Ensuite nous prévoyons de passer à des systèmes plus secondaires que le stockage rapide, ce qui devrait aboutir à des réductions supplémentaires. Pour finir, nous allons inclure des méthodes de traitements parallèles pour solliciter davantage les cœurs des processeurs dans la production de build (ndt : des versions exécutables). Cette étape, associée à la collecte éventuelle de ressources supplémentaires, devraient réduire les heures de génération de build à quelques minutes.

Nous avons également travaillé en étroite collaboration avec les DevOps pour améliorer nos systèmes d’automatisation de build qui feront gagner en stabilité et en simplicité notre système actuel. Nous espérons pouvoir déployer le reste de ces modifications au cours des prochaines semaines. Pour le moment, nous sommes vraiment satisfaits des premiers résultats et je pense que tout le monde a hâte de voir la vitesse à laquelle nous pouvons sortir des versions.

 

Dev Ops

Nous avons sorti deux patchs ce mois-ci, les patchs 1.1.2 et 1.1.3, et aucun des deux n’est sorti un vendredi ! Notre équipe continuera de travailler avec l’entreprise pour que ces sorties se fassent toujours un mardi, comme cela se fait normalement dans le milieu, et puis avec un peu de chance, elle travaillera sur une production continue sur plusieurs années, ce qui devrait nous éviter d’avoir à stopper la production.

Nous avons apporté notre aide pendant les phases de tests du module FPS et en avons profité pour essayer nos nouveaux launcher et patcher (ndt : le client de lancement du jeu, et le système d’application des patchs). Jusqu’ici les essais se sont montrés concluants, mais nous avons quelques améliorations à effectuer avant de mettre ceci en place sur l’UTP pour que tout le monde puisse s’en servir. Le développement du launcher sera décomposé en trois étapes. Nous venons de mentionner la première, qui est liée à l’UTP. Elle se sert des interfaces utilisateurs existantes et les combine à notre nouveau patcher. La seconde étape comprendra une réécriture complète du lancher en C++. Associée au nouveau patcher et à l’ancienne interface utilisateur, elle proposera des améliorations dans la stabilité du code et aura la même allure et le même fonctionnement que le launcher actuel ou le launcher de PTU à venir. La troisième étape apportera une toute nouvelle interface utilisateur pour aller avec le nouveau super code en C++ et le patcher. Ces étapes se dérouleront sur plusieurs mois, et vous en saurez davantage sur chacune d’entre elles prochainement.

Pour finir, nous avons beaucoup travaillé sur la façon dont les données de l’entreprise sont crées, stockées et utilisées. Nous réfléchissons à la façon dont nous pourrions utiliser des branches dans Perforce, et comme les données sont dupliquées sur le serveur de la version exécutable travaillée, quelles données sont exclues, comment les responsables du développement étudient ces données. Créer de meilleurs outils pour Perforce, un autre pour Exclusion, ainsi qu’un nouveau système de version exécutable a également pas mal occupé les membres de l’équipe. Ce serveur est un projet particulièrement ambitieux dont nous souhaitons terminer les éléments centraux avant le 14 juillet. À cet effet, l’un de nos ingénieurs du studio de Francfort a fait le voyage jusqu’à Austin pour travailler avec nous durant ces trois prochaines semaines, pour cogiter ensemble sur des façons de mettre ça en place.

Nous avons du mettre en pause la fin de notre travail sur nos modélisations de données et sur la virtualisation de serveurs pour finir les outils qui gèrent les données utilisées par les studios. Nous retournerons nous occuper de ces tâches lorsque les outils actuellement en développement seront achevés, et quand notre équipe en charge des serveurs commencera à travailler sur le service persistant qui servira de principale structure d’interface à la base de données. Avec de la chance, nous parlerons de ce travail dans le rapport de juin !

 

FOUNDRY 42

Bonjour à tous ! Ici à Foundry 42, nous travaillons sur tout, d’Arena Commander (jeu en équipage) à Squadron 42. Chris Roberts a passé le dernier mois ailleurs en Angleterre, à filmer des captures de mouvement pour Squadron 42… Et nous travaillons dur pour faire en sorte que les données générées là-bas donnent des cinématiques qui vont vous époustoufler ! Voici l’inventaire, division par division, de ce qui s’est passé à Manchester ce mois-ci :

 

Animations

Ici au Royaume-Uni nous travaillons encore pour répondre aux besoins de nos concepteurs. Pendant que les directeurs, qui sont à Imaginarium, continuent de capturer les données dont nous avons besoin, nous sommes occupés à fournir des animations pour les départements de conception et programmation, afin qu’ils s’attaquent aux mécanismes de prototypage et de mise en œuvre.

Nous travaillons aussi globalement avec les différents studios pour globaliser les outils dont nous avons tous besoin pour pouvoir travailler utilement et efficacement, afin d’atteindre les objectifs fixés pour Squadron 42 et le reste.

Chef britannique du département Animation, Uisdean Ross.

 

Ingénierie

Lors des rapports précédents nous avons brièvement mentionné quelques-uns des mécaniques de jeu générales sur lesquels nous travaillons ici au Royaume-Uni. Ce mois-ci nous avons décidé d’en dévoiler un petit peu plus sur quelques-unes d’entre elles, et en vous parlant desquelles il s’agît et de leur avancement.

Le système de conversation : comme d’habitude on a beaucoup travaillé dessus ce mois-ci, les points particuliers étant la correction des conversations PNJ à PNJ, et l’aspect multijoueur du système de conversation, dont un premier jet est en préparation pour le module social. La police des sous-titres a été également améliorée ; le travail de réorganisation de l’interface du choix des joueurs dans l’arborescence des conversations est également en cours. Pour Squadron 42 nous disposons maintenant de la synthèse vocale, ce qui est très utiles pour prototyper les conversations au vu du nombre de dialogues qui sont ajoutés à ces niveaux. Nous progressons également du côté des animations de ce système, avec l’aide du studio d’Austin, pour qu’il soit prêt à recevoir toutes les chouettes captures de mouvements disponibles.

L’ASP (Arc à Soudure Personnel). Cette arme/gadget est particulière, car son fonctionnement lui permet de multiples usages. Nous avons principalement pris des approches techniques et conceptuelles. Pour la partie technique, le système de découpe a été amélioré pour qu’il intègre notre système de dégâts, ainsi tout est maintenant plus réaliste ; en fait vous pouvez maintenant voir comment les surfaces découpées sont affectées par l’énergie de l’ASP. En plus, une révision complète du système de visée a été faite, permettant, par exemple, d’activer ou de désactiver la visée laser, de modifier son comportement, etc. Pour la partie conception et modifications, nous avons modifié différents effets comme le rayon et le point du système de visée (pointeur laser), et nous en avons ajouté de nouveaux comme les effets d’impact et de nouvelles particules.

Système de prélèvement d’objets. Dans ce cas nous nous sommes concentrés sur quelques changements techniques. Le système de prélèvement précédent était basé sur les objets donc, pour nous, une entité était un groupe d’objets qui pouvait être saisi. Nous voulions toutefois quelque chose de plus puissant, pas seulement pour prendre les objets, mais pour les positionner également, alors nous avons décidé d’utiliser le système des ports pour objets (il s’agit d’un moyen très puissant et adaptable qui définit comment les objets peuvent être assemblés les uns avec les autres). Il en résulte que nous dépouillons maintenant une entité, et pas nécessairement un cadavre ; nous cherchons quels genres de ports elle a, nous pouvons prélever les objets de ces ports et placer des objets dans ces ports. En résumé, nous avons transformé un système spécifique en quelque chose de plus général et plus puissant.

Portes hydrauliques. Les portes hydrauliques sont l’extension d’une porte automatique normale. Elles ont maintenant l’option de pouvoir être « contrôlées informatiquement », permettant ainsi d’avoir des particularités où nous pouvons verrouiller la porte dans chaque direction. Nous avons ajouté une nouvelle méthode de sécurité pour les joueurs ayant les accréditations nécessaires, ils peuvent maintenant verrouiller et déverrouiller les portes, et redéfinir les mécanismes de verrouillage et de commande manuelle. Le mécanisme de commande manuelle sur certaines portes permet au joueur d’utiliser son ASP pour en découper une partie et mettre à jour une pompe hydraulique manuelle qui permet d’ouvrir la porte manuellement. Ces portes ont été insérées dans les hangars, elles sont ainsi unifiées afin d’utiliser le même système partout.

Kit de soins : cet objet a été ajouté dans les modes FPS du jeu, afin de rétablir la santé du personnage. Lorsqu’il est utilisé le personnage effectue un premier soin : il se saisit de l’objet qui ressemble à une seringue et en injecte le contenu dans un port de son armure. Les soins prodigués de cette façon vont se répartir dans tous les membres de façon égale.

Objets récupérables : ils existent sous deux formes, soit en tant que matériels qui peuvent être récupérés à peu près comme le système de prélèvement, soit en tant qu’informations scannées, les deux pouvant être ajoutés à votre inventaire. On peut citer comme exemples des éléments de technologie qui peuvent être ramassés pour leur valeur financière, ou des plaques d’identification qui peuvent déverrouiller le profil de personnages. Ces objets peuvent être découverts dans de nombreuses zones de Squadron 42.

 

Graphismes

Ce mois-ci, l’équipe en charge des graphismes a principalement travaillé sur différents domaines en parallèle. Nous sommes sur le point de finir un système automatisé pour les artistes, qui trouve de façon pertinente les maillages qu’il peut fusionner dans l’environnement, afin d’augmenter les performances. De grandes parties de notre niveau étant construites à partir de kits modulaires (pour en produire la quantité nécessaire pour l’UP), nous finissons avec plus de maillages que CryEngine, DirectX et les pilotes graphiques peuvent supporter. Fusionner les maillages réduit le nombre total d’objets dans le niveau, mais si l’on faisait cela sans discernement, un simple niveau prendrait plusieurs gigas de RAM. Ainsi, notre algorithme évalue toutes les opérations de fusion potentielles et ne traite que celles qui nous donnent le plus d’économies en termes de performances, pour un coût de mémoire le plus bas possible. L’algorithme continue de fusionner les meilleurs candidats jusqu’à ce qu’il atteigne un capital de mémoire fixé ou un niveau de performances spécifié par l’artiste. Il en résulte finalement une économie massive du nombre d’objets donc des performances, le tout pour un coût minimal en mémoire et pour un effort moindre pour l’artiste.

Durant les derniers mois, l’équipe des effets spéciaux visuels s’est heurtée à des limitations et bugs variés dans le système d’éclairage des particules, pour lequel certains membres de notre équipe se sont consacrés l’améliorer ; cela devrait permettre aux artistes en effets spéciaux de pouvoir créer des effets qui s’intégreront mieux dans l’environnement. Le reste de l’équipe s’est occupé des nombreux bugs à traiter avant chaque sortie, et cette fois il s’agit des bugs du FPS relatifs à l’amélioration des performances, du flux et de la profondeur de champ. Nous avons aussi intégré certaines corrections pour le rendu du « vaste monde » qui permettront au CryEngine de fonctionner avec des cartes de taille pratiquement illimitée.

 

Conception

Ce mois-ci, l’équipe conceptrice britannique a continué son travail sur plusieurs chapitres de Squadron 42, le rapprochant de la boîte grise. Actuellement, la priorité pour l’équipe est la capture de mouvements qui se fait à Londres. Chaque concepteur pu assister aux performances incroyables de notre équipe d’acteurs, [colro=red]jouant des scènes dans les niveaux qu’ils avaient imaginés qui, même s’ils n’en sont qu’au stade de white boxing (ndt : une modélisation 3D non fonctionnelle), rendent incroyablement bien[/color] et donnent beaucoup de vie au monde que nous construisons !

Le niveau « tranche verticale » (Ndt : sorte de démo d’une partie du jeu), progresse considérablement aussi, ce qui nous permet de répondre à des questions essentielles concernant les mécaniques de jeu centrales et de développer nos caractéristiques pour les scénarios expérimentaux en combat spatial et en FPS.

Pour chapeauter le tout, l’équipe de conception britannique donne un coup de main dans tous les autres domaines de Star Citizen, comme vous l’avez sans doute vu avec Arena Commander, les armes les vaisseaux, et le module FPS à venir qui nous occupe tous !

 

Art

Eh bien, quoi dire, pour ceux qui ont osé regarder le contenu qui a fuité, vous pouvez certainement voir que nous faisons bon usage de votre argent durement gagné pour faire le meilleur contenu possible ! Si vous avez été raisonnable et vous êtes abstenu, c’est bien ! Nous allons vous donner quelque chose qui récompensera votre retenue.

Ici chaque mois est bien chargé, il n’y a pas une minute qui ne soit consacrée à une prise de décision sur l’intégration de pixels ou de polygones. Le travail sur la conception des vaisseaux commence à diminuer, il s’agit principalement de rectifier ici et là la drôle d’image que nous avions ratée. La flotte vanduul a été conceptualisée dans sa totalité, il ne reste plus que les armes et les tourelles sur lesquelles il faut travailler. Un bon travail a été fait par Jan Urschel et AtomHawk sur les environnements, ce qui nous aide vraiment à mettre en forme la ligne scénaristique de Squadron 42.

 

Environnements

Le mois dernier, nous nous sommes principalement consacrés à avancer sur notre tranche verticale, et à apporter notre soutien aux prises de vues à Londres. Pour la tranche verticale nous nous sommes forcés d’atteindre un niveau de détail approprié pour Star Citizen, une attention particulière a été apportée aux personnages lorsqu’ils traversent le niveau, aux bénéfices apportés par l’exploration des lieux, aux vues et compositions, et bien sûr à la qualité du travail artistique. Pour les prises de vues nous nous efforçons de faire en sorte que les scènes capturées fonctionnent correctement, et nous faisons les derniers changements, qui sont toujours importants. L’excitation est grande en amont comme en aval, et nous sommes impatients de tout vous montrer.

 

Effets spéciaux

Nous avons eu tout un mois de support de code de la part des ingénieurs graphiques, ils nous ont débarrassé d’un nombre impressionnant de bugs et requêtes diverses. Nous avons embauché un nouvel artiste en effets spéciaux, donc l’équipe grandit ! Cela nous a permis de progresser dans les domaines suivants :

– Les variantes d’effets spéciaux environnementaux pour Squadron 42, c’est-à-dire :
– Les étincelles
– La vapeur
– Le feu / les dégâts
– Les tempêtes spatiales (attention c’est dangereux !)
– La recherche et le développement des effets des grandes tourelles : flamme de départ, traçantes, impacts etc.
– La recherche et le développement des cinématiques de Squadron 42 : flux et pipelines typiques
– Effets divers sur les vaisseaux

Sur une note un peu moins exaltante, nous travaillons beaucoup, en arrière-plan, pour assurer nos flux et pipelines, et donner corps aux programmes des effets spéciaux, ce qui nous permet de maîtriser la multitude de demandes d’effets dans tous les domaines de l’univers de Star Citizen !

 

Vaisseaux

Ah les vaisseaux… ils maintiennent tous nos meilleurs artistes en alerte. L’Idris est en bonne voie, eh oui, il y a même quelques surprises (je sais que vous les adorez/détestez), il y a eu beaucoup de travail pour ficeler le style de conception de manière cohérente afin qu’en aval on sache clairement quel constructeur fait quoi, donne quelles lignes, quelles lumières à leurs vaisseaux … la liste est longue mais au moins, chaque artiste interne ou externe saura clairement quoi faire.

L’intérieur du Starfarer est en suspens, l’ARGO a besoin d’un traitement au shader, les drones de minage sont en cours, et oui, le Jav n’a pas été commencé, nous sommes au maximum de nos capacités jusqu’à ce que nous trouvions plus de personnel. Allez, rejoignez-nous, et faites Meilleure Foutue Simu’ Spatiale Jamais Créée 🙂

 

Interface de l’utilisateur (IU)

Nos effectifs ont doublé : nous sommes passés de un à deux artistes ! Le travail s’est poursuivi sur l’IU du FPS et actuellement nous explorons les possibilités du style et de l’apparence pour Shubin, Aegis et Vanduul – à surveiller.

 

Personnages

L’équipe en charge des personnages s’est rendue au studio de tournage d’Imaginarium, à Londres, nous avons reçu un choc absolu ! Chaque séance était drôle et excitante, et nous avons réussi à capturer des données de premier ordre sur des acteurs hors pair. On dit qu’on ne rencontre jamais ses héros, je ne suis pas du tout d’accord et chacun d’entre eux s’est montré amical, professionnel et enthousiaste.
Le traitement des données a commencé et quelques-uns d’entre vous ont déjà vu le résultat de notre séance avec Sandi, ce qui est un bon exemple de l’énergie et de la motivation qui nous animent sur ce projet.

Je regrette juste de ne pas pouvoir vous dire qui est passé devant les caméras !

 

Audio

Salut tout le monde ! Du côté de CIG Audio nous continuons principalement à avancer sur la mise en ligne du format Wwise. Il y a toujours beaucoup de choses basiques à faire mais nous progressons.

Il me paraît juste de dire que nous nous rendons compte que beaucoup de travail préparatoire a été nécessaire, en ce qui concerne l’ingénierie. Nous pensions (peut-être de façon optimiste) que la plupart des systèmes auraient simplement eu besoin d’avoir des événements Wwise mis en place, qui se déclencheraient de la même manière que leurs équivalents FMOD, et en avant la musique ! Mais cela a rarement été le cas, et plus l’on creuse, plus l’on trouve de choses à faire.

En fait ça a été plus une affaire de prendre le produit brut, le nettoyer, supprimer les détails en terme de données sonore, code et logique, car il a fallu s’assurer que les événements et les sons Wwise existaient purement et simplement. Certaines choses fonctionnaient sous FMOD, qui continuaient toujours à marcher, mais davantage en tant que telles qu’en terme de conception. Ce n’est la faute à personne en particulier, c’est juste que l’audio réagit aux changements de projets tardivement dans le développement du jeu.

Dans la mesure du possible, nous avons fait en sorte que le passage à Wwise se fasse sur le court terme, de façon réactive, dans le sens où nous voulons approcher les choses en allant au-devant du jeu (littéralement) autant que possible : avec des modules dans Wwise par exemple, en gardant le tout bien propre et sans bidouillage. Nous avons à nouveau réuni notre équipe de codage et notre équipe technique de conception sonore basée à Austin, de façon à mieux nous creuser les méninges sur le montage du FPS. Mettre en place ce nouveau système, mettre à niveau le module de dogfight, et soutenir les multiples aspects de l’univers persistant : tout cela aurait été suffisamment difficile sans avoir à s’occuper du nouveau moteur sonore. Mais nous ne devons pas trop râler !

Malheureusement l’un de concepteurs sonores en chef, Tom, nous a quittés ce mois-ci. Il nous manque, car il avait une solide expérience sur CryEngine en particulier, mais une occasion de se rapprocher de sa famille s’est présentée à lui, et l’on peut difficilement s’opposer à cela. Il part donc en bons termes – nous lui souhaitons bon vent dans ses futurs travaux, il ne sera pas facile à remplacer.

Autrement, nos nouveaux studios d’enregistrements viennent d’être achevés, la plupart sont prêts à être occupés. Nous devons encore habiller les murs pour l’acoustique, et nous attendons l’ameublement et les moniteurs (les moniteurs sont appelés haut-parleurs par les équipes-son, juste pour embrouiller tout le monde), mais c’est bien de voir se monter ces studios. Nous avons essayé de donner à chacun d’entre eux son propre motif de couleurs, ce qui provoquera soit des élans créatifs, soit de la folie douce. Cela dépend vraiment du studio. Nous aurons peut-être un peu des deux ! Ils devront être réglés et mis au point pour être acoustiquement neutres. Il faut dire qu’ils sont un peu petits, ce qui fait qu’il sera difficile de s’assurer qu’ils n’auront pas d’ondes stationnaires ou autres, mais les arranger ne prendra pas beaucoup de temps.

Nous essayons de tenir les délais pour expérimenter les processus liés aux voix extra-terrestres, ce que nous avons commencé à faire pendant que les linguistes mettent au point les langues extra-terrestres. C’est toujours un domaine épineux, mais c’est intéressant de voir ce qu’on peut faire entrer dans l’équivalent sonore de la vallée dérangeante. (Ndt : La vallée dérangeante (de l’anglais “uncanny valley”), est une théorie scientifique selon laquelle plus un robot androïde est similaire à un être humain, plus ses imperfections nous paraissent monstrueuses).

Comme ci-dessus, nous aidons au tournage en cours de Squadron 42, au sujet duquel je ne vais rien dire évidemment, donc ne me posez pas de questions à ce sujet. 😉

Merci d’avoir pris le temps d’avoir lu ce qui se passe au département Audio de CIG. N’hésitez pas à poster une ou deux questions dans le forum « Ask a Developer » (ndt : Interrogez un dev’ en français), nous ferons notre possible pour répondre. À la prochaine !

 

 

FOUNDRY 42 FRANCFORT

L’équipe de Francfort continue de s’agrandir et demeure active dans de nombreuses disciplines : technologie, IA, conception, cinématique, son, animation, effets spéciaux, ect. Comme vous avez pu le voir dans notre vidéo du mois dernier, nos bureaux temporaires se sont remplis très vite, nous louons donc une nouvelle salle pour pouvoir accueillir les nouveaux employés. Nous nous préparons à déménager dans notre bureaux définitifs, le déménagement officiel se fera début juillet, et nous réaliserons certainement une vidéo à cette occasion. Nous ne faisons partie de l’équipe que depuis quelques mois, mais l’inertie et les progrès qui se dégagent de cette coopération de studios fait plaisir à voir, et nous sommes ravis d’en faire partie.

 

Ingénierie

Pour le mois de mai, les ingénieurs de Francfort étaient sur de nombreux fronts. Nous avons fait beaucoup de progrès sur les grands environnements (passer le code vers une base de coordonnées 64 bits, permettant ainsi la création de niveaux à explorer faisant (littéralement) la taille d’une galaxie). Le plus gros du travail était de passer le rendu de la caméra en mode relatif : en fait, la transition au 64 bit obligeait à changer l’ensemble du code lié au rendu à être relatif à la camera, et non plus simplement en positionnement absolu dans l’univers.

Nous avons également fait beaucoup de progrès sur le système de zones, qui est notre nouveau système de partitionnement de l’espace, remplaçant le vieux système de partitionnement du CryEngine qui se basait sur une structure d’arbre à huit nœuds (ndt : OctTree, pour les plus calés en structure de données). Ce nouveau système est spécialement adapté pour Star Citizen qui possède de grandes cartes dynamiques, un nombre important d’entités et de vastes vaisseaux. En parlant de vaisseaux à équipages, nous avons également travaillé sur les grilles physique locales des vaisseaux (qui permettent aux joueurs de se déplacer dans un vaisseau en suivant son mouvement), le temps d’exécution des différents modules pré-requis et nous avons effectué des recherches concernent d’autres optimisations au niveau des entités et du streaming. Nous testons actuellement en interne tous ces nouveaux systèmes sur le Retaliator.

Nous avons également commencé à implémenter un format de stockage des données des sommets des modèles pour réduire la taille totales des données, améliorer le temps de chargement et la charge mémoire, ainsi que la performance CPU/GPU. Ces optimisations devraient arriver assez vite.

Nous avons lancé quelques discussions R&D au sujet de la génération procédurale, qui bénéficiera d’un temps dédié dans un futur plus ou moins proche, quand nous aurons mis en place tous les systèmes sus-mentionnés. Nous avons également fait beaucoup de nettoyage de fonctionnalités CryEngine devenues obsolètes pour Star Citizen, la gestion des levels 32bits, des noeux de rendu non utilisés, et beaucoup d’autre plus petits objets. De plus, nous avons travaillé sur l’intégration du nouveau SDK 3.7 dans notre code. Toutes ces tâches majeures sont sur le point de se retrouver dans la version publique. Enfin, nous avons continué à apporter une aide globale sur le moteur, en implémentant diverses fonctionnalités et en corrigeant certain bugs.

Nous avons également mis à jour nos outils de profilage mémoire et débarassé le code du moteur des traces de l’ancien outil.

 

IA

Le mois dernier nous avons bâti les fondations robustes pour le futur de l’intelligence artificielle dans Star Citizen.

Nous avons commencé à unifier le Système de Communication du CryEngine (SCC) avec le Système de Réaction Contextuelle de CIG (SRCC). Que font ces systèmes ?

Le SCC permet à l’IA de “parler” : le comportement (où un autre système) peut demander à jouer une certaine ligne de communication (par exemple “SaluerLeJoueurDevantVous”), le système va analyser cette requête et s’en occuper en choisissant une version appropriée pour ce concept (par exemple “Salutations, mon ami !”) et et en vérfiant si le chemin défini permet de jouer le son qui s’y rapporte. Si une communication sur un canal haute priorité arrive, le système doit annuler le message actuel s’il est d’une priorité moindre.

L’exemple classique est celui du PNJ qui se fait taper où tirer dessus alors qu’il est en train de parler. Son cri de douleur doit évidemment interrompre le message qu’il était en train de délivrer. Le SCC va lancer une ligne de communication spécifique, liée à un événement du jeu. Un vaisseau lourdement endommagé peut par exemple émettre un message “VaisseauEndommagé” qui est capté par le SRCC qui va choisir une variation adaptée de ce message. Le SRCC est déjà pleinement implémenté dans DataForge, les scénaristes peuvent donc créer du contenu sans avoir besoin de toucher au code. Nous avons donc travaillé à unifier ces deux systèmes en un seul pour combiner les avantages des deux.

Nous avons également commencé à connecter le Système de Surface de Couverture du CryEngine pour le connecter à notre Système de comportement de Kythera (ndt : leur gestionnaire d’IA) pour permettre le support de ces nouveaux environnements plus vastes. Le SSC est capable de prendre un objet physique et d’automatiquement créer les données relatives aux positions “à couvert” derrière cet objet.

De plus, nous avons également mis en place les bases pour étendre le système de Navigation MNM du CryEngine (ndt : Multi-layer Navigation Mesh, Navigation multi-niveaux), toujours pour mieux supporter ces niveaux plus grands et nos grilles locales. Nous sommes en train de prototyper la liaison à chaque vaisseau se déplaçant sur une grille de navigation locale. Cela nous permettra dans le mois prochain de déplacer les membres d’équipages PNJ dans l’environnement interne du vaisseau.

Nous nous sommes également concentrés sur la coordination des efforts avec Moon Collider sur l’amélioration du système d’arbre de comportement de Kythera (ndt : BTS, Behavior Tree System). Ce système est maintenant intégré dans DataForge, permettant au système comme aux développeurs de créer ou de prototyper de nouveaux comportements sans avoir à écrire du code C++. De nouveaux nœuds de comportement ont été ajoutés pour supporter des fonctionnalités basiques d’automates, compteurs et bascules. Toutes ces fonctionnalités vont nous permettre d’implémenter des comportements plus complexes et intéressants.

De façon générale, nous avons énormément de nouvelles fonctionnalités sous le coude, et nous vous préparerons des vidéos et des photos pour illustrer plus en détails nos progrès dans les mois suivants !

 

Conception

Coté conception, nous avons travaillé étroitement avec l’équipe en Angleterre et nous sommes approprié la paternité d’un niveau de Squadron 42. Nous sommes actifs dans tous les aspects du développement de Star Citizen, de la sortie du module FPS jusqu’au développement d’un retour haut-niveau du comportement de l’IA qui touche à tous les domaines du jeu. D’autre challenges sont présents comme l’intégration et la configuration la jouabilité à bord d’une tourelle, donner un retour haut-niveau vis à vis de Squadron 42 à l’équipe anglaise et le travail à faire sur l’unification du système de personnalisation des tenues du FPS pour la rendre plus semblable à nos vaisseaux actuels.

 

Cinématique

Quelques membres de l’équipe se sont rendu à Londres et y sont rester tout le mois avec Chris Roberts pour filmer des scènes de Squadron 42. Le casting est incroyable et nous avons hâte de vous annoncer qui en fait partie et vous montrer leurs performances. Nous consolidons notre équipe en charge des cinématiques et commençons à gagner en traction sur la production interne et ses méthodes .

 

Audio

Notre concepteur sonore a passé tout le mois en Angleterre pour leur permettre de lancer leur production audio sur Wwise pour la prochaine release.

Nous avons continué la conversion du vieux code FMOD vers le nouveau système audio. Passé un peu de temps à aider au développement de script de conversion pour automatiser les parties les plus simples du processus, pour que les concepteurs sonores puissent se concentrer sur les sons eux-mêmes et la façon dont ils sont appelés en jeu, plutôt que de devoir s’embêter à convertir des fichiers. Nous avons également mis en place les nouveaux outils relatifs aux fichiers audio à l’intention de nos concepteurs et des serveurs de productions pour accélérer la production audio quotidienne.

 

Effets spéciaux

Nous nous sommes concentrés principalement à la recherche de différent type de feux à inclure au jeu. Des petits débris enflammés jusqu’aux gerbes de flammes et autres gigantesques explosions. La fumée est également une partie cruciale, et réunir les deux de façon réalistes fut l’une de nos priorités pour ce cycle de R&D

Nous avons également travaillé un peu sur l’éclairage pour quelques missions de SQ42, qui sera en grande partie utilisé comme effet longue distance à l’arrière plan.

 

 

BHVR

Bonjour citoyens ! …ou bonsoir les pirates ? … Il est quelle heure dans l’espace de toute façon ?! Postez la bonne réponse dans les commentaires et gagner un pouce vers le haut.

Parce que ça prend plus d’un mois de créer toutes les choses importantes dans un jeu aussi immense et détaillé que Star Citizen, vous devriez trouver que ce rapport mensuel est similaire à celui du mois dernier mais avec des mots différents 🙂 Néanmoins, cela NE VEUT PAS DIRE que ce mois était vide de progrès, loin de là ! Voici le rapport mensuel de l’équipe BHVR :

Premièrement, nous avons fourni beaucoup d’efforts pour perfectionner, déboguer, et aider les autres studios sur différents modules du jeu. Comme nous approchons de la sortie du module FPS et de la livraison du module social (soyez prêts à ouvrir les vannes à excitation !) on n’a pas vraiment de temps pour ajouter de nouvelles fonctionnalités, mais plutôt pour polir et consolider ce qui est déjà présent.

Voici les principaux modules, systèmes, modules systémiques et systèmes modulaire que nous avons débogués, peaufinés et/ou travaillés ce mois :

– Le système de discussion instantannée du jeu
– Le système d’emotes (ndt : des commandes à entrer pour que votre avatar effectue des mouvements ou exprime ses émotions) : /dance /dothebender
– Le module FPS
– Le système pour rejoindre patienter dans la salle d’attente avec un équipage
– Le système pour gérer son équipement du module FPS dans la salle d’attente

Parlons un peu du module social. Nous avons ajouté plus de fonctionnalités au système de discussion instantannée afin de le rendre plus facile et plus amusant à utiliser. Nous avons intégré la première version des onglets de filtre de conversation pour permettre d’avoir plusieurs conversations privées ou publiques de manière compréhensible et ordonnée. Nous avons fait des essais sur l’interface et ça nous a conduit à verrouiller cette première version.

Nous avons passé un peu de temps à corriger les objets interactifs comme les cadeaux aux abonnés, l’holotable et les portes du côté client et serveur. C’est évidemment pertinent pour tous les emplacements en jeu, pas juste pour les hangars.

Les ingénieurs ont débogué les duplications et les instanciations des hangars pendant que les concepteurs de niveau ont corrigé tous les types de problème à l’intérieur de ceux-ci. Je ne sais pas ce que vous faites dans ces hangars les gars, mais ils semblent tout le temps cassés ! Arrêtez de fracasser vos buggies sur tous les murs, s’il vous plaît. 😉

La création du module d’apparition de base est complet ce qui, croyez-le ou non, gère l’apparition de plusieurs joueurs simultanément dans les hangars et sur les emplacements planétaires. Avec lui, nous pouvons vous faire apparaitre (Enfin pas vous, mais votre personnage) à l’emplacement correct, selon l’endroit d’où vous venez (Hangar -> Planète, Espace -> Planète, etc). Nous ne pensions pas que le chargement et l’apparition pourraient être aussi intéressants, mais nous avons hâte de voir voir les vidéos que vous posterez à propos de votre première apparition sur une planète.

Bien ! Maintenant on va s’amuser un peu : les planètes ! Ce mois-ci du côté du département artistique, nous avons terminé tous les éléments de décors pour une planète de minage industriel. Le but est d’utiliser ce décors à travers la galaxie, surtout, mais pas uniquement, sur Delamar dans le système Nyx. Notre principal objectif est de rendre ces éléments de décors aussi souples que possible pour permettre aux autres équipes d’artistes sur ce projet de créer différents endroits. Ça a pris pas mal de temps pour le terminer, mais nous sommes très heureux du résultat final.

Nous avons aussi débuté le travail sur l’héritage des objets pour les rendre conforme[olor=red]s[/color] avec nos nouveaux standards visuels et techniques. Alors que continuer de créer des environnements, nous améliorons nos techniques et puisque ces « vieilles » parties seront utiles à l’avenir, nous devons être certains qu’elles sont conformes.

Nos concepteurs de niveau sont en train d’explorer et perfectionner nos autres emplacements, comme les blocs sur Terra Prime, Marianna ou Odyssa et créent également de nouveaux décors intérieurs et apportent leur aide pour peaufiner les lieux déjà créés. Un peu comme le travail artistique qui a été accompli sur les objets d’héritage, quelques objets interactifs ont aussi étés modifiés et avaient besoin d’être retravaillés pour rester au top.

Nous avons beaucoup amélioré et avancé le mobiGlas. Nous avons intégré les animations pour le rendre super fluide. Quelques ajustements et améliorations ont également été apportés sur le flux d’achat. Nous pouvons désormais afficher votre solde d’UEC et vous pourrez aussi acheter de l’équipement et d’autres choses pour de vrai !

Dans la même veine, nous avons fait un premier test d’intégration sur l’IU, le code et les visuels du kiosque microTech. Vous devez vous demander “C’est quoi ce bord-hull ?” Eh bien, certaines boutiques et d’autres endroits dans l’univers ont des kiosques microTech qui sont utilisés pour montrer des représentations holographiques de produits extra larges qui ne tiennent pas dans ces lieux. Les kiosques sont aussi utilisés pour accéder à un catalogue d’inventaire avec l’aide du mobiGlas. Le mobiGlas est aussi un produit microTech, donc maintenant vous voyez le lien. Notre premier kiosque sera utilisé à Astro-Armada, où il pourra être utilisé pour parcourir les la liste des vaisseaux et les acheter.

Les kiosques sont une partie de la première phase de l’expérience d’achat de vaisseaux. Nous prévoyons de développer des façons plus immersives et intéressantes pour acheter vos vaisseaux qu’il était impossible de vous proposer aussi tôt.

Un autre objet intéressant sur lequel nous travaillons est le casier personnel. Ne soyez pas dupe, ça n’a rien de cosmétique. Vous pourrez trouver votre casier personnel dans votre hangar et c’est ici que vous entreposerez vos gadgets et vos armes du FPS. Plus tard, ce casier sera non seulement utilisé pour afficher des armes, mais aussi pour préparer vos équipements de d’équiper votre personnage en adéquation avec la mission qui vous incombe.

Comme toujours, nous avons terminé la récompense aux abonnées de ce mois, ainsi que d’autres fournitures secrètes, dont nous ne gâcherons pas la surprise, parce que gâcher les surprises n’est pas amusant du tout.

Merci pour votre attention ! Maintenant retournez détruire quelques vaisseaux, n’est-ce pas ?

 

 

ILLFONIC

Salutations citoyens des étoiles ! Je suis sûr que la plupart d’entre vous a lu le gros article qui parle de Star Marine et de la raison pour laquelle il accuse un certain retard. Merci de votre patience ! Nous avons consacré le plus gros du mois de mai à travailler sur les objets cités dans l’article sus-mentionné. Lisez ci-dessous les rapports de chaque équipe.

 

Ingénierie

En plus d’éradiquer beaucoup de bugs, l’équipe d’ingénierie a apporté son aide aux animateurs pour les nouveaux systèmes de feinte, de départ et d’arrêt. Chaque changement de direction bénéficie d’animations uniques, ainsi que chaque état et chaque vitesse à laquelle se déplace le joueur. On se retrouve rapidement avec beaucoup d’animations ! Le travail s’est également poursuivi sur les mouvements en apesanteur et sur les fonctionnalités liées au SATA Ball. Après avoir essayé ce dernier mode de jeu, nous avons réalisé qu’il y aurait certaines situations particulières que nous devions traiter, afin de pouvoir gérer la balle dans un espace aussi vaste.

 

Conception

Les concepteurs ont travaillé d’arrache-pied pour terminer le mode SATA Ball. Cela se résume principalement à un travail sur la jouabilité et sur les indications visuelles pour que le joueur sache ce qu’il se passe. Il faut s’assurer que les joueurs puissent facilement trouver le ballon, s’assurer que les joueurs puissent facilement attraper et lancer le ballon avec précision et s’assurer qu’ils puissent naviguer jusqu’à elle avec efficacité. L’équipe a également réalisé de nombreux tests sur les armes de base ainsi que des modifications sur la façon dont la respiration affecte la précision. (ndt : oui, ça fait beaucoup de rimes en “on”)

 

Animation

Les animateurs se concentrent actuellement à nettoyer toutes les animations de feinte, de départ et d’arrêt, et à les préparer à être ajoutées dans le jeu. Comme expliqué plus haut, il y a BEAUCOUP de données liées aux captures de mouvements, donc ils ont du travail à ne plus savoir quoi en faire.

 

Art

L’équipe artistique s’est consacrée à deux objectifs principaux le mois dernier. L’un consistait à retravailler les assets pour que la station Gold Horizon bénéficie de la même cohérence que les décors de l’Univers Persistant. Les équipes des différents studios pourront se resservir de ces éléments de décor dans leurs niveaux. Le partage, c’est essentiel !
Le second objectif pour l’équipe artistique a été de peaufiner les armes existantes et de créer un système universel de fixation d’accessoire par rail. Cela permettra de créer des accessoires beaucoup plus facilement à l’avenir, puisque tout fonctionnera sur une même base.

 

Effets visuels

De nouveaux effets visuels ont été créés pour le SATA Ball : des effets pour distinguer les buts de façon à ce que les joueurs ne se perdent pas, mais également des effets pour le joueur lorsqu’il est touché et neutralisé. Nous avons également peaufiné tous les effets déjà créés en fonction des commentaires de Chris.

Merci pour votre lecture, citoyens ! Illfonic, terminé !

 

 

TURBULENT

Voici ce que nous avons fait ici à Montréal pour ce mois de Mai :

 

Carte stellaire

Le travail artistique a extraordinairement bien progressé ce mois-ci concernant la carte stellaire pour le site web. Nous avons maintenant des concepts artistiques complets pour le niveau supérieur de la vue galactique où tous les systèmes stellaires sont affichés, avec les connexions de points de saut. La principale difficulté était de trouver une façon de représenter les points de saut de manière esthétique mais aussi fonctionnelle afin de montrer la taille des trous de vers et leur direction quand c’était possible. De grands progrès ont été faits sur un affichage de type grille thermique en 2D pour montrer (à tous les niveaux) les influences politiques, les crimes et les niveaux économiques des zones de la galaxie. Bien que ce soit encore au stade expérimental, les visuels proposés par nos artistes ont inspiré la progression cette fonctionnalité.

Un composant d’interface utilisateur majeur dans ce travail artistique est le disque de contrôle, qui est un concept très intéressant parce que nous pensons qu’il pourra également être utilisé comme une fonctionnalité en jeu. Ce disque vous permettra d’interagir avec tous les éléments que vous verrez à l’écran en parcourant la galaxie. Notre maquette fournie par les artistes comprend également l’écran de “Vue générale l’objet spatial”, ce qui est essentiellement ce qui apparaît lorsque vous demandez plus d’informations sur un objet, que ce soit une planète, une ceinture d’astéroïdes, une nébuleuse ou un trou de ver. Cet affichage général servira d’écran principal pour les informations sur quoi que ce soit au sein de la carte stellaire ainsi qu’un lien pour les entrées Galactapedia pour chacun d’entre eux.

La conception de la carte stellaire est maintenant à un stade où elle peut être croisée avec les données issues du jeu, c’est pourquoi nous avons également conçu notre interface pour être en accord avec les commandes du jeu et son expérience.

 

Centre communautaire

Ce mois-ci, nous avons terminé les maquettes de cette nouvelle section, en harmonisant son visuel avec la nouvelle apparence du site, et en la reliant à un affichage piloté par les données du jeu. Nous avons passé énormément de temps à nous assurer que nous pourrions intégrer autant de contenu que possible venant des joueurs : des images et galeries, mais aussi des vidéos de différentes sources, des chaînes de streaming, des podcasts… Cette plateforme est toujours en développement, mais nous serons bientôt en mesure de vous en dévoiler un peu plus.

 

Conseil de Débogage

Nous avons passé un mois à coder tête baissée le Conseil de Débogage, notre nouveau système participatif de rapport de bugs. Le coeur du système a été complété en ajoutant les modèles de données et un système de niveaux à l’interface de programmation. Pendant ce temps, l’équipe de conception a travaillé sur l’interface utilisateur. Nous avons envoyé une démo à l’équipe d’Austin et ils sont tous excités de commencer à l’utiliser. En juin nous allons le tester en enregistrant ses propres bugs.

 

Client de lancement

Ce mois-ci nous avons terminé le nouveau prototype du client de lancement de Star Citizen en conjonction avec l’équipe DevOps à Austin. Le nouveau launcher est juste interne pour le moment, uniquement destiné à des tests en interne et est basé sur la technologie BitTorrent. Cela nous permet au système de patchs d’être plus performant en termes de taille et de vitesse, et constitue la première étape vers un launcher piloté par une plateforme web, ce qui permettra d’avoir plus d’outils de configuration directement dans le launcher (configuration du hangar, le futur inventaire, l’activation des REC…).

 

Discussion instantanée

Le système de discussion instantanée a également été amélioré ce mois-ci. Nous avons repensé son apparence pour la faire correspondre au reste du site, et nous avons introduit les sujets épinglés pour une meilleure lisibilité.

 

En voilà plus !

 

Ce mois-ci a également apporté son lot de nouveautés sur le site. Nous avons vu deux ventes conceptuelles avec le Starfarer Gemini et le nouveau Reliant de MISC, le mini-transporteur, et nous vous avons également présenté le mini-jeu Hyper Vanguard Force IV créé au studio de Montréal par Dave Richard et Christine Marsh. Apex Predators, rassemblement !

Pour finir nous avons également mis en place le nouveau système de paiement Amazon “Login And Pay” pour les utilisateurs nord-américains.

 

 

MOON COLLIDER

Alors que les derniers mois furent chargés en planification et en conception, le mois de mai fut léger de ce côté, nous permettant de nous impliquer dans un passionnant travail d’ingénierie. Nous avons progressé sur plusieurs grandes fonctionnalités des outils de développement et nous sommes impatients de les voir utilisées.

Ingénierie

Le mois dernier, nous avons parlé de ces superbes améliorations de courbes vectorielles sur lesquelles nous travaillions. C’est une fonctionnalité permettant aux concepteurs de spécifier un modèle de trajectoire sur laquelle ils veulent coller un vaisseau (dans le but de lui faire faire des manœuvres fantaisistes ou de voler au plus près d’obstacles desquels une intelligence artificielle chercherait plutôt à rester à distance), après quoi l’IA calcule un chemin optimal pour coller à ce modèle aussi rapidement que possible. Pour cela l’IA doit définir un chemin depuis sa position et sa direction actuelles jusqu’au début de la trajectoire prévue et s’orienter une fois là-bas selon la direction de celle-ci. Cela peut alors devenir plus compliqué parce que les concepteurs peuvent spécifier la vitesse à laquelle ils veulent que le vaisseau soit quand il commence la fameuse trajectoire programmée, ce qui peut affecter le parcours de liaison effectué car le vaisseau pourrait avoir besoin de plus de distance pour prendre son élan ou au contraire de ralentir beaucoup. Et, bien sûr, nous voulons que tout ceci ait l’air parfaitement naturel.

Nous avons achevé cette fonctionnalité ce mois-ci et nous l’avons mise à disposition des concepteurs pour en faire usage. Maintenant que les vaisseaux peuvent rejoindre des modèles de trajectoire de façon fiable, ceux-ci sont beaucoup plus faciles à utiliser dans des comportements systématiques. Jusqu’ici nous avons été assez restrictifs quant à la décision prise par un vaisseau de s’engager sur un modèle de trajectoire, mais ceci leur donne beaucoup plus de liberté si bien que – lorsque nous aurons ajusté les comportements – vous verrez l’IA s’en servir beaucoup plus souvent dans les futures versions d’Arena Commander.

La plus grande caractéristique sur laquelle nous avons travaillé ce mois-ci a été un changement complet de la façon dont nous référons les arbres de comportement de l’IA. Jusqu’à présent, nous les référencions directement dans le code. Utiliser la recompilation à la volée de C++ de Kythera était assez efficace et permettait des changements rapides en cours d’exécution du jeu, mais cela n’était pas accessible aux concepteurs sans connaissances en programmation. Nous avons donc beaucoup travaillé pour permettre à ces arbres de comportement d’être manipulés à l’intérieur de DataForge.

Vous aurez entendu bien des mentions de DataForge dans le passé, car c’est un outil personnalisé de gestion de ressources utilisé par les concepteurs pour tous les types de données différentes de Star Citizen. Il a été conçu dès le départ pour permettre des vues différentes selon les types de données, de sorte que le cas échéant, vous puissiez modifier les données dans un format de style tableur, tandis que pour d’autres objets, une vue graphique en hiérarchie de nœuds est plus appropriée, et ainsi de suite.

Nous avons maintenant une catégorie de données de type arbre de comportement dans DataForge, qui permet aux concepteurs de les éditer à l’aide d’une interface graphique conviviale puis d’appliquer ces comportements directement à une entité IA, sans avoir à écrire le moindre code. De plus, ils peuvent modifier les arbres de comportement à la volée et voir les résultats immédiatement, un atout fantastique pour un développement rapide.

Pouvoir créer régulièrement de nouveaux nœuds dans les arbres de comportement est cependant ce qui a rendu cette caractéristique particulièrement intéressante à nos yeux, car nous voulions les ajouter dans DataForge aussi facilement que possible. Nous avons donc travaillé un moment pour créer une simple commande en ligne dans l’éditeur qui génère automatiquement de nouvelles définitions pour DataForge ainsi que le nouveau code de liaison en C++ qui relie les structures arborescentes de comportement stockés sous DataForge avec le code de comportement sous-jacent de Kythera. Alors, quand un codeur crée un nouveau nœud, il lui suffit de taper juste une ligne de commande et le nœud est désormais entièrement intégré dans DataForge !

Donc, bien qu’il soit toujours possible de créer des comportements d’IA en C ++ comme avant, nous avons maintenant une interface alternative avec cette méthode de création graphique, qui est ensuite traduite en code C++ équivalent lorsque le comportement fonctionne. Nous sommes ravis de voir les concepteurs commencer à travailler avec ce nouvel outil et créer de grands arbres de comportement. Nous nous attendons à devoir faire quelques petites améliorations dans un avenir proche pour rendre l’interface encore plus conviviale pour les concepteurs, mais nous pensons que nous tenons là un excellent point de départ. Et nous devons absolument décerner nos remerciements à Ash Canning de Foundry 42, le cerveau derrière DataForge qui a fait en arrière-plan beaucoup de réglages en un temps très court pour permettre à DataForge d’éditer au mieux des arbres de comportement.

Pour finir, nous avons travaillé un peu à l’intérieur de notre outil Kythera Inspector pour permettre aux concepteurs de déboguer leurs arbres de comportement beaucoup plus facilement, en obtenant en direct une représentation visuelle de ce que l’arbre est en train de faire à tout moment. Le mois dernier, nous avons ajouté la possibilité d’enregistrer et de rejouer les états d’arbres de comportement, mais c’est utile surtout pour corriger les bugs. Pour l’élaboration de nouveaux arbres de comportement, une vue en direct de ce qu’ils font est encore plus pratique. Nous mettons la touche finale à cette fonctionnalité et nous allons la mettre à disposition des concepteurs bientôt, nous livrerons donc plus de détails à ce sujet lors du rapport du mois prochain.

 

 

COMMUNAUTÉ

Mesdames et messieurs, damoiselles et damoiseaux, citoyens de tout âges, ici Thomas, cameraman et monteur d’exception, pour vous apporter le rapport mensuel du mois de Mai. Comme toujours, ce rapport vous vient tout droit d’un lieu qui ne peut être considéré que comme le paradis sur terre : la sublime et divine ville de Santa Monica en Californie.

Et tout comme notre splendide ville, Mai fut un mois extraordinaire pour nous. Nous avons lancé la nouvelle rubrique de notre émission phare, Around the Verse, intitulée Ship Shape. Présentée par Lisa Ohanian, d’une beauté toujours plus resplendissante, cette rubrique nous donne l’opportunité de présenter à nos fans et nos donateurs un aperçu de notre ligne de production de vaisseaux.

Toujours concernant Around the Verse, Ben Lesnick s’est remarquablement bien débrouillé en présentant seul l’émission alors que sa co-présentatrice Sandi Gardiner était appelée pour montrer ses talents lors des captures de mouvements pour Squadron 42 réalisées à Londres, et nous avons été chouchoutés par tout un tas de développeurs talentueux qui ont cherchés à se démarquer les uns des autres, en l’absence de notre illustre Président, dans des épisodes de notre série “10 question à”.

Le mois de Mai fut également l’occasion pour l’éradicateur de bugs préféré de la communauté, M. Mark Bartholomew Abent III, d’abandonner la rubrique qu’il présentait dans Around the Verse pour une émission bihebdomadaire qu’il anime seul. L’épisode pilote fut encensé par la critique, et c’est avec une immense joie que je vous annonce que la production a passé commande pour toute une saison.

Dans un tout autre registre, le mois de Mai nous a apporté le tant attendu Fuddruckers Santa Monica, l’équipe communautaire n’a pas perdu de temps pour aller y manger, et je dirai simplement que nous n’avons pas été déçus du voyage.

Mes chers citoyens, voilà qui conclut le mois de Mai. Merci à tous nos fans, sans vous, rien de tout ceci ne serait possible, et c’est un véritable honneur et un privilège de faire ce que nous faisons.

D’ici la prochaine fois, je serai pour toujours et à jamais,

Votre humble serviteur,

Thomas

 

 

Traduction depuis l’anglais et relecture par Aimame, Arma, Hotaru, Ironmanu, Kotrin, Shibitos, Sitasan, Super d et VinceKun – Source : https://robertsspaceindustries.com/comm-link/transmission/14758-Monthly-Report-May

Merci de contacter l’auteur de cet article par MP pour toute faute ou remarque éventuelles.

Traduction soumise à la licence CC By SA 3.0. Vous êtes libre de copier et réadapter ce texte en mentionnant les auteurs originaux, les traducteurs et la source. Merci !