Le Game Kitchen sur 3 défis techniques pour réaliser La Pierre de la Folie

Plus tôt cette année, The Game Kitchen a lancé The Stone of Madness, un RPG tactique où les joueurs aident cinq détenus à s'échapper d'une prison inquisitoriale. Dans cet article invité, trois développeurs du studio partagent comment ils ont abordé les défis de rendu, d'interface utilisateur et de tests pendant le développement.

Nous sommes The Game Kitchen, et nous avons récemment sorti The Stone of Madness sur PC et consoles. Nous voulons partager certains des défis les plus pressants auxquels nous avons été confrontés lors du développement de notre dernier projet, en les abordant d'un point de vue technique avec des exemples pratiques. Dans cet article collaboratif, notre équipe de programmation décompose les solutions clés que nous avons mises en œuvre dans Unity pour optimiser à la fois les performances et l'efficacité du développement.

Tout d'abord, Adrián de la Torre (programmeur graphique) expliquera comment nous avons conçu et rendu le pipeline artistique du jeu pour atteindre son style visuel distinctif.

Ensuite, Alberto Martín (programmeur UI) expliquera comment nous avons utilisé Noesis pour rationaliser le développement de l'interface utilisateur, améliorant le flux de travail avec des améliorations UX basées sur les retours des utilisateurs.

Enfin, Raúl Martón (programmeur de gameplay) présentera comment nous avons externalisé et automatisé les tests pour des actions complexes dans le jeu sur un serveur, en veillant à ce que plusieurs cas particuliers soient gérés sans perturber l'intégration.

Rendre la folie belle Un aperçu du pipeline de rendu personnalisé

Adrián de la Torre, Programmeur Graphique, The Game Kitchen
La Pierre de la Folie combine des visuels 2D avec des mécaniques de jeu 3D, ce qui présente un défi technique unique. Bien que les joueurs voient un monde en 2D, les systèmes sous-jacents du jeu fonctionnent dans un espace tridimensionnel, créant une dualité distinctive dans son design.

Pour relever ce défi, notre équipe de développement a créé un pipeline de rendu personnalisé qui comble efficacement le fossé entre les informations de jeu 3D et la représentation visuelle 2D. Cette solution met en œuvre plusieurs passes de rendu et des techniques spécialisées pour maintenir la cohérence visuelle tout en préservant la profondeur de jeu souhaitée, permettant une traduction fluide des éléments 3D dans le style artistique 2D distinctif du jeu.

Dans La Pierre de la Folie, il y a deux scénarios principaux qui contribuent à la réalisation d'un cadre.

Le premier scénario, que nous appelons le Scénario Proxy, est composé de primitives géométriques qui calculent l'éclairage du cadre final.

Le deuxième scénario est le Scénario Canvas, qui consiste en des sprites qui correspondent à la forme et à la position de la géométrie du Proxy. Le canevas est organisé en couches pour simuler un espace 3D et obtenir un tri Z approprié avec des éléments de jeu en mouvement.

La section suivante détaille chaque étape de notre pipeline graphique pour le rendu des images.

1. Cône de vision

Chaque fois qu'un cône de vision ou une capacité de jeu est activé, cela initie la première étape du pipeline. Nous positionnons une caméra au point de vue (PoV) du PNJ pour rendre la profondeur des proxys dans son champ de vision (FoV).

Ensuite, dans une autre texture de rendu, la caméra sort un dégradé de la distance depuis l'origine du joueur dans le canal B, qui est utilisé pour les effets de zone de compétence.

En utilisant la texture de rendu PoV du PNJ, la caméra du cône de vision rend un cône sur la texture précédente dans les canaux R et G avec des informations sur les obstacles et la distance.

Le passage final rend les ondes sonores dans le canal Alpha.

Ceci est la texture finale créée à cette étape, qui sera utilisée dans l'étape de la caméra Canvas pour rendre les sprites de la scène.

2. ID de rendu de toile caméra

Chaque proxy dans notre projet a un ID de rendu associé (une valeur flottante). Le proxy et son sprite associé partagent le même ID de rendu. Dans cette étape, nous rendons la valeur flottante de l'ID de rendu dans une texture de rendu.

