``The Legend of Zelda: Tierkin'' Rien de spécial n'a été fait pour implémenter Torre Roof. Né de la fusion de l'accès aux informations de terrain, de l'automatisation de la production de terrain et d'un environnement de débogage enrichi [CEDEC2024]

La conférence a été donnée par le département de planification et de production de Nintendo."Tiakine"L'équipe de développement comprenait Takuma Oiso, responsable de l'ingénierie QA, Jun Asakura, responsable de la programmation environnementale, et Manabu Takehara, artiste principal du terrain.

Torre Roof a été réalisé grâce aux efforts combinés d'ingénieurs QA, de programmeurs environnementaux et d'artistes de terrain.

Au début, M. Oiso"Tiakine"Présentation du "Torre Roof", qui est l'un des éléments du jeu. Torre Roof a la capacité de traverser le plafond et de se déplacer vers le toit, et peut être utilisé non seulement sur des plafonds minces mais également dans des grottes.

Bien que cette capacité puisse sembler difficile à réaliser à première vue, on dit que rien de spécial n’a été fait pour développer Torre Roof. M. Oiso, ingénieur assurance qualité, M. Atsushi Asakura, programmeur environnement, et M. Takehara, artiste de terrain, travaillaient sur des objectifs différents, mais lorsqu'ils ont eu l'idée du toit Torre, ils se sont réunis pour en faire une réalité.

Au cours de la conférence, les efforts déployés par chaque groupe seront présentés tour à tour. Bien que le contenu présenté par les trois intervenants puisse sembler sans rapport avec la mise en œuvre de Tore Roof, M. Oiso déclare : « À la fin de la conférence, les trois histoires seront liées ensemble et vous pourrez en apprendre davantage sur ce qui se cache derrière. aspects des coulisses de la mise en œuvre de Tore Roof.'' À propos. M. Asakura a expliqué que le public devrait essayer de prédire lequel des trois éléments serait la clé, puis M. Asakura a immédiatement expliqué l'approche.

Voxéliser grossièrement la surface du terrain pour stocker les informations uniformément sur le terrain

M. Asakura est l'auteur de l'ouvrage précédent «La Légende de Zelda : Breath of the Wild"(ci-dessous,"Brew Wai") a développé une méthode de dessin procédural pour faire pousser de l'herbe partout dans le monde, ainsi qu'un mécanisme permettant de contrôler le climat et la météo de manière appropriée pour s'adapter aux écosystèmes de la planète. Voici quelques-uns des mécanismes et conceptions internes qui ciblent le comportement de l’ensemble du monde du jeu. M. Asakura a introduit le traitement de l'ensemble du terrain.

"Brew Waï", divers terrains tels que des plaines, des montagnes, des déserts, des océans et des forêts apparaissent. Bien que ces terrains présentent des hauts et des bas, ils peuvent être considérés comme généralement plats. Ainsi, en préparant de simples tableaux de données bidimensionnels, il a été possible de stocker des informations correspondant à chaque coordonnée du terrain dans le monde.

en fait"Brew Waï"Désormais, les données sur la distance à l’eau et la distance à la lave sont conservées sous forme de données de tableau bidimensionnel. Il contenait également des informations topographiques telles que la densité des arbres, qui augmente à mesure que l'on se rapproche de la forêt, et la distance par rapport aux routes, afin qu'elles puissent être référencées à partir des programmes du jeu, peu importe où vous vous trouviez.

Par exemple, un cas d'utilisation pour la distance à la lave. La faune apparaîtra aux coordonnées autour du joueur, mais vérifiez au préalable la distance jusqu'à la lave pour vous assurer que vous n'en êtes pas trop près. Empêche la faune de se reproduire à proximité immédiate de la lave, même si le joueur s'en approche.

