Innovation survenue au sein de l'équipe sonore de The Legend of Zelda: Tierkin. Fabrication à plat réalisée avec des « spécifications mobiles » qui utilisent les données de développement comme matériaux de référence [CEDEC2024]

Dans cette conférence, les intervenants seront Nintendo Co., Ltd. Département de planification et de production"Tiakine"Le responsable de la programmation de l'équipe de développement, Yuichiro Okamura, le responsable de la programmation sonore Junya Nagata et le responsable du développement des outils de jeu Shozo Hidaka sont montés sur scène.

"Tiakine"Maintenant, jetons un œil au travail précédent ``La Légende de Zelda : Breath of the Wild"(ci-dessous,"Brew Waï") Même si les personnages ennemis ont la même apparence, leurs environnements de développement en arrière-plan sont complètement différents. Dans cette conférence"Tiakine"Il a expliqué le processus derrière la reconstruction de l'environnement de développement et comment cet environnement de développement a été réellement utilisé, citant des exemples de son utilisation du point de vue de l'équipe sonore.

Des « spécifications mouvantes » qui transforment les données de développement en matériaux

"légende de zeldaDans les jeux précédents de la série, le développement était encore à petite échelle et le nombre de développeurs impliqués dans chaque personnage ennemi était faible. Cela a facilité la communication entre tous et ils se sont rencontrés face à face tous les jours pour réfléchir à des idées tout en produisant.

mais

Malgré cette tendance, l’équipe de développement de Nintendo a cherché une direction différente. Tous les membres de l'équipe réfléchissent au jeu et visent à créer des produits de manière plate, permettant des essais et des erreurs. Par exemple, la structure permet à chacun de trouver plus facilement de bonnes idées, comme par exemple que les artistes réfléchissent à l'équilibre du combat et ajoutent leurs propres actions.

Cette façon de penser est la même pour l'équipe sonore, et dans la production sonore, qui a tendance à être un processus plus tardif que d'autres processus, nous créons activement une production liée à la réponse de la pièce, plutôt que de simplement produire des sons qui correspondent à l'apparence. .J'ai fait des suggestions.

en premier lieu

Pour que l'équipe son puisse travailler de manière proactive, il était important de « savoir », c'est-à-dire de recueillir des informations. Il est cependant difficile d’appréhender les détails des spécifications rien qu’en jouant au jeu en cours de développement. Il y a des moments où il est difficile de contacter directement la personne responsable, et les documents de développement tels que les spécifications contiennent une grande quantité d'informations et sont complexes, et il est possible que le comportement réel puisse différer des documents en raison de bugs ou de changements dans caractéristiques.

Cette importance du « savoir » est commune à toutes les sections. Les documents tels que les spécifications sont les plus faciles à consulter, mais comme mentionné précédemment, le contenu des spécifications avait le problème de s'écarter du contenu réel du jeu à mesure que le développement progressait. Ce problème devient particulièrement visible lors de la création de produits plats, où le contenu du jeu ne cesse de changer légèrement.

Là"Brew Waï"Parmi "l'aperçu" et les "comportements et paramètres spécifiques" qui devraient être décrits dans les spécifications, l'équipe de développement a décidé d'inclure ces derniers dans les données et les programmes produits sur la base des spécifications. Au lieu d’écrire les politiques de mise en œuvre dans des spécifications, ces politiques ont été mises en œuvre à l’aide de données.

Les spécifications ont été réduites, et même si le développement progresse, les grandes lignes s'écarteront rarement du contenu du jeu, de sorte que l'écart entre les spécifications et le développement a été réduit. En conséquence, le nombre de choses pouvant être réalisées avec les données a augmenté et la proportion de programmes a diminué. De cette manière, un système basé sur les données (prenant divers jugements et décisions basés sur les données) sera établi.

En conséquence, les spécifications ont rétréci et sont devenues inutiles en tant que source d'information pour « savoir », mais les données peuvent être utilisées pour compléter cela. Il suffit de visualiser les données de différentes manières, comme des tableaux et des graphiques, ou de permettre de visualiser les données directement dans une application.

Vous pouvez connaître les dernières informations sur le jeu à partir de ces informations visualisées et de la sensation que vous ressentez lorsque vous touchez le jeu. L'équipe de développement a appelé cela une « spécification mobile ». Il ne s’agit cependant pas de nier l’utilité des spécifications conventionnelles pour organiser et communiquer les pensées. En fin de compte, il n’était pas adapté pour obtenir les dernières informations sur les jeux en cours de développement.

