FICHE SIGNALETIQUE :

Moteur: Unity.Genres: Action, Aventure, Infiltration.Cible: Joueurs matures bercés par la culture nipponne, notamment par les manga et animés des années 80 à 2000, à la recherche d'un jeu d'infiltration nostalgique.Contraintes: Il s'agit du projet de fin d'étude, nous l'avons développé en groupe de 4 Game Designers et 2 artistes 3D, le tout sur une durée de 10 mois en parallèle des cours et autres devoirs.

USP :

Le personnage de Binah est mis en scène de façon à mettre en avant le développement d'une conscience. Cette aspect est soutenu par la narration et le Gameplay.Le personnage du joueur passe progressivement de personnage principal à personnage de soutiens.Le joueur observe le monde depuis des caméras intra-diégétiques dont il prend le contrôle.Une esthétique inspirée des mangas et des animés Cyberpunk des années 90.

Mon travail :

System Designer et Programmeur, j'ai travaillé sur l'intégralité des mécaniques du jeu et me suis chargé de la programmation du jeu dans son entièreté.Pour transmettre l'évolution de Binah par le gameplay je me suis renseigné sur differents paternes d'IA et me suis avec deux options, l'Utility AI et le GOAP (Goal-Oriented Action Planning).L'Utility AI attribut un score à chaque actions possibles basé sur des variables internes. Il sert à évaluer la pertinence d'une action.Le GOAP définit un enchainement d'actions en vu d'un objectif. Il sert à planifier.Ce dernier me laissait rêveur pour ce qui est de mettre en scène une évolution chez Binah. Mais il s'accompagnait aussi de beaucoup trop de soucis qui allaient soit réduire l'impact de ce système soit aller contre le flow du jeux. Par exemple la difficulté du jeu aurait été grandement réduite par la possibilité de simplement indiquer l'objectif suivant à Binah et la laisser faire. La voir planifier trop longtemps dans le future serait aussi perturbant par ce que le raisonnement paraitrait plus abstrait.Alors j'ai décidé d'implémenter l'Utility AI qui s'adaptait bien mieux au gameplay moment to moment. Binah peu refuser d'effectuer une actions, en effectué une autre ou agir d'elle même selon l'état de ses variables internes. L'utility AI est utilisé dans des jeux comme les Sims.J'ai également conceptualisé et implémenter un système de détection précis basé sur la lumière et les parties du corp visible par les IA ennemies. Chaque os de l'armature de Binah se voit attribuer une cible utilisé pour un lancer de rayons vérifiant sa visibilité. La position de cette cible est également utilisé pour sample le niveau de luminosité ambiant depuis le Light Probes et ainsi définir un score au membre visible qui s'ajoute a la jauge de détection de l'IA ennemie. D'autres paramètres comme la distance ou la proximité avec d'autres ennemie influent sur le score final et donc la vitesse de détection.Malheureusement les systèmes cités jusqu'à présent n'ont pas pu être implémentés correctement dans les niveaux à cause de retards dans leur productions hors de mon contrôle. Pour compenser ces manques nous avons décidé de scripter manuellement certains passages pour tout de même faire passer la progression de Binah par le gameplay.Pour que les déplacements de Binah paraissent le plus naturels possible et impacté par on environnement et son état à elle. J'ai apporté des modification au path finding de Unity de manière à ce qu'elle évite les zone de danger et de stresse en les contournant légèrement. Ces chemin sont considéré comme plus couteux par l'algorithme. Il peut s'agit d'un endroit définit manuellement ou alors lié a la présences d'ennemies.Pour rendre les ennemies moins robotique j'ai implémenté un système de chemin de patrouille dynamique. Un ennemis qui aurait chassé Binah loin de son chemin de patrouille original en cherchera un nouveau plus proche plutôt que de simplement revenir sur ses pas après avoir perdu Binah de vue.J'ai également fait le blocking d'un niveau en prenant en compte les positionnement des ennemis et les points de vue fixe des caméras. Le niveau était jouable de bout en bout mais n'a pas pu être habillé à temps. Et pour faciliter la création de niveau j'ai aussi développé des outils. Par exemple pour la création procédurale d'échelles utilisable.

Ce que j'ai appris :

J'ai réalisé l'importance et l'omniprésence du Game Design même dans les jeux aux ambitions narratives avec des gameplay plus passif et systémique.La taille du projet et la quantité de travail à abattre m'ont poussé à être plus proactif dans le groupe, au delà des tâches qui m'étaient directement associées.J'ai également pu approfondir mes connaissances de Unity et de programmation de manière générale.

FICHE SIGNALETIQUE :

Moteur: Unreal Engine 5.Genres: Parcours à la première personne.Cible: Joueur de jeu de parcours à la première personne avec des éléments contemplatifs.

