La version Scratch « The Legend of Zelda Tierkin » a tellement de combinaisons que l'équipe de développement a abandonné ? Même si vous décidez de ne pas faire quelque chose, il existe 120 000 combinaisons [CEDEC2024]

Les intervenants étaient Hidemaro Fujibayashi et Kenichi Hirose du département de planification et de production de Nintendo Co., Ltd. M. Fujibayashi"Tiakine"Hirose a été l'ingénieur principal de l'équipe d'infrastructure de développement de jeux.

Le thème lors de la création du nouveau "Legend of Zelda" est "créer un système où des choses intéressantes se produisent".

Tout d'abord, M. Hirose a présenté le rôle de l'équipe d'infrastructure de développement de jeux. Cette équipe est responsable de la maintenance des services et de l'infrastructure utilisés lors du développement du jeu. Le terme service fait ici référence à une application Web utilisée à partir d’un navigateur.

Par exemple, l'un des services est le tableau d'affichage d'images créé par l'équipe d'infrastructure de développement de jeux de l'entreprise. Il s'agit d'un système permettant aux artistes de publier et de partager des idées d'images, et est utilisé à partir d'un navigateur Web.

L'infrastructure fait référence à l'infrastructure qui exécute des services tels que des serveurs. Le travail de l'équipe d'infrastructure de développement de jeux est de rendre le développement plus pratique et plus efficace en les diffusant au sein du projet.

Lors de la conférence, le directeur Fujibayashi, la personne à l'origine de Scrabbuild, et M. Hirose, la personne qui crée l'infrastructure de service, ont donné des explications au nom de leurs sections respectives.

"Brew Waï"L'élément apparu dans « Octa Balloons » qui permet de flotter en les attachant en est un aperçu, et a été implémenté dans le but de rendre le jeu encore plus riche. Grâce à ces expériences, il s’est rendu compte que le jeu consistant à coller des choses ensemble avait un grand potentiel.

La raison pour laquelle j’ai senti qu’il avait du potentiel était qu’il était similaire au travail précédent, mais qu’il était nouveau."La Légende de Zelda"Il y avait un thème lors du développement de ceci. Il s’agit de « créer un système dans lequel des choses intéressantes se produisent ».

En effet, l'idée était de créer de nombreux mécanismes qui provoqueraient naturellement des choses intéressantes dans le jeu, et en combinant ces mécanismes, des choses inattendues se produiraient et, à travers ces phénomènes, de nouvelles expériences seraient créées.

Par exemple, dans un monde qui introduit la physique, nous préparons un terrain vallonné, des roches rondes et des trous adaptés. Placez un rocher qui peut être poussé sur la falaise et un trou en dessous. Aussi, un rocher est placé sur la falaise où se trouve l'ennemi. Je vais également essayer de le placer sur une colline où les gens pourront voir les gens marcher.

Même si vous placez simplement les mêmes roches, divers phénomènes se produiront selon la situation. C'est le « système dans lequel des choses intéressantes se produisent » qu'ils visent depuis les travaux précédents. Si vous disposez d’un grand nombre de ces mécanismes, vous pouvez créer de nouveaux

Dans ce travail, nous avons eu l'idée d'étendre encore plus ce mécanisme, et c'est Scrabbuild. J’ai réfléchi à ce qui serait intéressant de les réunir et comment donner forme à mes idées ? M. Fujibayashi a expliqué le processus en détail.

Afin de créer un "The Legend of Zelda" plus riche et plus agréable, nous poursuivons le jeu de colle de Scrabbuild

en premier lieu"La Légende de Zelda"M. Fujibayashi dit que c'est un jeu dans lequel on raisonne, fait quelque chose et apprécie les résultats. Si vous allumez une flèche et tirez dessus, la boîte en bois qu'elle touche brûlera, et vous pouvez également couper des bûches et les faire flotter dans la rivière pour passer de l'autre côté. Faites des déductions à partir d’une situation donnée et exécutez-les. Indépendamment de ce que vous faites, si votre réponse est correcte, vous recevrez une récompense ou une avance dans le jeu. C'est"La Légende de Zelda"On dit que c'est un jeu de

