Carnet de développement n°56 : Présentation de l'Équipe

Bon après-midi, tout le monde ! Je suis Magne "Meneth" Skjæran, programmeur sur CK2. Par le passé, j'ai écrit des carnets sur le modding, l'optimisation et l'amélioration de l'ergonomie.
L'été a commencé, et les bureaux resteront en grande partie vide jusqu'à la fin du mois de juillet, y compris en ce qui concerne l'essentiel de l'équipe de CK2. Cependant, the show must go on, comme on dit (ndt littéralement, "le spectacle doit continuer") donc pendant les quatre prochaines semaines, j'écrirai tous les carnets de développement de CK2.
Puisque la majeure partie de l'équipe est en vacances, le travail avance peu, ce qui signifie que nos quatre carnets seront assez légers en termes d'infos sur l'extension et le patch à venir, mais j'espère parvenir tout de même à les rendre intéressants en partageant avec vous des réflexions et des informations croustillantes.

Pour ce qui d'aujourd'hui, je vous parlerai des différentes fonctions des membres de notre équipe, et des responsabilités de chaque fonction.
Au moment où j'écris ces lignes, le noyau dur de l'équipé est constitué par un directeur créatif, un chef de projet, un concepteur, deux concepteurs de contenu, un programmeur, un artiste, et deux testeurs intégrés d'assurance qualité.
En plus de ce noyau dur, nous avons aussi le soutien de notre unité central d'assurance qualité, un artiste 3D, et un certain nombre d'externes sous contrat, ainsi que dans la publication.

Commençons donc par le haut de la pyramide, avec le directeur créatif.

Coordonnateur du Jeu
Henrik "Doomdark" Fåhraeus

Le directeur créatif de CK2 depuis son lancement est Henrik Fåhraeus, bien qu'à cette époque, il cumulait les fonctions de chef de projet et de programmeur, et qu'il avait simplement le titre de chef de projet.

Le rôle du directeur créatif est de définir une direction générale pour le jeu. Le moyen privilégié d'y parvenir est de rédiger une vision générale à chaque extension, et de fournir des lignes directrices et une armature afin que le concepteur-designer puisse se baser dessus pour travailler, le tout étant rassemblé dans un document de vision. Ce document esquisse chaque élément potentiel de l'extension et du patch, avec la description des implications, des objectifs, de l'importance de chaque élément, leur caractère payant ou gratuit, et les professions concernées par leur mise en place.

Le coordonnateur contrôle ensuite l'état du nouveau contenu afin de s'assurer qu'il reste dans la même ligne que leur vision et que le concept original ; que les ajouts sont mis en place de manière cohérente avec les besoins auxquels ils souhaitaient répondre, et fonctionnent de la manière souhaitée.

Concepteur
Alexander “rageair” Oltner

Nous avons également un concepteur-designer. Tandis que le coordonnateur se consacre en premier lieu à la vision d'ensemble, le concepteur s'attache à enrichir les détails, bien qu'il y ait parfois d'importants recoupements avec le coordonnateur en ce qui concerne les détails, et que le concepteur soit parfois responsable d'une partie des enjeux concernant la vision générale.

Le concepteur transforme le document de vision en document de conception ; il rentre suffisamment dans les détails pour que le tout soit mis en place par les programmeurs, les concepteurs de contenu et les artistes sans avoir constamment à faire des suppositions sur la manière dont certaines choses sont supposées fonctionner.

Le concepteur est également un point de contact entre ceux qui mettent en place le design et l'équipe de design (le directeur créatif et le concepteur-designer). Si le design n'est pas suffisamment clair, s'il est ambigu, ou si un exécutant repère un problème potentiel, le designer en personne est la personne à laquelle s'adresser pour résoudre ces problèmes.

Chef de Projet
Anna “Anona” Norrevik

