Bonjour!
Je suis Ambre Laurent, Tech Designer
en recherche d'un Stage de 6 mois ou d'un CDD à partir de Juillet 2026.

Tout autant fan de jeux de stratégie et de plateformer comme de comédies musicales et œuvres sur la mythologie, j'aime particulièrement designer du gameplay ou des outils pour les productions où je travaille.

Dans ce portfolio vous pourrez trouver mon processus de créations pour différents projets que j'ai pu réaliser en Solo ou en équipe.

Projets de jam

Au fil des années passées à Piktura, j'ai fait de nombreuses jam, dont certaines sont sur Itch.io!

• Lien Itch.io

Mon CV

Si vous voulez me contacter, n'hésitez pas à m'envoyer un mail via l'adresse ci-dessous.
Vous pouvez aussi aller sur ma page Linkedin.Passez une bonne journée!

• LinkedIn

Mail : [email protected]

• Retour accueil

Chara controller Beat'em All BlazBlue Entropy Effect

Analyse, conception, prototypage

Objectifs du projet :

Analyse BlazBlue Entropy Effect

L'objectif de cette analyse était de comprendre ce qui donnait un game feel aussi bon à BlazBlue Entropy Effect, et étudier leurs méthodes de transposition de personnages de jeux de combat a un Beat'em all.Cette analyse est séparée en trois parties :

• Analyse origines jeux de combat de BlazBlue Entropy Effect
• Analyse 3C Controller
• Analyse 3C Character, Game Feel

Origines de BlazBlue Entropy Effect

On en arrive au coeur de mon analyse :Cette double origine Beat'em All, jeu de combat, est extrêmement importante pour le Game Feel du projet, et c'est cela qui m'as donné envie de créer un prototype dessus.

BlazBlue Entropy Effect, en reprenant les personnages de la licence BlazBlue, a aussi repris leurs mouvements et attaques.Cependant, ce n'est pas un jeu de combat, mais un Beat'em all.Il faut donc retravailler les 3C, adapter des éléments, et revoir la manière globale dont sont joués les personnages pour les simplifier et les rendre le plus juicy possible.Outre les graphismes polish, voici quelques éléments techniques qu'ils ont réalisé et que je dois intégrer dans mon prototype :

Analyse 3C, Controller

3C : Character, Game Feel

Dans ce jeu, l'élément le plus important est le côté "Freestyle" des combos :
Le joueur est libre de construire ses enchaînements à partir du set de moves définis. Les combos sont plus permissifs que dans un jeu de combat.BlazBlue Entropy Effect met en avant l'idée de combos freestyles, même dans son trailer originel.

Quand a la précision : les hitbox sont beaucoup plus généreuses, tandis que la hurtbox du personnage est mineure.
Cela permet de ne pas frustrer les joueurs.
C'est bien mieux pour un Beat'em all de ne pas punir le joueur s'il se fait toucher son bras, cela serait frustrant.

Apprentissage :En plus de l'aisance avec laquelle on peut effectuer les attaques et combos, et le game feel amélioré via les 3C, le joueur est aidé à l'apprentissage par le fait que toutes les attaques d'un personnage ne sont pas disponibles des le début.Le joueur débloque les attaques au fil des ateliers, en débloquant des potentiels : nouveaux combos, bonus de dégâts, d'invincibilité sur des attaques... Les mouvements des personnages se renforcent au fil de la partie, ce qui simplifie l'apprentissage de ceux-ci pour un joueur néophyte.

Après avoir étudié les 3C du jeu, je me suis penchée sur les personnages en eux même.Afin d'éviter d'avoir un résultat similaire a un personnage déjà existant dans mon prototype, j'ai réalisé un tableau analysant les personnages du jeu et leurs points clefs :Thématique personnage, portée d'attaque, aérien ou terrestre, style de combat, vitesse...

Conclusion analyse

BlazBlue Entropy Effect a su tirer les forces des personnages de la licence BlazBlue, tout en amplifiant un ressenti de puissance chez les joueurs en modifiant des aspects des personnages pour les adapter à un Beat'em All.En reprenant les aspects de jeux de combat, ils ont créé une expérience dynamique et unique parmi les jeux de Roguelite/Beat'em all.Pour la suite de mon projet, j'ai créé un personnage de ce jeu que vous pouvez visionner ci dessous :

• Conception et Prototypage

Vous pouvez aussi visionner d'autres projets si vous le souhaitez :

• Retour accueil

• Retour accueil

Chara controller Beat'em All BlazBlue Entropy Effect

Analyse, conception, prototypage

Conception et réalisation d'un nouveau personnage

Les objectifs de cette partie étaient les suivants :

Conceptualisation, Schématisation, State Machine Finale

Le point principal que je souhaitais travailler dans cette partie était ceci :
"Donner une sensation de puissance au joueur incarnant mon personnage de Beat'em all"
Je concentrerais donc la présentation de ce nouveau personnage sur ce point.

Voici les étapes de la conceptualisation et réalisation de mon personnage. Si vous le souhaitez, vous pouvez aller sur un point qui vous intéresse en particulier.

• Bases du personnage
• Schématisation et préparation
• Prototypage - Rendre le personnage juicy

Bases du personnage

Uka est le nom du personnage que je souhaite développer.Pour commencer, je devais répondre à des questions clés pour orienter son développement :Quel feeling voulais-je transmettre ? Quelle arme choisir pour cela? Comment démarquer mon personnage?


J'avais déjà quelques objectifs de base :

Cette combinaison Guan Dao et explosions donne un gameplay violent, lourd, plutôt lent, avec quelques attaques tournoyantes rapides pour l'aspect "mixte".Le personnage dispose aussi d'options aériennes : le Guan Dao envoie bien les ennemis en l'air, et ses pieds servent de rocket jump pour enchaîner les attaques.

Une fois ces choix faits, j'ai intégré les caractéristiques d'Uka dans mon tableau comparatif avec les personnages existants.

J'ai ensuite créé un tableau recensant les données du personnage (touche utilisée, type d'attaque) et mes besoins pour les futures attaques.

