Isaby est un jeu de plateforme 3D à énigmes que mon groupe et moi avons réalisés dans le cadre de notre projet de fin d’études. On y incarne une petite fille du nom de Léonie qui se retrouve plongé dans un monde onirique dans lequel elle va devoir affronter ses peurs pour retrouver son nounours.

La production du jeu a duré 6 mois (en plus de 3 mois de préproduction), où on fonctionnait selon la méthode SCRUM.

Si vous souhaitez télécharger le jeu il est disponible ici

Le moteur de jeu est : Unity 2020.1.17f1
Le langage de programmation utilisé : C#

On était une équipe de 6 et nous avions comme contrainte de faire un jeu s’inspirant d’une légende occitane. Pour notre part, nous nous sommes inspirés de la légende du lac d’Isaby.

Ce jeu cible tout type de personne aimant le genre platformer/réflexion et ayant l’habitude des mouvements dans un environnement en 3D en utilisant clavier/souris.

Sur ce projet, je me suis occupé principalement de la création et l’équilibrage des différentes mécaniques de jeu, du level design, de l’UI/UX design et de la programmation du jeu.

Pour ce qui est de la création des mécaniques de jeu, nous avons pris la décision de faire un platformer 3D, le platformer étant un genre que nous apprécions et qui nous semblait réalisable pour une équipe de 6 étudiants dans le temps imparti, puis réaliser ce jeu dans un espace en 3D nous semblait être le plus adapté à notre équipe (4 personnes de notre groupe aspirant à devenir 3D artist). Nous avons aussi voulu y rajouter des énigmes afin d’apporter de la variation dans le gameplay et permettre au joueur d’avoir des zones de jeu plus calmes, en plus de cela les énigmes ont également l’avantage de servir de ligne directrice pour le joueur et rappel aussi le côté malin du protagoniste de la légende qui terrasse le serpent sans se battre directement contre lui, mais plutôt grâce à son ingéniosité.

Pour parler plus en profondeur de la création des différentes mécaniques de jeu, on va commencer par les plus importantes : les mécaniques de déplacement du joueur (mouvement horizontal et saut)

Nous avons donc commencé par mettre en place des mouvements très linéaires avec assez peu de air control mais en le testant en interne, on s’est très vite rendu compte que ce genre de mouvement ne serait pas du tout agréable pour le joueur, donc pour ajouter de la flexibilité, nous avons décidé de rajouter au joueur un sprint, en ralentissant légèrement la vitesse de base du joueur, pour lui laisser la possibilité prendre des sauts serrés plus facilement avec la marche, mais les sauts plus longs en utilisant le sprint. Nous avons aussi ajouté un air control assez conséquent, car nous voulions laisser au joueur une grande flexibilité de trajectoire durant le saut.

Par la suite, en le faisant tester à des joueurs, ceux-ci nous ont fait remarquer que les mouvements manquaient de fluidité. Pour essayer de régler ce problème, nous nous sommes intéressés aux courbes d’accélérations (easing functions) pour les intégrer à nos mécaniques de saut.

Après quelques tests, on a remarqué que le joueur se retrouvait souvent à chuter à cause du temps d’arrêt rajouté par la courbe d’accélération, nous avons donc dû ajuster ça (pour le début du saut et l’arrêt, et également plus légèrement pour les changements de direction) pour permettre d’avoir le système de déplacement final qu’on a aujourd’hui (avec quelques petits ajustements en plus).

En ce qui concerne les attaques du serpent, nous nous sommes inspirés directement de la légende et du fait que le serpent aspirait ses victimes, nous voulions au départ donner deux attaques au serpent, une « Aspiration » et un « Crachat ».

Le crachat : le serpent lance un projectile vers le joueur lui infligeant 1 point de dégât, cette mécanique a pour but d’inciter le joueur à ne pas rester trop longtemps sur place et donc prendre plus de risques sur ses sauts.
Dans sa première version, le serpent tirait juste son projectile en direction du joueur, ce qui faisait que le projectile n’inquiétait que rarement le joueur.

Par la suite, nous avons donc ajouté de la prédiction de mouvement au projectile du serpent en fonction de la vitesse et de la direction du joueur. Également vue que la précision du serpent avait été grandement amélioré nous avons dû réduire la vitesse du projectile.

Après plusieurs tests, nous avons remarqué que le serpent était malgré tout beaucoup trop précis et touchait quasi systématiquement le joueur même lorsqu’il était en mouvement. Pour régler ce problème, nous avons donc rajouté au serpent une marge d’erreur (uniquement lorsque le joueur est en mouvement) pour laisser au joueur une plus grande liberté dans ses mouvements, nous avons également encore réduit légèrement la vitesse, mais aussi la taille du projectile afin de le rendre plus facilement esquivable.