Tandis que l'équipe de design décide des objectifs de l'extension et du patch, le chef de projet doit s'occuper du "comment" afin de faire en sorte que le contenu à la sortie soit aussi bon que possible, et que le calendrier soit respecté. Pour ce faire, le chef de projet suit de près les progrès effectués vers la mise sur le marché afin de s'assurer que l'on reste sur la bonne voie, et que des ajouts ne s'infiltrent pas dans le plan du projet sans motif valable. Si du retard s'accumule par rapport au calendrier, il revient également au chef de projet de le rattraper. Les trois principales actions à la disposition du chef de projet pour y parvenir sont les suivantes :
  • Demander davantage de ressources. Par exemple, si c'est le code qui prend du retard, un programmeur peut être emprunté à un autre projet. "Davantage de ressources" peut dans certains cas se résumer à davantage de temps ; en retardant la mise sur le marché afin d'avoir plus de temps pour travailler.
  • Réduire l'ampleur de la tâche. Le plus souvent, il est possible de réduire dans une certaine mesure l'ampleur d'une fonctionnalité s'il n'y a pas suffisamment de temps pour l'inclure en entier. Par exemple, si un ajout devait comprendre six chaînes d'événements reliées entre elles, on peut rattraper les retards en réduisant à cinq chaînes.
  • Retirer des fonctionnalités entières. Tous les concepts commencent avec un certain nombre d'idées et de fonctionnalités qui ne sont pas au centre du design général. Si le projet prend du retard, ce genre de choses sont les premières dont on se débarrasse. Par exemple, pendant le développement de Monks and Mystics, nous avons mis en place un grand nombre d'améliorations d'ergonomie, mais certaines d'entre elles ont été mises de côté avant leur implémentation. Cependant, les ajouts qui n'ont pas été inclus dans un patch ou dans une extension sont souvent compris dans le ou la suivante.

Afin de suivre la ligne directrice, le chef de projet met en place un certain nombre d'activités :

Réunions d'estimation
Au début du développement de chaque extension, le chef de projet rencontre chacune des professions liées à l'exécution du projet (art, conception du contenu, code). Lors de ces réunions, tous les éléments de design sont pris en considération, et chaque représentant de l'une des professions identifie les tâches qui correspondent à la sienne, et peut évaluer combien de temps il lui faudra pour les effectuer.

En se basant sur ces évaluations, le chef de projet peut savoir dès le début s'il est possible d'accomplir le projet dans le temps imparti, et déterminer s'il faut déjà renoncer à certains ajouts.

Si de nouvelles fonctionnalités sont ajoutées au cours du développement, des réunions d'estimation plus courtes ou de simples estimations effectuées par le représentant de la profession concernée auront lieu afin de les intégrer dans le plan du projet.

Répartition des sprints
En fonction des estimations et du temps disponible, les tâches à accomplir sont réparties en sprints. Chaque sprint dure quatre semaines, où les trois premières sont dédiées à une nouvelle fonctionnalité, tandis que la quatrième sert à corriger les problèmes introduits pendant les trois premières semaines. Les tâches sont réparties de sorte que chaque sprint représente environ la même quantité de travail, et celles qui représentent le plus de risques sont traitées en premier.

Répartition et priorisation des tâches
Quand une fonction compte plus d'un membre, le chef de projet est responsable de l'attribution des tâches individuelles, ou de la délégation de cette responsabilité à l'un des représentants de cette profession.

Le chef de projet est également responsable de l'ordre de priorité du traitement des tâches et des bugs afin que le reste de l'équipe puisse savoir dans quel ordre les traiter.

Réunions Scrum
L'équipe de CK2 se sert de la méthodologie de développement Scrum, avec ses trois réunions : la mêlée quotidienne (la "réunion du matin"), la revue de sprint, et la rétrospective du sprint.
  • Les réunions du matin - chaque matin, l'équipe se retrouve pour résumer rapidement ce qui a été fait la veille, et ce qui nous occupera le jour même. Cela permet de garder tout le monde au courant de l'avancée du projet.
  • Revues de sprint - à la fin de chaque sprint, chaque membre de l'équipe montre ce qu'il a fait pendant le sprint. Il y a généralement des gens extérieurs à l'équipe principale lors de cette réunion, afin qu'ils puissent également visualiser la progression du projet. C'est également l'opportunité de formuler des commentaires sur le travail accompli jusque-là.
  • Rétrospectives du sprint - à la fin de chaque sprint, l'équipe identifie les aspects du travail effectué qui pourraient être améliorés, et ceux qui se présentent bien. Par exemple, l'équipe pourrait se rendre compte que la communication entre deux fonctions a été améliorée, ou que certains éléments du design doivent être clarifiés. Les problèmes les plus importants sont mis en évidence, et un plan est mis en place afin de les régler pour que l'équipe puisse être plus efficace à l'avenir.

Concepteurs de contenu
Milla “IsakMiller” Isaksson, Joel “Divine” Hansson, et jusqu'il y a peu, Drikus “Bratyn” Kuiper (qui travaille désormais sur HoI4).
Matthew “blackninja9939” Clohessy de l'équipe du mod Game of Thrones nous rejoindra bientôt cet été.

Les concepteurs de contenu font partie de l'équipe d'exécution. Autrefois, on les appelait simplement les "scripteurs" mais le nom a changé, car si ce mot correspond en effet à une aprtie du travail du concepteur de contenu, il en délaisse une partie considérable.

