Aller au contenu

À l'intérieur du processus de développement de Star Citizen


Maarkreidi

Recommended Posts

À l'intérieur du processus de développement de Star Citizen - Entrevue exclusive par Adrian Lp pour le site WCCFTECH.COM

ZdCSE5j.jpg 

Introduction

Ce n'est un secret pour personne que je suis un backer de Star Citizen. Comme je l'ai écrit à de nombreuses reprises, c'est ce qui m'a ramené au jeu sur PC. J'ai sauté dans le train à la fin de 2012 quand le kickstarter a commencé et il a ouvert un monde que j'avais oublié pendant des années et m'a aidé à découvrir une multitude d'autres jeux comme je me suis immergé dans la communauté de jeu. Je me suis fait de nouveaux amis et, dans l'ensemble, l'expérience a été très agréable.

 

Depuis ce jour fatidique de novembre 2012, j'ai observé au fil des ans que le jeu a enduré à la fois ses triomphes et ses controverses. De ces premiers jours excitants de voir le module hangar se produire et de réaliser que je n'avais pas de carte graphique DX11 pour pouvoir l'essayer, aux grognements sur les retards (module de combat, module social, univers persistant, Squadron 42 vertical slice anyone ?) et bien sûr les différentes controverses dont les déclarations d'effondrement financier de Derek Smart, les procès Crytek, les méga paquets de jeux coûteux qui coûtent des dizaines de milliers de dollars et plus, Star Citizen a tout eu. J'ai regardé beaucoup de contenu, passé beaucoup de temps dans le jeu, gémi à des retards avec le reste de la communauté, été à des événements CIG et j'ai largement suivi le jeu où je peux (si le temps le permet).

 

Au fil des années, j'ai eu l'occasion de rencontrer plusieurs employés de Cloud Imperium Games et j'ai réussi à obtenir du temps en ligne ou physique en face à face avec les personnes qui fabriquent le jeu. Il y a plusieurs années, j'ai écrit une série d'articles expliquant à un haut niveau comment fonctionne le processus de développement logiciel (je suis chef de produit/projet par métier, bien que je travaille dans le commerce électronique en finance) et le reliant spéculativement au développement de Star Citizen. Heureusement, j'ai récemment eu l'occasion de rencontrer Eric Kieron Davis, le directeur du studio LA et chef de production de CIG pour parler du processus de développement et de la façon dont les choses fonctionnent là-bas.

 

L'entrevue Star Citizen

Adrian Lp : Merci d'avoir pris le temps de me parler Eric ! J'ai écrit une série d'articles sur le processus de développement logiciel il y a plusieurs années et spéculativement associé à ce que j'ai supposé être le processus de développement chez CIG sur Star Citizen, donc c'est formidable d'avoir l'opportunité de parler avec vous et de vérifier certains de ces éléments. Alors commençons par une question simple, est-ce que vous utilisez une forme d'Agile ou de Scrum ?

Eric Kieron Davis : Ce que je suppose, Adrian, c'est que nous allons parler surtout des pratiques de développement, pas des équipes de soutien et d'autres domaines. J'ai adhéré en 2015 et le projet a naturellement évolué. Ce que nous avons déterminé dès le début, c'est que nous voulions permettre aux équipes de chaque site de travailler en étroite collaboration, mais dans un système qui fonctionne bien à l'échelle mondiale. Quand nous avons commencé, vous vous souvenez que chaque studio était comme une nacelle et fonctionnait dans un silo. Nous avons fait des embauches au fil des ans, de sorte que les mots clés que vous venez d'utiliser comme Agile et Scrum sont maintenant profondément enracinés et j'ai des conversations quotidiennes avec les propriétaires de produits et les maîtres de scrum. Nous avons des points d'histoire et, comme vous le savez, avec le nouveau plan de publication trimestriel, nous avons plus de points de données qui guident les échéanciers, alors nous prenons ces données et nous les utilisons pour projeter et dire "voici où nous voyons 3.3 et 3.4".

fqomd0v.jpg