Il n'est pas naturel que des animaux sauvages se trouvent juste à côté de la lave, et s'ils s'approchent trop près, ils pourraient toucher la lave et allumer un feu. Ces contrôles étaient considérés comme importants pour garantir que le monde du jeu soit convaincant. De plus, les informations de terrain ont été utilisées pour déterminer les actions des ennemis et des PNJ, ainsi que pour sélectionner les sons environnementaux.

Ce travail"Tiakine"Dès le début du développement, des efforts ont été déployés pour étendre le monde verticalement, notamment en ajoutant de nombreuses îles et grottes vides. Si les îles et les grottes vides augmentent sur le terrain auparavant plat, le terrain nouvellement ajouté se croisera au niveau du sol, ce qui le rendra incompatible avec les données des tableaux bidimensionnels conventionnels, un problème surviendra dans la mesure où les informations ne pourront pas être stockées.

Au sol, il est possible d'obtenir la distance à la lave à l'aide de données de tableaux bidimensionnels. La faune a réussi à éviter la proximité de la lave, mais comme il n'y avait pas de données de table pour la grotte, il n'a pas été possible d'obtenir des informations sur la distance jusqu'à la lave, de sorte que la faune ne connaîtrait pas l'emplacement de la lave. S’il était mis en œuvre tel quel, il se comporterait différemment que sur terre, par exemple en apparaissant juste à côté de la lave.

Pour résoudre ce problème, il peut être nécessaire de permettre la détection de la lave par raycasting depuis le point d'apparition prévu vers le terrain environnant, ou de préparer un tableau 2D supplémentaire de données pour la grotte.

Quoi qu’il en soit, cela signifie qu’il est désormais nécessaire de mettre en œuvre une implantation spécifique à la grotte et séparée du sol. Cela pourrait fonctionner s’il ne s’agissait que d’une simple grotte, mais étant donné qu’il est également possible de créer une grotte complexe, il n’était pas sûr du nombre de couches de données de table réellement nécessaires.

L’augmentation du nombre d’implémentations dédiées dans cet état tend à devenir un terrain fertile pour les bugs et les incohérences comportementales. Pour résoudre ce problème, il faut envisager d'imposer des limites aux spécifications. Afin de pouvoir créer librement des grottes et des îles célestes, nous avions besoin d'une méthode capable de stocker les informations de manière uniforme sur le sol, dans les grottes et dans les îles célestes, sans avoir besoin d'une implémentation dédiée.

Par conséquent, j'ai pensé que le problème pourrait être résolu en abolissant l'utilisation de données de table bidimensionnelles, en rendant la surface du terrain rugueuse et en la convertissant en voxels, et en permettant de stocker des données dans ces voxels. En effet, en vous référant aux voxels à vos pieds, vous pouvez obtenir des informations de terrain n'importe où, permettant ainsi de mettre en œuvre des comportements.

Notez que lorsqu'un terrain en croise un autre, le problème se pose de savoir comment créer une structure de voxel sur la surface du terrain. M. Asakura dit que vouloir stocker des données sur la surface du terrain signifie : « Je veux stocker des données sur la surface que le joueur peut atteindre. » Afin d'identifier la surface du sol, il est nécessaire de simuler le mouvement du joueur et de tracer en permanence la surface du sol.

Nous avons donc décidé d'étudier la surface du sol que le joueur pourrait atteindre en tirant des raycasts à intervalles réguliers sur le terrain. De cette manière, même sur des terrains comportant des passages supérieurs tels que des grottes, les points de la surface du sol que le joueur peut atteindre sont couverts à intervalles réguliers. Étant donné que les points générés sur la surface du sol sont déjà disposés à intervalles réguliers, ils peuvent être traités tels quels comme des positions de voxels.

Lorsqu'il est appliqué aux données de collision réelles, il est possible de couvrir uniquement les coordonnées de la surface du sol que le joueur peut atteindre à intervalles réguliers, et en remplaçant ces coordonnées par des voxels, les coordonnées de la surface du sol que le joueur peut atteindre sont couvertes. Le voxel est terminé.

