Bacharo : Comment fonctionne le changement de monde ?
Dernière mise à jour : 25 juin
Le cœur du gameplay de Bacharo repose sur le changement de monde ; le défi était donc de créer deux ambiances au sein d’un même jeu.
Quelles étaient nos premières pistes ?
Dès le début du projet, nous savions que ce changement de monde (aussi appelé switch ou permutation) serait l’un des plus grands défis. C’est pourquoi j’ai commencé très tôt à réaliser des tests.
Test 1 : Se téléporter
La première idée a été de faire fonctionner le tout sous la forme d’un TP. Nous aurions alors eu deux versions de la carte, avec des éléments de décor différents, afin de mieux matérialiser ce changement de monde.
On voit, à la fin de l’extrait ci-dessus, que ce fonctionnement n’est pas stable : le joueur se retrouvait parfois entre les deux cartes, tombant alors dans le vide.
De plus, cette technique aurait été bien trop coûteuse, aussi bien en temps de production, avec deux fois plus d’assets à créer et l’intégralité du level design à réaliser en double, qu’en ressources. Cela aurait entraîné d’importantes baisses de performances en jeu.
Test 2 : Objets impactés individuellement par la permutation
a. Alternance entre visible ou non
On voit ici que ça fonctionne, les éléments passent de visible à invisible. Cependant, il n'y avait pas de moyen de savoir quel objet est sensible au changement de monde, où il est quand on ne le voit pas, ni même de savoir dans quel monde on est.
Pour pallier ces problèmes, j'ai ajouté des particules visibles à l'emplacement des objets, ainsi qu'un post-process simple qui altère les couleurs afin de comprendre le changement. Concernant le fait de savoir si tel élément est affecté par le switch, à ce stade très précoce de test, ça n'avait pas encore été réfléchi car les objets de test sont clairement identifiables.
b. Changement de visuel
Dans cet extrait, les deux sphères change de couleur mais ne fonctionne pas pareil.
Pour expliquer plus facilement nous allons les nommées : sphereU pour la sphère a la couleur unie ; sphereT pour la sphère texturé.
En effet, sphereU possède deux materials distinct en variable. Quand on change de monde la sphereU change de material.
De son coté sphereT ne possède que un seul material, mais dans ce material se trouve deux texture relier a un Lerp (linear interpolation) et c'est l'alpha de ce Lerp qui va changé entre 0 et 1 pour afficher la bonne texture. Donc la sphereT modifie une constant1 sous forme de paramètre qui gère l'alpha du Lerp.
Ces deux versions on permet d'évaluer les pours et les contres de chaque méthodes et il est très vite apparu que devoir faire 2 materials pour chaque objet serai bien trop gourmant et contraignant.
Techniques finales
Le test 2 a constitué la base du système final mais quelques améliorations et optimisation on pu être ajouté.
Centralisation de la fonction Switch
Dans les premiers tests, la fonction de switch n'était pas optimisé. Le joueur cherchais tout les BP (blueprint) qui avait comme interface "SwitchWorld" puis pour chacun il appelait la fonction de switch. J'ai découvert durant le projet ce qu'on appel des Dispatch Event et ce fut une révélation. Pour faire simple un Dispatch Event est une forme de fonction qui, quand elle est appeler va automatiquement le faire savoir aux fonctions qui s'y attache.
Pour faire en sorte que les BP ai accès facilement au Dispatch Event, je l'ai mis sur un Blueprint spécial nommé PlayerState qui est dans les objets que l'on peut obtenir (get) juste en cherchant son nom.
Grâce a toute cette logique, je n'avais plus qu'à appeler la fonction une fois depuis le player (quand il appuie sur l'input) pour que tout les BP lancent leur fonction de switch.
Tout cela influence aussi le comportement des ennemis.
La fonction du PlayerState gère aussi le changement du PostProcess et un paramètres très important pour...
Le MasterMat
Et oui, tous les objets doivent avoir 2 textures pour changer de monde. Or gérer individuellement chaque changement de texture avec un paramètre pour chacun aurait vite était un chantier sans fin.
Heureusement la programmation orienté objet (donc ce qui est utilisé pour les jeux vidéo) possède un système de parent/enfant. En gros des sous catégorie qui possèdent les caractéristique de leurs parents tout en ayant les leurs.
Ce système très utile pour les BP fonctionne aussi pour les materials.
On peut ainsi créer ce un material qui aura la logique de Lerp (image 1) expliquer dans le test 2, mais en reliant l'alpha non pas a un simple paramètre mais plutôt a une CollectionParameter. Celle-ci peut être modifier beaucoup plus facilement via le node Set scalar parameter (image 2).
De plus les differentes textures utilisé sur le material (base color, normal, metalic, etc...) peuvent eux être transformé en paramètre. Ainsi en créant des instances de ce premier material, il n'y a plus qu'à Drag & Drop les textures (image 3).
Conclusion
C’était un défi de taille, mais nous l’avons relevé. Cela nous a tous permis de gagner en expérience et en savoir-faire.
Faire coexister ces deux mondes a entraîné de nombreuses contraintes. J’ai ici évoqué l’aspect le plus technique, mais il y a également eu toute une réflexion autour du game design — notamment pour les combats et les ennemis — ainsi que sur le level design, qui était directement impacté.
![Bacharo : des combats dynamiques [en cours d'écriture]](https://static.wixstatic.com/media/b01d65_26046be9bae04e879b19430f9d4e1552~mv2.png/v1/fill/w_980,h_612,al_c,q_90,usm_0.66_1.00_0.01,enc_avif,quality_auto/b01d65_26046be9bae04e879b19430f9d4e1552~mv2.png)
Commentaires