Au fil du temps, comme nous avons des gens qui travaillent pour l'entreprise depuis plus longtemps, vous apprenez à connaître les gens et ce qu'ils peuvent et ne peuvent pas livrer. Cela nous aide de connaître les gens, je sais que si je donne quelque chose à "Jill", elle va le claquer en un jour, mais si je le donne à "Chuck", peut-être qu'il n'est pas si fort dans ce domaine et cela lui prendra quelques semaines.

 

Apprendre à connaître l'équipe, la structure de gestion, le code, ce sont tous des facteurs de développement du produit de sorte qu'au fur et à mesure que nous passons par ces cycles et que ces équipes se forment, cela tombe naturellement en place et vous n'avez plus à réfléchir si fort et vous savez qu'en général vous allez avoir certaines tâches qui vont être confiées à une personne ou à une équipe naturellement contre d'autres.

 

Le cycle de publication trimestrielle que nous avons maintenant, une petite restructuration est une chose positive et cela nous aide à mieux livrer la marchandise.

 

ALP : En parlant de versions et de sorties, quelle est votre stratégie de ramification ? Vraisemblablement vous avez une branche principal de travail à laquelle tout le monde contribue, à un moment donné vous prenez une coupe et dites que c'est une fonctionnalité complète puis vous la stabilisez, fusionnez et réconcilierez pour la suivante ? Comment cela fonctionne-t-il avec Star Citizen ?

 

EKD : Adrian, tu as littéralement dit ce que j'allais dire. C'est exactement ce que nous faisons, il n'y a pas de magie là-dedans. Quand je suis arrivé ici, nous avions l'habitude d'appeler notre référentiel principal "main" de manière assez amusante. Nous l'avons renommé ainsi il s'appelle maintenant "gamedev" qui est notre branche qui détient tout. Quand nous serons prêts à commencer à publier dans une branche, nous l'appellerons branche SC3.2 et c'est notre publication trimestrielle. Nous avons un processus d'inclusion/exclusion pour s'assurer que certains actifs entrent ou sortent s'ils ne sont pas prêts et donc ça commence à passer de ce gros bordel à ce joli paquet raffiné que nous allons finalement mettre à la disposition du PTU.

 

Par exemple, nous avons fait un tas de corrections au système gravlev, nous ne voulions pas seulement que ce soit sur la branche 3.1 et puis Squadron ne l'a pas, donc nous le remettons naturellement dans gamedev. En général, tout revient en arrière, à moins que nous ne fassions ce qu'on appelle un "no merge" si par exemple c'est quelque chose que nous avons mis dans la version 3.2 mais que nous voulons faire un peu mieux à l'avenir, donc nous ne voulons pas le remettre dans gamedev parce qu'il pourrait casser d'autres systèmes sur lesquels nous travaillons.

zNoXJWf.jpg 

ALP : Oui, je le sais ! Mes équipes font aussi beaucoup de hacks !

 

EKD : Hah ! Nous devons être prudents, c'est un terme que beaucoup de gens n'aiment pas à moins de savoir comment le faire et comment ça marche. Faire les choses de cette façon peut permettre d'atteindre les objectifs de donner à la communauté ce qu'elle veut, mais ensuite, nous l'élaborons correctement.

 

ALP : Je suis donc curieux, vous faites la sortie trimestrielle depuis un certain temps pour Star Citizen et j'ai l'impression que vous vous mettez dans un rythme régulier maintenant, combien de temps vos fusions remontent à la prise principale ?

 

EKD : C'est un processus assez rapide maintenant, nous l'avions bien sûr dans la version 2.x et donc un processus pour cela existe depuis un certain temps. En général, c'est assez rapide, mais cela dépend de la version et de ce que nous essayons d'obtenir avec cette version. S'il s'agissait d'un jeu vraiment gros et que nous en avons un peu plus que ce que nous pouvions mâcher, mais que nous avons tout mis là-dedans à la fin, cela peut prendre plus de temps à remettre dans gamedev. La fusion aura lieu tout au long de la phase PTU et en direct, mais avec 3.2, nous parlions de jours. Ce doit être parce que nous savons que nous devons agir rapidement pour la prochaine succursale.

 

Nous avons Sean Tracy, un autre nom que vous connaissez, les gars comme lui sont super concentrés sur la santé technique de nos builds et le maintien de notre dépôt gamedev en bon état.

 

