Chez Nintendo, « chaque développeur est un directeur ». Si vous cherchez des excuses, vous êtes retiré de l’équipe, affirme un vétéran

L’ancien vétéran de Nintendo, Motoi Okamoto, parle de l’approche « tout le monde est directeur » de l’entreprise en matière de développement de jeux.



« Si un directeur n’est pas capable de juger si les spécifications d’un jeu sont bonnes ou mauvaises sans les implémenter au préalable, est-il incompétent ? » Ce sujet fait l’objet de nombreux débats parmi les développeurs japonais sur X ces derniers temps – certains critiquant les game designers qui demandent que des systèmes soient implémentés « juste pour vérifier », ce qui augmente la charge de travail des programmeurs. En contre-argument, le développeur de jeux Motoi Okamoto a partagé son point de vue sur le processus de développement principalement « pratique » qui prévaut chez Nintendo.

Bien qu’il soit aujourd’hui connu comme producteur de la série Silent Hill de Konami, Okamoto a commencé sa carrière de développeur chez Nintendo, où il a travaillé près de dix ans sur plusieurs titres Mario et Pikmin. Participant à la discussion récente, Okamoto a commenté sur X : « J’ai vu passer des avis du genre : “On ne peut pas juger si une spécification de jeu est bonne ou mauvaise sans l’implémenter ?” ou encore “Les directeurs qui ne savent pas juger sans implémentation sont incompétents.” Mais chez Nintendo, ce qui compte, c’est justement d’implémenter et de tester – les décisions ne se basent pas sur ce qui est écrit sur papier. »

Il ajoute ensuite : « Les programmeurs paresseux qui rechignent à implémenter des éléments, ainsi que les chefs de projet et programmeurs qui essaient d’éviter le processus d’essais-erreurs en se cachant derrière les délais et les contraintes budgétaires, sont écartés des équipes de développement sans hésitation. »

Fait intéressant, Okamoto décrit l’environnement de développement chez Nintendo comme une culture où « tout le monde est directeur », ce qui signifie que chaque développeur de l’équipe participe, à un certain degré, aux prises de décision pour améliorer le jeu. « Si un programmeur trouve une spécification ennuyeuse, il est libre de l’implémenter de la manière qu’il estime la rendre amusante. C’est ça, le travail d’un vrai programmeur de jeux. »

En revanche, il précise que cela ne signifie pas développer entièrement des éléments pour ensuite les abandonner. « Ce qui est mal vu, c’est lorsqu’un développeur est incapable de juger sans graphismes élaborés. Si vous ne pouvez pas dire si une mécanique de jeu est amusante en vous basant uniquement sur des graphismes simplifiés, vous pouvez être considéré comme incompétent. »

« Le plus grand danger dans la création de jeux révolutionnaires et de succès », explique Okamoto, « vient des soi-disant “experts en game design” et des critiques omniscients qui étouffent le processus nécessaire d’essais et d’erreurs. Ce qui est important, c’est de ne pas hésiter à tester même des spécifications qui peuvent sembler déraisonnables au départ. »

Comme exemples majeurs, Okamoto cite le créateur de la série Mario, Shigeru Miyamoto, et l’ancien président de Nintendo, Satoru Iwata, qui, selon lui, ont toujours gardé une approche humble et pratique dans la création de jeux, malgré leur réputation de « sages » de l’industrie. À l’inverse, il commente : « Si vous prétendez pouvoir juger sans rien fabriquer concrètement, je pense que c’est simplement de l’arrogance. »

En même temps, il reconnaît que ce style de développement ne convient pas à tous les genres, en particulier les jeux narratifs (que Nintendo développe rarement en interne). Pour les jeux centrés sur l’histoire, attendre l’implémentation pour porter un jugement peut signifier devoir reconstruire des ressources coûteuses comme des cinématiques, ce qui n’est pas viable avec un budget de développement moyen. Au lieu de cela, Okamoto affirme que, idéalement, le processus d’essais-erreurs doit être effectué au stade du scénario, avec autant d’itérations que possible.