"La Légende de Zelda"a une structure dans laquelle plus le processus est riche, plus il devient intéressant. Par conséquent, si vous créez un nouveau jeu, il sera plus riche et plus agréable si vous permettez aux joueurs d'utiliser leurs idées libres pour élargir la gamme de choses qu'ils peuvent faire en termes de déduction et d'exécution."La Légende de Zelda"Il a pensé que ce serait possible et a décidé d'explorer l'idée de joindre des versions Scrab.

Pour donner forme à l’idée, nous avons d’abord examiné Scrabbuild comme une capacité qui permet d’attacher quelque chose à une arme. Si vous balancez une lance dans un champ de citrouilles, les citrouilles resteront collées à la pointe, augmentant ainsi son pouvoir destructeur et vous permettant de briser des caisses en bois. Si vous portez un bouclier avec des épées attachées aux côtés gauche et droit, vous pouvez couper l'herbe sous vos pieds et autour de vous simplement en marchant. Si vous attachez une ruche à une arme, les abeilles peuvent attaquer l'ennemi.

En répétant ce type de vérification et en les reliant entre elles, vous pouvez être sûr que l’éventail de vos déductions s’élargira. Dans le même temps, la véritable nature de Scrabbuild est devenue claire. Autrement dit, « l'image représente la fonction ».

En d'autres termes, avec ScrabBuild, « l'apparence de ce que vous créez doit expliquer la fonction ». Tout comme vous pouvez imaginer que si vous attachez une pierre à un bâton en bois, vous pouvez créer une arme au pouvoir destructeur, il est important de pouvoir imaginer le résultat afin d'apprécier le processus de raisonnement, d'exécution et de résultats.

Au départ, il existait une option qui se transformerait en autre chose suite à son attachement. Cependant, avec cette spécification, il est difficile d’imaginer le résultat à l’avance, il est donc difficile de faire des déductions. Cela ne veut pas dire que l'idée d'attacher deux objets ensemble pour changer de forme et augmenter leur puissance est mauvaise, mais comme elle n'est pas adaptée pour jouer à Scrabbuild, cette spécification a été abandonnée. Il pensait que si l'image représentait symboliquement la fonction, au lieu de A + B = C, A + B = AB, alors le jeu souhaité pourrait être obtenu.

L'étape suivante consistait à augmenter le nombre d'éléments pouvant être attachés, et les idées ont continué à croître, en pensant à ce qui se passerait si trois ou quatre éléments étaient attachés ensemble, et des choses encore plus intéressantes se produiraient si davantage d'éléments pouvaient être attachés.

« Décomposer le problème » pour éliminer l'anxiété causée par le grand nombre de combinaisons dans les builds Scrab

Mais voici le problème. Cela signifie un grand nombre de combinaisons. Étant donné que des combinaisons apparemment infinies se produisent, de sombres nuages ​​s’accumulent autour de la réalisation des constructions Scrab.

• Qu’arrivera-t-il aux performances de l’arme si elle peut être attachée à quelque chose ?
• Si vous les combinez pour créer une nouvelle arme, à quoi ressemblera-t-elle et s’appellera-t-elle ?
• Quels types de sons seront ajoutés lors du balancement d'une arme ou lorsqu'un effet spécial est activé ?
• Que dois-je faire lorsque je dois vérifier un grand nombre de défauts ?

Diverses opinions ont émergé de chaque section.

En raison du grand nombre de combinaisons, un sentiment de « N'est-ce pas impossible ? » tourbillonne autour des officiels de l'équipe. Il semble qu'une situation se soit produite dans laquelle le personnel de chaque section considère vaguement le grand nombre de combinaisons comme problématique.

Cependant, M. Fujibayashi dit : « On n’y peut rien. » En premier lieu, les spécifications de construction de Scrab elles-mêmes étaient encore en phase de vérification et contenaient beaucoup d'illusions et d'imagination, ce qui les rendait moelleuses. Par conséquent, au lieu de se laisser influencer par le sentiment de « Est-ce impossible ? », il a mené une certaine tâche afin de découvrir si c'était vraiment impossible.