ALP : Vous m'avez donc rappelé un autre sujet que je voulais aborder lorsque vous parlez de santé technique. L'une des choses que je déteste quand je change d'emploi, c'est que vous creusez et que vous essayez de voir jusqu'où va le terrier du lapin. Invariablement, si vous avez un projet avec un tas de codes hérités, vous allez constater qu'il y a un tas de dettes techniques à payer. En tant que membre depuis 2015, quelle a été votre impression sur le niveau de la dette technique de la base de code Star Citizen et quelle est votre évaluation honnête du niveau de la base de code aujourd'hui ?

 

EKD : Avec un projet comme celui-ci, et vous savez que Chris (Roberts) lui-même est un codeur et qu'il est debout toutes les nuits à lire le code, l'homme est une machine. Avant ma venue, il y avait un élément du genre "nous devons sortir le module hangar" ou "nous devons sortir le module commandant d'arène". Quand vous voulez sortir ça, il y a des éléments que vous mettez en place et ils fonctionnent et puis quelqu'un dit "on ferait mieux d'écrire ça pour plus tard" !

 

Vous avez utilisé le terme négatif "dette technologique", honnêtement quand j'ai rejoint pour la première fois, il y avait ce que je considère comme un montant normal. Ce n'était pas comme si j'étais "whoah ! L'équipe a fait du bon travail en gardant la trace de tout ce qui se trouvait dans l'arriéré que nous devions traiter. Ce qui est vraiment cool, c'est qu'au fur et à mesure que nous avons mis à l'échelle les équipes et poursuivi le développement, nous avons introduit beaucoup de ce genre de choses dans nos périodes de deux semaines (sprints) et le taux d'endettement de la technologie a diminué de façon significative au cours des deux dernières années.

 

Nous avons toujours une longue liste de choses que nous voulons faire correctement et nous savons que nous devons continuer à rembourser cette dette technologique. Item 2.0 était énorme pour nous, ce n'était pas la version parfaite que nous voulions et chaque fois que nous livrons une release, nous faisons une mise à jour de cette technologie. C'est devenu une attitude très saine de prendre de l'avance sur notre dette technologique et nous nous améliorons continuellement.

9czMAsP.jpg 

ALP : L'une des choses que nous entendons toujours à propos de la base de code partagée entre Squadron 42 et Star Citizen et il a parfois surpris la communauté que les choses à joueur unique ne sont pas arrivées plus tôt. Dans quelle mesure le jeu à un seul joueur est-il dépendant de choses comme Item 2.0 et l'élimination des liens réseau et d'autres choses de ce genre, compte tenu du fait qu'il s'agit évidemment d'un seul joueur et non pas d'un jeu en ligne ?

 

EKD : C'est une base de code partagée mais il y a évidemment certaines choses qui seront plus critiques que d'autres et vous avez raison parce que c'est un jeu à un seul joueur, les composants en ligne ne sont pas si importants. Cela dit, il y a beaucoup de Star Citizen qui sera utilisé dans Squadron 42, donc c'est une question intéressante, beaucoup de choses dont je ne peux pas parler, mais en fin de compte, nous voulons en faire le meilleur jeu possible. A un niveau élevé, les gens regardent Star Citizen et voient "200 millions de dollars, 500 personnes" et se demandent pourquoi il n'est pas encore sorti.

 

ALP : Oui, les vieilles "9 femmes ne peuvent pas avoir un bébé en un mois".

 

EKD : Oui, c'est mon exemple préféré de productivité que j'utilise tout le temps.

 

ALP : Je ne veux pas parler de personnes en particulier, car il y a eu une certaine controverse à ce sujet dans le passé, mais le roulement de personnel est un fait de la vie de toute entreprise. Comment trouvez-vous que votre vitesse de base est affectée par le roulement du personnel et les personnes qui quittent l'entreprise, les nouvelles personnes qui se joignent à l'entreprise et qui ont besoin d'être à bord, etc.

 

