14/07/2025

06. Test de lumières sur Unity

Nous avons quasiment terminé notre phase de prototypage sur Godot et nous apprêtons à passer sur Unity. Mais avant de porter le code et réellement passer à autre chose, nous avons décidé qu'il était nécessaire de voir quelle solution nous utiliserions pour gérer le Lighting du jeu, étant donné l'importance de cet apect.A l'origine nous pension utiliser Bakery pour remplacer le système de Lightmap de Unity qui nous a déjà beaucoup posé problème par le passé. Mais après plusieurs jours de test nous avons trouvé une meilleure solution.

A. Nos contraintes

Pas de GI dynamique obligatoire. Nous souhaitons utiliser des lumières précalculées comme option de base pour pouvoir proposer une expérience qui tourne bien, avec une bonne qualité d'image et sans artefacts de lumière. C'est d'ailleurs pourquoi nous avons choisi Unity et non Unreal. Lumen permet de se concentrer uniquement sur le rendu final, mais ce sont les joueurs qui en pâtissent avec de mauvaises performances et des artefacts visuels distrayants.. Une option pour du SSGI et du RTGI sera surement disponible dans le jeu a la sortie.Les environnements à illuminés peuvent être très ouverts comme très denses, s'étendant parfois jusqu'à l'horizon tout en ayant beaucoup de détails au premier plan.Nous souhaitons conserver du dynamisme dans les niveaux, donc seul l'illumination globale peut être bake et les objet dynamique devront avoir un système d'illumination convainquant peut importe leur taille.

B. Nos options

Les Lightmap de Unity sont très mauvaises et nous ont souvent posé problème. Alors la seul option viable en cas d'utilisation de lightmaps seraient Bakery. Ce plugin propose une meilleure qualité, un temps de calcul divisé par 10 et des textures deux fois plus légère. Mais nous avions également l'option de ne tout simplement pas utiliser de Lightmaps pour notre GI et passer par l'Adaptative Probe Volume introduit dans la version 6 de Unity.Et avant de réellement penser au contraintes techniques de chacune de ces options nous voulions comparer les visuels en isolation avec le reste pour être sur de ne pas exclure l'option qui nous plait le plus à cause d'aprioris. Nous avons créer un environnement pour pouvoir comparer toutes les solutions facilement (je vous conseil d'ouvrir les images a part si vous voulez les comparer plus facilement).

C. Notre choix et ses particularitées

Visuellement parlant c'est le système APV de Unity qui nous à le plus convaincu, il a un aspect bien plus doux et légers. Du coup c'étaient le moment d'approfondir les tests et se pencher sur les aspect technique:

Si Bakery est bien plus rapide et léger que le Lightmaper de Unity, le système APV est encore plus impressionnant sur ces points là. La scène ci dessus rendu avec Bakery a pris 1m30 à être calculée avec un poids de 90mo. La scène APV a quand a elle pris 10s à calculer pour un poids sur le disque de 13mo.Le système APV place soit même les probes dans l'environnement selon la proximité avec des assets et placer des volumes pour changer manuellement la qualité est bien plus simple qu'avec Bakery et les baisses de qualité sont bien moins remarquables par ce que la lumière reste appliqué pixel par pixel.L'Adaptive Probe Volume gère nativement les objets dynamiques, la ou avec Bakery il aurait fallu ajouter un autre volume ou système de probes qui auraient encore ajouter du poids au jeux.APV permet également de précalculer plusieurs scénarios de lumière et transitionner progressivement de l'un à l'autre. Rendant par exemple un cycle jour nuit possible. On aurait pu manuellement faire quelque chose de similaire avec des Lightmaps mais ça aurait été bien plus complexe.

D. tests approfondis

Nous avons déjà vu que ce système se prêtait parfaitement au scène ouvertes, mais nous devons aussi vérifier que cela se prête aux environnements plus fermés et denses. Et les premiers problèmes n'ont pas tardé à apparaitre:

Nous avons également vite découvert que le SSGI de Unity se mariait très bien avec l'APV, ou plus précisément son denoiser.

Nous tenons tout de même a préciser que la SSGI ne sera pas obligatoire a cause de son coût en performances non négligeable et que l'Adaptative Probe Volume sera calculé à une qualité suffisante pour ne pas avoir besoin du denoiser du SSGI. Le denoiser en lui même coute jusqu'à 30% de performances et la GI 10%. Les performances affiché dans les screens ne sont pas représentatives..

Et bonus pour la route, le denoiser du SSGI est même capable de denoise les horribles Lightmaps de Unity:

Après les test sur la GI en elle même, il était temps de nous attaquer à la transition entre différents scénarios de GI et essayer de simuler un cycle jour nuit:

Transitionner entre deux scenarios était bien plus simple que nous l'espérions par contre faire bouger le soleil en même temps était plus compliqué que prévu. Le rendu final nous plait beaucoup, APV correspond parfaitement à nos besoin. Une GI relativement dynamique à un coût très légers et aucun artefacts.

03/07/2025

05. Mécanique de vol