Avec ces bases, je pouvais passer à la schématisation.

Schématisation et préparation

Mes schémas avaient des objectifs clairs dans leur manière d'être conceptualisés :

En effet, en me basant sur BlazBlue Entropy Effect, je souhaitais avoir des combos freestyles.
Cela signifie qu'un joueur doit être capable de créer ses propres combos à partir de ses différentes options d'attaques et de mouvements.

J'ai donc utilisé trois éléments globaux à tout mes schémas.

Avec cette méthode, je pouvais aisémment avoir accès aux points cités plus haut. Il était aussi assez aisé de retravailler des parties, en schéma ou en développement plus tard.
Je devais aussi faire attention à d'autres points en designant mes attaques :

Lorsque j'ai terminé de schématiser et d'annoter mes attaques dans mon tableau, j'ai réalisé le schéma de state de mon personnage : Il est très important pour la partie développement.Cependant, celui-ci devrait être retravaillé. Bien qu'il m'aie été utile dans le coding du personnage, il s'est avéré très chaotique et peu flexible en cas de modification.

Il était alors temps de passer a la partie prototypage.

Prototypage d'Uka

L'objectif principal est toujours :
"Donner une sensation de puissance au joueur incarnant mon personnage de Beat'em all".Jai prit plusieurs axes d'approches pour mon projet afin d'atteindre cet objectif.
Certains sont en lien avec la conceptualisation vue précédemment.

1 - Mouvements :

Pour la base du chara controller, j'ai choisi de prendre un package de controller de platformer 2D pour améliorer ma rapidité de prototypage de la state machine et des attaques, en m'appropriant le code pour l'adapter à mes besoins.

2 - Préparer les enchaînements du personnage :

Afin de permettre au joueur de créer ses propres combos, je devais faire en sorte que mes attaques peuvent aisément être enchaînées.Pour ce faire, les attaques sont des prefabs d'objets contenant des animations. Les formes que l'on voit représente les hitbox. Les animations permettent d'avoir un contrôle complet sur leur forme, vitesse et feeling, et préparent les cancels de mon personnage.Les attaques animées n'ayant pas besoin du personnage pour fonctionner, elles permettent à un joueur d'annuler son mouvement sans annuler son attaque lancée.

Aucune de mes attaques n'a besoin de savoir si mon personnage bouge ou non, mais au minimum s'il est sur terre ou dans les airs.Cela simplifie les touches, et les mouvements du personnages.J'ai fait en sorte de respecter les state de mon schéma, tout en étant flexible et ajoutant des cancels là où cela pouvait améliorer la fluidité et le feeling du controller.

3 - Hitboxes, trajectoires de l'ennemi :

Les hitboxes dans un Beat'em all doivent être généreuses.
L'imprécision permet d'avantager le joueur et de lui donner une sensation de puissance.
Blazblue Entropy Effect le fait déjà plutôt bien, la hitbox étant bien plus grande que le visuel de l'attaque.

Le Guan Dao n'est pas une arme très large, m'ai j'ai fait en sorte d'élargir la hitbox de mes attaques.
De plus, les explosions possèdent une grande zone d'effet.

Quand un ennemi subit une attaque du joueur, il fallait lui appliquer une trajectoire qui avantage les possibilités de combos. Cela permet au joueur d'avoir des possibilités diverses pour enchainer.
On peut aussi les placer pour mieux suivre les mouvements d'une suite d'attaque.Dans mes concepts, j'avais déjà prévu les trajectoires des ennemis. Pour les coder, j'ai décidé d'utiliser deux méthodes :

4 - Effets sur l'ennemi

Un point à ne pas négliger était le hitstun que subit un ennemi à chaque attaque.Ce hitstun sert deux fonctions.

Chaque attaque possède son propre hitstun, afin de laisser plus ou moins de temps pour enchaîner des coups et ressentir la puissance derrière chaque attaque.

Au delà de cet hitstun, j'ai aussi ajouté un léger freeze frame à chaque attaque. Il permet d'accentuer les éléments cités ci-dessus.

5 -Polish!

J'ai déjà polish le feeling global du personnage via des éléments ci-dessus, mais j'ai aussi ajouté des éléments à plus petite échelle afin de rendre un peu plus juicy/fluide le chara controller, par exemple :

Et + encore.

Ces éléments étaient importants pour compléter le ressenti en jouant le personnage.

Conclusion

Le projet a un feeling qui me semble assez plaisant. Le chara controller est fluide, et est amusant à prendre en main.
Cependant il possède encore quelques axes d'améliorations pour accentuer le ressenti du joueur :

De plus, en avançant le projet et en retravaillant mon architecture de code, j'ai trouvé un moyen d'en créer un outil en modifiant quelques éléments.Celui-ci devrait laisser un game designer ajouter et modifier des états en touchant très peu au code, laissant des designers non développeurs l'option de créer leurs propres personnages en quelque clics.

Si vous souhaitez observer d'autres projet comprenant de la programmation, vous pouvez retrouver mon
Chara Controller Speed Racer :

• Speed Racer Project

Ou encore mon Tool Infiltration pour la production d'un outil destiné à un Level Designer :

• Tool Infiltration

Et si vous souhaitez un voir un outil intégré lors de la production d'un projet plus avancé, voici
L'Outil Ballons de Blown Away que j'ai pu réaliser :

• Outil Ballons Blown Away

• Retour Accueil

• Retour à l'accueil

Application gamifiée GHT Psy

Fiche du projet :

Pitch

L'application Android a été créé dans le but d'accompagner les patients du GHT Psy dans leurs parcours.
Elle avait deux objectifs principaux à remplir :

Bien que le GHT Psy touche à plus de sujets, on nous a demandé de développer des éléments pour 2 d'entre eux :

Mes tâches

Je m'occupais de tout l'aspect Design du projet :

Mais je m'occupais aussi de développer de nombreux aspects, en tant que Dev plus expérimentée du groupe :

Vidéo application navigation

Sommaire

Ce somaire suit les étapes de production de l'application

Débuts du projet

• Conceptualisation
• Prototypage

Text