EKD : Autrefois, c'était plutôt dépendant de la personne qui partait. Si c'était un artiste conceptuel qui avait reçu une offre d'emploi pour travailler sur la prochaine combinaison Iron Man, peut-être que nous avions un autre gars qui pouvait ramasser les choses assez rapidement, mais si c'est un ingénieur qui est profondément ancré dans une zone de code spécifique, c'était plus difficile et nous prenions un coup de vitesse. Je pense que c'était plus un problème quand nous étions plus petits et que tout le monde était hyper focalisé sur un domaine, mais comme nous avons grandi et grandi, nous avons maintenant une capacité beaucoup plus grande de déplacer le travail. Comme nous avons grandi et que nous faisons tous carrière ici et que nous voulons que ce soit l'endroit où nous travaillerons pour le reste de notre vie, nous partageons vraiment nos connaissances et le modèle de développement solaire nous aide aussi parce que nous travaillons tous sur de multiples composantes.

 

Il y a des domaines où l'on peut toujours s'améliorer, mais nous travaillons toujours dans ce sens.

cxDnV5w.jpg 

ALP : L'un des défis est que vous voulez toujours un degré de pollinisation croisée dans les équipes de développement afin que vous n'ayez pas "ce type" qui sait tout et qui se fait peut-être écraser par un bus, mais la pollinisation croisée prend aussi du temps, donc c'est toujours un jeu d'équilibre. Est-ce que vous faites de la planification de sprint en tant qu'équipes globales ?

 

EKD : C'est global et ça doit l'être. Il y a des années, nous avons découvert que si nous ne faisons pas ce genre de choses à l'échelle mondiale, nous allons simplement nous heurter à des bloqueurs et nous devrons attendre que quelqu'un se réveille dans un autre bureau pour aider à résoudre un problème. Nous avons des outils pour nous aider et nous utilisons Confluence et Jira, nous avons des tableaux partagés, donc vous n'aurez pas quelqu'un assis dans un autre bureau en train de dire "Je ne savais pas que ça allait arriver". De toute évidence, nous ne réunissons pas tous nos développeurs dans une seule pièce.

 

Nous pouvons nous rendre compte que "oh, nous devons faire ce morceau en 3.3 parce que c'est super crucial pour 3.4" tout le monde devrait en être conscient et c'est ainsi que nous avons conçu l'entreprise pour s'assurer que les connaissances se répandent.

 

ALP : Un sujet un peu délicat auquel vous ne voudrez probablement pas répondre ! J'ai travaillé dans plusieurs endroits où il y a un gars, il est vraiment senior dans l'entreprise et c'est un codeur et il a été l'un des fondateurs et il fait ce qu'il veut faire et dit "ça ne devrait pas marcher comme ça" et il fait tout ce qu'il veut dans la base de code. À bien des égards, tout le monde dans l'entreprise relève de Chris, mais en même temps, si Chris coupe le code pour Star Citizen, il doit faire rapport à quelqu'un. Alors, qu'est-ce qui se passe là-dedans ? Est-ce que Chris vient dans la planification du sprint et se voit attribuer des tâches et ses billets sont sur un tableau de Jira où tout le monde peut voir ce qu'il fait ? Est-ce que quelqu'un révise son code ? Ou est-ce qu'il est comme "nah, f**k tout ça, je fais ce que je veux et vous, vous vous occupez des retombées" ?

 

EKD : C'est délicat ! Ce qui est vraiment important pour nous à tous les niveaux, surtout du côté du leadership, c'est de rester le plus près possible du produit et il faut beaucoup d'efforts pour le gérer. Mais du côté du codage, absolument, tout le monde a un examen par les pairs, Paul Reindell est notre directeur de l'ingénierie et nous avons d'autres ingénieurs incroyablement talentueux et Chris travaille en étroite collaboration avec eux. Il y a certainement un niveau de respect maintenu à tous les niveaux. Sean Tracy sait tout sur Perforce, tout ce qu'il y a dans notre moteur et c'est un gars super intelligent. Il a dit qu'il allait essayer de faire une demande de vérification qui purgerait toute la base de données juste pour voir ce qui se passerait et heureusement c'est bloqué ! Nous avons des freins et contrepoids partout. Nous faisons beaucoup de tests et il y a un sens complet de responsabilité partagée dans tout ce que nous faisons.

 