De cette manière, il a été constaté qu’il était possible de générer une structure voxel du terrain, mais ces données sont nécessaires pour le terrain du monde entier. La conversion du terrain du monde entier en voxels signifie qu'il est nécessaire de lancer une grande quantité de raycasts sur le terrain du monde entier.

Cela nécessite une énorme quantité de calculs. J'ai pensé qu'il serait possible d'effectuer des calculs à grande vitesse à l'aide de Houdini, un outil TCC puissant en traitement géométrique (traitement qui convertit des coordonnées tridimensionnelles en coordonnées sur un plan bidimensionnel), et j'ai décidé de travailler sur un une mise en œuvre spécifique l’a fait.

Il existe différents types de collisions dans le jeu. Importez toutes ces informations de lecture et informations sur les attributs du matériau dans Houdini. Ils ont également importé les données de placement d'un éditeur de niveau interne et créé des collisions de terrain dans Houdini qui étaient équivalentes au terrain du jeu.

Les calculs de raycast de Houdini étaient suffisamment rapides pour que ces opérations soient effectuées chaque nuit sur des terrains partout dans le monde. Nous avons pu continuer à mettre à jour les voxels en réponse à l'évolution quotidienne du terrain. Il fallait également préparer des données pour stocker les voxels générés, mais comme Houdini importait également les informations matérielles du terrain, il était possible de les calculer directement dans Houdini.

En utilisant largement Houdini, nous avons pu créer des informations voxels pouvant être référencées en intégrant des données dans la topographie du monde entier. En conséquence, la même implémentation peut être effectuée pour les grottes, les îles célestes et les mondes souterrains. Que ce soit à l’extérieur, à l’intérieur d’une grotte, au plafond d’une grotte ou à la limite entre une grotte et l’extérieur, la mise en œuvre cohérente d’un simple référencement des voxels environnants permet de traiter de manière transparente toutes les situations.

Il n'est pas nécessaire de se référer à des données spéciales simplement parce qu'il s'agit d'une grotte, et il n'y a pas lieu de s'inquiéter des incohérences de comportement dues aux différences de mise en œuvre. Les bugs sont moins susceptibles de se produire et il n'y a plus de limitations de spécifications. Ces informations voxels sont désormais utilisées dans diverses situations et permettent d'éviter des incohérences comportementales. Des exemples de son utilisation ont également été présentés.

Éliminer le fossé en termes d'informations et d'outils entre les développeurs et les testeurs pour des « jeux amusants et sans bugs »

Ensuite, j'ai passé le relais à M. Oiso de QA Engineering.

Vous pourriez penser que les ingénieurs QA visent un jeu sans bug. Cependant, si vous vous fixez comme objectif final un jeu sans bugs, vous aurez tendance à penser que l'élimination des bugs est primordiale, et pendant le développement vous vous retrouverez avec le mauvais sentiment de dire : « Je veux que cet élément soit supprimé parce que il y aura certainement des bugs et ce sera pénible. » « J'ai l'impression que cela va finir par arriver », a déclaré Oiso. Il a poursuivi en soulignant que si vous freinez les éléments susceptibles de contenir de nombreux bugs, "vous risquez de vous retrouver avec un jeu qui ne présente aucun bug, mais dont les éléments intéressants sont également supprimés".

Lorsque M. Oiso est revenu à ses bases et s'est demandé ce qu'il devait réellement viser, il s'est rendu compte que ce qu'il visait était « un jeu amusant et sans bugs ». Pour y parvenir, il a pensé qu’il était important non seulement de se concentrer sur l’absence de bugs, mais aussi de rendre le jeu intéressant.

C’est pourquoi il a dressé un résumé de la façon dont les jeux en cours de développement peuvent devenir plus intéressants. Le cycle de production et de confirmation est important dans la production de jeux. Créez et testez des idées de jeux amusants. Au fur et à mesure que vous répétez cela, le jeu devient plus intéressant. Il en va de même pour les bugs. Vérifiez s'il y a des bugs, recherchez la cause, corrigez-le et vérifiez à nouveau. En répétant ce processus, les bugs disparaîtront progressivement.