Ce flux est donc"Tiakine"Alors que s'est-il passé ? Comme l'« Ultra Hand » qui peut soulever et connecter n'importe quel objet, et le « Scra Build » qui crée une nouvelle arme en attachant un autre objet à une arme."Tiakine"En plus d'incorporer des niveaux de spécifications complexes sans précédent, le domaine est devenu une structure tridimensionnelle, élargissant le monde et augmentant simplement la quantité de matière.

Les spécifications mobiles et basées sur les données s’étendent pour correspondre à l’échelle. Dans le cadre de cet effort, l'équipe audio a également utilisé son propre outil de contrôle BGM « BGMEditor ».

La « musique interactive », qui modifie la musique en fonction de la situation et du contenu du jeu, est désormais monnaie courante, mais sa mise en œuvre nécessite une définition. Par exemple, si la musique change pendant la journée et la nuit, il faut définir à quelle heure la journée doit se terminer.

Traditionnellement, lors de la création de modifications musicales détaillées pour chaque situation, un compositeur sonore dessinait un diagramme et demandait à un programmeur de le faire. Cependant, avec ce BGMEditor, une spécification a été réalisée dans laquelle les schémas imaginés par le compositeur peuvent être utilisés tels quels. Il est devenu plus facile pour le compositeur de créer des définitions détaillées et des essais et erreurs pour créer une production naturelle.

La technologie basée sur les données a également progressé dans d'autres domaines, et des outils de programmation visuelle sont introduits pour chaque phase afin de visualiser les algorithmes lors de la mise en œuvre des spécifications pour le comportement de chaque personnage. Les avantages pour l’équipe dans son ensemble étaient qu’il était plus facile pour des personnes autres que la personne mettant en œuvre la mise en œuvre d’obtenir des informations, que des essais et des erreurs étaient possibles dans d’autres domaines et qu’il était plus facile de diviser le travail.

Deux exemples d'outils ont été expliqués, mais on dit que Nintendo a une forme d'implémentation d'outils qui existe depuis longtemps. Contrairement aux moteurs de jeu intégrés couramment utilisés, chaque outil n'est pas implémenté sur un framework commun, mais est un « type de composant » dans lequel chaque outil est créé indépendamment et utilise différents langages et technologies.

Dans ce format, chaque outil est considéré comme un composant et les outils nécessaires sont sélectionnés pour chaque projet.

Le type de composant est hautement compatible avec la grande variété de matériel Nintendo, ce qui facilite la génération d'outils et d'idées uniques au sein d'un projet de jeu et facilite l'adoption de nouvelles technologies. En revanche, elle présente également l’inconvénient de fragiliser la coordination entre les outils. Par exemple, même si vous souhaitez introduire une fonction de sélection déroulante dans Sound Tool, vous devez analyser séparément les données du modèle pour afficher les options, et compte tenu du temps et des efforts, vous n'avez d'autre choix que de vous contenter d'une saisie de texte. méthode.

Un autre inconvénient est que la « structure » du jeu est difficile à comprendre. Il existe des connexions entre les données créées avec différents outils, par exemple les personnages ont des modèles, qui sont également connectés aux champs de démonstration et de niveau. Pour comprendre la structure, vous devez comprendre tous ces outils associés. La technologie basée sur les données a facilité l'obtention d'informations à partir d'outils individuels, mais le « savoir » que l'équipe de développement visait réellement n'a pas été atteint.

Dans la démarche visant la fabrication à plat, il est devenu difficile de « savoir » et nous avons atteint un tournant où les spécifications sont devenues plus complexes."Tiakine"Les équipes de développement ne peuvent plus ignorer les défis liés aux composants.

Il était considéré comme basé sur l'environnement de développement du travail précédent, mais comme le travail précédent donnait la priorité à la vitesse de mise en œuvre, il manquait d'évolutivité et de nombreuses parties n'étaient pas organisées. Par conséquent, la décision a été prise de reconstruire l’environnement de développement pour ce travail.

Deux outils qui ont créé un nouvel environnement de développement

Afin de résoudre le problème de la reconstruction, nous analysons dans un premier temps les faiblesses de la coordination entre les outils. Le problème était que si vous essayiez de lire des fichiers à partir d’autres outils, vous deviez les implémenter individuellement et leur analyse prendrait du temps.

En tant que solution pouvant être utilisée universellement, nous avons conçu une méthode dans laquelle une base de données est préparée comme une plate-forme commune et où les outils accèdent aux informations des fichiers via la base de données. Nous avons réduit la commodité à trois points.