• Navigation, fondations de l'application
• Développement mini-jeux et plus
• Polish de l'application

Conclusion

• Une application fonctionnelle

Conceptualisation

Text

• Retour Accueil

Outil d'infiltration

Fiche du projet :

Pitch

Ce projet de 4 jours en équipe avec un Level Designer avait deux objectifs :

Je m'étais donnée comme objectif d'utiliser le Behaviour Tree d'Unity pour développer l'IA de l'ennemi afin de découvrir cet outil.Celui-ci m'intéressait et je souhaitais en apprendre plus via ce projet.Le développement allait de l'étude de la référence à la state machine de l'IA et enfin le développement de celle-ci avec un outil pour l'accompagner.

Vidéo d'utilisation de l'outil. Les timings des patrouilles sont gardés en editor mode!

Vidéo de l'IA finale

Sommaire

Ce sommaire suit les étapes de développement pour ce projet

• Étude de la référence

• Conceptualisation prototype

• Développement IA ennemie, outil Splines

• Développement outils globaux, GPE

• Conclusion

Étude de la référence

Voici le contexte pour ce projet :Nous étions 2 Game Designer en R&D qui avions un jeu 2D en référence dont on devait s'inspirer afin de l'adapter et développer une IA d'infiltration en vue Top Down ainsi qu'un outil pour créer des niveaux avec celle-ci, et ce en
4 jours.Le Level Designer devait conceptualiser les éléments dont il aurait besoin dans le prototype ainsi que les niveaux de celui-ci.Quant à moi, je devais créer l'IA et les outils de développement de niveaux pour le prototype.

La référence que l'on nous a donné est
Mark of the Ninja : Remastered
Trailer ci-dessous

Dans celle-ci, on peut retrouver trois éléments que l'on a voulu reprendre pour notre projet :

Ces 3 éléments allaient composer nos GPE.

Conceptualisation prototype

Pour commencer, j'ai d'abord schématisé la state machine de l'ennemi.

Image globale, cliquez pour l'avoir en large!
Plus de détails en dessous!

La state machine est séparée en deux étapes :

Routine de patrouille :

Cliquez sur l'image pour l'avoir en large!

Il y a de nombreuses conditions via des variables :L'objectif était que le Level Designer aie main mise sur ce que fait l'ennemi durant toute sa patrouille.L'ennemi a comme point central son déplacement :
Il va de points en points d'une spline Unity.Ensuite, il vérifie ses variables :

Si oui, alors il s'arrête durant cette durée.

Si c'est le cas, il tournera la tête une ou deux fois, pendant une durée déterminée, et ce après avoir attendu son temps d'attente.Sinon, il ne tournera pas.

Chaque point de patrouille possède des variables différentes.
Ainsi, le Level Designer est complétement libre de choisir ce que l'IA fait à n'importe quel point.

Routine de détection:

Cliquez sur l'image pour l'avoir en large!

Si l'ennemi détecte le joueur, il suit alors 3 étapes simples :

Dans notre prototype, l'ennemi tue le joueur dés que la jauge de danger est remplie.
Il n'y a donc pas d'état "Attaque".La jauge de détection commence à se vider uniquement lorsque l'ennemi est fixe à une position, et est remplie à 100% tant qu'il voit le joueur. Cela permet d'éviter une situation où l'ennemi voit le joueur et stoppe son état d'alerte pendant qu'il se déplace vers la position supposée du joueur.La même logique s'applique lorsque l'ennemi entends un son.Une fois que l'ennemi a perdu sa jauge de détection, il est important qu'il aille au point le plus proche de lui, puis reparte dans la direction de la spline.
Cela donne un effet plus naturel!

Développement IA + Outils Splines

J'ai fusionné ces deux notions car durant le développement, je travaillais les deux en parallèles.Ma méthode était ainsi :

Puis, lorsque je voyais qu'il manquait quelque chose, ou après des retours du Level Designer, je retravaillais des éléments.

Comme je disais au début, j'ai décidé d'utiliser le Behaviour Tree pour créer l'IA.L'énorme avantage de celui-ci, c'est sa liberté de modification.
C'est super simple d'ajouter un élément au behaviour tree, comme une condition ou autre.C'est aussi simple de créer ses propres scripts pour celui-ci, et la majorité des actions du Behaviour Tree de l'IA ennemie sont des scripts que j'ai créé.

Behaviour Tree final

Cependant, après ce projet, j'ai pu remarquer une chose :
Le Behaviour Tree fonctionne comme son nom l'indique comme un arbre descendant et non comme une Finite State Machine.Ainsi, bien qu'il soit très bon pour des suites d'actions, il est plutôt mauvais en terme de réactivité.

Il a fallu "tricher" à quelques moments pour forcer l'arbre à être réactif avec des booléens et en forçant des actions de l'ennemi, afin que l'ennemi aie une réaction vive en détectant le joueur.

Cependant, pour les états de patrouille différents, il fonctionne parfaitement!

Le tout est accompagné de scripts sur l'ennemis pour détecter le joueur, et effectuer d'autres actions à des moments plus précis.

Patrouilles ennemis

L'outil de patrouille fonctionne ainsi :L'ennemi se dirige de point en point d'une Spline avec son NavMeshAgent.Le Level Designer doit simplement créer la spline, puis placer les points où il le souhaite sur le LD.Un prefab a été créé pour intégrer un script de modifications éditeur, qui permet de mieux détecter les points de la spline via des Gizmos :

Chaque point de la spline possède des paramètres pour que le Level Designer puisse faire s'arrêter l'ennemi, lui faire tourner son regard et la durée qu'il prend pour faire ceci afin qu'il puisse avoir un maximum de flexibilité.

Exemple Spline : Non sélectionné, sélectionné. Les couleurs diffèrent pour voir sur quelle spline on travaille actuellement.
Le point de départ (vert) et le point d'arrivée (rouge) ont des couleurs différentes pour mieux comprendre les trajets de la spline, et pour aider à la mécanique de "Loop" des patrouilles.

Il faut ensuite simplement assigner la Spline que l'ennemi dois suivre dans son Behaviour Agent!