En d'autres termes, un « jeu amusant et sans bug » est composé des deux cycles mentionnés ci-dessus qui se produisent plusieurs fois. J’ai donc décidé de rendre le processus de production et de confirmation plus efficace afin que ce cycle puisse être répété plus souvent. La fonction de débogage rend cela possible.

Bien que la fonction de débogage soit appelée débogage, elle est utilisée à d’autres fins que la recherche de la cause d’un bug. Il est utilisé tout au long du processus de production et de vérification, comme les essais et erreurs des développeurs, la vérification de la réponse via le gameplay et l'amélioration du plaisir.

L'amélioration des fonctions de débogage peut être considérée comme un effort non seulement pour se concentrer sur le petit nombre de bugs, mais aussi pour rendre le jeu plus amusant. Il serait préférable de disposer d'une fonction aussi pratique dès le début, c'est pourquoi ils ont décidé d'y travailler dès les premiers stades de développement.

S'il y a de nombreux membres impliqués dans le développement, même si vous pensez : « Qui a mis cet objet là ? J'ai quelque chose dont j'aimerais discuter... » il peut être difficile de savoir qui contacter. Si vous pouvez vérifier les informations de placement à l'aide de la fonction de débogage, vous pouvez rapidement savoir qui est en charge de l'objet et également déterminer s'il a été ajouté dans ce jeu ou s'il existait dans le jeu précédent.

De plus, une fonction a été implémentée qui vous permet de vous déplacer facilement vers un emplacement spécifié en copiant les informations d'emplacement à l'aide de la fonction de débogage et en collant les informations d'emplacement sur le wiki ou la tâche de développement. Cela réduit le temps perdu, comme par exemple à chercher des endroits que vous souhaitez vérifier, et vous permet de passer plus de temps à réfléchir à vos projets. Il semble qu'il ait utilisé le bouton de distorsion plusieurs fois.

Il existe également une fonction de débogage qui peut être utilisée pour les tâches que vous pouvez effectuer vous-même. . Par exemple"Tiakine"« Ultra Hand » est un jeu dans lequel vous créez des choses en assemblant des objets dans le jeu. Lorsque vous voulez un autre pneu, cliquez dessus dans le jeu et l'outil PC sélectionnera cet objet, vous permettant de le créer dans le jeu avec un seul bouton. Puisque tout peut être généré, les essais et erreurs deviennent encore plus rapides. De plus, ils ont créé des fonctions qui vous permettent de vous déplacer vers l'emplacement du PNJ à partir de la liste des PNJ et d'obtenir des armes à partir de la liste d'objets.

M. Oiso a estimé que les fonctions de débogage amélioraient l'efficacité et souhaitait que les testeurs utilisent également ces fonctions. Cependant, les testeurs ont un accès limité à des informations et à des outils limités. Estimant que cela ne serait pas suffisamment efficace, j'ai décidé de créer un nouveau thème en tant qu'ingénieur QA : "Briser le fossé entre développeurs et testeurs".

Premièrement, afin d'éliminer le manque d'information, nous avons décidé de faire participer les développeurs au processus de communication avec la même autorité que les développeurs. À partir du journal de développement, vous pouvez obtenir diverses informations sur le jeu, y compris les idées de jeu du développeur.

L'outil de chat invite les testeurs à discuter avec d'autres développeurs. L'outil de gestion des tâches a également été rendu public et tout a été partagé sur ce que l'équipe de développement avait accompli, sur quoi elle travaillait actuellement et ce qu'elle envisageait de créer à l'avenir. Nous leur avons également demandé de participer à des réunions entre développeurs. Des efforts ont également été faits pour éliminer les disparités dans les outils, réduire les bugs et rendre le jeu encore plus amusant.