Accédez à des méthodes utilisables avec n’importe quel outil

Nous avons adopté une base de données relationnelle (*) et construit une base de données accessible à l'aide d'un langage de gestion de base de données appelé "SQL (Structured Query Language)". Étant donné que SQL peut être utilisé par une variété de programmes, il a créé une base commune pour tous les outils.

*Base de données relationnelle : base de données qui stocke les données sous la forme d'un tableau avec des lignes et des colonnes. Le traitement des données peut être effectué en reliant les données communes dans chaque ligne et colonne et plusieurs tableaux.

qui écrit dans la base de données

Par exemple, un développeur d’un outil sonore n’est pas forcément familier avec le format d’un outil modèle. Par conséquent, comme solution naturelle, nous avons établi une règle selon laquelle les fichiers de chaque outil doivent être rédigés par une personne qui les connaît. Même si cela peut sembler plus de travail, la charge globale est réduite car il n'est plus nécessaire de prendre en charge d'autres outils individuellement.

que mettre dans la base de données

Même les personnes qui connaissent un fichier ne peuvent pas prédire quel type de données d'autres outils voudront de ce fichier par essais et erreurs. Compte tenu de l’effort nécessaire pour répondre aux demandes, il serait idéal d’avoir le plus de données possible dès le début. À l'exception des données extrêmement volumineuses ou difficiles à gérer, nous avons même analysé le code source et l'avons publié.

De plus, si la base de données commune est placée sur un serveur et accessible par chaque développeur, il est possible que des fichiers qui ne soient pas les plus récents existent si la base de données commune est en cours de modification. Afin de résoudre le problème des conflits d'informations provoqués par l'écriture de chaque développeur, l'idée d'``avoir une base de données pour chaque développeur'' a été adoptée. L'équipe de développement a appelé cela « LocalDB ».

Cela empêchait le mélange des données d'autres développeurs et créait la commodité de pouvoir acquérir facilement les dernières données en mettant à jour la version, mais LocalDB avait également ses problèmes. Afin de réduire l'espace disque et le temps nécessaire à la récupération des données, chaque développeur essaie d'éviter les fichiers inutiles et, par essais et erreurs, il se retrouve avec des données qui ne peuvent pas être référencées.

Par conséquent, pour compléter LocalDB, nous avons également préparé une base de données sur le serveur. C'est dans le même format que LocalDB et les dernières données mises à jour sont écrites. Ce "GlobalDB" peut être référencé lorsqu'il n'y a pas de fichiers dans LocalDB, et il écrira les fichiers nécessaires dans LocalDB, permettant d'obtenir toutes les informations uniquement avec LocalDB. L'interface utilisateur de sélection déroulante mentionnée précédemment a également été introduite dans divers outils à mesure que l'intégration a été renforcée.

En augmentant le nombre de fonctions coopératives entre les outils, nous avons également progressé dans la résolution du problème de la non-compréhension de la structure du jeu. LocalDB contient toutes les informations, donc si vous la visualisez bien, vous pouvez comprendre la structure.

Cependant, si vous tracez les connexions entre les fichiers référencés par chaque fichier, l'échelle est trop vaste. Comme nous ne pouvons pas voir l’ensemble, nous n’avons d’autre choix que de le découper et d’en examiner les parties. La méthode de découpe des données a été envisagée en trois étapes : sélectionner le type de données, le affiner et tracer les connexions. L'outil de visualisation créé à cet effet est « ProjectPortal ».

Cet outil organise et affiche d'abord les données sous forme d'onglets à l'étape « sélectionner le type ». Pour affiner davantage votre recherche, en plus de rechercher par nom, vous pouvez également rechercher des conditions par balise. Par exemple, si vous souhaitez rechercher des données sur des cibles frappées par la foudre dans un jeu, vous pouvez les affiner en utilisant la balise « métal ».

Ces balises doivent être attachées avec précision à une énorme quantité de données et doivent être réattachées à chaque fois que les spécifications changent. Par conséquent, concernant les balises, nous avons introduit la spécification d'une « balise de requête » qui agit comme une balise et apparaît dans la recherche lorsqu'une condition telle que « brûler » ou « bouclier » est remplie en faisant référence aux paramètres dans les données lors d'une requête avec SQL. Élimine le besoin de marquage manuel.