L'avantage du NavMesh, c'est que le Level Designer ne doit pas se préoccuper du positionnement des points des splines pour que celles-ci ne touchent absolument aucun mur.Même si les splines passent à travers un mur, le NavMesh s'occupera de diriger l'ennemi sur la bonne voie

Exemple chemin ennemi :

Il peut cependant positionner plus de points pour avoir des chemins plus précis, étant donné que l'ennemi va prendre le chemin le plus court pour aller de points en points.

Plus haut, dans mon schéma de State Machine, je parlais d'effectuer des actions selon des variables.

Afin de simplifier la création de niveaux, chaque ennemis possède ses propres variables pour les points de leurs splines :

Chaque élément des listes correspond à un point de la spline.
Si le Level Designer assigne un WaitTime de 2 à l'élément 0 par exemple, l'IA attendra 2 secondes au premier point de sa patrouille (le point de départ) à chaque fois qu'il le touchera.Ensuite, le RotateAmount a lieu uniquement si un WaitTime existe, étant donné que l'ennemi ne peut pas tourner sur un point s'il ne s'y arrête pas.De plus, il prendra le temps "RotateTimes" à tourner, pour pouvoir faire varier ses points d'arrêts.C'est plus clair dans le Behaviour Tree :

Cliquez pour zoomer

Voici un exemple de ma méthode de fonctionnement pour la modification de l'outil durant le développement


On peut remarquer que Rotate_Times est un Vector 3, contrairement à un Vector2 qui était prévu à la base :

A la base, on souhaitait avoir un RotateAmount en Vector2 pour dire que la première variable est la première direction où l'ennemi tourne, et la deuxième, si elle existe, est la seconde direction où il tourne.On s'est rendu compte en testant avec le Level Designer que l'ennemi avait son regard dans la direction d'où il venait en arrivant sur le point

Exemple : Ici l'ennemi regarde vers le mur en arrivant.

Pour donner un meilleur effet, j'ai donc modifié l'outil pour avoir un Vector3 :La première valeur donne la direction que l'IA possède en arrivant sur le point, et la seconde/troisième valeur sont les valeurs qui font tourner le regard de l'IA.


Créer ces listes est agaçant. Il faut compter le nombre de points de la spline, mettre exactement le même nombre de variables dans la liste que de nombre de points
de la Spline...Pour simplifier la tâche, j'ai créé un bouton permettant de créer ces listes en un clic.

Le bouton possède tout de même un défaut : Il supprime les valeurs qui étaient déjà existantes. Ce n'est pas le plus pratique, mais je n'ai malheureusement pas eu le temps de corriger celui-ci dans les 4 jours que j'avais pour le projet.

On a donc tout les éléments de l'IA :

En testant l'outil, le Level Designer m'a fait une remarque :C'est dur de faire se rejoindre des patrouilles exactement au même moment.Dans un jeu d'infiltration, le but est de trouver un moyen de passer les gardes pour arriver à son objectif.Dans notre prototype, on souhaitait devoir trouver des moyens de passer au bon moment, ou déranger le chemin des gardes en faisant des sons/les attirant nous même, pour pouvoir atteindre l'objectif d'un niveau.

Exemple : Ici le Level Designer voudrait que les deux ennemis arrivent en même temps sur les deux points proches de leurs deux Splines respectives :
Le point sélectionné, et celui en rouge à côté.Les deux points sont entourés en vert sur l'image.

Ainsi, j'ai développé un outil qui permet de calculer le temps que chaque ennemi prend pour arriver à tel ou tel point d'une Spline.C'était la fin du temps imparti pour le prototype, j'ai donc reprit un package en ligne pour gagner du temps : Celui-ci permettait d'avoir des objets qui se sauvegardent du Playmode à l'Editor Mode.Puis, j'ai fait en sorte qu'à chaque fois qu'un ennemi atteigne un point, le temps qu'il a prit pour arriver à ce point soit calculé et affiché.

Option pour activer le debug

Exemple debug temps : On peut aussi voir que les temps sont gardés en quittant le PlayMode

On peut voir, avec les chiffres après la virgule, que les patrouilles possèdent un risque de désynchronisation sur la durée à cause de petites fluctuations.Il faudrait trouver un moyen à terme de simplifier le fait de les faire arriver exactement au même moment. (Exemple : Synchroniser un WaitTime pour que les ennemis partent exactement à X secondes en fin de boucle)

Éléments globaux, GPE

Jusqu'à présent j'ai présenté l'outil sous l'angle
d'une IA spécifique.Lors de la production de l'outil, j'ai pu remarquer que le
Level Designer avait besoin de deux types de variables

Le texte barré en noir est car la mécanique n'a pas pu être intégré dans notre temps imparti.

J'ai donc séparé les éléments en deux :

Au cas où, j'ai tout de même laissé la possibilité au Level Designer d'assigner data à différents ennemis.

GPE, autres

Comparativement à l'IA, les GPE ont été très simples à développer.Je pouvais les rendre fonctionnel et les intégrer à l'IA de l'ennemi en recyclant au maximum les Scripts déjà présents.Par exemple :

Les sons du joueur sont générés aux lancés de projectiles par celui-ci :

Pour me simplifier la tâche, j'ai simplement créé un collider à la position où le projectile du joueur touche un obstacle.Pour l'ennemi, il détecte le collider comme si c'était le joueur, et vas à la position où le collider a touché l'obstacle.

Le GPE son amplifie l'effet, et augmente simplement la taille de la zone générée.

Le GPE son possède un Gizmo pour voir la taille que le son aura.

Ici, l'effet du son sur l'ennemi

Le GPE lumière a le même fonctionnement.

J'ai simplement reprit la variable de longueur de champs de vision de l'ennemi, et l'ai boosté. Cela évite de changer entièrement le comportement de l'ennemi, et a l'effet voulu.

Pareil pour la cachette!
L'ennemi détecte le collider du joueur.
Du coup, j'ai caché le collider du joueur quand il interagit avec la cachette, pour l'empêcher de se faire détecter.