La superficie au sol est 2,5 fois supérieure à celle du jeu précédent et il y a plus de 200 grottes. Mise en place d'un « système de grottes » pour maintenir la qualité et améliorer l'efficacité

Ensuite, M. Takehara est monté sur scène. Dans le jeu précédent, il était responsable de la conception de la structure, supervisant et produisant tous les bâtiments du jeu, et dans ce jeu, il est en charge du responsable du terrain, supervisant l'art global du terrain. M. Takehara a déclaré qu'à grande échelle"Tiakine"Il a expliqué comment la topographie de la zone avait été rendue plus efficace.

Parlons d’abord de la qualité et de l’efficacité des produits. Il est de la responsabilité de l'artiste de rationaliser le travail de création de données, d'imaginer des expressions artistiques basées sur le jeu, ainsi que d'expérimenter et de confirmer à quoi elles ressembleront finalement dans le jeu. M. Takehara dit qu'il s'agit d'un travail important qui ne doit pas être supprimé. avec.

D’un autre côté, des choses aussi importantes demandent du temps et des efforts. Une main d’œuvre importante directement liée à la qualité ne doit pas être éliminée, mais selon la façon dont l’efficacité est améliorée, elle peut avoir un impact négatif sur la qualité du produit. L'objectif de M. Takehara était d'améliorer l'efficacité sans éliminer ce travail important.

"Tiakine"Afin d'offrir une nouvelle expérience de jeu aux utilisateurs, les spécifications et la quantité du jeu ont augmenté par rapport aux travaux précédents. Il était nécessaire de créer une nouvelle expérience de jeu, mais la surface au sol est 2,5 fois supérieure à celle du jeu précédent, ce qui rend assez difficile la création de cette logistique. De nouveaux outils et flux de production sont nécessaires pour créer un système permettant de traiter de grandes quantités de matériaux, y compris un contrôle qualité.

D'ici"Tiakine"Parmi les éléments complémentaires, il a cité la réalisation de grottes, remarquable par son efficacité. Il existe plus de 200 grottes dans le monde d’Hyrule, et chacune d’elles est associée à une variété d’activités. Créez les données, mettez-les dans la construction et enfin jouez. Considérez-le, créez-le et expérimentez-le vous-même. Si l'expérience n'est pas bonne, je reconsidérerai. Répéter ce type de cycle de production de jeux plus souvent est également important pour rendre les jeux plus intéressants.

Afin de répéter ce cycle autant de fois que possible, nous voulons automatiser des choses qui peuvent l'être, mais si nous procédons à l'aveuglette, nous risquons de perdre quelque chose d'important pour le jeu. Par conséquent, nous avons réfléchi au travail qui devrait être effectué manuellement sans automatisation.

Tout d’abord, travaillez le level design pour créer du jeu. C'est un élément essentiel de l'expérience de jeu, il est donc naturel que cela soit fait à la main. Vient ensuite le travail de placement des actifs, tels que le placement des matériaux et des bases ennemies, conformément à la conception des niveaux. En plus de cela, la prise en compte et le contrôle de l’art lié aux grottes ont été évoqués.

De plus, certains éléments artistiques du jeu sont étroitement liés au jeu et affectent le côté ludique. L'artiste doit donc contrôler la considération afin que l'apparence n'interfère pas avec le jeu.

Sur la base de ce qui précède, seules les parties artistiques qui ne sont pas liées au jeu peuvent être automatisées. Sur cette base, nous avons discuté à plusieurs reprises avec les programmeurs de la solution optimale pour le flux de travail des grottes et, par conséquent, un « système de grottes » a été construit.