Maintenant passons à l’aspiration :

L’aspiration avait pour but d’attirer le joueur vers le serpent pour essayer de le faire tomber de la plateforme, malheureusement après plusieurs tentatives d’équilibrage, on s’est rendu compte que cette mécanique n’était par forcément la plus pertinente pour notre jeu, la mécanique était soit très punitive et très frustrante, soit anecdotique voir complétement inutile, en plus de ça, il était compliqué au niveau animation d’avoir une différence significative pour le joueur entre les deux attaques, nous avons donc préféré l’enlever et garder uniquement le crachat. (Le GIF qui suit provient du premier prototype du jeu)

Au niveau des énigmes, nous avons testé plusieurs types de mécaniques différentes durant la phase de prototypage (un wagon à faire descendre, des objets à déplacer en les portant ou les poussant, un cristal qui nous suivrait et qu’on devrait emmener au bon endroit en lui débloquant le passage, etc), en effectuant des tests deux mécaniques sont ressortis comme étant les plus agréables en jeu, mais aussi les plus proches de la direction dans laquelle on voulait aller avec les énigmes (on voulait que le cœur de notre jeu reste le côté platformer et que les énigmes soit des sortes de phase de repos où le joueur pourrait prendre son temps sans que ça soit trop compliqué pour lui).

Les deux mécaniques qui sont ressorties de ces tests sont donc la mécanique des leviers et des rayons lumineux à déplacer avec des cristaux.

Ces deux mécaniques n’ont pas énormément changé d’un point de vue game design entre le début et la fin du développement du jeu, car elles remplissaient correctement leurs objectifs même si quelques ajustements ont été faits (au niveau des hitbox des cristaux par exemple), ce qui a été le plus ardu face à ces mécaniques était surtout le leveldesign.

Pour Le Level Design, nous avons d’abord dû mettre en place les différents objectifs qu’on voulait donner au joueur, nous donnant une ligne directrice à suivre par la suite.

Puis, nous avons fait un level design en 2D de notre jeu en fonction de ces objectifs pour avoir un plan du jeu et savoir comment mettre les différentes parties du niveau en place avant de passer à la 3D. (le tutoriel n’est pas présent sur cette image)

Une fois cela fait, nous nous sommes attaqués à la création de gabarit afin de faciliter la création des niveaux et s’assurer de garder des distances fixes entre les différents sauts. Ce qui permet de ne pas retrouver à un moment avec des valeurs de position comme 72.625145312 et de faciliter les sauts pour le joueur, car ceux-ci seront toujours à des distances rapidement reconnaissables pour lui.

Enfin avec tout ça on a pu assembler le niveau dans Unity et ajouter petit à petit les assets graphiques.

Après ça et avec les différents retours des joueurs, nous avons pu faire des modifications plus ou moins importantes sur les différentes parties du jeu, notamment cette salle par exemple (amicalement surnommée l’énigme maudite) :

Cette salle nous a pendant longtemps posé beaucoup de soucis, les joueurs avaient souvent beaucoup de mal avec cette énigme, et ce, malgré les modifications que nous y apportions, elle était toujours désagréable pour le joueur. Avec mon groupe, on s’est donc posé la question : est-ce que cette salle est vraiment pertinente ? On a essayé de revoir par rapport à nos objectifs quelles pourraient être les éventuelles solutions pour améliorer le ressenti des joueurs vis-à-vis de cette salle qui était jusque-là le gros point noir de notre level design, et finalement, on s’est dit que le souci de cette salle était peut-être tout simplement le fait de mettre une énigme à ce moment-là du jeu en lui-même. Notre jeu étant basé principalement sur le côté platformer, on avait sûrement mis un peu trop d’énigme dans le jeu (alors qu’elles n’étaient pas pensées pour être l’élément central du gameplay pour le joueur).
On a donc créé par la suite cette nouvelle salle pour remplacer « l’énigme maudite » et voir les retours des joueurs avec cette modification :

Et après les tests, la réponse était claire, cette salle fonctionnait beaucoup mieux comme ça, pour certains joueurs, c’était même ressorti comme leur parti préféré du jeu, ce qui nous a grandement conforté dans l’idée que c’était probablement la bonne solution.

Tout ceci nous a donc finalement permis d’arriver à ce niveau qui, même s’il n’est pas parfait, me rend très fier du travail que mon groupe et moi avons accompli durant ces longs mois de production.

Lien de téléchargement du jeu disponible ici