Avec ces GPE, j'ai oeuvré à les rendres simples d'utilisation.Si le Level Designer veut modifier la forme, la taille... Il a simplement à aller dans l'instance du prefab et
à scale le tout.
Pour le son généré, il lui suffit aussi d'aller dans le prefab du projectile, et à changer la taille générée sur GPE.Ainsi, le level Designer peut aisément modifier ce qu'il souhaite.Dans le cas du GPE son, la taille du Gizmo est dynamique avec la valeur assignée au projectile!

Conclusion

Ce projet a été intéressant pour voir jusqu'où je pouvais aller dans la création d'un outil
en un cours laps de temps.Bien que l'outil manque quelques polish pour rendre le tout encore plus fluide, il est déjà fonctionnel et permet d'avoir une première pipeline de production pour des niveaux utilisant une IA d'infiltration.J'ai déjà quelques idées pour améliorer l'outil :

Mais actuellement, l'outil est déjà fonctionnel.

J'ai aussi peu remarquer les défauts du
Behaviour Tree d'Unity :

Mais aussi ses forces :

Utilisation Tool

Gameplay Prototype

• Retour à l'accueil

• Retour à l'accueil

Speed racer project

Fiche du projet :

Problématique secondaire :

Le second objectif du projet était de faire en sorte que le chara controller soit modulable pour être capable à la fois d'obtenir un chara controller du style de Speed Racer, mais aussi un chara controller plus classique de voiture simplement en bougeant des variables.

Ci-dessous une comparaison d'un chara controller aux variables plus ancrées dans la réalité, et un second aux variables visant l'effet Speed Racer.

Sommaire

Ce sommaire suit mes étapes de réflexion pour ce projet

Débuts du projet

• Références

• Un premier chara controller non adapté

• Un second chara controller plus arcade

Développement des spécificités "Speed Racer"

• Ajouter un slope effect

• Ajouter un air control

• Ajouter un effet de drift mécanique

• Ajouter un effet de drift visuel

• Ajouter le saut

Conclusion

• Un chara controller flexible

Références

Ma référence principale était un film :
"Speed Racer".
Trailer ci-dessous, commence quand on voit la voiture prise en référence

Voici les effets que je voulais reproduire
de la voiture :

L'effet de drift :

Dans speed racer, l'élément le plus exagéré d'une voiture de base est le frein, et l'effet de drift qu'on les voitures.
Les voitures sont capables de tourner à des vitesses extrêmes, et on peut les voir se mettre en position latérale pour tourner.

Exemples de drift

J'ai voulu obtenir une voiture agissant comme les schémas ci-dessous : Capable de virages très serrés, avec un effet visuel sur la voiture pour accentuer le virage.

A gauche : Tourner normalement. A droite : Drift

Effets visuels de drift à droite.

Le saut des voitures :

Le second élément majeur que je souhaitais représenter était le saut dont est capable la voiture dans le film.

Dans mon projet, je devais interpoler ce saut afin de le rendre utilisable en gameplay. J'ai donc schématisé ce saut pour pouvoir
le développer plus tard.

Effet de saut dans le cas de pente sur le côté. En bleu : le côté roue de la voiture.

Le saut devait pouvoir permettre à la voiture de pouvoir utiliser l'aspect "rampe" qu'on peut voir dans le film pour la majorité des courses.

1er chara controller non adapté

Pour commencer, j'ai tenté d'utiliser le système de wheels unity. Ce système utilises 4 roues désignées, et des variables comme
le torque ou le downforce.

Cependant, ce système n'était pas adapté au projet :

Vidéo test du chara controller

J'ai vite stoppé l'utilisation des Wheels Unity, et j'ai décidé à l'aide de quelques références de créer une sphère en guise de controller principal.Ma voiture était alors composée de 4 éléments :

Cette méthode a pour avantage d'être très flexible, à la fois pour diriger le véhicule, ainsi que pour décider de la représentation graphique de celui-ci.On a alors un chara controller fonctionnel : Une boule roulante, dirigeant le véhicule.J'ai réalisé quelques animations de voiture simple au niveau des roues afin de rendre la voiture plus plaisante et le mouvement de celle-ci plus clair à lire.

Vidéo déplacements basiques de la voiture

Chara controller speed racer

Étape 1 : Slope management

Une fois la base de mon chara controller effectuée, je me suis penchée sur les côtés plus uniques de Speed Racer.J'ai commencé par créer un système de slopes.Le controller est très arcade, et dans
"Speed Racer", de nombreuses courses ont des pentes démesurées.Je me suis dit qu'implémenter un système utilisant ces éléments serait intéressant, et j'ai donc changé mon contrôleur pour qu'en fonction de s'il se trouve sur une slope ascendante ou descendante, il ai plus ou moins de mal à accélérer, et pourrait même dépasser la vitesse maximale de la voiture.
Ce système prends tout son sens dans un circuit en forme de "dôme"!

Déplacement sur slope

Exemple avec variables exagérées sur énorme dome

Des variables permettent de changer les effets.
Elles priorisent le sentiment de vitesse

Étape 2 : Air control

Afin de permettre à la voiture d'aller dans les airs comme dans le film, j'ai ajouté du air control.

Ce air control est important, notamment car il affecte aussi les sauts effectués.

On peut modifier les effets dans les airs, notamment la vitesse de rotation verticale ainsi qu'horizontale, ou le ralentissement appliqué à la voiture.Cela permet alors d'avoir plus de contrôle aérien, de vitesse de chute, de ralentissement dans les airs..

Exemple de valeurs différentes pour le contrôle aérien de la voiture

Un effet de suspension des roues a également été ajouté, pour renforcer l'effet de chute sur les roues de la voiture.

Étape 3 : Drift handbrake

Pour l'effet de drift, je me suis inspirée de
Mario Kart, notamment d'une vidéo de
Mix and Jam qui a reprit cet effet.

Le drift a plusieurs étapes.Premièrement : Sans le handbrakeSans appuyer sur cette touche, la voiture drift de manière moindre. Elle tourne moins rapidement, et reprends plus le comportement d'une voiture arcade classique.