Les concepteurs de contenu sont essentiellement responsables de la création du contenu du jeu, par opposition aux fonctionnalités de code et à la partie artistique. Les ajouts sont déterminés par l'équipe de design, mais les détails sont généralement délégués aux concepteurs de contenu, et c'est la raison pour laquelle on ne les appelle plus "scripteurs" ; la conception de contenu ne consiste pas uniquement à l’exécution des indications, mais à un travail d'écriture et de narration, à des recherches, à l'équilibrage du jeu, etc.

Par exemple, le design des artefacts inclus dans Monks and Mystics était assez vague. Par exemple, "Ajouter 10-20 reliques chrétiennes majeures. Pour les rendre plus intéressantes, elles sont uniques et ne pourront jamais être détruites."

Le concepteurs de contenu doivent ensuite trouver les artefacts historiques à inclure, les descriptions de chacun, des idées sur leur apparence, leurs effets, leurs méthodes d'acquisition. Un petit paragraphe de design est ainsi transformé en centaines de paragraphes de textes d'événements, et en milliers de lignes de script.

Les créations des concepteurs de contenu :
  • Événements individuels ou en chaînes
  • Décisions
  • Sociétés et autres systèmes
  • Artefacts
  • Textes immersifs
  • Personnages
  • Titres
  • Religions
  • Cultures
  • Et bien plus encore
Tandis que le designer donne les indications, le concepteur de contenu les transforme en un produit fini et décide de tous les détails. Les concepteurs de contenu améliorent également l'ancien contenu du jeu, par exemple en corrigeant les bugs des événements, les fautes de grammaire ou en étoffant certaines chaînes d'événements.

Artiste
Bjarne “Grimjotun” Hallberg

L'artiste est responsable de la création des éléments graphiques du jeu. Cela se manifeste principalement dans la diversité des icônes de l'interface, mais ils sont également responsables de la configuration de chaque interface, et doivent proposer des ébauches et autres brouillons afin que l'interface puisse être mise en place avant même que les éléments graphiques ne soient terminés.

Voici par exemple un schéma pour l'interface de société tiré d'un document de design de Monks and Mystics :
schema d interface des societes


Comme vous le voyez, un certain nombre de choses a changé, mais l'idée générale est reconnaissable dans l'état actuel du jeu. Ce genre de schémas a beaucoup de valeur quand il s'agit de s'assurer que les versions précoces d'un système de jeu peuvent être exécutées et reproduites.

L'artiste contribue également à définir ce qui sera demandé aux artistes extérieurs à l'équipe de base. Par exemple, si on a besoin d'un artiste 3D, celui de l'équipe pourra fournir un schéma en 2D de ce qu'il souhaite afin que l'artiste 3D ait une base de travail et que le résultat soit cohérent avec le reste du jeu.

En somme, l'artiste a un impact significatif sur la direction artistique du jeu, tout en s'assurant que les interfaces sont cohérentes avec le reste du jeu.

Programmeurs
Magne “Meneth” Skjæran, et jusqu'il y a peu Gwenael “Moah” Tranvouez (qui travaille maintenant sur Stellaris)

La principale responsabilité des programmeurs est de créer de nouveaux systèmes en se basant sur le document de design. Par exemple, le système des sociétés de Monks and Mystics a été créé par les programmeurs, tandis que les sociétés elles-mêmes ont été créées par les concepteurs de contenu, et les graphismes par l'artiste.

Pour certains systèmes, il n'est besoin d'aucune conception de contenu. C'est par exemple le cas pour les ordres donnés aux alliés dans Monks and Mystics. Cependant, pour la plupart des systèmes , le travail des programmeurs consiste principalement à produire une fondation sur laquelle les concepteurs de contenu pourront travailler. Dans ce cas, les programmeurs rencontrent habituellement les concepteurs pour discuter des besoins de ces derniers, et se mettre d'accord sur la syntaxe dont les concepteurs se serviront pour interagir avec le système programmé.

Au moment de l'exécution, les concepteurs vont souvent se rendre compte qu'ils ont besoin d'une nouvelle fonctionnalité. Les programmeurs vont donc revenir au code pour y remédier.

Au-delà de la création de nouveaux systèmes les programmeurs doivent assurer la maintenance des anciens systèmes en corrigeant des bugs et en effectuant des améliorations. La plupart des changements liés à l'ergonomie dans le patch 2.7 ont par exemple été effectués par les programmeurs, mais souvent avec une aide significative de la part du département artistique.

Un autre aspect de la maintenance est de s'assurer que le jeu reste performant. Cela consiste à la fois à essayer d’ajouter de nouvelles fonctionnalités sans affecter les performances, et à passer du temps à optimiser les systèmes existants pour les rendre plus rapides.