On voulait ajouter une mécanique qui permettrait d'alterner le rythme du jeu et d'ajouter à la fantaisie de jouer un ange. On a de suite pensé à permettre au joueur de voler dans certaines sections de jeu et ce sera utilisé comme un marqueur de progression du personnage dans son évolution interne.

A. Les insipirations

On souhaitait donner retranscrire la sensation de voler avec des ailes, et pas juste en flottant. Alors ça passe évidement par le sound design et les animations, mais on à d'abord réfléchir à un moyen de montrer ça par le gameplay et le fonctionnement du Griffon dans Ark Survival Evolved ou les Elytras de Mincraft nous sont vite venu en tête.Basiquement la vitesse dépend de l'inclinaison, descend en piquet permet de prendre de la vitesse et de la conserver un certain temps en remontant. Il n'y a pas de risque de perdre trop de vitesse et s'écraser, le joueur n'est pas puni si il n'arrive pas à exploiter la mécanique correctement, mais les bons joueurs seront récompensé par de la vitesse.

B. Demonstration

Nous avons vite mis en place un niveau pour montrer à quoi la mécanique ressemble en action. Ce niveau est composé de deux partie. La mécanique de vol est d'abord utilisé en complément aux déplacements classiques du jeu avant de basculer dans des déplacements exclusivement aériens.

04/06/2025

04. Modification de l'inertie

Pour accompagner l'ajout des Grapin et Jump Pad qui propulsent le joueur à haute vitesse. Nous avons du rework le fonctionnement de l'inertie.

A. Comment ça marchait

Jusque là l'inertie était fixe, avec un taux de friction qui ne changeait jamais. Ce qui rendait une mauvaise représentation du poids et delà vitesse du joueur. Après l'atterrissage le joueur perdait tout son momentum en l'espace d'un quart de second.

B. Ce qui change

Pour palier à ce soucis nous avons ajouté un regain de la friction progressif à partir de l'atterrissage. Résultat le joueur glisse plus longtemps sur le sol à l'atterrissage et peu conserver plus de vitesse plus longtemps. Ca rend les mécaniques impliquées bien plus agréable a utiliser. Mais ça peu aller beaucoup plus loin qu'une simple couche de polish de notre coté ça nous à même débloqué quelques techniques de speedrun !

20/05/2025

03. Grapin et Jump Pad

On avait besoin d'un moyen de changer efficacement le rythme du jeu pour briser la monotonie et aussi d'un moyen de parcourir de grande distances plus vite. On a de suite penser aux Grapin et Jump Pad. Les deux permette de résoudre partiellement nos problème initiaux

A. Fonctionnement générale

Pour rendre les réglages de ces factures plus simples, au lieu de juste ajouter une impulsion dans une direction réglé manuellement on a décidé que calculer l'impulsion initiale serait plus efficace. Le calcul prend en compte la position initiale du joueur, la position cible et la durée souhaité durée de projections. La durée permet de régler la courbe du mouvement. Une durée élevé augmentera l'amplitude de la courbe de la trajectoire.Pour briser le déterminisme de ces features le joueur possède toujours un certain air contrôle. À terme il n'est pas non plus exclu d'ajouter des variantes. On peut imaginer un grapin qui attire précisément vers lui, ce qui permettrait d'ajouter un moyen d'expression au joueur en lui donnant le choix de l'angle d'attaque de ce grapin.

B. L'impacte des réglages

Voilà deux vidéo montrant l'impacte de la variable de durée de la projection sur la courbe des mouvements. La seconde vidéo contient également l'exposition d'une particularité des Jump Pad, il est possible de les rendre inactifs de base et de les activer manuellement pour une courte durée.

B. Mise en situation des mécaniques

Ces mécaniques permette réellement de dynamiser le gameplay. Ce niveau avait déjà été utilisé en interne pour les tests de mécaniques de Wall Run, il est d'ailleurs possible de voir le Wall run guidé sur la fin de la vidéo.

Ce niveau a gagner a peu près 20% en taille, mais en parallèle le niveau est également 20% plus rapide a traverser. Le jeu est plus rapide. Mais aussi plus dynamique grâce aux inputs supplémentaires demandé au joueur.

28/04/2025

02. Prototype jouable

Pendant qu'on travaillait sur la théorie derrière le jeu, on s'est dit qu'on devrait faire une "démo" pour le projet. Quelque chose qui permettrait de partager notre vision pour le jeu à d'autre tout en l'affinant. Jusque la tout nos exe étaient concentrés sur des mécaniques uniques hors contexte, elle n'était ni pratique à faire tester ni même représentative de l'expérience que l'ont souhaitait créer.Nous avons alors opté pour faire une démo entre le MVP et la Vertical Slice. Un petit niveau avec de la mise en scène le cœur du gameplay développé jusque la, un onboarding et un travail sur les visuels et l'audio.Si vous voulez tester cette démo par vous même, vous pouvez la télécharger depuis cette page Itchio, mais si non, vous pouvez aussi regarder cette vidéo mettant en scène une run de la démo.

A. How it started

Après avoir fait un schéma très simple, on est vite passé in engine pour construire la base du niveau et voir si la forme générale et la durée est bonne ou pas. Nous avons utilisé des Path3D (Splines) et CSG de Godot, les deux pouvant être combiné tout ça a été très rapide.