Deuxièmement : Avec le handbrakeLe handbrake s'inspire de
Need For Speed Most Wanted 2012.
Dans ce jeu, une touche permettait d'utiliser le frein à main, et ainsi de drifter.

Exemple Need For Speed Most Wanted 2012

En reprenant ce principe, et en m'inspirant de Mario Kart, j'ai créé une touche "Handbrake" qui permet à la voiture d'avoir un drift lui permettant de tourner brusquement comme dans Speed Racer et ayant un effet visuel plus extrême.

On peut modifier ces effets pour plus ou moins ralentir la voiture durant le drift, et la faire tourner plus ou moins rapidement

Ci-dessous : Exemple où la voiture n'est que très peu ralentie par le handbrake et est très rapide durant celui-ci, pour donner des drifts rapides et similaires à Speed Racer.

En utilisant les quelques variables, on peut modifier les effets physiques et visuels du véhicule, pour plus ou moins ralentir/exagérer les éléments.

Étape 4 : Drift Visuel

Enfin, après le drift méchanique, il fallait le drift visuel.Dans les vidéos ci-dessus on le voit déjà, mais de manière séparée aux mécaniques du handbrake, le visuel de la voiture est affecté lui aussi :La voiture se positionne dans un angle plus ou moins élevé lors du handbrake.


En plus de cela, un overshoot est appliqué à la voiture.
Cela fait que quand elle revient à sa position initiale, elle donne un "coup" à l'arrière, elle revient plus ou moins brusquement et peut aller légèrement au delà de la position initiale pour ensuite revenir, comme un ressort.

Ci-dessous : effet visuel exagéré pour le drift comme pour l'overshoot

Étape 5 : Sauter

Sauter était la partie la plus complexe du projet.Le principe était de reprendre le saut de Speed Racer.Il fallait que la voiture garde de la vitesse, saute de rampe en rampe, et que le saut ai une utilisation simple
(une touche)

Le niveau de contrôle aérien ne devait pas être aussi élevé que Rocket League après un saut. Mais il devait tout de même permettre plus que simplement sauter tout droit, car cela aurait été peu utilisable pour de vraies courses.

Ainsi le système fonctionne ainsi :La voiture détecte si oui ou non elle est sur une pente de côté.
Si elle est sur un sol plat OU une pente descendante/montante : Elle saute vers le haut.Si elle est sur une pente de côté: Elle saute dans l'axe opposé de la pente.

Exemple de saut ci-dessous : Pente descendante, pente côté

En utilisant la vitesse et les pentes, on peut faire des parcours dantesquesLa voiture finira TOUJOURS par s'orienter à l'inverse de la pente où elle se positionnait pour les sauts horizontaux.

Après le développement du saut, j'ai fini par des éléments de polish, comme les trainées des roues en line renderer, les effets de lignes de vitesse ou encore les FX de fumée lors du Handbrake.

Conclusion

Mon objectif dans ce projet, outre recopier le chara controller de Speed Racer, était de permettre d'avoir un chara controller flexible.En modifiant quelques variables, on peut soit retrouver un chara controller Speed Racer, que j'ai mit en avant dans les vidéos ci-dessus...
Mais on peut aussi retrouver un chara controller plus classique, simplement en retirant les variables plus ésotériques.
Sur ce point de vue, mon projet a atteint son objectif.

Chara controller réaliste et chara controller Speed Racer côte à côte

Cependant il mériterait d'être amélioré sur des points de polish, comme la caméra qui parfois rentre dans des murs et pentes.De plus, il manque le côté "Outil" du projet :Les variables sont certes modifiables et le projet est flexible, mais il manque des modifications éditeurs d'Unity comme j'ai pu réaliser sur mon outil d'infiltration ou à la fin de Blown Away pour avoir des presets de véhicules simples à utiliser, ou une modification plus aisée de celui-ci.

• Retour à l'accueil

• Retour à l'accueil

Blown Away Process

Fiche du projet :

Trailer du jeu

Pitch

Blown Away est un jeu 3D mixant l'exploration et le plateformer prenant place dans une cité flottante, portée par des ballons.Nous jouons un enfant, Balloon Boy, partant à la recherche de ses amis dans une partie de cache-cache géante.J'ai majoritairement travaillé le Level Design, mais ai globalement travaillé le game design global.

Si dessous une pipeline de production du projet, dans les débuts du Level Design.

J'ai également eu l'occasion d'utiliser mes compétences de Tech Design pour produire un outil, utilisant le saut de l'enfant sur les ballons.

Exemple sauts sur ballon

Outil pour poser ces ballons

Sommaire

• Préproduction

• Chara controller

• Level Design

• Outil Ballon

• Conclusion du projet

Préproduction

Blown Away a eu une préproduction très trouble. Avant d'arriver à la mécanique principale actuelle, nous sommes passés par maintes itérations.

V1 Projet, GDD Original du Lead

Le projet a commencé comme un jeu à plans de caméras multiples, où l’on utilisait un ballon de baudruche pour créer des formes et résoudre des puzzles.Mais l’idée ne nous a pas convaincus, alors nous avons gardé l’univers et exploré d’autres pistes.

On a décidé de créer une ville dans les airs et d’y prendre des photos de lieux clés pour renforcer l’exploration. On pouvait aussi déplacer certains éléments de la ville pour obtenir les bons angles pour notre appareil photo.

Problème 1 : Scope trop ambitieux. L’environnement était trop complexe à produire pour notre petite équipe et le style visé.Problème 2, le plus important : Ce n’était tout simplement pas fun, ni aussi enfantin qu’on le voulait. On visait un monde onirique, léger et ludique.

On a enchaîné plusieurs idées, et avons expérimenté pendant un mois et demi.Avec le Lead, on s’est posé une après-midi pour tout redéfinir : qu’est-ce qui est fun pour un enfant?
Dans notre univers de ballons et de ciel, qu’est-ce qui pourrait être amusant ? Comment exploiter l’exploration qui nous tenait à cœur ?On a repensé à nos activités d’enfance, et une idée est restée :
Le cache-cache.
Simple, mais elle cochait toutes nos cases.