Pour le processus final de « traçage des connexions », des interfaces utilisateur distinctes sont fournies lors du traçage dans le sens direct et lors du traçage dans le sens inverse à partir des résultats. Le premier peut être exprimé dans une structure arborescente générale, nous avons donc utilisé une interface utilisateur de style arborescent, et pour le second, le format de l'arborescence semblerait compliqué, nous avons donc décidé d'agréger les données par type et de les afficher dans une liste.

En outre, des spécifications ont été élaborées pour agréger des données discrètes telles que des modèles 3D et des paramètres physiques connectés à plusieurs acteurs. Découvrez comment combiner diverses informations dans des tables LocalDB à l'aide de la fonction de jointure de table. Dans l'état actuel des choses, le format n'est pas facile à lire, c'est pourquoi des efforts ont été déployés pour faciliter les essais et les erreurs en ajoutant des vignettes à partir des noms, en affichant les noms de colonnes et en ajoutant des boutons pour sélectionner les données.

L'idée était de rendre ce mécanisme commun à tous les outils, plutôt que de l'utiliser individuellement, il a donc été complété sous la forme d'une « table de ressources » qui pourrait être produite en masse en écrivant simplement les méthodes SQL et de traitement des colonnes dans le fichier de configuration. Par rapport à la gestion manuelle des feuilles de calcul, il y a moins de soucis de fautes de frappe et il est désormais possible de se référer à tout moment à la structure du jeu dans son état le plus récent.

Innovation dans le travail sonore avec deux outils majeurs

La conférence s'est poursuivie en présentant des exemples de la manière dont LocalDB et ProjectPortal ont été réellement utilisés dans l'équipe audio.

Le travail sur la section sonore a tendance à être un processus ultérieur dans le processus de développement. Cependant, en tant que membre de l'équipe son, je souhaite être actif dans la production comme les autres sections. Pour y parvenir, une collecte d’informations précises et des flux de production efficaces sont essentiels.

Comme mentionné ci-dessus, l'outil interne "BGMEditor" utilisé par l'équipe son est un outil basé sur des données qui vous permet de définir les sons que chaque personnage émettra, comment il les émettra et quand il les émettra. Il est possible de définir des choses comme se déplacer à une certaine vitesse ou émettre un son en conjonction avec une animation.

L'important ici est que cette définition est définie uniquement sur l'outil sonore, il n'est donc pas nécessaire de modifier les données dans d'autres sections. Même en post-traitement, des ajustements peuvent être effectués autant de fois que le temps le permet.

Des travaux tels que la lecture de l'animation des personnages et la vérification du son peuvent être effectués à l'aide de cet outil. Grâce à LocalDB et SQL, les données d'animation que vous souhaitez associer au son peuvent être sélectionnées dans un format déroulant, ce qui contribue également à améliorer l'efficacité. Non seulement vous pouvez demander une liste d'anime à LocalDB, mais vous pouvez également retracer quels anime et quels sons sont associés à cet acteur simplement en écrivant du SQL.

Vous pouvez également vous référer aux connexions de données et passer directement de l'outil audio aux outils de gestion et d'édition des données d'anime. Sur l'outil d'animation, les données sont plus faciles à voir en organisant les nœuds, et même les données compliquées organisées par conditionnement peuvent être visualisées.

Cet environnement de développement facilite la gestion des problèmes qui surviennent lors de processus ultérieurs nécessitant des révisions en raison de modifications. À l’inverse, en traçant les sons à partir des données de l’anime, nous avons pu rechercher les parties à modifier, et nous avons également pu mettre en place un système qui trace le responsable, détecte les changements et le notifie. Cette possibilité de passer instantanément à chaque outil est très pratique, et comme le code source est également stocké dans LocalDB, vous pouvez même accéder à l'éditeur de code.

Comme exemple spécifique de son utilisation, un exemple de travail dans lequel des outils de contrôle d'événements et des outils sonores étaient liés dans la « Bataille de défense de la ville de Gerudo » a été présenté. Cet événement étant une scène importante du point de vue de l'histoire, le compositeur a pensé créer une production spéciale où la musique changerait en fonction de la situation de bataille.

De telles modifications interactives de la musique de fond peuvent désormais être facilement mises en œuvre à l'aide de BGMEditor. De plus, vous pouvez créer des détails encore plus détaillés, comme le moment où le timing de la performance correspond à la musique, et le moment où la musique s'arrête juste avant la fin du jeu, sans compromis.