Il s’agit de « décomposer le problème ». Afin de clarifier les spécifications floues de Scrabbuild, nous avons classé les idées développées en espoirs et souhaits selon lesquels « ce serait bien d'avoir quelque chose comme ça » et en spécifications essentielles. Les espoirs et les désirs sont appelés une « liste de souhaits » et les spécifications essentielles sont appelées une « liste de plans ».

Voici un exemple de liste de souhaits. Constatant que le patron Bokoblin pouvait contrôler ses acolytes Bokoblin avec le son de son sifflet, il eut l'idée d'attacher un sifflet à sa propre arme et de le secouer pour émettre un son permettant de contrôler le Bokoblin. Il y a aussi l'idée que si vous attachez des ailes de Zonautear et que vous les portez sur votre dos, vous pouvez voler, et les deux étaient de bonnes directions car vous pouvez imaginer le comportement à partir des images, mais c'est un peu trop tiré par les cheveux pour spéculer. il a été ajouté à la liste de souhaits.

En ce qui concerne la liste de plans, les exemples typiques incluent des éléments tels que des images représentant des fonctions, tout ce qui peut être attaché, plusieurs matériaux pouvant être attachés et des matériaux pouvant être attachés n'importe où.

Après l'avoir classée en deux catégories, j'ai décidé de supprimer la wishlist de la liste des tâches prioritaires car ce n'était pas une exigence essentielle. Ensuite, dans la liste restante des plans, nous décomposons les problèmes qui deviennent extrêmement nombreux.

Le « nombre énorme » était un point clé dans les questions soulevées dans chaque section, nous avons donc décidé de nous concentrer sur cela dans une analyse plus approfondie. Essayez d'attacher plusieurs armes du même type, essayez de changer l'angle auquel elles se fixent, ou attachez simplement un grand nombre d'entre elles ensemble et voyez comment elles réagissent lorsqu'elles s'attachent automatiquement. De nombreux autres tests ont également été effectués, notamment le test du type A+B=C, qui modifie ce qui est attaché.

En plus des outils, ils ont également étudié s'il serait amusant d'attacher 3 ou 4 armes à la fois, mais il y avait des problèmes avec la difficulté de viser et l'impossibilité de les ranger à l'arrière, ils ont donc fabriqué 2 jeux de 2. armes attachées. Comme cette méthode était plus efficace, ils ont eu l’idée qu’il serait préférable de combiner les deux.

De plus, concernant l'idée qu'il serait amusant de pouvoir fixer des matériaux sous n'importe quel angle, lorsque nous l'avons essayé avec un coin, nous avons constaté qu'il n'existait actuellement aucune spécification telle que le coin orienté directement vers le côté, ce qui rend l'épée plus fort lorsqu'il est basculé sur le côté. Comme il n'est pas dans le film, l'angle a été ignoré car il n'avait pas de sens.

Quant aux feuilles qui peuvent créer des vents forts, la théorie était que si elles étaient attachées à une arme et balancées, le vent serait créé, et l'angle n'avait pas d'importance en termes d'image représentant la fonction. En fait, j’ai réalisé qu’il serait plus facile de tirer des conclusions à partir de l’image si les lettres étaient attachées au hasard, puis attachées directement.

Lorsque j'ai testé l'idée qu'il serait amusant de pouvoir attacher différents types d'objets ensemble, cela semblait amusant lorsque je l'imaginais, mais je ne pouvais pas imaginer quel genre de forme cela finirait par prendre. Puisqu’il n’était pas possible de déduire la fonction du produit fini, celui-ci n’était pas adapté à un usage ludique.

Nous avons également examiné si les noms représentent des fonctions. C'était très facile à comprendre, nous avons donc décidé de changer le nom d'origine pour refléter autant que possible la fonction.

Sur la base de ces résultats, Fujibayashi a déclaré : « J'ai décidé de ne pas le faire. » Le problème majeur est que nous avons décidé de ne pas « en combiner deux ou plus », de « les placer où vous le souhaitez » et de « rendre chaque nom unique ». J'ai réfléchi sur la liste du plan à ce que je ne ferais pas et j'ai mis à jour le contenu. Parmi eux, nous reconsidérons et adoptons ceux qui semblent réalisables parmi la liste de souhaits. L'idée d'ajouter des ailes au bouclier a été mise en œuvre avec un effet différent de l'original.

