Salut tout le monde,
Lorsque nous avons constaté que notre ancienne feuille de route ne représentait pas correctement nos progrès en matière de développement, nous avons commencé à explorer les possibilités de construire quelque chose de plus informatif qui corresponde à notre façon de développer nos jeux. Notre message initial à ce sujet figurait dans un Point sur la feuille de route de mars, et nous avons donné des indices à ce sujet dans notre Calling All Devs axé sur Squadron 42 le 13 mars.
Nous avons alors mentionné que nous étions satisfaits du développement de Squadron 42 et nous étions engagés sur quelques points que j’aimerais aborder à nouveau. Nous avons parlé d’injecter plus de contenu Squadron 42 dans nos publications régulières, c’est pourquoi vous avez peut-être remarqué des choses comme l’épiode de Calling All Devs sur la campagne solo, ou les mises à jour dans Inside Star Citizen sur les vaisseaux Vanduul, la technologie de gaz, un regard plus approfondi sur l’Aciedo Comm Array, et d’autres contenus connexes. Tout cela était accompagné de nos rapports mensuels sur Squadron 42 (mars, avril, mai, juin). L’un des éléments importants de transmission des mises à jour sur Squadron 42 a également consisté à faire prendre conscience que le travail effectué pour Star Citizen est aussi un travail effectué pour la campagne solo. Le seul contenu exclusif à SQ42 sont les personnages, les lieux et l’intrigue – et nous ne voulons pas les spoiler.
Avec toutes les mises à jour sur SQ42, notre objectif a été de trouver un équilibre dans le partage de contenu SQ42 tout en minimisant l’impact sur l’équipe de développement afin qu’elle puisse se concentrer sur ce qui compte le plus : terminer le jeu.
La récente vidéo de mise à jour SQ42, qui est une toute nouvelle émission que nous débutons et qui s’appelle “The Briefing Room”, était une vidéo à moindre effort que nous avons lancé dans le but de partager plus d’informations avec vous, mais de manière plus rapide et décousue, afin de minimiser les perturbations sur l’équipe de développement tout en vous donnant de nouvelles informations. Nous avions prévu que ce serait une émission semi-régulière, dont la cadence dépendrait de la qualité du contenu et du degré de perturbation (ou non) de ce premier épisode pour nos développeurs. Ce premier épisode devait se concentrer spécifiquement sur les mises à jour (alerte spoiler) de notre technique d’interruption des conversations et du level design dans SQ42. Ce que nous avons découvert après avoir terminé l’ensemble de l’épisode et nous être préparé à le publier, c’est que notre approche a donné lieu à une émission décevante. Non seulement l’épisode présentait des problèmes audio majeurs en raison des enregistrements de travail à la maison, mais il manquait aussi des éléments visuels pour soutenir la conversation, et nous préférons vraiment montrer plutôt que raconter. Finalement nous avons décidé qu’il n’était pas acceptable de le montrer, même pour une vidéo “brouillonne” qui n’était pas destinée à être une bande-annonce marketing. Cependant, avant que le message “arrêter l’envoi” ne puisse atteindre notre équipe marketing, nous avions avancé la date de publication.
Au départ, nous pensions que nous pouvons simplement faire un montage de “b-roll[1]” tout frais, mais au fur et à mesure que nous passions en revue l’émission, nous avons constaté la nécessité d’actualiser nos visuels pour mieux refléter ce dont nous discutions, et cela nous a fait réaliser que nous n’avions toujours pas les bonnes séquences, dans notre standard de qualité, pour raconter l’histoire que nous voulions. Nous avons donc décidé de refaire tout l’épisode avec nos normes de qualité habituelles. Comme nous l’avons mentionné, The Briefing Room n’a jamais été conçu pour déranger l’équipe au point que nous donnions la priorité aux séquences de l’émission par rapport à nos étapes internes de développement. Par conséquent, notre équipe artistique SQ42 ne pouvait travailler sur la capture de nouvelles séquences qu’après les heures de travail habituelles. Ajoutez à cela le fait que le personnel clé a été malade pendant plus d’une semaine, et vous pouvez voir comment notre calendrier a été repoussé de plus en plus loin.
Nous avons bien sûr communiqué sur les retards et leurs raisons, et avons même demandé à Brian Chamberts de relayer la nouvelle au début, avec nos Community Managers répétant ce message lorsque le sujet est revenu plusieurs fois. Nous avons dû le faire plusieurs fois au cours des dernières semaines, et malheureusement, la vérité est toujours la même : la vidéo initiale ne correspondait pas à nos normes et nous la refaisons. Nous ne sommes pas entrés dans les détails tels que le personnel malade, et nous n’avons explicitement précisé que les séquences vidéos ne pouvaient pas dépassé le travail de développement réel dans notre liste des priorités. Après tout, nous n’aimons pas trouver d’excuses. Mais il est clair que la convergence du retard prolongé de The Briefing Room et l’absence de toute nouvelle information (parce qu’il n’y en avait pas) a créé de l’angoisse au sein de la communauté.
Ce que l’on ne voit pas souvent de l’extérieur, c’est le temps et les efforts qu’il faut réellement pour assembler le contenu vidéo que nous diffusons régulièrement. Sortir les mises à jour dans les standards que nous voulons prend du temps, et bien que ceux qui disent qu’ils seraient d’accord avec un premier montage avec juste des têtes qui parlent, nous recevons des plaintes sans fin lorsque c’est ce que nous livrons, par exemple lorsque les rapports mensuels ou les exemples liés ci-dessus sont rapidement rejetés ou oubliés. La vidéo SQ42 est toujours prévu (probablement dans les prochaines semaines), ainsi qu’un ensemble d’autres mises à jour, dont une révision de notre feuille de route publique.
La nouvelle feuille de route est une chose à laquelle nous avons fait allusion en mars, mais comme nous sommes encore en développement, nous ne pouvons pas en parler autant que je le voudrais. Croyez-moi quand je vous dis que je suis personnellement très impatient de vous la communiquer. Nous avons pris le temps d’explorer les options pour mieux représenter nos progrès, et je crois que nous sommes en très bonne posture. Notre objectif avec cette nouvelle feuille de route est de vous donner une meilleure visibilité sur quelle équipe travaille sur quoi, d’en partager les progrès d’un plus grand nombre et d’aller jusqu’à indiquer la dimension des projets pour nos équipes chargées des technologies, des fonctionnalités et du contenu. La nouvelle feuille de route changera radicalement la façon dont vous suivez les progrès du développement de Squadron 42 et Star Citizen. Elle se concentrera davantage sur la répartition des équipes et les fonctionnalités afin que vous puissiez voir de façon interactive ce sur quoi travaillent toutes les équipes, par opposition aux fonctionnalités qui sortiraient au patch X. Bien qu’elle ne soit pas encore tout à fait prête, elle est actuellement la priorité absolue des projets actuels de l’équipe web. Dans l’avenir immédiat, nous prévoyons de diffuser les communications suivantes :
- Expliquer les objectifs de notre nouvelle feuille de route et ce qu’il faut en attendre
- Montrer une maquette sommaire de la nouvelle feuille de route proposée
- Partager une version en cours de la feuille de route pour au moins une de nos équipes clés
- Et enfin la transition vers cette nouvelle feuille de route
Nous les aborderons dans l’ordre ci-dessus, et il nous faudra probablement quelques semaines entre les étapes, donc je ne veux pas donner l’impression que cela se fera du jour au lendemain. Mais nous devrions annoncer l’étape 1 très bientôt si ma réunion de jeudi (ndt : 30 juillet 2020) à ce sujet est aussi bonne que je le pense.