USP :

Le joueur est encouragé à aller de plus en plus vite. Effectuer des actions de parcours apporte un bonus de vitesse temporaire cumulable.

Mon travail :

J'ai principalement travaillé sur le prototypage et développement des mécaniques de déplacement.Je me suis également occupé du Level Design et Level Building. Nous manquions d'artistes 3D, nous n'avions donc demandé qu'un ensemble tile set limité de cathédrale gotique en espérant pouvoir polish au maximum cette partie de l'environnement, j'ai construit tout le bâtiment pièce par pièce. Malheureusement le reste du niveau n'à pas pu recevoir le même soin et je regrette cette approche. Des matériaux triplanaire on dut être appliquer sur du blocking pour compenser le manque d'asset sans grand succès.J'ai aussi pris part à l'organisation. Mais n'étant que deux dans ce projet nous avions sous estimé son importance, ce qui se ressent dans l'aspect inachevé du projet.

Ce que j'ai appris :

J'ai pu prendre conscience de l'importance d'avoir un *scope adapté à la taille de son équipe et de ne jamais sous estimé la gestion de projet nécessaire. Dans le cas de ce projet nous n'étions que deux et Game Designer avec une visions trop grande et une suivit de projet trop laxe.Plus que de simplement éviter le scope creep, je fais désormais un effort actif pour le réduire dès que possible. Ca m'a beaucoup aidé dans mes projets personnels suivants.Aussi, remarque utile pour la reprise du projet. Nous avions remarqué qu'une vitesse trop rapide empêchait la contemplation sans aménagement particuliers. Dans cette version l'aménagement se résumait a allonger les ligne droite, créant bien trop de temps mort.

FICHE SIGNALETIQUE :

Moteur: Unity.Genres: Rogue Lite Top Down.Cible: Amateurs de Rogue Lite, de Science Fiction et de jeu nerveux.Contraintes: Le jeu a été developpé à 4 Game Designers en l'espace de 3 semaines. Nous devions utiliser Unity pour la première fois et nous inspirer du film "Sunshine".

USP :

Mourir permet de choisir une amélioration à conserver de façon permanente contre une réduction de sa vie maximum.

Mon travail :

Je me suis occupé du Game Design et équilibrage des systèmes de combat, incluant les compétences du joueur, les effets actif et passifs des artefacts et les comportements des ennemis. Après avoir définit une base solide je me suis également occupé de l'implémentation du Game Feel et de la Juiciness du jeu.La caméra a été un vrais défis, développant sur un écran à haut taux de rafraichissement, je poussais les effets trop fort. La présentation finale à du se faire sur une télé bloqué à 30FPS, ce qui a mis en avant ce problème. Mais le jeu était désagréable même a 60FPS à cause de la camera. Depuis le jeu à été mis à jour avec une caméra moins chaotique.Autre challenge, en tant que Lead du projet j'ai décidé d'assumer la production des niveaux à la place de la personne qui y était originalement attitré après qu'il ai échoué à livrer quoi que ce soit à de multiples reprises. Et pour éviter qu'il soit frustré je l'ai réattribuer au Sound Design, un domaine que je sais qu'il aimait. J'ai d'ailleurs appris plus tard qu'il avait volontairement saboté son travail en Level Design dans l'espoir de pouvoir s'occuper du Sound Design en prétendant en avoir fini avec le Level Design. Alors je pense avoir pris la bonne décision en le réattribuant si tôt. Malgré le désordre que ça a causé je suis fier d'avoir réussi à garder la situation sous contrôle.

Ce que j'ai appris :

Depuis ces problèmes d'intensité avec les effets de caméra, je fais attention à tester mon travail dans différentes situations pour être sur de ne plus laisser passer un over-sight aussi grand et problématique.J'ai aussi réalisé trop tard dans ce projet que le concept de base de progression rythmé par la mort était trop fragile pour être le cœur du jeu et qu'il encourageait les joueurs à mourir régulièrement plutôt que de persévérer. J'aurais du passer plus de temps à évaluer ce système avant de le valider.D'un point de vue relationnel, le groupe était composé de personnes s'entendant mal, et je faisais aussi parti du problème. Alors naviguer cette environnement m'à pousser à améliorer mes compétences en communication et en gestion, en restant professionnel.

FICHE SIGNALETIQUE :

Moteur de Jeu: Unreal Engine.Genres: Tower Defense.Cible: Joueur de Tower Defense lassé des layouts classiques et amateur de l'esthétique Maori.Contraintes: Le jeu à été développé par 5 Game Designers en l'espace de 3 semaines avec l'aide de la promo d'artistes 3D. L'utilisation d'Unreal Engine était imposée, de même que le thème "Tahiti".