Dans l'ensemble, les programmeurs et les concepteurs de contenu travaillent ensemble ; les programmeurs s'assurent que les systèmes principaux fonctionnent, tandis que les concepteurs font en sorte que ces systèmes sont variés et amusants à utiliser.

Assurance qualité
Arthur “[Arthur-PDX]” Bialecki et Daniel “Tuscany” Moore

L'équipe de design donne des lignes directrices. Le chef de projet décide qui fait quoi et quand, et comment respecter le calendrier. L'équipe d'exécution réalise tout cela.

L'assurance-qualité consiste à s'assurer que tout fonctionne de manière intéressante.

Cette équipe a un certain nombre de tâches à accomplir. La plus connue est simplement de trouver les bugs, mais c'est loin d'être leur seule activité. En bref, leurs responsabilités comprennent :
  • La vérification que les nouvelles fonctionnalités sont opérationnelles
  • La vérification que les bigs corrigés sont effectivement corrigés
  • L'identification des problèmes causés par les ajouts sur l'ancien contenu
  • L'identification des problèmes dans l'ancien contenu qui n'avaient pas encore été trouvés
  • La production de retours sur l'équilibrage du jeu
  • La production de retours sur le caractère divertissant des nouvelles fonctionnalités
  • La production de retours sur les aspects désagréables du jeu qui pourraient être améliorés (par exemple, l'ergonomie)
  • Le contrôle de la stabilité du jeu (crashs et désynchronisations)
  • Le contrôle des performances du jeu
  • Le fait d'attirer l'attention de membres de l'équipe sur les bugs qu'ils pourront corriger en fonction de leur spécialité
  • Parcourir les forums afin de collecter les bugs qui n'ont pas été trouvés lors des phases de test en interne, et informer ceux qui les rapportent que le problème est connu
  • Parcourir les forums afin d'identifier les inquiétudes de la communauté
  • L'identification des risques, comme l'accroissement du nombre de bugs, la dégradation des performances ou de la stabilité du jeu, etc
  • Déterminer sur les patchs peuvent être publiés
Au-delà des testeurs de l'assurance qualité propre à CK2, PDS dispose aussi d'un département central d'assurance-qualité. Ce département est mis à contribution pour certains types de test, comme le fait de déterminer si un patch est prêt pour sortir, la participation à des parties multijoueur en interne afin d'identifier les problèmes qui émergent lorsque un grand nombre de joueurs sont dans la même partie.

Prestataires
En plus de l'équipe interne, nous avons également un certain nombre de prestataires qui accomplissent des tâches d'une ampleur plus réduite :
  • La localisation - Nous avons plusieurs prestataires qui traduisent le jeu en allemand (shokii), en espagnol (kgw), et en français (zimxavier)
  • Les portraits - Nos portraits sont depuis longtemps le résultat du travail d'un prestataire, CrackdToothGrin. Il est également présent sur le forum de modding.
  • Les images pour les événements - Nous faisons généralement appel à une entreprise extérieure pour créer les images des événements de chaque extension.
  • La musique - Bien que nous créions également de la musique en interne, il nous arrive d'en sous-traiter une partie.
Les prestataires nous aident dans des domaines où la quantité requise de travail varie beaucoup dans le temps, ou bien quand les tâches à accomplir sortent de nos domaines de compétence.

Résumé
J'espère que vous avez apprécié cette introduction aux fonctions des différents membres de l'équipe de CK2.

La semaine prochaine, nous parlerons de la vie d'un bug, de sa découverte initiale à la publication d'une correction.

En bonus, voilà cinq entrées aléatoires du changelog du patch 2.8 :

- La liste des membres d'une société inclut dorénavant un décompte des membres. En passant la souris au-dessus, vous pourrez trouver la répartition des membres en fonction du rang qu'ils occupent.
- La règle d'égalité des genres "Tous" n'empêche plus de débloquer des succès steam, mais vous ne pourrez pas obtenir le succès "Empressive" quand cette règle est activée.
- Correction d'un bug où la piété procurait un bonus d'opinion à tous les personnages possédant des temples, et pas uniquement aux gouvernements théocratiques.
- L'IA vérifie désormais de combien de soldats elle privera son suzerain en se révoltant, plutôt que d'évaluer grossièrement "Environ la moitié de mes troupes, j'imagine ?"
- Correction du bug où la date de fin de construction d'un bâtiment ne correspondait pas à la véritable date de fin de construction même quand les modificateurs restaient les mêmes pendant toute la construction.
Auteur : Meneth
Traduction : Spectator_Errans