Les développeurs ont la parole, Vol. 14 : Le réveil musical de Nintendo : Alarmo – Chapitre 2
28.10.2024
Certaines des images et vidéos présentées dans cette interview ont été créées lors du développement.
Le contenu de cet article a été publié à l'origine en japonais.
Toutes les images présentées montrent la version japonaise du produit. Le réveil musical de Nintendo : Alarmo est disponible en français.
Chapitre 2 : Les défis d'un développement transverse
Visiblement, ce projet a été porté par des développeurs matériel et logiciel travaillant en équipe. Ce type de collaboration est-il courant sur d'autres projets ?
Tamori :
Il est assez rare qu'un développeur de matériel ait un rôle de directeur pour un produit comportant du développement logiciel, comme M. Akama l'a fait ici. Cependant, lors du développement de Ring Fit Adventure (3), l'équipe logiciel a fait des demandes à l'équipe matériel sur le thème : « Nous aimerions créer tel style de jeu, vous pouvez nous fournir le matériel nécessaire ? » Même si certaines de ces idées n'arriveront pas forcément au stade de la commercialisation, les équipes logiciel et matériel collaborent sans cesse pour développer des produits.
(3) Logiciel Nintendo Switch publié en octobre 2019. Jeu d'aventure et de fitness dans lequel le joueur accroche une manette Joy-Con au Ring-Con et à la sangle de jambe fournis et joue en utilisant son corps entier.
Même ainsi, le processus de développement semble complètement différent de celui d'un jeu normal.
Tamori :
C'est effectivement complètement différent. En plus, dans ce cas, outre les développeurs matériel et logiciel, nous avions avec nous des développeurs d'un domaine faisant le lien entre les deux, ceux du logiciel système. Ainsi, ces trois départements ont uni leurs forces depuis le tout début du développement.
Le terme « développement » recouvre une diversité de domaines. Le développement matériel inclut la conception du produit et de ses mécanismes, le développement logiciel système permet le contrôle du capteur de mouvement et des systèmes internes et le développement logiciel d'application est nécessaire à l'alarme et à l'affichage. Les pratiques ne sont pas les mêmes selon les départements ou les postes. Nous avons donc souvent eu du mal en termes de cohésion d'équipe et il a fallu réfléchir à la façon d'aller de l'avant.
Jusqu'ici, M. Tamori, vous aviez travaillé au développement logiciel et M. Akama au développement matériel. Quels sont, de vos points de vue respectifs, les défis que vous avez dû relever en développant Alarmo ensemble ?
Tamori :
Lorsqu'il s'agit du développement logiciel, les tests d'un prototype peuvent être effectués par les développeurs logiciel seuls, donc tout avance très rapidement. Lorsque le développement matériel est impliqué, comme c'est le cas ici, il faut créer le matériel, contrôler le capteur et les éléments internes, lancer l'application, etc., ce qui complexifie le processus de développement.
Par exemple, si le logiciel système ne gère pas le capteur correctement, l'alarme émise par le logiciel ne réagit pas correctement. Par ailleurs, il est possible d'attribuer l'absence de réaction du capteur à un problème de logiciel système, alors qu'il est dû à une modification minimum apportée au matériel.
Akama :
À ce propos, je me souviens avoir rencontré des difficultés quand une légère modification de la zone du capteur a diminué sa réactivité. J'ai cru qu'il s'agissait d'un problème de logiciel système, mais je n'arrivais pas à trouver la cause. C'est compliqué quand ce n'est pas votre domaine de compétences.
Tamori :
Ajouter une petite pièce ou modifier légèrement le matériau utilisé ou la forme du produit peut affecter son comportement. Le logiciel système et l'application devant être modifiés en fonction des changements apportés au matériel, nous avons finalement dû veiller à tous partager nos façons de faire et travailler en parallèle. Du point de vue du développement logiciel, c'était un défi de devoir suivre un processus de développement entièrement différent de celui du jeu standard.
D'un autre côté, travailler en équipe sur la totalité du développement, de la conception de l'objet au développement du logiciel système et de l'application, a été très utile, car, en cas de problème, nous pouvions rapidement trouver la cause et prendre les mesures correctives.
Si l'on prend ça par l'autre bout, le fait que vous ayez rencontré de tels obstacles en coopérant indique que tous les départements avaient bien leur place dans ce projet. M. Akama, quels sont les défis auxquels vous avez dû faire face ?
Akama :
En termes de développement matériel, le vrai défi a consisté à déterminer les spécifications en partant de zéro. Les consoles de jeu sur lesquelles j'ai travaillé obéissaient à certaines règles, comme la forme générale ou le nombre de boutons. Là, puisqu'il ne s'agissait pas d'une console, ces règles ne s'appliquaient pas. Cela n'a pas été facile de décider des spécifications sans aucune ligne de conduite, comme le type et le nombre de boutons nécessaires.
À entendre les défis que les développeurs logiciel et matériel ont dû relever, je me rends compte des différences de culture de chaque département. En tant que développeurs ayant travaillé à des tâches différentes, y a-t-il eu des moments où, au premier abord, vous ne vous compreniez pas ?
Akama :
Ça a été ça tout le temps. (rires)
Tamori :
Le fossé entre nos cultures de développement et nos personnalités s'est traduit par des... différences de compréhension. (rires) M. Akama et moi sommes concepteurs, et nous avons tendance à utiliser des termes abstraits. Cependant, les expressions vagues sont difficilement intelligibles pour des programmeurs système ou des ingénieurs matériel qui sont habitués à être précis dans leur travail quotidien. Quand nous leur expliquions que nous voulions améliorer encore la réactivité du produit, ils nous posaient des questions précises, du genre : « Quelle est la marge de manœuvre en secondes ? »
Akama :
Ou si nous leur disions : « Il faut que ça fasse boing », les programmeurs étaient capables de revenir en demandant : « Définissez "boing" ».
Tamori :
Une fois, j'ai observé M. Akama du coin de l'œil. Les programmeurs étaient en train de lui poser des questions et je me disais : « M. Akama, mais comment vous voulez qu'ils comprennent ça ? » (rires) J'ai vécu des expériences similaires en développant des jeux et, dans une certaine mesure, je savais que ce n'était pas une bonne idée de parler aux programmeurs en termes abstraits, mais M. Akama n'en était pas conscient. Je pense que ça a été un peu compliqué pour lui de ce point de vue-là.
Akama :
À mi-chemin du développement, j'ai commencé à faire des photos et des vidéos de moi m'endormant ou me réveillant, et à retoucher le son. Je m'en servais pour expliquer les effets sonores que je voulais obtenir si je m'étirais, etc.
Y a-t-il eu des moments où le développement s'est arrêté en raison des problèmes de communication ou des différences dans la façon de travailler ?
Tamori :
Oh oui. Plusieurs fois, même. Et puis, le développement ayant eu lieu au cours de la pandémie de COVID-19, il était difficile de communiquer facilement, ce qui a eu un gros impact. À un moment, le développement d'Alarmo était dans une telle impasse que nous avons tout mis en pause pendant une semaine pour nous consacrer à autre chose.
Vous étiez en train de développer un réveil, n'est-ce pas ? Et tout le monde a mis le projet de côté ?
Tamori :
Exactement. Pour que tout le monde comprenne les caractéristiques du capteur de mouvement, sans se focaliser sur le réveil, nous avons demandé à des membres de l'équipe matériel et de l'équipe logiciel de se mettre par deux et de trouver des idées. Certains ont ainsi proposé d'utiliser la détection de mouvement pour recréer « Daruma-san ga koronda » (Daruma-san est tombé) (4) ou pour faire de la musique en bougeant en rythme. C'était fascinant de voir toutes ces idées surgir.
C'était la première fois que les équipes matériel et logiciel collaboraient si étroitement au développement d'un produit autre qu'une console de jeu ou un jeu, alors tout ne s'est pas toujours passé comme prévu et il y a parfois eu des tensions. Malgré tout, cette expérience nous a permis de redécouvrir le plaisir de développer ensemble, et cela a grandement rapproché les équipes.
(4) Jeu traditionnel très populaire au Japon, proche de notre « 1, 2, 3 soleil ». Un joueur se met face à un arbre ou à un mur, dos tourné aux autres participants. Ceux-ci se tiennent sur la ligne de départ, à quelques pas de lui. Le joueur de dos se met à chanter « Daruma-san ga koronda » et les participants doivent se rapprocher de lui le plus possible. S'il se retourne, les participants ne doivent plus bouger. Si l'un d'eux fait un mouvement, il se fait attraper. Lorsqu'un participant arrive à toucher le dos du joueur sans s'être fait attraper, les autres doivent partir en courant avant que le joueur ne compte jusqu'à 10. Arrivé à 10, celui-ci fera 10 pas et attrapera quiconque se trouve à sa portée. Cette personne prendra alors sa place. S'il n'y a pas de participant à portée, le joueur retourne compter. Il existe plusieurs variantes.
Akama :
Finalement, après amélioration de la réactivité du capteur, nous nous sommes approchés du produit final. Avoir eu le temps de créer différents prototypes et avoir vu les membres des différentes unités de l'équipe se rapprocher, c'est ce qui a permis, selon moi, de faire avancer ce projet.