Ensuite le niveau a vite été rendu jouable en comblant les espaces réservé à des mécaniques particulières et habillé pour rendre le tout un peu plus cohérent, sans pour autant se concentrer sur les visuels.

B. How it's going

Ensuite il était temps d'ajouter du polish pour donner à cette démo un ambiance forte malgré le manque d'assets. Les captures d'écrans ne peuvent pas complément capturer l'ambiance de cette démo alors nous vous recommandons de la tester directement ou alors de regarder la vidéo la mettant en scène.

15/03/2025

01. gameplay

Le concept du jeu en lui même nous apporte certaines contraintes. Comme celle de mélanger parcours et contemplation sans briser le flow du jeu. Nous avions déjà pensé à certaines idées pour régler ce problème mais ces potentielles solutions demandaient à être prototypé et playtest rapidement pour passer à la suit. Alors c'est ce que nous avons fait.Mais n'ayant toujours pas délibéré sur notre moteur de jeu, nous avons décider de commencer le prototypage sur Godot afin de ne pas biaiser notre décision finale tout en profitant de la rapidité de prototypage propre a ce moteur de jeu, GDScript, Signaux et système de CSG, tous ses outils nous ont vraiment aidé a itérer rapidement.

A. systemes de caméra

Les idées mentionnées plus tôt avaient à voir avec l'implémentation de systèmes de caméras assistées permettant au joueur de continuer d'avancer tout en ayant la camera qui cadre automatiquement les action importantes.Quand le contrôle de la camera est pris au joueur les mouvements de souris ne permettent plus que de petit ajustement sur la camera et la direction de la camera et des mouvements du personnage sont décorrélés. Un système de guidage aide également le joueur à suivre les tracé plus complexe tout en lui permettant de n'avoir qu'à appuyer sur avancer et se concentrer sur ce que la camera automatique veut lui montrer.

Un système de guidage visible dans la seconde vidéo permet au joueur de suivre des tracés plus complexes toujours sans avoir à effectuer des contrôles particuliers. Mais il est bon de noter que le joueur ne perd pas le contrôle de ces actions. Il peut toujours se décaler sur les coté ou même arrêter d'avancer.Certaines de ces effets de camera ne se déclenche pas automatiquement et doivent être activé manuellement. Ceux la peuvent aussi être désactiver manuellement. Cette nuance dépendra des besoin de la narration.

B. Movements

Ensuite nous avons concentré nos efforts sur la définition des mouvements, notamment par rapport aux fait que nous voulions mettre l'accent sur la progression vertical sans avoir à abuser de simples pentes. Pour commencer nous nous sommes concentré sur l'incorporation du mouvement vertical au Wall Run qui étaient déjà prévu dans le jeu.





Le Wall Run libre fait monter le joueur pendant un certain temps avant de commencer à redescendre. Depuis le murs le joueur peut faire un Wall Jump dont la puissance dépend du moment ou le joueur l'active. Plus le joueur est proche de l'apex de son mouvement vertical, plus il sera puissant.

Une variante guidé du Wall Run a aussi été testé. Il s'agit d'un Wall Run suivant un guide sans limite de temps ou contrainte de timing. Cette variante n'a pas été exploré autant en détail que la version libre, mais reste visible dans la seconde vidéo ci dessous.

La première vidéo montre le fonctionnement du Wall Run et son interaction avec le Wall Jump. Et la seconde vidéo met en scène ces mécaniques dans un niveau pensé comme un blocking de niveau.

04/03/2025

00. Le projet

ASCEND est un jeu de parcours à la première personne avec des aspirations narratives et contemplatives. Le joueur incarne un ange qui essaie de retourner au paradis après en avoir été déchu pour avoir détruit le monde des hommes. Sur son chemin il apprendra de ces erreurs et tentera d'en réparer leurs conséquences.

A l'origine, ASCEND est un projet de fin de première année d’étude, que nous avons réalisé en duo (Enzo POLI et Jodie HANN), sur une durée de deux mois. Après plusieurs années passées à réfléchir au potentiel du projet, ayant enfin terminé nos études, nous avons décidé de le ressusciter avec l'objectif d’une sortie sur Steam d'ici 2028 !Nous souhaitons créer un jeu aux intentions narratives et philosophique. Une expérience basée sur une ambiance forte, où le joueur est immergé dans son histoire et son propos. Un commentaire sur la guérison, pour pouvoir réparer ses fautes il faut aussi se réparer soit même en leur faisant face.

Voici le rendu du projet d'origine. Vous pouvez aussi consulter le portfolio d'Enzo pour plus de détails sur le développement de cette version du jeu.

l'équipe


Fraichement diplômé, nous formons une petite équipe de deux Game Designers Jodie HANN et Enzo POLI, collaborant à distance depuis le sud de la France.
Nos sensibilités respectives, bien que différentes, sont au cœur de notre complémentarité. Enzo POLI est davantage tourné vers les aspects techniques et les mécaniques de jeu, tandis que Jodie HANN apporte une approche plus artistique et narrative.