Dans le système de grottes, des images contrôlées par l'artiste sont générées à l'aide d'une modélisation procédurale sur des zones qui n'affectent pas le level design ou des zones décoratives qui ne sont pas liées au jeu, sur le terrain qui a été conçu manuellement. Il est possible de générer non seulement des grottes mais également des formes ressemblant à des îles, et peut couvrir un large éventail de tâches allant de la conception de niveaux au travail manuel. Il semble que l’apparence de ce système de grottes ait radicalement modifié le flux de création du terrain.

Dans le flux de travail précédent, une fois l'étude et la mise en œuvre du jeu (level design) terminées, la planification et la mise en œuvre des images (dessin manuel) commençaient, et une fois terminées, le produit était créé. Le jeu et le travail de création d’images s’influencent fortement l’un l’autre, et si le jeu n’est pas déterminé, la création d’images ne peut pas avoir lieu. Une fois le travail passé au stade du dessin, il était difficile de modifier le jeu et de suivre le cycle de production du jeu.

Dans le nouveau flux de travail qui a introduit le système de grottes, HAD a été créé dans Houdini pour ajouter automatiquement des détails basés sur les dessins prototypes réalisés avec le système de grottes lors de l'examen et de la mise en œuvre de la pièce et des dessins. Ces deux tâches sont effectuées simultanément et des détails sont ajoutés à l'aide d'une modélisation procédurale basée sur celles-ci pour créer un produit.

En étant capable de travailler en parallèle sur le jeu et la création d'images sans être influencé par l'avancement du travail de chacun, j'ai pu augmenter la vitesse du cycle de production du jeu, ce qui était mon objectif. À partir de là, le système de grottes a été utilisé dans d’autres productions de terrain et est devenu un outil rentable.

Grâce à ces étapes, nous avons pu parcourir de nombreux cycles de création de terrain, ce qui a créé plus de variété dans le jeu dans les grottes et a ainsi enrichi l'expérience de jeu. La modélisation procédurale a permis aux artistes de contrôler le processus de production et de créer une grande variété d'images de qualité produit en peu de temps, le rendant plus efficace tout en préservant les éléments importants initialement prévus.

Il existe une autre tâche importante dans le travail sur place d'un artiste. Il s'agit d'un travail de débogage du terrain qui affecte la qualité du produit. Étant donné que l'échelle est plus grande que celle des travaux précédents, nous souhaitons rationaliser le débogage du terrain, qui a été effectué à l'aide de tactiques maritimes humaines dans les travaux précédents. Le processus d’inspection visuelle humaine ne pouvant être éliminé, le défi consistait à le rendre plus efficace.

Dans tout Hyrule, il y a environ 1000 Korogs qui vous donneront des objets utiles pour votre voyage si vous leur demandez une faveur. Il est difficile de déboguer Corolog à chaque fois que les spécifications ou le terrain changent, j'ai donc eu l'idée de l'automatiser lors de la construction d'un système de grottes, mais la confirmation visuelle par les humains est toujours importante.

Nous avons donc étudié les causes de l’augmentation des coûts de confirmation. En conséquence, le temps nécessaire pour se rendre à l’endroit où se trouvent Korok et ses amis est devenu un problème majeur. C'est une lutte constante pour se perdre même dans des endroits auxquels je suis habitué, ou quand je pense l'avoir trouvé, il s'avère que c'est un Korok différent. Quoi qu'il en soit, afin de réduire le nombre d'étapes nécessaires pour me rendre sur place, j'ai décidé de rationaliser les opérations qui me paraissaient pénibles.

À cette fin, nous avons demandé la production d'un "système de tir automatique Korogu" qui tirerait parti de la fonction de tir sur laquelle l'équipe d'infrastructure de développement du jeu avait travaillé et prendrait automatiquement des photos des endroits où se trouvent Korogu. Il existe également un bouton d'accès qui vous permet d'accéder simultanément à n'importe quel endroit de l'écran, et vous pouvez utiliser les captures d'écran prises avec le système de prise de vue automatique Corolog pour effectuer de petites vérifications quotidiennes, et enfin utiliser le bouton d'accès pour vérifier sur place. . De cette manière, l’efficacité a été améliorée sans éliminer le besoin de vérification humaine.