Dans l'étape suivante, nous utilisons cette texture pour faire correspondre les informations d'éclairage calculées dans le scénario proxy avec les sprites dans le scénario Canvas.

3. Éclairage

L'éclairage dans notre jeu se compose de :

• Éclairage cuit Lumières naturelles qui restent activées en permanence, comme l'éclairage extérieur
• Éclairage mixte Lumières statiques dans la scène qui peuvent être allumées et éteintes, comme des bougies.
• Éclairage en temps réel : Lumière qui se déplace à travers la scène et peut être activée et désactivée (nous avons implémenté cela dans une seule instance, la lampe à huile d'Alfredo)

En utilisant la texture RenderID, nous créons une texture de rendu contenant les informations d'éclairage de la scène proxy.

4. Caméra Canvas

Après avoir créé toutes les textures de rendu, une caméra commence à rendre les sprites avec des informations sur l'éclairage, les zones d'effet des compétences, les cônes de vision et les vagues de bruit.

5. Post-traitement

Le étalonnage des couleurs, le vignetage et d'autres effets sont appliqués lors d'un passage de post-traitement.

6. UI

Enfin, l'interface utilisateur est superposée.

Folie dans le HUD : Accélérer les processus de l'interface utilisateur

Alberto Martín, programmeur UI, The Game Kitchen

La version finale de The Stone of Madness comprend plus de 50 interfaces utilisateur. La raison derrière ce chiffre est que ce jeu a beaucoup de données à montrer à l'utilisateur. Notre travail sur l'interface utilisateur a été très chronophage, surtout avec la taille réduite de l'équipe au début, et nous avons donc continuellement optimisé nos processus pour nous assurer que nous obtenions de bons résultats dans les meilleurs délais.

Notre travail sur l'interface utilisateur a couvert l'ensemble du projet, il était donc important que nos designers UI/UX comprennent clairement toutes les fonctionnalités que nous devions mettre en œuvre. Pour garantir que notre jeu offrait une bonne expérience utilisateur et était amusant à jouer, nous avons veillé à maintenir une ligne de communication ouverte entre les équipes de programmation et de design.

Pour créer les meilleures versions de tous nos composants d'interface utilisateur, nous devions éliminer les silos entre nos équipes techniques et nos équipes créatives/recherche afin que tout le monde soit activement impliqué dans le développement du jeu. Voici comment nous avons abordé ce flux de travail en deux parties.

Le rôle de la recherche et de la création dans la conception de l'interface utilisateur

Nos designers UI/UX sont responsables de la définition de l'apparence des éléments de l'interface utilisateur dans le jeu final et de garantir que nous offrons une expérience utilisateur satisfaisante. Avec cela en tête, ils ont commencé par créer chaque élément avec une charge technique minimale et à le valider avec des utilisateurs potentiels. Ce processus ressemblait à ceci :

1. Exigences : Comprendre les besoins du joueur et créer une liste des besoins du jeu et des objectifs de l'utilisateur
2. Enquête Regarder d'autres jeux pour voir comment ils ont géré des problèmes similaires
3. Maquettes Travail sur les schémas et la structure (pas d'art final à ce stade)
4. Maquette À ce stade, nous montons l'interface presque entièrement conçue avec des éléments précédemment créés (boutons, défilements, cadres, etc.), ce qui nous permet d'itérer sans trop d'effort.
5. Prototype Nous construisons un prototype sur Figma en utilisant notre maquette, simulant des interactions avec des manettes et un clavier/souris pour montrer comment cela fonctionnera dans un environnement réel.
6. Test utilisateur En utilisant notre prototype précédemment créé, nous lançons un test utilisateur, validant les besoins et les objectifs que nous avons identifiés à l'étape 1.
7. Phase d'itération: Si le test utilisateur répond aux attentes, il est transmis aux processus techniques, fait plus d'itérations ou effectue d'autres tests si cela est approprié.
   

Mise en œuvre technique de l'interface utilisateur

Comme mentionné précédemment, le nombre d'éléments d'interface utilisateur dans La Pierre de la Folie est énorme. Développer un moteur d'interface utilisateur est coûteux, donc nous devions utiliser un cadre qui était facile à apprendre avec des outils et des flux de travail décents. Après avoir évalué une gamme de middleware, nous avons choisi Noesis GUI, qui suit le modèle Model-View-ViewModel (MVVM).

Nous avons choisi Noesis car il est basé sur WPF (Windows Presentation Framework) et suit le modèle MVVM de manière à ce que nous puissions réutiliser la plupart de la documentation, de la bibliographie, des entrées de forum, etc. pour résoudre la majorité des problèmes. Ce cadre existe depuis un certain temps - cela fait maintenant 18 ans depuis sa première version - et est familier à un grand nombre de développeurs d'interface utilisateur, ce qui donne à notre studio la possibilité de recruter dans un vivier de talents comparativement plus large pour mettre en œuvre des interfaces et des outils pour nos projets. Une autre chose importante à propos de Noesis est que nous pouvons utiliser les mêmes outils que ceux de WPF.

Avec XAML, notre équipe créative UI a été impliquée dans le travail de mise en page et le polissage de tous les éléments avec un minimum d'implication technique. Grâce à l'approche MVVM, nos programmeurs UI techniques ont pu se concentrer sur la fonctionnalité et apporter un soutien aux équipes créatives dans certains domaines si nécessaire.

Tests (ou comment ne pas devenir fou en créant un jeu avec un design systémique)

Raul Martón, Programmeur de gameplay, Teku Studios

Le gameplay dans La Pierre de la Folie est basé sur trois piliers fondamentaux : Compétences des joueurs, IA des PNJ et interactions de scène. Chacun de ces trois systèmes est fondamentalement interconnecté, ce qui augmente de manière exponentielle le nombre de situations que le joueur doit contrôler – et le nombre de scénarios que nous devons tester.

Dès que nous avons commencé le projet, nous avons réalisé qu'un système de QA traditionnel allait être insuffisant. Il y avait tout simplement trop de scénarios qui dépendaient de plusieurs éléments interagissant les uns avec les autres d'une manière particulière, créant une situation incontrôlée. De plus, ces situations pourraient bien se produire dans une fenêtre de temps qui est tout simplement trop petite pour qu'une équipe d'assurance qualité puisse tester confortablement.

Pour résoudre ces problèmes, nous avons créé une suite de tests automatiques. L'idée était que tous les scénarios/situations possibles qui pourraient survenir à notre équipe de développement en relation avec un système particulier pourraient être pris en compte et testés automatiquement de manière beaucoup plus efficace dans un environnement de jeu simulé.

Pour donner un exemple, l'un des personnages principaux de The Stone of Madness, Amelia Exposito, a une capacité de pickpocket. Lors de la mise en œuvre de cette compétence, nous avons lancé une série de tests pour garantir :

• Le fonctionnement de base de la compétence était correct : Lorsque vous volez à un PNJ, le mini-jeu de vol à la tire s'ouvre et le jeu se met en pause jusqu'à ce que ce soit terminé.
• Des situations moins courantes sont également couvertes : Si vous essayez de voler un PNJ pendant qu'un autre PNJ (comme un garde) vous regarde, ou si le PNJ est en train de courir, l'action est impossible.

Créer un test d'intégration

Chaque test d'intégration que nous avons créé nécessitait une configuration basée sur les exigences suivantes :

1. Une scène spécialement préparée pour créer cette situation particulière.

Pour tester la compétence de pickpocket, nous avons créé une scène avec deux gardes et un joueur. Nous avons positionné chaque personnage de manière à ce qu'ils soient tournés dans la direction nécessaire pour que la situation soit testée avec précision (rappelez-vous, le joueur ne peut pas utiliser le vol à la tire s'il est dans le champ de vision d'un garde).

De plus, la scène ne doit inclure que les composants minimaux nécessaires pour tester le scénario, car des éléments superflus peuvent ajouter du bruit à la mesure. C'est pourquoi notre scène d'exemple n'a pas de HUD, de système d'entrée manuelle, d'effets sonores, etc.

• Cette étape nécessite que la structure du jeu soit bien compartimentée, ce qui peut demander un certain effort, mais, une fois atteint, en vaut vraiment la peine ! 😉

2. Un code de test capable de forcer la situation à être testée

De nombreuses situations que nous devions tester peuvent être difficiles et longues à créer manuellement et nécessitent un déploiement de code pour être initiées.

Par exemple, si nous voulons créer un scénario de test pour garantir que nos PNJ ne marchent jamais sur des pièges à souris à moins que le PNJ ne soit en mouvement, la chaîne d'instructions serait :

1. Lancez la scène
2. Attendez une seconde
3. Faites apparaître un piège à souris sous le PNJ
4. Attendez une seconde de plus
5. Commandez au PNJ de commencer à marcher dans n'importe quelle direction.

Cette partie du projet est très sensible à tout changement pendant le développement (dépendant de facteurs tels que les spécifications du jeu qui changent et divers scénarios inattendus), il est donc essentiel que le code de test et les retours qui en résultent soient aussi clairs que possible.

Il n'y a rien de pire qu'un test qui échoue sans donner d'informations claires sur ce qui ne va pas.

3. Un moyen fiable de savoir si le scénario fonctionne comme prévu, ou si le test a détecté une erreur de logique.

Les tests automatisés nécessitent toujours une supervision. Le nombre croissant de tests avec une plus grande spécificité sur ce qui est testé peut devenir difficile à surveiller, ou les scénarios finissent par ne pas être testés suffisamment longtemps pour être statistiquement significatifs. Pour contourner ces problèmes, nous avons créé des outils personnalisés.

Par exemple, certains de nos tests impliquaient des interactions combinées entre plusieurs PNJ dans une scène. Pour surveiller correctement ces cas, nous avons créé un système pour enregistrer les différents états de l'IA par lesquels les PNJ passent pendant le test.

Nous avions également besoin d'une bonne API qui nous donnerait une visibilité sur l'état actuel du jeu (un PNJ a-t-il été mis hors de combat ? Un PNJ est-il entré dans un état de routage ? Combien de fois ? Quel personnage joueur a été capturé ? Et ainsi de suite).

4. Un système pour pouvoir lancer tous ces tests rapidement :

Contrairement aux tests unitaires, les tests automatisés doivent être effectués avec le jeu en cours d'exécution en temps réel. Cela peut rendre l'exécution de ces tests très lente.

Dans ces circonstances, nous pouvons tirer parti du fait que notre jeu n'utilise pas le système de mises à jour standard de Unity. Au lieu de cela, tous nos composants utilisent une fonction Tick(), qui simule les mises à jour de Unity mais lancées de manière contrôlée par notre moteur de jeu.

Cela nous a aidés à atteindre plusieurs objectifs différents avec nos tests :

• Tout d'abord, nous pourrions accélérer leur exécution avec une fonction de forçage qui exécute plusieurs trames de code pour chaque trame du jeu.
• Deuxièmement, parce que ces tests sont effectués en temps réel, ils sont très sensibles aux variations causées par les taux de rafraîchissement de l'ordinateur exécutant le scénario de test. En les convertissant à un taux de rafraîchissement contrôlé, nous évitons cette variance : Si un test réussit sur une machine, il réussira sur toutes les machines, et vice versa.

Et ce serait le résultat.

Comment les tests de sécurité nous aident à éviter les builds défectueux

Avec la création de cette suite de tests, nous devions également mettre en place un garde-fou qui interromprait automatiquement la fusion d'une branche si elle contenait des bogues. Pour garantir cela, nous créons un script de fusion automatique qui se lance chaque fois qu'un changement est engagé dans la branche principale du projet.

Ce script s'assure de lancer tous ces tests et de surveiller leurs résultats. Si un test échoue, il renvoie une détection d'erreur et interrompt la fusion.

Avec ce système, nous pouvons éviter des situations où un changement dans un système apparemment isolé casse d'autres mécanismes avec lesquels il interagit.

Merci à The Game Kitchen de partager ce regard en coulisses sur le développement de The Stone of Madness. Explorez plus de jeux Made With Unity sur notre page de Curateur Steam et obtenez plus d'informations pour les développeurs sur la page des Ressources de Unity.