USP :

La zone de jeu est répartie sur la hauteur d'un pilier que le joueur doit protéger. Des anneaux amovibles servant de support aux tourelles se trouvent autour du pilier, ils peuvent être tourné et déplacé verticalement. Les anneaux servent aussi de rempart protégeant physiquement le pilier.Elle est également divisée en deux zones, sous l'eau où se passe l'action et en dehors où le joueur peut améliorer ses défenses et réparer passivement les anneaux. Cette séparation encourage les joueurs à prendre des risques en jouant à l'aveugle.

Mon travail :

La phase de préproduction était chaotique, nous avions du mal a nous mettre d'accord. J'ai donc prototyper de nombreux systèmes pour nous permettre d'avancer dans le projet.Une fois la préproduction terminée je me suis occupé d'organiser l'emploi du temps de chacun pour être sûr d'avancer au bon rythme. Nous avions passé beaucoup de temps a choisir la voie a prendre et nous ne pouvions plus en perdre désormais.D'ailleur, mon groupe n'ayant aucune expérience avec le moteur de jeu, j'ai commencé la programmation seul en Blueprint le temps que mes camarades se puissent me rejoignent sur le code vers la fin du projet.J'ai également fait des recherches pour le rendu stylisé de la lumière et de la surface de l'eau. Ces deux effets ont été obtenu grâce à la modification de morceaux de code issues de tutoriels.

Ce que j'ai appris :

C'est la que j'ai découvert le pouvoir du prototypage comme outils de communication. Ca nous a vraiment permis de débloquer rapidement une situation qui nous semblait à tous désespérée.

FICHE SIGNALETIQUE :

Moteur: Godot.Genres: Platformer 2D, Semi Rogue Lite.Cible: Joueurs aimant les expériences courtes, typique des joueurs de Itch.io. Adaptée aux joueurs casuals comme plus expérimentés, prêt a en découdre pour s'améliorer.Contraintes: Il s'agit d'un projet solo développé en 3 mois. Le tout en parallèle des cours et de mon projet de fin d'étude, SEPHIRA-03.

USP :

Le joueur équilibre lui même son expérience pour profiter de son propos:

“Pour connaître une évolution personnelle saine, il est aussi important de travailler sur la définition de son idéal de soi, que sur le processus d'approcher cet idéal”

Il est libre de choisir comment atteindre son objectif. Sa façon de faire reflète sa personnalité, mais il n'y a pas un seul profile qui ne puisse pas s'y retrouver.

Mon travail :

S'agissant d'un projet personnel de fin d'étude, j'ai conçut et développé IMPROV entièrement seul:J'ai commencé par la définition du propos après une discussion avec une amie sur le sujet, puis j'ai réfléchit aux genres et aux mécaniques qui s'y adapteraient le mieux.Une fois le jeu et ses objectifs définit et documentés, j'ai commencé en parallèle l'apprentissage de Godot, et le prototypage sur ce dernier.Pour le double du joueur, j'ai développé des outils pour enregistrer mon gameplay. Ce système était plus rigide qu'une IA, mais aussi bien plus simple à implémenter. J'ai dû attendre les derniers équilibrages avant d'enregistrer mon gameplay. Ce qui n'était pas facile non plus, je ne devait ni aller trop vite, ni trop lentement.

Le Game Design Document de Improv est disponible sous format Word en haut de la page. Il s'agit d'un livrable demandé par l'école, pas du document vivant utilisé pendant le développement du jeu. Ayant utilisé Notion je ne pouvait pas le rendre pour ce devoir.

Ce que j'ai appris :

Il s'agit du projet qui m'à le plus apporté en terme d'expérience de gestion de projet.J'ai du me tenir à une organisation stricte et un suivi de projet clair avec Notion pour réussi à le produire dans la fenêtre de temps que je m'était accordée. Ce n'était pas facile, le jeu ayant été développé en parallèle des cours et de mon projet de fin d'étude, SEPHIRA-03.

FICHE SIGNALETIQUE :

Moteur: Godot.Genres: Idle Game.Cible: Joueurs casual à tendances hyperactives ayant besoin de distractions pendant qu'il font d'autres choses, qu'il travaillent, étudient ou regardent des vidéos.Contraintes: Je voulais utiliser Godot après un moment sans avoir utiliser le moteur.

USP :

La progression est lié à la physique des dé, progresser dans le jeu le rend de plus en plus juicy. Et des modificateur aléatoire inspiré des Rogue Lite s'ajoutent à ça pour rendre le jeu encore plus chaotique. Ils influencent la physique avant d'influencer les statistique pour jouer plus efficacement sur le gimmick de base.Dice Thrower est aussi pensé comme un jouet. La fenêtre reste en overlay par dessus les autres activités du joueur, comme un jouet sur son bureau pour encourager ce rapprochement.