Lors du travail de débogage à la fin du projet, il a été nécessaire d'effectuer une « vérification complète » pour confirmer que tous les actifs placés dans le monde d'Hyrule étaient dans le bon état. Leur nombre est d'environ 160 000. Si ces contrôles sont effectués de manière désordonnée, une catastrophe se produira. C’est là que l’efficacité entre en jeu.

C'est ici qu'est né un outil pour les aider, le « Total Check Tool ». Les outils sur le PC et l'écran de jeu sont liés et vous pouvez vérifier la zone tout en utilisant la version, ce qui en fait un outil facile à utiliser même pour les artistes qui vérifient habituellement à l'aide de la version. Même si le travail de confirmation visuelle demeure, cet outil a permis d'effectuer des contrôles systématiques et précis, ce qui autrement aurait été une tâche fastidieuse.

Il est également important de vérifier les trous de collision avec le terrain qui pourraient perturber l'expérience de jeu, par exemple en permettant aux joueurs de passer derrière le terrain. Cependant, comme le terrain est structuré par le placement des actifs, certains trous sont créés involontairement et il est très difficile de les trouver. De plus, l'échelle du terrain est 2,5 fois supérieure à celle du jeu précédent, il y a donc une limite à ce que vous pouvez rechercher en utilisant les tactiques maritimes humaines.

Nous avons donc développé un outil pour trouver des trous. L'outil de recherche de trous peut identifier grossièrement les trous grands et dangereux dans lesquels le joueur pourrait tomber, ce qui interférerait avec l'expérience de jeu, et les petits trous qui n'interféreraient pas avec l'expérience de jeu. Puisqu'il s'agissait également d'un outil de sélection des utilisateurs, les trous qui n'interféraient pas avec l'expérience de jeu ne faisaient pas l'objet de corrections afin d'être rentables. En conséquence, les grands trous dans les collisions de terrain ont été éliminés par l'outil de recherche de trous.

Grâce aux efforts de trois parties, le toit de la Torre a été réalisé avec une douceur surprenante.

Jusqu’à présent, nous avons présenté les initiatives entreprises par chaque entreprise, mais comment celles-ci ont-elles conduit à la mise en œuvre de Torre Roof ? Avant d'expliquer cela, M. Oiso présente l'histoire de la naissance de Torre Roof.

Lorsque j'ai pu jouer dans une grotte pendant le développement, je voulais explorer activement la grotte pendant le jeu de test pour voir ce que je ressentais, mais j'ai trouvé fastidieux de devoir revenir en arrière pour explorer la grotte. Même lorsqu’il a découvert une grotte, il a commencé à hésiter à l’explorer et n’a pas pu s’amuser comme il l’espérait.

C'est là que la fonctionnalité de débogage entre à nouveau. En production normale, j'étais capable de me déplacer librement en utilisant la fonction de débogage, j'ai donc pensé qu'il serait possible d'utiliser la fonction de débogage en revenant de la grotte pour me déplacer librement et m'échapper facilement. Ensuite, nous avons décidé de l'implémenter dans le jeu.

Nous avons donc interrogé M. Asakura, un programmeur environnemental, sur la mise en œuvre. Lorsque l'idée lui est venue, M. Asakura a pensé que la partie la plus difficile était de déterminer où apparaîtrait le toit une fois le toit installé. Où se trouve le sol que le joueur peut atteindre après avoir traversé le plafond ? Est-ce que ça existe au moins ? En effet, il est nécessaire de pouvoir le déterminer à l'avance, quel que soit le terrain.

Cependant, comme il avait entendu parler du concept d'un étage que les joueurs pouvaient atteindre, il a immédiatement pensé qu'il pourrait utiliser les informations voxels. Puisque le voxel couvre la surface du sol que le joueur peut atteindre, il inclut également toutes les informations sur le sol accessible qui apparaissent après la toiture. Avec cela, il semblait que le problème difficile de trouver le point d'apparition après Tore Roof pouvait être résolu simplement en examinant les informations du voxel au-dessus du joueur.

