SaxonDragon, sur Prophesy of Pendor : « Le modding m'a appris à diriger sans avoir d'autorité »

Après deux articles, vous savez ce qu'est Prophesy of Pendor 2 et ce qu'il ambitionne. Mais pour comprendre pourquoi SaxonDragon est la personne capable de le construire, il faut remonter à la source : le mod qui a tout déclenché, la discipline créative qui l'a façonné, et les leçons durement acquises sur l'art de diriger des gens que personne ne paie.

Ce troisième volet aborde la partie la plus universelle de l'interview : comment un grand mod se fabrique vraiment, ce que le modding et le développement commercial ont en commun (bien plus qu'on ne le croit), et les dimensions humaines du développement de jeux que les documents de conception n'évoquent jamais. Que vous ayez passé un millier d'heures dans Pendor ou que vous n'ayez jamais touché à Mount & Blade, cette conversation s'adresse à quiconque a déjà essayé de construire quelque chose avec d'autres personnes.

La vraie réponse, c'est que Prophesy of Pendor a résonné parce que j'ai appliqué les mêmes principes de game design qui guidaient ma réflexion depuis mes campagnes en bac à sable dans les années 1970, mais cette fois avec un outil supplémentaire que la plupart des concepteurs n'utilisaient pas explicitement : un cadre psychologique formel pour comprendre pourquoi les gens jouent aux jeux vidéo.

J'avais consacré beaucoup de temps à enrichir le modèle motivationnel de McClelland, un cadre théorique initialement développé pour expliquer les besoins humains d'accomplissement, d'affiliation et de pouvoir, en l'étendant sur des axes supplémentaires afin de couvrir l'ensemble des besoins que les jeux mobilisent. Quand on cartographie ces besoins de façon systématique et qu'on confronte un jeu à cette carte, quelque chose se clarifie. Les lacunes deviennent visibles. Les endroits où le design laisse des besoins insatisfaits cessent d'être de vagues impressions de frustration pour devenir des défauts précis, identifiables et corrigeables.

Quand j'ai appliqué ce modèle à Mount & Blade et Warband, le tableau était limpide. Le jeu de base avait une ossature extraordinaire : le système de combat, la structure monde ouvert, les batailles à cheval. Mais la couche de présentation présentait des lacunes importantes. Le lore était mince. Le monde ne s'expliquait pas vraiment lui-même. Le sentiment de conséquence, celui d'une réalité politique et culturelle vivante qui évolue autour du joueur, était insuffisamment développé.

Les joueurs s'engageaient avec le squelette d'un monde alors qu'ils méritaient un monde avec de la chair dessus. Prophesy of Pendor était, dans son essence, une tentative de fournir cette chair, de combler les lacunes que la cartographie motivationnelle avait rendues lisibles.

Ce qui a rendu l'exécution particulièrement difficile, et je tiens à être transparent là-dessus, c'est le contexte dans lequel tout cela a été construit. Pas de budget. Aucune ressource professionnelle au-delà de mon propre temps. J'apprenais un nouveau langage de programmation au fur et à mesure. Et je dirigeais une équipe de développement de près de deux douzaines de contributeurs que je ne connaissais que sous forme de pseudos sur un forum, des gens que je n'avais jamais rencontrés, répartis sur plusieurs fuseaux horaires, unis uniquement par l'enthousiasme partagé pour ce que nous construisions ensemble. Gérer ce type d'effort créatif distribué et bénévole est une discipline à part entière, et qui ne s'accompagne d'aucun manuel.

Le résultat n'était pas ce que j'appellerais parfait. J'en connaissais les limites mieux que personne, parce que je savais ce que le design visait et exactement là où il tombait court. Mais la perfection n'a jamais été l'objectif premier. L'objectif était de démontrer, à moi-même autant qu'à quiconque, que les compétences étaient toujours là. Qu'après des années loin de l'industrie, je pouvais encore construire quelque chose dans lequel les joueurs s'engageraient profondément et reviendraient régulièrement. Prophesy of Pendor a répondu à cette question avec bien plus d'emphase que je n'avais osé l'espérer.