Mon travail :

L'idée m'est venue en jouant à Cookie Clicker et en réalisant que même si le jeu est amusant tel quel, il n'est pas vraiment juicy en comparaison à la progression numérique. Je me suis dit qu'ajouter de la physique à ce genre de jeu serait génial, et en pensant à la physique et aux nombres, les dés me sont venus directement à l'esprit. J'ai fait quelques tests et j'ai découvert que le résultat était déjà très amusant sans aucun système de progression.

Le projet est actuellement en pause, après un début très prometteurs j'ai rapidement fait face à plusieurs obstacles qui m'ont nettement ralenti et finalement poussé à mettre en pause le projet. Il n'a toujours pas repris mais n'est pas pour autant à l'abandon. Voici quelque détails sur le projets et comment je l'ai abordé:Pour commencer j'ai très vite décidé de concentrer mes efforts sur le feeling en priorité, quitte à délaisser l'équilibrage pour un temps.Je me suis fixé comme règle que la majorité de mes modificateurs se devaient de se concentrer sur la physique pour rester pertinent avec le gimmick. Et je pense toujours que c'était une bonne décision, seulement, il n'y a pas tant de façon d'influencer la physique de manière pertinente que ça... Beaucoup de mes effets sont de simple variations les uns des autres plus que des changements radicaux.À cela s'ajoute le problème de l'équilibrage, l'ayant délaissé pendant trop longtemps je ne savais plus pas ou commencer et la perspective d'équilibrer un tel jeu m'effrayait. C'est la principal raison de la mise en pause de ce projet.L'audio n'a pas été particulièrement difficile à implémenter, mais je suis très content du rendu alors je tiens a préciser que la vidéo en haut de page inclus le son.

Ce que j'ai appris :

J'ai réalisé trop tard qu'il était bien plus difficile que je ne le pensais d'équilibrer un Idle Game, et que les contraintes physiques ajoutées rendaient la tâche encore plus complexe.

FICHE SIGNALETIQUE :

Moteur: Unity, Prototype fait sur Godot.Genres: FPS, Parcours, Walking Simulator.Cible: Joueurs attirés par les expériences courtes aux thématiques fortes avec des éléments contemplatifs. Ainsi que les joueurs attiré par un potentiel d'expression mécanique élevé.Contraintes: Nous développons le jeu à deux sur notre temps libre et visons une durée de production de 3 ans.

USP :

Tout est fait pour encourager le joueur à ne jamais s'arrêter.La narration et la contemplation se font en mouvement. Ces éléments deviennent alors accessible même aux joueurs les moins patients en leur garantissant une progression continue. Il ne s'agit pas d'un compromis, mais d'un outils thématique et mécanique.

Comparaison effets de camera désactivé et activé à 00:24

Démonstration des plateformes mobiles

Démonstration des interactions

Mon travail :

Responsable du Gameplay Design et du Game Feel, pour garantir que les contrôles soient agréables mécaniquement parlant je les ai prototypés en isolation, sans aucun effet superficiel.Après quoi, j’ai ajouté des effets de caméra et procédé à un rééquilibrage des mouvements. Avec les feedback supplémentaire nous avons constaté que le personnage se déplaçait trop rapidement.Le travail sur le Game Feel est encore loin d'être fini. L'ajout d'un model animé viendra chambouler l'équilibre actuel. Les effets de caméra étant volontairement over-tuned pour compenser le manque actuel d'assets.Craignant que ma collègue se sente laissée pour compte concernant le réglages de ces effets de caméra de par les connaissances techniques requises pour leurs réglages. J'ai créé un outils permettant d'effectuer ces réglages sans connaissances particulières ainsi que de créer des presets pour faciliter les comparaisons.Un défis particulier issue du mon implémentation custom des déplacements dans Unity était le support des plateformes mobiles.Le système d'interaction pour notre jeu se devait d'être généreux pour ne pas encourager le jouer à s'arrêter par peur de manquer de précision, être consistant peu importe la distance et être performant pour des scènes complexes. J'ai alors conceptualisé et implémenté un système sans collisions à base de comparaison de vecteurs qui limite l'usage des raycast coûteux en les réservant à des tests d'occlusion optionnel.J'assure également le maintient d'un Devblog.

Ce que j'ai appris :

Il s'agit de notre premier projet non scolaire ensemble et nous voyons les chose en grand. L'importance d'une organisation rigoureuse nous a sauté au yeux des la première semaine, il en va de même pour l'importance de la documentation.Ce projet m'apprend également à accorder moins d'importance à la qualité de mon code et plus à son utilité. Pour ça, prototyper le jeu dans un moteur temporaire était une excellente idée.