Cependant, pour utiliser Tore Roof, des informations de voxel d’assez haute précision sont nécessaires. De petits trous de collision dans le terrain permettront aux raycasts de sonder la surface et de pénétrer à travers eux, même si l'espace est trop petit pour que le joueur puisse passer.

En conséquence, des voxels sont générés même sur la surface de collision restée derrière le terrain. C'est un endroit que les joueurs ne devraient pas pouvoir atteindre. Si Torreroof continue tel quel, le jeu échouera, donc Torreroof ne pourra pas être réalisé à moins que même les petits trous de collision, qui normalement ne conduisent pas à des bugs, ne soient éradiqués partout dans le monde.

En parlant de remplissage de trous, les artistes de terrain ont l'habitude de combler des trous lors de collisions de terrain à l'aide de l'outil Rechercher des trous. Les artistes de terrain peuvent combler les trous, mais les trous que Torreroof veut combler sont de petits trous qui n'auraient pas interféré avec l'expérience de jeu, et que nous avons décidé de ne pas corriger dans ce travail. S’il y a des milliers de trous, il sera difficile de les identifier.

Nous avons besoin de gens pour combler ce petit trou. En parlant de ressources humaines, M. Oiso s'est efforcé d'éliminer l'écart entre les testeurs et les testeurs. Le manque d'informations a été éliminé et les testeurs connaissaient bien le jeu, ses spécifications et les collisions avec le terrain. Il n'y aura aucun écart entre les outils et les testeurs pourront utiliser Houdini pour les aider à trouver des trous.

Il y a trois étapes principales pour combler le trou. La première étape consiste à détecter les trous. Ceci est automatisé avec un outil de recherche de trous capable de détecter l'emplacement approximatif du trou. La deuxième étape consiste à trouver les trous et à les signaler. Vous devez vous rendre sur place dans le jeu tout en regardant Houdini et découvrir l'emplacement et la situation exacts du trou. Ce processus était étonnamment difficile et a pris le plus de temps, mais nous avons pu le résoudre avec l'aide de nos testeurs.

Enfin, l'artiste a corrigé les données avec des trous. Le processus de création de rapports de recherche de trous permet aux artistes d'effectuer des corrections en douceur en fournissant toutes les informations nécessaires aux corrections, telles que la position exacte du trou, un bouton de déformation, une capture d'écran et le nom de fichier des données placées. En conséquence, le toit déchiré a été installé avec succès.

Parce que cette conférence était intitulée "Dans les coulisses de Torre Roof", "beaucoup de gens s'attendaient peut-être à une histoire directe sur Torre Roof", a déclaré Oiso. Cependant, dans les coulisses, trois personnes travaillaient sur le projet.

Le programmeur d'environnement prépare les informations de voxel pour créer des jeux tridimensionnels tels que des grottes et des mondes célestes, et met en œuvre une méthode cohérente d'accès aux informations topographiques.

Les ingénieurs QA ont amélioré les fonctions de débogage et éliminé l'écart entre les développeurs et les testeurs afin que les testeurs puissent travailler dans le même environnement que les développeurs.

Les artistes de terrain améliorent l'efficacité de la production de terrain dans son ensemble en automatisant les éléments qui peuvent l'être et en rationalisant les éléments qui nécessitent un travail manuel.

En combinant ces facteurs, « Toreroof a été réalisé avec une étonnante fluidité », se souvient M. Oiso. En outre, a-t-il analysé, "l'un des facteurs pourrait être que tous les trois étaient conscients de l'amélioration des mécanismes et des flux de travail à usage général et robustes, plutôt que d'adopter une approche spécialisée dans des spécifications de jeu spécifiques."

Précédentau prochain