Il nous restait à trouver comment se déplacer dans ce monde, avec une mécanique amusante et enfantine.
On s’est dit que des enfants joueraient avec la sécurité : alors pourquoi ne pas leur donner un gilet gonflable, conçu pour éviter les chutes dans les nuages, qu’ils utiliseraient comme propulsion plutôt que par précaution ?

Notre projet s’est débloqué à ce moment-là.
Cela m'as appris qu’il suffit parfois de penser simplement et d’essayer des idées pour relancer un projet bloqué.

C’est devenu notre mécanique et objectif principal: en explorant et retrouvant nos amis, on recharge notre gilet et débloque des gameplay elements (GPE) pour atteindre les autres.
On obtient ainsi un monde semi-ouvert et un Chara Controller atypique.

Chara Controller

Le chara controller avait des problématiques importantes à régler :

Avec le programmeur, nous avons défini des variables du Chara Controller pour équilibrer tous les éléments, comme la décélération après propulsion, pour donner l’effet “ballon”.Je testais directement en moteur afin de trouver le meilleur feeling pour le joueur.

Exemple : Balloon Boy ayant trouvé aucun ami, puis ayant trouvé un premier ami.

En développant le jeu, nous avons notamment décidé d'ajouter un dash au joueur. Celui ci permet de combler la verticalité de notre main mechanic avec de l'horizontalité.Mais en avançant dans le développement,
nous avons décidé d'en faire une mécanique achetable :
Cela rajoute un intérêt supplémentaire aux pièces. Elles étaient déjà utiles pour guider les joueurs et satisfaire les complétionistes.
Elles permettent maintenant de récompenser les joueurs qui fouillent la carte de manière plus directe avec un gain de liberté, thématique de notre jeu.Enfin, nous avons pu s'en servir pour débloquer des zones de jeu et des challenges, pour inciter les joueurs à revenir sur leurs pas.

Level Design

Le LD fut ma tâche la plus conséquente dans le jeu.
Le plus gros challenge était d'apprendre comment attirer le joueur à l'endroit où se cache l'un de ses amis, sans pour autant donner directement la solution au joueur.

La première tâche en fin de préproduction fut de tester plusieurs styles de niveaux afin de voir lequel respectait le plus nos objectifs :

C'est avec ses règles en tête que j'ai fait mes premières versions du Level Design.

Assez tôt, nous avons découpé notre monde par zones qu'on appellera "Quartiers" , pour thématiser l'aventure de Balloon Boy et rendre notre ville plus unique.
Nous accentuerions chaque quartier d'un élément spécial pour les démarquer.


Avec cette base, j'ai alors créé un document de LDD.

A la fin de celui-ci, j'ai créé une modélisation 3D de la zone...

Après ce premier test on a pu remarquer quelques problèmes.

Ce premier blocking a cependant permis de valider notre chara controller rough pour assurer une progression fluide dans le niveau. Il a également servi de base à la construction du level design.


Plutôt que d’utiliser des schémas 2D ou 3D, j’ai privilégié une itération rapide en testant différentes combinaisons directement en 3D.Cette approche m’a permis d’optimiser les éléments cachés en jeu et d’affiner le level design de manière plus intuitive.Avec du recul, quelques schémas de flow auraient pu être bénéfiques, mais cette méthode a facilité de nombreuses variations.J’ai également structuré le level design par zones, en travaillant chaque section à différentes passes pour renforcer l’identité des quartiers.

Zone détaillée :
Le marché

La zone du marché est, selon les retours et mon propre ressenti, la plus réussie.
Voici son évolution, afin de présenter mon process de création :

Au départ, j’ai introduit des variations de hauteur pour tester leur impact visuel et gameplay. J’ai également conçu une mécanique avec le téléphérique : il ne revient pas automatiquement, obligeant le joueur à explorer la zone pour retrouver l’enfant avant de pouvoir partir.

Par la suite et avec les retours obtenus j'ai voulu développer l'exploration en ajoutant un deuxième niveau aux bâtiments.
C'est devenu le thème de la zone, un LD à deux niveaux d'exploration.


J’ai cherché à attirer le joueur vers une vue sous les bâtiments, où un enfant caché s'y trouverait. L’ensemble de la zone a ensuite été conçu autour de cet élément de design.

Vue globale...

Deuxième niveau de bâtiment...

Vue de la fenêtre en haut, permettant de voir un enfant caché...

J’avais jusqu'alors trop abordé le Level Design sous un angle "jeu vidéo", ce qui se ressentait en test.
J’ai donc adopté une approche "worldbuilding" en pensant à la vie des habitants : Comment je peux rendre plausible leur vie au sein de cette ville?J'ai en conséquence agrandit les toits, et ajouté des téléphériques pour les laisser se déplacer entre ceux-ci.
L’ajout clé a été un Landmark visible à travers tout le niveau (représenté par un pilier gris), servant à identifier la zone et guider naturellement le joueur. En revenant en arrière après l’avoir exploré, il peut découvrir un chemin caché menant à l’enfant dissimulé.

J'ai par la suite ajouté les ballons rebondissants qui arrivent une fois que l'enfant est trouvé. Ils permettent notamment de rapidement revenir à la tour de la gare et débloquent le joueur de la zone. Je les ai également mit dans la zone en elle même afin de faciliter les mouvements et débloquer des éléments cachés.

Enfin, voici la version blocking final avec une première passe graphique de cette zone.

Quand au reste du LD, j'ai suivi le même process :

Ceci donne mon LD final, lié grâce aux ballons et bâtiments des zones :

On y voit bien l'effet "quartiers", avec la tour de la gare comme landmark central.

Outil ballon

Vers la fin du projet, je voulais placer les ballons rebondissants de manière à ce que le joueur puisse aisément les enchaîner.Le développeur était occupé. Ainsi, en vertu de mes aptitudes de Tech Designer, j'ai réalisé moi même un outil pour m'aider à placer ces ballons.

Explication :
Dans le projet, des ballons rebondissants permettent de se propulser horizontalement de l’un à l’autre, ou d’exécuter un rebond vertical en s’écrasant dessus avec une compétence.

Propulsion horizontale