Une fois la liste des plans mise à jour, l'ingénieur du son a déclaré : « Si nous ne mettons pas plus de deux choses ensemble, nous pouvons faire quelque chose parce que le nombre est limité », et le concepteur sonore a répondu : « Nous ne mettons pas plus de deux choses ensemble. que deux choses ensemble », et nous avons dit : « Vous pouvez les placer où vous voulez. » Si vous ne le faites pas, vous pouvez faire quelque chose à ce sujet. » Les opinions de chaque section ont changé.

Cependant, même avec les nouvelles conditions, il restait encore 120 000 combinaisons, le problème persistait donc : ce serait une lourde tâche pour les artistes de vérifier l'apparence.

Utilisez le tableau d'affichage d'images pour réduire le coût de vérification de 120 000 combinaisons existantes

La solution consistait à utiliser l’infrastructure de développement de jeux. M. Hirose est monté sur scène ici.

Bien qu'il existe 120 000 combinaisons, ce qui est un nombre énorme, la construction de Scrab est possible si vous résolvez le problème de la vérification de l'apparence, et la vérification a montré qu'il est amusant de jouer, nous ne réduirons donc pas le nombre de combinaisons et ne ferons aucun compromis. .Pour y travailler. L'équipe d'infrastructure de développement de jeux a collaboré avec l'équipe d'assurance qualité pour introduire des efforts visant à résoudre ce problème.

Les éléments à vérifier lors de l'exécution d'une construction Scratch sont l'apparence et le nom. Lorsque vous attachez une épée et une pierre, la pierre doit être attachée à la pointe de l’épée, et non à l’épée. Quant au nom, comme l'a présenté M. Fujibayashi, il est généré selon certaines règles, mais si les règles sont insuffisantes, un problème surviendra lorsque l'apparence et le nom ne correspondent pas.

Ceux-ci doivent être confirmés par les artistes et les testeurs. À ce moment-là, si la forme de la roche change, les résultats de la combinaison due au changement de matériaux doivent également être vérifiés, par exemple si la roche s'enfonce. De plus, étant donné que les contrôles globaux sont répétés plusieurs fois à des moments importants du projet, il est important que le cycle de confirmation se déroule rapidement.

Pour confirmer, exécutez Scrabbuild et faites pivoter la caméra pour voir s'il y a des problèmes visuels, et vérifiez l'écran de la pochette pour voir si le nom ou l'image de l'icône semble étrange. Ce serait bien de le faire une seule fois, mais comme il y avait 120 000 variantes, c'était une tâche très difficile.

Si le coût de la confirmation est élevé, il faudra juger si le contenu de la révision en vaut le coût et, dans certains cas, celle-ci pourra être annulée. En conséquence, la recherche du plaisir devient impossible.

Par conséquent, afin de réduire les tracas de vérification, nous avons créé un système qui vous permet de prendre des images de Scrabbuild à l'avance et de vérifier les images déjà prises sur un navigateur Web. Cela permet de vérifier le jeu simplement en regardant l'image, sans avoir à jouer au jeu. Vous pouvez utiliser le tableau d'affichage d'images présenté au début pour organiser votre recherche et affiner votre recherche en spécifiant des conditions. En cliquant sur une image dans l'écran de liste, vous accéderez aux détails de l'image, où vous pourrez également créer une tâche pour corriger les zones d'intérêt. De plus, il dispose d'une fonction qui vous permet de générer du matériel sur le jeu à partir d'un tableau d'affichage d'images en un seul clic.

La date de prise de vue est enregistrée dans l'historique, donc si un problème survient, vous pouvez voir d'un coup d'œil quand il a commencé. Le numéro de build au moment de la prise de vue est également affiché, ce qui facilite l'identification de la cause. Lorsqu’un problème est découvert, il est difficile de déterminer quand il a commencé. Pouvoir éliminer ce problème a donc été un énorme soulagement.

Cette fonction de tableau d'affichage d'images a réduit le coût de vérification de Scrabbuild et a fait des 120 000 questions de contrôle un fardeau réaliste. Ce tableau d'affichage d'images est devenu populaire au sein du projet et est également utilisé pour vérifier le comportement du blindage et le balancement du vent.