Pour ce faire, il est nécessaire de composer de la musique tout en comprenant en détail la scène événementielle. En plus des audiences, vous pouvez également utiliser ProjectPortal pour afficher des informations sur les événements faisant référence à BGM, ainsi que des données sur les acteurs et les effets qui y sont liés. Divers nœuds ont été placés dans l'outil de gestion d'événements par le compositeur lui-même, comme la désactivation des sons des personnages hors écran dans les endroits où les sons inutiles ne voulaient pas être entendus, et la poursuite d'un montage minutieux.

"Tiakine"On dit que le nouvel environnement de développement a également été utilisé pour « Scra Build », qui est un système distinctif de « Scra Build ». Dans ce jeu, les effets sonores ont été définis comme des caractéristiques individuelles des armes elles-mêmes, mais l'équipe sonore a voulu modifier les sons pour qu'ils correspondent aux modifications apportées par la construction de Scrab.

Comme il y avait tellement de combinaisons de versions de Scrab, l'équipe sonore a réagi en établissant des règles pour modifier le son. Cependant, même si des règles sont définies, il est difficile de faire des ajustements sans comprendre l'ensemble de ce que Scrabbuild peut faire. Les données des paramètres de construction Scrab étaient très complexes.

C'est là que ProjectPortal entre en jeu. En formatant les données LocalDB dans un format facile à lire à l'aide de la fonction de table de ressources, il est devenu plus facile de vérifier les informations sur les acteurs capables d'effectuer des constructions Scrab à partir d'une vue plongeante.

La vue à vol d'oiseau de cette fonctionnalité était à l'origine utilisée par les concepteurs de jeux et les artistes pour affiner les paramètres, mais l'équipe du son a pu l'utiliser pour comprendre les spécifications. En d’autres termes, il s’agissait d’une source d’information que l’on pourrait qualifier de « document de cahier des charges » pour le personnel du post-processus.

Une situation similaire s'est produite lors du débogage du son. Il s'agit d'un cas où les effets sonores des armes ne changent pas même après une construction Scrab. Ce ne serait pas un problème s'il existait un document qui faisait intentionnellement du son un son commun, mais il semble qu'une telle chose n'existe pas. Si vous regardez l’outil sonore, vous pouvez vous référer à des règles sonores spécifiques, mais cela ne signifie pas que toute personne autre que le responsable peut utiliser l’outil librement.

Cette situation utilise également la table des ressources dans ProjectPortal. Si vous rendez les informations sur l'outil sonore plus faciles à voir, elles peuvent remplacer les spécifications plus faciles à vérifier pendant la phase de débogage. Cela aide également le responsable à comprendre les données sous un angle différent.

On peut ainsi dire que pour les collaborateurs du post-processus, les outils qu'ils utilisent au quotidien fonctionnent comme un substitut aux spécifications. Les données changeront au fur et à mesure que vous révisez et modifiez les paramètres, mais la fonction d'affichage facile à lire et adaptée à votre objectif a rendu beaucoup plus facile la compréhension des données et la recherche des erreurs.

Les résultats de ces contrôles sont réinjectés dans l’outil, augmentant encore la fiabilité des données. Les outils basés sur les données ont acquis la capacité d'être qualifiés de « spécifications mobiles » fiables. Inutile de dire que LocalDB et ProjectPortal ont été essentiels à ce mécanisme.

Antécédents et polyvalence des « spécifications mobiles »

A la fin du cours, en guise de résumé"Tiakine"Dans l'environnement de développement, l'ajout de la plateforme LocalDB au flux d'outils basés sur des composants a démontré une fois de plus que le problème de coordination entre les outils était résolu.

De plus, en visualisant les données LocalDB sur ProjectPortal, vous pouvez obtenir une image globale du jeu. Tous les outils visibles et la structure du jeu sont devenus une « spécification mobile », nous permettant de saisir l'état actuel du jeu.

Lors de la création de contenu en utilisant les informations ainsi confirmées, les spécifications de travail sont connectées via LocalDB et ProjectPortal et changent de forme. En faisant suivre à chaque membre de l'équipe ce cycle, ils peuvent toujours saisir des informations précises et créer des conceptions appropriées, conduisant à une fabrication encore plus plate.

La section sonore, qui est une partie de post-traitement, a besoin de « connaître » une grande partie de la structure du jeu. Cependant, comme le montre l'exemple présenté cette fois, nous avons pu réaliser une fabrication à plat même en post-traitement.

Cet environnement de développement est déjà utilisé dans d'autres projets. En d’autres termes, c’est aussi un environnement très polyvalent. Nous pensons que ce cas peut servir de tournant ou de nouvelle idée dans divers environnements de développement.

Précédentau prochain