Ce qu'il a également fait, c'est me montrer, avec une clarté considérable, ce que la prochaine itération devait être. Prophesy of Pendor était la preuve de concept. Ce qui vient ensuite, c'est l'expression complète de l'idée.

C'est une question fascinante, et ayant travaillé des deux côtés de cette frontière, je peux vous donner une réponse qui pourrait surprendre : la différence est moins fondamentale que la plupart des gens ne le supposent. C'est avant tout une question de portée et d'échelle, et non une distinction catégorielle dans la philosophie créative.

Regardez comment la majorité des jeux commerciaux sont construits aujourd'hui. L'écrasante majorité utilise des middlewares, des moteurs comme Unity ou Unreal, et quand vous construisez dans ces moteurs, vous travaillez par définition dans la maison de quelqu'un d'autre. Vous opérez dans un cadre que vous n'avez pas architecturé, soumis à des contraintes que vous n'avez pas conçues, dépendant de systèmes que vous ne contrôlez pas entièrement. La maison a un mobilier différent de celle d'un mod, et une superficie considérablement plus grande, mais la réalité structurelle est remarquablement similaire. Il y a toujours des murs qu'on ne peut pas déplacer.

Dans le modding, la contrainte spécifique est ce que les développeurs appellent la boîte noire, les systèmes codés en dur au cœur du jeu original qui ne sont tout simplement pas accessibles à la modification. On travaille autour d'eux, avec eux, on trouve des solutions créatives pour atteindre ses objectifs de design dans leurs limites, mais on ne peut pas les réécrire. Cela exige un type particulier de créativité disciplinée : apprendre à travailler dans le sens d'un système plutôt que contre lui, trouver les espaces où votre vision et l'architecture du moteur peuvent coexister de façon productive.

La différence la plus profonde, dans mon expérience, tient moins à la liberté créative qu'à la nature de l'engagement. Quand on dispose d'une équipe de développement professionnelle à temps plein, on possède quelque chose d'énormément précieux qu'il est facile de tenir pour acquis : la fiabilité. Le travail est documenté. Les processus sont établis. Chaque membre de l'équipe se présente, accomplit ses tâches assignées, et on peut compter sur lui pour livrer. La machine tourne de façon régulière.

Une équipe de modding fonctionne sur des bases entièrement différentes. Vos contributeurs sont conditionnels, ils sont là parce qu'ils aiment le projet, et dès que la vie leur impose d'autres priorités, le projet attend. Les niveaux de compétence varient énormément. La disponibilité fluctue sans prévenir. La documentation est au mieux irrégulière. Vous dirigez, en somme, une organisation bénévole maintenue ensemble par un enthousiasme partagé, et l'enthousiasme partagé, aussi réel soit-il, est un liant bien plus fragile qu'un salaire et un contrat.

Mais c'est là que le tableau se nuance, car les équipes de modding portent quelque chose que les équipes professionnelles n'ont pas toujours, et qui compte bien plus qu'on ne le reconnaît : la passion. Les gens rejoignent une équipe de modding parce qu'ils aiment le jeu de base et croient en la vision de ce qu'ils créent ensemble. Cette passion est auto-sélective et auto-entretenue.

Personne ne remplit un dossier de candidature pour modder un jeu qui lui est indifférent.

Ce que le modding m'a appris, en définitive, c'est comment diriger sans autorité, comment susciter une contribution régulière de personnes que je n'avais jamais rencontrées, en n'utilisant que la qualité de la vision et la culture de la communauté comme outils. C'est une compétence qui se transfère directement dans n'importe quel environnement de développement, commercial ou non, et je ne donnerais pour rien au monde l'expérience de l'avoir acquise.