À l'époque, les choses étaient peut-être différentes lorsqu'il y avait 10 personnes, mais à mesure que nous avons grandi, nous devons nous assurer que le processus créatif tient toujours compte de notre nature indépendante, mais qu'il fonctionne quand même de telle manière que nous pouvons obtenir des résultats avec de meilleurs délais et une meilleure qualité et que tout le monde est d'accord avec cela.

 

ALP : Donc, si j'étais un employé de CIG travaillant sur Star Citizen, je pourrais me connecter à votre Jira et voir les billets sur lesquels Chris Roberts travaille ? Il adhère au processus ? Il ne m'a pas l'air d'être un homme de processus....

 ctF2iyP.jpg

EKD : Peut-être.... Je plaisante ! Bien sûr, bien sûr. Il faut que tu comprennes, ça a grandi à partir de rien. Si vous allez travailler chez Activision, ils ont tout ce qu'il faut pour concevoir et construire des jeux. Pour nous, au début, il s'agissait simplement d'embaucher des gens et d'accomplir des choses. Nous ne construisons donc pas seulement un jeu, pas seulement une entreprise, mais aussi tous les processus pour faire en sorte que tout cela fonctionne. Est-ce que je prendrais un ingénieur junior et leur donnerais des travaux de R&D ou d'architecture vraiment compliqués ou est-ce que je les donnerais à mon PDG ou à Tony Zurovec ? La réponse est évidente. Lorsque vous produisez un produit, il y a la phase de R-D qui sera un peu plus lâche et vous faites du prototypage, alors je vais consacrer différentes ressources à ce genre de tâches.

 

Il y a un art de produire et de travailler pour obtenir le meilleur des gens qui n'est pas nécessairement écrit dans un livre, surtout quand on travaille sur des choses créatives.

 

ALP : Plus tôt dans le projet, vous avez fait une quantité raisonnable d'externalisation pour Star Citizen. J'ai de l'expérience dans ce domaine et c'est un outil extrêmement utile, mais en même temps, le degré de précision requis pour obtenir une production appropriée est extrêmement élevé. En dehors de Turbulent qui sont plus concentrés sur le site Web, y a-t-il encore des composants de jeu de base qui sont externalisés et comment les contrôler si c'est le cas ?

 

EKD : Comme vous le savez, il y a des forces et des faiblesses à la fois à l'impartition et à l'interne. Lorsque nous avons commencé, nous avons fait de l'impartition pour essayer d'accélérer les choses et cela nous a aussi permis d'apprendre quelles étaient nos forces à l'interne. Au fur et à mesure que nous avons mis en place des studios, maintenant c'est comme "J'ai cette équipe follement talentueuse en Allemagne et ils connaissent ce genre de choses à fond et je leur parle tous les jours et ils sont dans ma Jira et dans mes processus". Nous avons évidemment encore recours à l'externalisation, mais c'est moins de développement de jeu de base et beaucoup plus contrôlé. Nous avons vu des choses que nous externalisons maintenant, nous sommes en mesure d'en tirer le meilleur parti et de changer les choses très rapidement.

 

ALP : En parlant de l'Allemagne, les gars là-bas sont pour la plupart des ex-Crytek, donc j'ai l'impression qu'il y a ce que j'appellerais des "centres d'excellence" autour de l'entreprise. Autant qu'il y a un fonctionnement global et un travail d'équipe avec des transferts, y a-t-il des choses qui vont toujours aller en Allemagne ou rester à Los Angeles ?

 

EKD : Absolument, mais nous n'en voulons pas trop, car nous ne voulons pas trop dépendre d'une personne ou d'un groupe.

 

ALP : Merci beaucoup pour votre temps Eric ! Cela a été une excellente introduction au processus de Star Citizen et CIG, peut-être vous voir à un événement à un moment donné !

 

EKD : Absolument, et à bientôt dans le « verse »!

 

Source : WCCFTECH.COM

Traduction : Maarkreidi

zbwfBnp.gif

"... there are a lot of Freelancer fans out there that love that, that mouse control where guns target for you but no it’s going to be Wing Commander"

source: http://tinyurl.com/q46br4w

Lien vers le commentaire
Partager sur d’autres sites

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
×
×
  • Créer...