Utilisez le tableau d'affichage Rupee pour créer une culture d'équipe

Ensuite, M. Fujibayashi est remonté sur scène. Il semble que la création des spécifications de construction Scrab qui ont été introduites précédemment nécessitait des préparations telles que « former une culture d'équipe ». Afin de mettre en œuvre Scrab Build, les membres de l'équipe doivent avoir une compréhension commune des objectifs de Scrab Build, en se concentrant sur la liste de plans. « Créer une culture d'équipe » implique la création de règles et d'une compréhension commune de ce qui est acceptable et de ce qui est inacceptable, pour ainsi dire, et la création d'un dictionnaire commun.

Le tableau d'affichage créé par l'équipe d'infrastructure de développement de jeux aurait contribué à cela. Avant cette explication,"Tiakine"Présentation du flux de production. Nous avons expliqué les nouvelles spécifications et les avons mises en œuvre une fois que les membres les ont comprises. À chaque étape, tous les membres jouent et collectent des informations, qui sont ensuite examinées par les membres clés. Les points d'amélioration sont partagés avec les adhérents, et le même flux de production est refait.

La formation d'une culture d'équipe était nécessaire pour poursuivre en douceur ce cycle de développement, et en particulier, un jeu de kilométrage efficace, une agrégation des informations et un examen minutieux étaient nécessaires. C’est là que le système de babillard électronique s’est avéré utile. La règle est que les membres publient ce qu'ils ressentent en jouant à Mile en temps réel, et que les autres membres gardent également un œil sur le tableau d'affichage pendant qu'ils jouent.

En plus du numéro de série et du champ d'affiche, les publications ont un champ d'impression où vous pouvez sélectionner ce que vous avez aimé ou ce qui vous intéresse, un champ de commentaire où vous pouvez écrire des commentaires spécifiques, un bouton "Je vois" avec lequel les membres qui sont d'accord le contenu du message peut être pressé, et un lecteur. Il y a une colonne de politique qui affiche les résultats de l'examen, et une colonne d'examen où les producteurs, les réalisateurs et les dirigeants de chaque section se rassemblent et notent les détails qui ont été examinés. Le nombre de « Oui » est"La Légende de Zelda"Le nom du babillard est devenu Rupee Bulletin Board car il est affiché dans la monnaie locale « Roupie ».

M. Fujibayashi dit que la section de révision a été particulièrement utile. Étant donné que tous les membres de l’équipe peuvent confirmer directement comment une conclusion a été tirée concernant un sujet publié, celle-ci est très transparente et convaincante, et les informations sont partagées avec précision sans se transformer en jeu de messages. Il semble qu’ils aient réussi à les faire pénétrer.

　Cependant, comme il s'agit d'un tableau d'affichage sur lequel des commentaires peuvent être publiés, il existe un risque qu'en cas de mauvaise utilisation, des problèmes surviennent qui entravent la progression du développement. Pour cette raison, il a établi trois règles majeures lors de l'utilisation des tableaux d'affichage : écrivez des « informations » plutôt que des « opinions », ajoutez plus d'informations si votre compréhension change et « évitez les discussions ».

La règle la plus importante est d’écrire des « informations » plutôt que des « opinions ». Un message qui dit : "J'ai été touché par une épine et le jeu est terminé. C'est déraisonnable" est une opinion. Le message `` J'ai pensé que ce n'était pas raisonnable d'être touché par une épine et de terminer la partie. La raison est que je pouvais voir l'épine de la droite, mais je ne pouvais pas voir l'épine de la gauche, donc c'était une surprise L'attaque est une information. La différence entre les deux est de savoir s’il existe des informations et s’il existe des pistes d’amélioration.

Ensuite, j'ajouterai des notes si ma compréhension change. Si vous pensez que « j'ai trouvé cela difficile lorsque j'ai joué pour la première fois, mais au fur et à mesure que je continuais à jouer, je m'y suis habitué et j'ai apprécié », notez le changement dans votre perception. Ce faisant, il a été dit qu'il était utile pour les concepteurs de jeux d'ajuster le niveau de difficulté et les niveaux de conception.