Propulsion verticale

Cet outil devait respecter 4 demandes :

J'ai donc un boolean qui me permet de décider lequel des deux modes il va utiliser, étant donné que dans mon niveau, je ne fais aucun chemin qui fait les deux en même temps.

Le premier est le classique :

Et le second est le rodéo :

Ce n’est pas un outil parfait et il nécessite encore quelques ajustements manuels pour créer différents types de défis. Mais il fait gagner beaucoup de temps de production en me permettant de placer les ballons rapidement et selon mon design global.
Le résultat a atteint son objectif : placer les ballons vite, avec seulement de petits ajustements nécessaires.
Il m’a fait gagner du temps sur le level design, et c’est exactement ce pour quoi il était fait.

En conclusion

Blown Away a été une expérience formatrice, notamment sur la conception de niveaux semi-ouverts.
La production du jeu m'as énormément apprit sur le Level Design.Si la zone du marché est aboutie, d’autres sections, comme le tutoriel et la zone des tuyaux après la cinématique de la gare, restent perfectibles.L’absence de schémas 2D, notamment de flow, a parfois compliqué l’intégration de mes tests 3D.De plus, la construction en « quartiers » est parfois trop marquée, donnant une impression de niveaux séparés plutôt qu’une ville unifiée, révélant un worldbuilding encore trop peu développé.Malgré ces points, je suis satisfaite du résultat final : la navigation est fluide et la zone d’exploration fonctionne bien, malgré quelques ajustements encore possibles.

Trailer du jeu

Lien Itch.io : Blown Away

• Retour à l'accueil

Pitch

"Alice's Crazy Day" est un jeu de jam qui avait pour thème "un vampire survivors".
On a été placés en équipe de 2, j'avais ces tâches :

On a créé ce jeu en deux semaines à "temps partiel" (le soir, après nos cours, et les week-ends)Je m'étais donnée comme objectif de développer mes compétences de programmation pour ce projet.Ce projet a été formateur pour mon niveau en programmation C#.

Vidéos gameplay

Phase 1 : Début, Brainstorming, Planification.

On a débuté en brainstormant avec ma coéquipière sur le projet.
Une fois qu'on a décidé du thème que l'on voulait (Alice au pays des merveilles, en gore), il fallait que je trouve en GD un système qui changerait du vampire survivors original.


J'ai recherché des références sur le jeu originel et pourquoi il pouvait être si bon.

J'ai remarqué, en testant le vampire survivors, que je n'aimais pas du tout rester statique et éliminer tout mes ennemis de loin.J'ai donc décidé que les armes que notre Alice utiliserait seraient du corps à corps, boostant la sensation de folie qu'on peut avoir en la jouant : On va dans le tas d'ennemis, et on essaie de les massacrer, les découper en morceaux de papier.
Le but était d'avoir un
Game Feel nerveux et agressif!
On s'est dit qu'on pourra utiliser la robe d'Alice en tant qu'arme, ce qui nous semblait intéressant.

Mon process pour créer les armes était le suivant :

Cela donnait ce genre de document :

Au final, nous n'avons pas eu le temps de faire les évolutions, mais j'ai globalement suivi ces schémas d'amélioration lors de la jam, que j'ai adapté pour équilibrer le jeu.

Pour les ennemis, nous ne nous sommes pas prit la tête.On a décidé de faire des ennemis simples, qui iraient vers le joueurs, avec deux styles d'ennemis corps à corps différents pour indiquer leurs puissance. Ils allaient s'améliorer au fil de la courte partie (5 min).Cela améliorerait le Game Feel si on pouvait massacrer de plus en plus d'ennemis.


Il était important pour moi d'ajouter un ennemi qui tire à distance.Le joueur pouvait techniquement rester sans bouger pour taper autours de lui. Je voulais forcer son mouvement, et le faire aller vers les ennemis.

Phase 2 - Programmer les éléments

Après avoir reçu une base 2D de Vampire Survivors (un cercle tirant sur d’autres cercles), j’ai d’abord étudié et transposé le code en 3D.L’objectif était de rapidement pouvoir créer les armes et de faciliter l’intégration des assets par ma coéquipière.J’ai ensuite créé un script par arme et utilisé des Scriptable Objects pour gérer leur évolution, facilitant l’équilibrage en fin de projet.

Ma méthodologie a été de développer les armes des plus simples aux plus complexes en réutilisant et modifiant du code existant :

Cette approche m’a permis d’itérer rapidement et de détecter facilement les bugs.
J'ai d'ailleurs simplement reprit le code des "tirs" d'Alice pour ensuite les transposer sur les ennemis.

Après avoir codé les armes, j'ai pu tester le jeu en profondeur, et il y avait deux problèmes
qui apparaissaient :

Pour y remédier :
Les ennemis donnent directement l’XP.Alice peut dépenser de l’XP pour "crier" et repousser tous les ennemis visibles.Monter de niveau la soigne, incitant les joueurs à éliminer un maximum d’ennemis.
Ces solutions ont permit de fluidifier le jeu, et de le mener à une direction différente du Vampire Survivors classique.

Phase 3 : Polish, équilibrage

Avec les armes, l’XP et le sauvetage en place, il restait peu de temps pour finaliser le projet.
J’ai consacré la fin du projet au polish : intégration des animations, ajout de FX, amélioration des feedbacks (dégâts, sons dynamiques) et correction des derniers bugs.

Et enfin, je me suis laissée une part de temps pour équilibrer le jeu, tandis que ma coéquipière retravaillait l'UI.

En conclusion

Ce projet court mais enrichissant m'a permis de renforcer mes compétences en programmation.Pouvoir créer directement les prototypes d'armes imaginés était efficace pour les tester.Cependant, certains points auraient pu être améliorés :Le thème du jeu manque de profondeur.Plus nous créons de projets au sein de notre école, plus il m'apparait qu'un jeu au thème fort et à l'identité unique est important.
Aucune mécanique unique ne distingue ce jeu de Vampire Survivors, alors qu’un système basé sur le papier (comme les origamis) aurait pu apporter de l’originalité.

• Retour à l'accueil