C'est une question qui appelle plusieurs réponses honnêtes, et je veux résister à la tentation d'en donner une seule, parce que les plus grands défis du développement de jeux, qu'il s'agisse de modding ou de développement commercial, ont tendance à se regrouper autour d'un noyau commun dont on ne parle jamais assez dans les cercles du game design. On parle beaucoup de technologie, de systèmes, de pipelines. On ne parle pas assez des dimensions humaines de la création de jeux, et c'est là, dans mon expérience, que se livrent les vraies batailles.

Le leadership est le socle sur lequel tout le reste repose. Pas le type de leadership qui s'impose par l'autorité ou qui dicte sa vision de haut en bas, mais celui qui crée les conditions pour que le bon travail puisse se faire.

Cela exige, avant tout, la capacité à écouter, et j'entends écouter dans le sens le plus plein du terme. S'écouter soi-même, pour que ses instincts et ses principes de design restent alignés tout au long d'un cycle de développement qui fera tout son possible pour les dissocier. Écouter son équipe, parce que les personnes les plus proches du travail voient des choses que le responsable du design ne peut pas voir à distance. Écouter ses joueurs, parce qu'ils vous diront, clairement, avec insistance, et parfois sans ménagement, exactement là où votre vision et leur expérience ont divergé. Et écouter tout le monde, les critiques, les sceptiques, les voix qu'on n'a pas sollicitées, parce que ce sont souvent elles qui portent les informations dont on a le plus besoin.

Le défi le plus sous-estimé de tous est peut-être de maintenir une vision cohérente sur un cycle de développement qui peut s'étaler sur des années. Le glissement de périmètre est réel. Le renouvellement d'équipe est réel. La tentation de courir après les tendances, de répondre à chaque retour joueur par un changement de design, de laisser la vision se brouiller aux bords sous l'effet du temps et de la pression, tout cela est bien réel.

Tenir la ligne sur ce que le jeu est fondamentalement, tout en restant sincèrement ouvert à la façon dont il peut être amélioré, est un équilibre qui exige une attention constante et consciente.

Et puis il y a l'ego. Le laisser à la porte n'est pas une décision qu'on prend une fois pour toutes ; c'est une pratique quotidienne. Le moment où vous devenez plus attaché à avoir raison qu'à créer quelque chose de grand, vous avez perdu le fil.

Accepter la réalité que vous ne savez pas tout, que les membres de votre équipe verront des solutions que vous n'avez pas envisagées et identifieront des problèmes que vous n'avez pas remarqués, n'est pas une concession de faiblesse. C'est la position la plus stratégiquement intelligente qu'un responsable de design puisse occuper.

Réduire la distance hiérarchique entre soi et son équipe, créer un environnement où les retours circulent librement dans toutes les directions et où personne n'a peur de dire que quelque chose ne fonctionne pas, produit systématiquement de meilleurs résultats que n'importe quelle quantité de brillance individuelle appliquée en silo.

Pour le développement commercial en particulier, les défis changent d'accent, sinon de nature. L'évolution technologique est une pression constante. Communiquer efficacement avec le client, les personnes qui financent le développement et dont vous détenez la confiance, est une discipline à part entière. Ils ont besoin de comprendre ce qu'ils obtiennent, quand ils l'obtiennent, et quels risques existent entre ici et là. Cela exige un niveau de transparence qui peut sembler inconfortable, parce que la réponse honnête à beaucoup de questions de développement est : on ne sait pas encore.

Et enfin, les jalons. Des jalons atteignables et réalistes, qui intègrent une marge pour l'imprévu, parce qu'en développement de jeux, l'imprévu n'est pas l'exception, c'est la règle. Chaque calendrier de développement que j'ai jamais vu a été mis à rude épreuve par l'inattendu. La différence entre les équipes qui survivent à ces moments et celles qui n'y survivent pas se résume à une chose : ont-elles intégré de la place pour la réalité dans leurs plans ? La marge n'est pas du pessimisme. C'est le tissu cicatriciel de l'expérience.