Enfin, la discussion porte sur ce qu’il ne faut pas faire. Sur le babillard, j'ai pu commenter les messages d'autres personnes, mais je n'y ai eu aucune discussion, et si j'avais des informations selon lesquelles je ressentais différemment le même événement, je les publierais séparément. Cela ne veut pas dire que la discussion n’est pas une bonne idée, mais qu’il serait préférable de publier de nouvelles informations si vous avez quelque chose à penser, ce qui contribuerait à favoriser une meilleure culture d’équipe.

M. Fujibayashi a expliqué qu'en mettant en œuvre ces règles, le tableau d'affichage collectait des informations uniquement pour rendre le jeu plus intéressant et devenait un outil rendant le cycle de développement plus efficace.

Implémenter un mécanisme permettant aux développeurs d'inventer librement de nouvelles idées pour un développement de jeux plus efficace

L'équipe d'infrastructure de développement de M. Hirose a également effectué des préparatifs. Nous mettons en œuvre des initiatives pour soutenir des services tels que le tableau d'affichage d'images et le tableau d'affichage en roupies qui ont été introduits jusqu'à présent.

Dans le développement de jeux, il existe de nombreux problèmes, problèmes et nouvelles choses que vous souhaitez essayer. Nous aimerions résoudre ce problème de plus en plus pour le rendre plus pratique et efficace, mais il y a des limites à ce que nous pouvons faire pour le résoudre directement. Par conséquent, l'équipe d'infrastructure de développement a réagi en créant un système qui permet aux développeurs d'inventer librement de nouvelles idées afin que les joueurs puissent profiter du jeu avec leurs propres idées.

Un exemple de ceci a été présenté comme un mécanisme de « collecte/analyse de données ». Il a été implémenté en réponse aux demandes des ingénieurs qui souhaitaient analyser le contenu des bogues, et en publiant les informations sur les erreurs provenant des machines de développement, les utilisateurs peuvent désormais voir une liste des bogues fréquents.

Parce que le mécanisme de « collecte/analyse de données » peut stocker un large éventail de données, et pas seulement des informations sur les erreurs, diverses personnes chargées de son utilisation ont inventé de nouvelles façons de l'utiliser, et d'autres utilisations ont été successivement créées.

De plus, il est important que les services utilisant ce mécanisme fonctionnent de manière stable, donc même si plusieurs serveurs tombent en panne, ils continueront à fonctionner sans aucun problème, et même si le nombre de membres de développement augmente et la charge augmente, le nombre de serveurs sera automatiquement Nous créons un environnement qui améliore les performances.

M. Hirose estime qu'il est extrêmement difficile de créer quelque chose d'utile pour un projet. Cela pourrait conduire à une orientation et à des spécifications complaisantes, il est donc important de les apporter sur le site le plus tôt possible et d'y travailler tout en recevant des commentaires.

Le système cloud de la machine de développement a été introduit en tant que service qui s'est développé au sein du projet. Le système vous permet d'utiliser immédiatement celui dont vous avez besoin à partir des machines de développement pré-préparées, et en même temps, un environnement PC CI est également préparé pour contrôler les machines de développement. Ainsi, lorsqu'une machine de développement supplémentaire est nécessaire, la procédure d'utilisation peut être effectuée immédiatement. En raison de sa facilité d'utilisation, le système Development Machine Cloud a été utilisé dans un large éventail de projets au sein de Nintendo.

Après avoir été présenté jusqu'à présent, M. Fujibayashi est monté sur scène à la fin. Avec le recul, je repense au fait qu'avant que Scrabbuild ne soit terminé, le réalisateur qui a eu l'idée devait former une culture au sein de l'équipe et que l'infrastructure de développement de jeux devait préparer des services pour soutenir le développement de jeux.

Il a poursuivi : « Ce dont j'ai parlé aujourd'hui ne concerne pas tout ce qui a conduit à la création de Scrab Build, mais j'aimerais présenter les méthodes, les concepts d'infrastructure et les méthodes de fonctionnement qui ont été efficaces pour y arriver, afin que vous puissiez les appliquer. J'espère que ce dont j'ai parlé aujourd'hui vous aidera dans le développement de votre futur jeu.''Il a conclu la séance.

Précédentau prochain