TomoTomo

TomoTomo est un jeu développé dans le cadre du Gamagora Game Show (GGS), un événement organisé par la section Gamagora de l'Université Lumière Lyon 2.

Le GGS réunit les étudiants du master informatique spécialisé dans le jeu vidéo ainsi que ceux des licences professionnelles Métiers du Jeu Vidéo, notamment les sections I3D et Level Design. Pendant quatre mois, les étudiants des trois sections sont répartis en quatre équipes pluridisciplinaires afin de concevoir ensemble un jeu vidéo complet.

Concept du jeu

TomoTomo est un platformer semi-ouvert se déroulant dans une ville japonaise du début des années 2000. Le joueur peut explorer librement les rues et les toits de Yōhōbakoto.

Son objectif est de collecter des batteries, débloquer de nouvelles améliorations et récupérer progressivement ses capacités perdues, tout en échappant aux patrouilles de la ville.

Présentation du jeu

---

Structure générale du Level Design

Afin de simplifier la production des assets dans le temps imparti, l'ensemble du jeu se déroule dans un seul biome : une grande ville rétro-futuriste.

Cette ville est divisée en cinq zones ouvertes, chacune ayant une identité et une mécanique principale différente :

• le hub central ;
• la zone centrée sur le Wall Run ;
• la zone centrée sur les ennemis ;
• la zone centrée sur les rails ;
• la zone centrée sur le parkour.

J'étais responsable de la conception de la zone centrée sur le parkour.

Chaque zone étant ouverte, le joueur doit l'explorer afin de réaliser les quêtes proposées par les PNJ et de trouver les différentes batteries cachées dans l'environnement.

Chaque zone possède également un marchand permettant de débloquer une nouvelle capacité lorsque le joueur dispose d'un nombre suffisant de batteries.

Chaque niveau contient trois batteries, chacune associée à une manière différente de jouer :

• Une batterie d'exploration, cachée dans l'environnement.
• Une batterie de Time Trial, obtenue en réussissant un défi chronométré.
• Une batterie liée à la compétence du niveau, nécessitant d'utiliser la capacité spécifique de la zone pour l'obtenir.

Mon rôle et mes contributions

Au cours de ce projet, j'ai occupé plusieurs rôles au sein de l'équipe : Game Designer, Level Designer, QA et médiateur au sein de l'équipe.

Game Design

Avec mes collègues de la section Level Design, nous avons collectivement travaillé sur la rédaction du Game Design Document (GDD).

La majorité de sa rédaction a été réalisée en collaboration avec l'ensemble de l'équipe, mais certaines parties ont été conçues presque entièrement par moi-même.

J'ai notamment travaillé de manière particulièrement autonome sur la partie consacrée à la Homing Attack, ainsi que sur l'intégralité du document consacré au Game Feel.

Level Design — Jigoku / Tengoku

J'étais responsable de la conception du niveau Jigoku / Tengoku.

Ce niveau possède une structure particulière puisqu'il est séparé en deux parties : une première zone située au sol, puis une seconde située au-dessus des nuages.

Partie basse — Exploration

La partie basse est principalement centrée sur l'exploration. Le joueur doit notamment aider un PNJ en retrouvant deux objets dispersés dans la zone.

Partie haute — Parkour

La partie située au-dessus des nuages est davantage orientée vers le parkour, avec une grande section centrée sur la compétence spécifique de mon niveau : la récupération de boost grâce aux barrettes de RAM.

Dans cette section, le joueur doit traverser un parcours composé de plateformes qui disparaissent sous ses pieds. Il doit courir et sauter tout en suivant précisément le tracé formé par les barrettes de RAM.

Problèmes rencontrés et solutions

Donner une identité aux environnements

Problème observé

Lors d'un playtest, une remarque revenait régulièrement : les différents environnements se ressemblaient trop et leur identité n'était pas suffisamment marquée.

Solution proposée

Pour renforcer l'identité de mon niveau, j'ai proposé d'y ajouter une dimension de lore.

La partie supérieure représente le paradis, où vivent les personnes riches, tandis que la partie inférieure représente les enfers, où vivent les populations plus pauvres.

Le lien entre ces deux espaces est constitué par un immense hôtel, permettant d'accéder aux parties situées dans le ciel. Sa conception est notamment inspirée du Marina Bay Sands.

Contraste entre les deux parties

Dans la partie basse, une grande rue centrale mène jusqu'à l'entrée de l'hôtel. Cette rue est relativement belle et accueillante, tandis que les zones qui s'en éloignent deviennent progressivement plus étroites, plus sales et plus mal fréquentées.

Ce contraste permet de renforcer visuellement la différence entre les différentes catégories sociales représentées dans le niveau.

Pour accentuer encore cette séparation, la lumière globale de la partie basse possède une teinte rougeâtre, tandis que la partie supérieure est davantage teintée de bleu.

Cette dominante rouge distingue également le niveau de l'atmosphère des autres zones du jeu et contribue à lui donner une identité visuelle propre.

Une solution adaptée aux contraintes de production

Afin de renforcer cette identité sans ajouter une charge de travail importante à la section I3D, j'ai réutilisé les textures déjà créées pour les bâtiments en faisant varier leurs couleurs.

J'ai ainsi créé plusieurs variations colorées des textures utilisées dans les différents niveaux, puis sélectionné principalement les variantes proches du rouge pour mon niveau.

Cette approche m'a permis de donner une identité visuelle plus forte à la zone tout en limitant le travail supplémentaire demandé à la section I3D.

Améliorer le guidage du joueur

Problème observé

Lors d'un autre playtest, nous avons constaté que certains joueurs étaient régulièrement perdus et ne savaient pas clairement où aller malgré le système de guidage basé sur le breadcrumbing.

Solution proposée

Nous avons donc décidé d'expérimenter un véritable langage visuel de Level Design permettant d'orienter naturellement le joueur dans l'environnement.

Ce langage visuel est représenté principalement par la couleur violette.

Dès le tutoriel, le chemin est ainsi ponctué d'éléments violets permettant au joueur d'identifier progressivement cette couleur comme un indicateur de direction.

Ce système a ensuite été utilisé dans les différents niveaux grâce à des éléments adaptés à l'univers du jeu :

• enseignes publicitaires ;
• néons ;
• poubelles violettes ;
• fenêtres éclairées en violet.

L'objectif était de créer un guidage intégré directement dans l'environnement plutôt que de dépendre uniquement d'éléments d'interface.

Game Feel

Afin d'assurer une cohérence dans les sensations de jeu, j'ai rédigé seul l'intégralité du document de Game Feel.

Son objectif était de définir précisément les effets visuels, sonores et les animations associés aux principales actions du joueur, afin de servir de référence commune pour l'ensemble de l'équipe.

Pour chaque mécanique, je me suis d'abord demandé quelles sensations le joueur devait ressentir — vitesse, puissance, fluidité, impact, etc. — avant d'imaginer les différents feedbacks permettant de renforcer ces sensations.

Toutes les propositions du document n'ont pas pu être implémentées. Voici cependant un extrait de la documentation réalisée :

Action	Feedback principaux	Intention de design	Référence
Ride	Traînée d'énergie sous les pieds et augmentation du FOV.	Renforcer la sensation de vitesse même lors des déplacements de base.	Bomb Rush Cyberfunk
Saut	Stretch vertical, léger délai de caméra et nuage de propulsion proportionnel à la vitesse du saut.	Rendre l'impulsion et la vitesse du saut plus lisibles et satisfaisantes.	Super Mario Odyssey Bomb Rush Cyberfunk
Atterrissage	Squash et onde de choc de fumée dont l'intensité dépend de la durée de la chute.	Donner du poids au personnage et renforcer l'impact de la réception.	Super Mario Odyssey
Boost	FOV augmenté, longue traînée de fumée, léger stretch vers l'arrière et oreilles plaquées par la vitesse.	Amplifier la sensation de vitesse tout en renforçant la personnalité et le côté attachant de Tomo.	Bomb Rush Cyberfunk
Homing Attack	Impulsion d'énergie et animation où Tomo s'élance avec le pied en avant.	Rendre l'attaque plus puissante, spectaculaire et agréable à utiliser.	Super Meat Boy Forever Sonic
Ramassage d'une batterie	Jingle dédié, particules allant vers le HUD et légère pause du jeu.	Transformer une récompense importante en moment gratifiant pour le joueur.	Super Mario Odyssey The Legend of Zelda
Time Trial	Compte à rebours sonore, tic-tac pendant l'épreuve et son spatialisé lors de l'apparition des anneaux.	Créer de la tension et guider le joueur sans dépendre uniquement de l'interface.	Mario Kart

QA et Playtests

En parallèle de mes missions de Game Design et de Level Design, j'ai également participé à la QA du projet. Afin de répartir le travail, nous nous sommes partagé les différentes mécaniques de gameplay entre les membres chargés de la QA. Cela nous permettait de tester plus précisément chaque mécanique et d'identifier les problèmes à corriger.

Les différents playtests nous ont permis d'identifier plusieurs problèmes de compréhension, de guidage et de lisibilité, puis d'adapter le jeu en fonction des retours obtenus.

Un premier contact avec les joueurs

Lors de la Lyon Game Dev en avril 2026, nous avons eu l'occasion de faire tester TomoTomo directement au public. J'ai notamment pu être aux côtés des joueurs pendant leurs sessions afin d'observer leur manière de jouer et de recueillir leurs avis, conseils et critiques.

Cette expérience m'a permis de constater que le cœur du jeu fonctionnait déjà : les joueurs prenaient du plaisir à jouer et comprenaient globalement le concept. Elle nous a également permis d'identifier les nombreux points qui nécessitaient encore du travail et des corrections.

J'ai également appris à prendre du recul sur les retours des joueurs. Tous les avis ne nécessitent pas forcément une modification du jeu : leur pertinence peut dépendre de l'expérience du joueur, de la manière dont il a joué ou encore du problème qu'il rencontre.

Cette expérience m'a donc permis de mieux comprendre comment trier et interpréter les retours de playtest afin d'identifier ceux sur lesquels il était réellement pertinent de travailler.

Médiation et communication d'équipe

En complément de mes missions de Game Designer, j'ai également joué un rôle de facilitateur au sein de l'équipe.

L'un des membres de l'équipe étant moins disponible durant le projet, j'ai aidé mon lead à maintenir une communication régulière avec lui.

J'organisais notamment des échanges vocaux afin de faire le point sur son avancement, de lui transmettre les informations importantes et de coordonner son travail avec le reste de l'équipe.

Cette démarche nous a permis de maintenir autant que possible une bonne collaboration malgré les contraintes de disponibilité.

Conclusion

TomoTomo m'a permis d'expérimenter plusieurs aspects du métier de Game Designer et de Level Designer dans le cadre d'une production en équipe pluridisciplinaire.

J'ai notamment pu travailler sur la conception d'un niveau, la rédaction d'un Game Design Document, la création d'un document de Game Feel, le playtest et la QA, ainsi que sur la communication au sein de l'équipe.

Le projet m'a également appris à concevoir en tenant compte des contraintes de production et à rechercher des solutions permettant d'améliorer l'expérience du joueur sans augmenter inutilement la charge de travail des autres pôles.

Tower of Baël

Tower of Baël est un jeu développé sur Unity en duo, sur une durée de deux semaines. Il s’agit d’un roguelike top-down twin-stick shooter, directement inspiré de The Binding of Isaac.

Objectif du projet

L’objectif du projet était double : permettre à mon collègue Houcine de réaliser son premier jeu complet, et me permettre de faire mes débuts en génération procédurale dans un contexte de production cadré.

Concept du jeu

Le joueur incarne un aventurier peu héroïque qui pénètre dans la tour de Baël afin d’en atteindre le sommet et d’affronter le boss final. Chaque partie propose une exploration différente grâce à la génération procédurale des salles.

Le gameplay repose sur des déplacements et des tirs dans huit directions, avec des variations possibles via des objets modifiant les attaques, comme le Trap Beam, inspiré du Brimstone.

Rôle et contributions personnelles

Sur ce projet, j’ai principalement travaillé sur :

• la génération procédurale des niveaux
• la logique environnementale et la caméra
• la conception et l’implémentation d’ennemis avancés
• la mise en place de comportements simples d’IA

Houcine était principalement en charge du gameplay du joueur, des systèmes de combat, de l’interface utilisateur ainsi que de l’ensemble des assets et animations.

Génération procédurale

Compte tenu du temps limité, j’ai mis en place une Path-based Procedural Generation simplifiée. Le niveau repose sur une grille logique stockée dans un tableau à deux dimensions, composée d’objets Room.

La génération suit les étapes suivantes :

• Placement de la salle de spawn au centre de la carte
• Placement aléatoire de la salle de boss sur le bord de la map
• Création d’un chemin principal de salles de combat entre les deux
• Ajout de salles secondaires (objets, combats) à proximité
• Instanciation des prefabs et génération des portes selon les connexions

Cette approche permet de garantir une progression cohérente tout en conservant une forte variabilité entre les parties.

Level Design

Le level design repose sur une structure en salles adjacentes, favorisant un sentiment d’exploration labyrinthique. Certaines portes peuvent être bloquées afin de contrôler les chemins possibles et le rythme de progression.

Plusieurs types de salles sont générés : salles de combat, salles d’objets, salle de boss et salle de départ, chacune étant identifiable visuellement par un code couleur.

Ce que ce projet démontre

• Capacité à concevoir et implémenter une génération procédurale
• Compréhension des contraintes de production en temps limité
• Travail en duo avec une répartition claire des rôles
• Création d’une structure de jeu scalable et rejouable
• Capacité à mener un projet fonctionnel jusqu’au bout

Lien du projet

Voir le projet sur itch.io

Lien du code source du projet

Voir le projet sur Github

Conclusion

Tower of Baël marque une étape importante dans mon apprentissage. Ce projet m’a permis d’expérimenter la génération procédurale, de mieux comprendre la structure d’un roguelike et de confronter mes choix techniques à un jeu réellement jouable.

Babbles

Babbles est un projet de Level Design réalisé en groupe de quatre, basé sur un jeu déja existant. L’objectif était de concevoir et blockouter de nouveaux niveaux jouables tout en respectant l’univers, le ton et les mécaniques du jeu original.

Objectif du projet

Le projet consistait à créer deux niveaux reliés narrativement dans le jeu Babbles, à l’aide de Unity. Les niveaux devaient être accessibles à un public grand public, avec une ambiance légère et peu sérieuse, en accord avec l’identité du jeu.

Concept général

Notre équipe a choisi de développer un arc narratif se déroulant dans deux environnements contrastés : une grande ville de type capitale pirate, suivie d’un volcan. Ces deux espaces sont liés par l’histoire et la progression du joueur.

Rôle et contributions personnelles

J’étais responsable d’environ la moitié du premier niveau, situé dans la ville. J’ai principalement travaillé sur :

• la zone industrielle
• la rue marchande nord
• la lisibilité des parcours
• le rythme de progression du joueur
• la documentation

Intentions de Level Design – Niveau 1 : Grande Ville / Capitale Pirate

Le premier niveau se déroule dans une grande ville pirate construite autour d’un volcan. L’objectif du joueur est de comprendre l’origine du problème et de rassembler les éléments nécessaires pour calmer la colère du volcan.

Intentions de gameplay

Le niveau est centré sur l’exploration, l’enquête et le dialogue avec les PNJ. Le joueur est encouragé à découvrir la ville, à interagir avec ses habitants et à comprendre leur mode de vie.

La verticalité est un élément clé du level design, renforçant la navigation et la variété des parcours.

Mécaniques utilisées

• Tremplins poulpes
• Geysers
• Courants marins

Ces mécaniques sont utilisées pour encourager le déplacement, le parcours et l’exploration de manière ludique et accessible.

Structure et progression

La progression repose sur une série de quêtes simples. Le joueur doit aider quatre personnages, chacun demandant un service en échange d’un objet nécessaire à l’avancée de l’histoire :

• Un maraîcher demandant de récupérer des graines
• Un éleveur cherchant son bébé baleine disparu
• Un antiquaire demandant de négocier avec un client
• Un chasseur demandant de récupérer un hippocampe en hauteur

je me suis charger des 2 dernier.

Ces objectifs obligent le joueur à explorer les différents quartiers et à utiliser les mécaniques de déplacement pour progresser.

Intentions narratives

Le niveau débute par l’arrivée du joueur dans un marché animé, où l’ambiance chaleureuse contraste avec le danger imminent du volcan. Sur la place centrale, un vieil homme prêche seul au sujet de la « colère du géant », sans être pris au sérieux.

Ce personnage, ancien sage, déclenche la quête principale en expliquant les rituels nécessaires pour calmer le volcan, incitant le joueur à parcourir la ville et à aider ses habitants.

Intentions artistiques et ambiance

La ville est pensée comme un espace vivant et diversifié, composé de quartiers marchands, résidentiels, historiques et industriels. Les matériaux (bois, pierre volcanique, métal) et la lumière du coucher de soleil renforcent l’identité pirate et chaleureuse de la cité.

Un contraste fort est créé entre les zones marchandes animées et la zone industrielle, plus froide et désertée, afin de raconter l’évolution et les tensions internes de la ville.

Fin du niveau

Une fois tous les objets récupérés, le joueur les rapporte au vieux sage, qui fabrique l’élément permettant de calmer le volcan. Le niveau se conclut par l’utilisation d’un courant marin menant au sommet du cratère, marquant la transition vers la suite du jeu.

Conclusion

Ce projet m’a permis de travailler le level design à partir d’un jeu existant, en respectant un univers, des mécaniques et des contraintes précises. Il m’a également appris à concevoir un niveau cohérent, mêlant exploration, narration et gameplay.

Deathtination Finale – A Floumby’s Stourie

Deathtination Finale est un jeu développé lors de ma première Game Jam (environ 54 heures), sur le thème de la mort. Le projet a été réalisé par une équipe de six personnes : trois développeurs, un artiste et deux level designers.

Pitch du jeu

Le joueur incarne Floumby, un extraterrestre au style cartoon, coincé dans un parking abandonné. La particularité du jeu repose sur une mécanique centrale : mourir permet de progresser.

Chaque mort débloque une nouvelle compétence indispensable pour continuer l’exploration, transformant l’échec en outil d’apprentissage et de progression.

Objectif de design

L’objectif du projet était de concevoir une expérience ludique autour de la mort, non pas comme une punition, mais comme un levier de gameplay. Le joueur est encouragé à expérimenter, prendre des risques et tester les limites du niveau pour découvrir de nouvelles possibilités.

Mécanique centrale

• La mort débloque des compétences
• Les compétences sont nécessaires pour accéder à de nouvelles zones
• Le joueur apprend par l’expérimentation et l’échec
• La progression est liée à la compréhension du level design

Game Design & Level Design

Avec mon collègue level designer, j’étais en charge du Game Design et du Level Design du projet. Nous avons travaillé conjointement sur la structure des niveaux, le rythme de progression et l’intégration des mécaniques.

J’ai notamment participé au brainstorming initial et proposé l’introduction du jeu par une chute depuis une grue. Cette séquence sert de tutoriel implicite, permettant au joueur de comprendre dès le début que la mort fait partie intégrante du gameplay et qu’elle est nécessaire pour avancer.

Contraintes et apprentissages

Ce projet m’a confronté à de fortes contraintes de temps, typiques d’une game jam. Il m’a appris à :

• faire des choix de design rapides et efficaces
• prioriser les mécaniques essentielles
• communiquer clairement les intentions de gameplay
• concevoir des niveaux lisibles en très peu de temps

Ce que ce projet démontre

• Capacité à concevoir un gameplay autour d’un thème imposé
• Compréhension du lien entre mécanique et level design
• Utilisation de l’échec comme outil de progression
• Travail en équipe dans un contexte de forte pression temporelle
• Conception de tutoriels implicites par le level design

Lien du projet

Voir le projet sur itch.io

Conclusion

Deathtination Finale a été un projet très formateur. Il m’a permis de travailler le game design et le level design sous de fortes contraintes de temps, et d’explorer une manière originale de faire progresser le joueur grâce à la mort.

L’Influence

L’Influence est un projet de Game Design réalisé en groupe de cinq, ayant pour objectif la création d’un nouveau genre vidéoludique : les Influence Games. Le projet comprend la définition théorique du genre, la rédaction d’un Game Design Document complet et la conception d’un prototype papier.

Pitch du genre

« Dans un Influence Game, le joueur n’est pas au centre de l’action, mais au centre des causes. »

Le joueur n’agit pas directement sur le monde, mais influence ses systèmes (personnages, environnement, objets ou règles), déclenchant des chaînes de causes et de conséquences au sein d’un monde autonome.

Objectif de design

L’objectif du projet était de sortir des schémas traditionnels du game design en proposant une expérience basée sur l’action indirecte, l’émergence narrative et la rejouabilité.

Le joueur observe, influence, puis s’adapte aux réactions du monde, sans jamais en avoir le contrôle total.

Boucle de gameplay principale

• Observer l’état du monde et des systèmes en place
• Identifier un ou plusieurs leviers d’influence
• Appliquer une influence indirecte
• Observer les réactions et effets en chaîne
• Adapter sa stratégie en fonction des conséquences

Principes fondamentaux du genre

• Action indirecte et non intrusive
• Monde autonome et crédible
• Chaînes de causes et conséquences
• Histoires émergentes
• Choix aux résultats partiellement imprévisibles
• Forte rejouabilité

Concept de jeu illustratif

Pour illustrer ce genre, nous avons conçu un jeu de comédie horrifique dans lequel le joueur incarne un fantôme cherchant à faire fuir un groupe de jeunes explorant sa maison abandonnée.

Le joueur n’interagit jamais directement avec les personnages. Il agit uniquement par l’environnement :

• ouvrir ou fermer violemment des fenêtres
• faire tomber des objets
• modifier l’ambiance sonore ou lumineuse

Ces influences modifient la peur, les croyances et les décisions des PNJ, générant des situations imprévues et des récits émergents.

Rôle et contributions personnelles

• Définition et formalisation du genre Influence Game
• Rédaction du Game Design Document
• Conception et tests du prototype papier
• Réflexion sur la lisibilité, les limites et les erreurs de design

Documents de conception

Consulter le Game Design Document et le cahier des charges

Aperçu du prototype papier

Conclusion

L’Influence est un projet structurant dans mon parcours de game designer. Il m’a permis de penser le jeu comme un ensemble de systèmes interconnectés, de questionner la place du joueur, et de concevoir une expérience où le sens émerge des interactions plutôt que d’un script imposé.

Projet Luna

Objectif du projet

Concevoir et présenter un concept de jeu original lors des sélections du Gamagora Game Show, en mettant l’accent sur la narration, l’intention de design et la cohérence du concept.

Pitch

Après une discussion avec sa mère autour d’un vieil album photo, Luna fait un rêve inspiré de son enfance marquée par la guerre. Accompagnée de son chien, Capitaine Babine, elle explore un monde de jouets et de souvenirs déformés pour sauver la mère enfant et comprendre son passé.

Concept de jeu

Projet Luna est un jeu d’infiltration coopératif asymétrique en 3D, centré sur l’observation, la discrétion et la coopération. La guerre n’est jamais montrée directement, mais suggérée par la symbolique, la tension et l’environnement.

Intentions

• Aborder la guerre par l’imaginaire et la métaphore
• Créer de la tension sans combat
• Raconter une relation mère-fille à travers le gameplay
• Faire ressentir l’oppression et la fragilité du monde

Gameplay

• Infiltration et gestion du bruit / visibilité
• Énigmes environnementales coopératives
• Complémentarité des personnages

Luna est orientée infiltration et interactions précises, tandis que Capitaine Babine crée des diversions et ouvre des chemins alternatifs.

Rôle et apprentissages

J’ai conçu le concept du jeu et rédigé le Game Design Document. Le projet m’a permis de travailler le lead design, la communication d’un concept et l’intégration des retours.
Projet Luna a été sélectionné jusqu’au dernier tour du Gamagora Game Show.

GDD

Consulter le Game Design Document

Blockout – Contrast

Contexte du projet

Blockout – Contrast est un exercice de Level Design réalisé dans Unreal Engine, dans le cadre d’un projet scolaire. L’objectif était de concevoir un niveau de type walking simulator jouable, en se limitant volontairement à un blockout (primitives, couleurs unies, sans assets visuels).

Objectif de design

L’objectif principal du projet était d’explorer comment le contraste peut guider le joueur et structurer son expérience, uniquement à travers la forme, la couleur et la composition de l’espace.

Le niveau devait proposer une expérience courte et contemplative, en mettant l’accent sur la lisibilité, la navigation et les émotions ressenties par le joueur, sans recourir à des éléments narratifs explicites ni à des assets détaillés.

Intentions artistiques et références

Un travail de recherche et de brainstorming a été réalisé en amont afin de définir les intentions visuelles et émotionnelles du niveau. Pour le traitement du contraste, je me suis inspiré du manga Blue Period, notamment pour ses ambiances urbaines froides et bleutées. Les wow moments s’inspirent quant à eux de Girls’ Last Tour, pour leur manière de révéler progressivement l’immensité des espaces.

Le niveau prend place dans une gigapole abandonnée, composée de vastes volumes artificiels et industriels, plongés dans des teintes froides. Ce décor sert de toile de fond à un contraste fort avec les rares zones habitées par l’humain.

Utilisation du contraste

Le contraste est exploité à plusieurs niveaux :

• Vie / mort
• Couleurs froides / couleurs chaudes
• Industriel / naturel
• Formes rigides et symétriques / formes organiques et asymétriques

La ville abandonnée est construite à partir de volumes carrés, massifs et symétriques, renforçant son aspect artificiel et inhumain. À l’inverse, les éléments liés au camp de survivants utilisent des formes plus rondes et irrégulières, traduisant une présence humaine et vivante.

Navigation et guidage du joueur

Le joueur débute l’expérience désorienté au sein de la gigapole et doit retrouver le camp de survivants. Pour l’aider à se repérer, des éléments laissés par le camp sont disséminés dans l’environnement :

• Feux de camp visibles à distance
• Structures en bois servant de repères visuels
• Contrastes de couleurs guidant naturellement la progression

Ces éléments remplissent à la fois un rôle de guidage, de navigation et de narration environnementale.

Structure et wow moments

L’expérience est rythmée par trois wow moments majeurs :

• La révélation de l’immensité du lieu, lorsque le joueur débouche sur une ville gigantesque au plafond très élevé, recouvert d’étoiles.
• La découverte du camp de survivants, dont l’atmosphère chaleureuse et organique contraste fortement avec la froideur de la ville.
• La révélation d’une structure verticale sur plusieurs étages, suggérant que l’espace exploré n’était qu’une fraction du monde réel.

Ambiance et expérience joueur

L’ambiance générale cherche à provoquer un sentiment de vide apaisant, mêlant solitude, contemplation et calme. L’objectif est de laisser au joueur le temps d’observer, de ressentir l’espace et d’interpréter lui-même le monde qui l’entoure.

Document d’intention

Télécharger le document d’intention

Aperçu vidéo du projet

Conclusion

Ce projet m’a permis de renforcer ma compréhension du Level Design à travers le blockout, notamment sur les notions de contraste, de composition, de framing et de guidage du joueur. Il m’a également appris à transmettre une intention claire et une expérience émotionnelle forte, même avec des moyens visuels très limités.

Ascension

Contexte du projet

Ascension est un jeu de société coopératif réalisé dans le cadre de notre tout premier examen de Game Design. Il s’agit également de notre premier projet de groupe, conçu entièrement à la main et en autonomie.

• Premier projet de Game Design évalué
• Premier travail de groupe en Game Design
• Premier jeu de société conçu
• Projet soumis à des contraintes de design imposées

Objectif du projet

L’objectif principal était de découvrir les bases du Game Design à travers la conception complète d’un jeu de société, en respectant des contraintes précises. Notre groupe a fait le choix de concevoir un jeu coopératif, mettant l’accent sur la communication, la coordination et la gestion du risque entre les joueurs.

Concept et inspirations

Le projet s’inspire de jeux tels que Chained Together, Peak et Mille Bornes. Ascension oppose plusieurs équipes de deux joueurs, en compétition les unes contre les autres, dont l’objectif est de gravir une montagne tout en restant physiquement reliés à leur partenaire.

La progression se fait à l’aide de cartes, sur un principe proche de Mille Bornes. Les joueurs avancent sur un plateau composé de cases pouvant déclencher des effets positifs ou négatifs.

Les joueurs disposent également d’objets leur permettant :

• de contrer certains effets de cases
• d’handicaper temporairement une équipe adverse
• d’accélérer leur propre progression

Livrable – Règles du jeu

Télécharger le document des règles

Apprentissages et conclusion

Ce projet a été extrêmement formateur. Il nous a permis de comprendre l’importance des tests, de l’itération et de l’équilibrage dans le processus de Game Design. Les nombreuses erreurs commises au cours du développement nous ont aidés à améliorer le jeu et à mieux saisir les enjeux de la conception ludique en groupe.

Jeu de la vie de Conway

Pour progresser en C++, j’ai décidé de ne pas me limiter uniquement au site learncpp.com. J’ai donc commencé à réaliser mes propres projets en C++. Le premier a été le développement du Jeu de la vie en utilisant la librairie Raylib.

C'est quoi le Jeu de la Vie ?

Le Jeu de la vie (Game of Life) est un automate cellulaire — devenu un jeu de simulation mathématique — imaginé par John Horton Conway en 1970. Malgré des règles très simples, il est Turing-complet. (Source : Wikipedia)

Le principe est simple : on a une grille sur laquelle on peut activer des cases. À chaque intervalle de temps, des règles s’appliquent sur toutes les cases de la grille pour déterminer leur état suivant (activée ou désactivée).

Les règles appliquées :

1 - Si une case désactivée possède exactement 3 voisines activées, elle devient activée.

2 - Si une case activée ne possède pas 2 ou 3 voisines activées, elle se désactive.

La première version (V1) du projet proposait une grille de taille moyenne sans possibilité de déplacement. Avec un clic de souris, on peut activer des cases. Les règles s’appliquent automatiquement toutes les secondes, mais on peut les interrompre grâce au bouton [S]. Je l’ai développée en me concentrant uniquement sur les fonctionnalités, sans me préoccuper de l’optimisation.

Dans la deuxième version du projet, je me suis concentré sur l’optimisation des performances en découvrant l’utilisation d’un profileur externe : Very Sleepy. Cet outil m’a permis d’identifier l’origine de ralentissements visibles lors des déplacements dans la grille.

Le problème venait d’une erreur de conception dans la fonction chargée d’analyser l’état des cases en fonction de leurs voisins. Plusieurs variables locales étaient instanciées à chaque itération, provoquant des réallocations inutiles. Bien que je savais que ce n’était pas une bonne pratique, je n’avais pas mesuré l’impact réel sur les performances. Une fois cette erreur corrigée, les ralentissements ont disparu.

J’ai ensuite augmenté volontairement la taille de la grille afin de pousser le système dans ses limites et identifier de nouveaux goulots d’étranglement. Après avoir doublé sa taille, un nouveau problème de performance est apparu.

L’analyse a montré que ce ralentissement provenait principalement de l’utilisation répétée de la méthode find sur une std::map pour rechercher les voisins de chaque case.

Cela m’a conduit à me documenter sur les structures de données afin de mieux comprendre pourquoi la std::map n’était pas adaptée à ce cas et par quoi la remplacer. La solution retenue est l’utilisation d’un tableau statique.

Une std::map repose sur un arbre binaire équilibré, ce qui implique une complexité en O(log n) pour les recherches, alors qu’un tableau permet un accès direct en O(1) via un index. Le choix d’un tableau statique plutôt qu’un std::vector s’explique par le fait que la taille de la grille est fixe pour le moment.

Après avoir remplacé la structure de données initiale et optimisé les accès mémoire, j’ai poursuivi les tests en augmentant progressivement la taille de la grille afin d’identifier de nouveaux goulots d’étranglement.

En multipliant la taille de la grille par 4, un nouveau point critique est apparu : une structure utilisée pour stocker le nombre de voisins (nouveauxNbrVoisins) devenait à son tour trop coûteuse. J’ai donc appliqué le même raisonnement en réduisant les coûts d’accès et en évitant les opérations inutiles.

J’ai également optimisé la fonction de récupération des voisins. Initialement, celle-ci allouait un std::vector à chaque appel, ce qui engendrait de nombreuses allocations dynamiques. J’ai remplacé cette approche par un std::array, instancié une seule fois et réutilisé, ce qui a permis de réduire significativement le coût en mémoire et en temps d’exécution.

Avec une grille 8 fois plus grande, le programme restait fonctionnel mais atteignait environ 30 FPS (contre 60 FPS auparavant). À ce stade, il n’y avait plus de ralentissements majeurs, mais une perte de performance globale due au volume de calcul. L’analyse a montré que la fonction de vérification des voisins était devenue relativement stable (environ 0,08 ms), ce qui indiquait que le problème venait d’ailleurs.

Le nouveau goulot d’étranglement provenait du rendu : toutes les cellules étaient dessinées à chaque frame, même celles hors caméra. Avec plusieurs millions de cellules, cela représentait un coût inutilement élevé.

J’ai donc mis en place une optimisation du rendu en ne dessinant que les cellules visibles à l’écran (culling). Cette modification a permis de réduire drastiquement le nombre d’opérations graphiques.

En augmentant encore la taille de la grille (×32), un nouveau problème est apparu : le nombre total de cellules à traiter devenait trop important pour la fonction de mise à jour (VerifVoisin). Pour résoudre cela, j’ai changé d’approche en limitant les calculs uniquement aux cellules actives et à leurs voisines directes, plutôt que de parcourir toute la grille.

Cette optimisation marque un changement important : on passe d’une approche globale (toute la grille) à une approche locale (zones actives uniquement), ce qui améliore fortement les performances sur de grandes grilles.

Enfin, en poussant les tests jusqu’à une grille 256 fois plus grande, j’ai atteint une limite technique : la grille ne pouvait plus être stockée efficacement dans un tableau statique en mémoire.

Vidéo de démonstration

Lien de Téléchargement

GitHub

Comba d'la Mort

Contexte

Ce projet final a été réalisé en groupe de 2 dans le cadre de la fin de mon DEC en Techniques de l'informatique – option jeu vidéo. Il s'agit d'un jeu en 2D développé à l'aide d'Unreal Engine.

Consignes du Projet : Jeu 2D

Vous devez créer un jeu 2D, de type plateformer ou autre.

• Le projet peut être réalisé seul ou en équipe de deux.
• La présentation finale sera individuelle.

Le jeu devra intégrer les éléments suivants vus en session :

• Des animations via ligne du temps et propriétés.
• Des arbres de décision (au moins deux cas différents).
• Une minimap.
• Un système de dommages.
• Utilisation de Paper 2D.
• Une caméra qui suit le joueur.
• Des matériaux personnalisés.

Un effort de travail raisonnable est attendu.

Votre jeu doit inclure les fenêtres suivantes :

• Fenêtre d'accueil
• Fenêtre de jeu
• Fenêtre de fin avec possibilité de recommencer une partie

Principe du jeu

Comba d'la Mort est un jeu d'affrontement contre un boss. Le joueur incarne un héros seul qui doit affronter la Mort à travers 4 phases distinctes.

Fonctionnalités principales

• Personnage jouable (Character) animé dans 8 directions :
  • Système de vie et de stamina.
  • Roulade activant un bouclier renvoyant les projectiles (comme dans Hades), si la stamina est supérieure à 50%.
  • Attaque normale avec possibilité de combo : si le joueur appuie au bon moment, une deuxième attaque plus puissante est déclenchée.
  • Attaque chargée rotative (inspirée des Zelda 2D).
• Boss (animé dans 4 directions) :
  • Points de vie répartis par phase. À chaque fin de phase, le boss se téléporte dans une nouvelle zone.
  • Contrôlé par un AIController et un Behavior Tree.
  • Peut attaquer au corps à corps.
  • Peut invoquer un crâne qui fonce sur le joueur (renvoyable avec le bouclier).
  • Peut invoquer deux types de mobs : un squelette et un Witch Doctor.
  • Ses capacités se débloquent progressivement à chaque nouvelle phase.
• Squelette : animé dans 4 directions, attaque en mêlée.
• Witch Doctor : animé dans 4 directions, fuit le joueur tout en invoquant des crânes à distance.
• Système automatisé de placement : ajout automatique de Blueprints au-dessus de certaines tuiles de la TileMap (ex. : piques infligeant des dégâts placés automatiquement sur toutes les tuiles correspondantes).
• Détection de la mort du joueur ou de la victoire, avec affichage de l’écran correspondant.
• Système de caméra et de mini-carte empêchant tout dépassement en dehors des limites de la carte active.

Mon rôle

Voici les éléments dont je me suis chargé :

• Développement complet du personnage jouable.
• Création de l’interface utilisateur (vie, stamina, écrans de fin).
• Conception des cartes (maps) 3 et 4.
• Système d’ajout automatique de Blueprints sur les tuiles ciblées.
• Programmation du Witch Doctor.
• la gestion de la camera et minimap
• Création d’un composant de gestion d’animation 2D facilitant l'utilisation des flipbooks :
  • Utilisable dans n'importe quelle blueprint tant qu'il y a un flipbook
  • Ignore les demandes de changement si le flipbook en cours est déjà celui demandé.
  • Choix du looping ou non de l’animation.
  • Flip horizontal si nécessaire.
  • Support d’animations prioritaires non annulables pendant leur exécution.

Vidéo de démonstration

Conclusion

Je suis plutôt fier de ce projet et de ce que nous avons réussi à accomplir à deux dans le temps imparti. C’était mon premier projet en groupe sur Unreal Engine, et également mon premier projet UE en 2D.

Mini Projet : Behavior Tree

Objectif du projet

Ce projet a pour but de développer un jeu interactif où le joueur doit résoudre des équations mathématiques en interagissant avec un protagoniste. L'objectif est d'acquérir des compétences en :

• Création d'un personnage jouable pouvant se déplacer librement dans un environnement.
• Utilisation de classes ou structures pour gérer les équations mathématiques.
• Mise en place d'un protagoniste non-joueur (PNJ) qui interagit avec le joueur à des moments précis.
• Développement d'un système de réponse permettant au joueur de saisir une solution.
• Ajout d'une rétroaction pour indiquer si la réponse du joueur est correcte ou incorrecte.

Consignes du projet

• Le joueur doit pouvoir se déplacer librement dans l'environnement.
• Le jeu doit inclure une classe ou structure contenant une équation mathématique à résoudre.
• Un protagoniste non-joueur (PNJ) doit être présent et interagir avec le joueur aux moments opportuns.
• Le joueur doit pouvoir saisir une réponse à l'équation proposée.
• Une rétroaction doit être affichée pour indiquer si la réponse est correcte ou incorrecte.

J'ai eu de la chance sur ce projet, car j'avais déjà développé mon système de dialogue dans le projet précédent. J'ai donc pu passer mon temps à l'améliorer au maximum.

Doc technique :

Télécharger le document

Aperçu Video du projet :

Mon Behavior tree

Conclusion

Je suis content des améliorations que j'ai pu apporter à mon système de dialogue. Je pense avoir parfaitement fait ce qui m'a été demandé.

Jeu de Recherche - Collecte d'Objets

Objectif du projet

Ce projet a pour but de concevoir un jeu où le joueur doit explorer un environnement en vue à la troisième personne afin de collecter des objets pour accomplir une tâche spécifique. L'objectif est d'acquérir des compétences en :

• Création d'environnements interactifs et immersifs.
• Gestion de l'inventaire et affichage des objets collectés.
• Utilisation d'une mini-carte pour guider le joueur.
• Modélisation d'objets et de structures dans Blender.
• Ajout d'animations pour améliorer l'expérience de jeu.

Consignes du projet

Vous devez créer un jeu de recherche dont vous déterminerez vous-même le but. L'objectif est de récolter des objets dans l'environnement afin d'accomplir une tâche. Le jeu doit inclure au minimum trois objets à récupérer.

Exigences

• Le jeu doit être en vue à la troisième personne.
• Une vignette avec une vue du dessus doit indiquer les endroits clés (certains peuvent être inaccessibles en début de partie).
• Ajout de bâtiments et/ou structures pour enrichir l’environnement.
• Intégration d'animations pour rendre le jeu plus dynamique.
• Une liste des objets récupérés doit être affichée à l'écran.
• Les objets du jeu doivent être créés dans Blender.

Doc technique :

Télécharger le document

Lien de Téléchargement

GitHub

Aperçu Video commenter du projet :

Connclusion

Je suis content de ce projet. Pour moi, il y aurait quelque point a retravailler comme la décoration de l'environnement et la qualité globale des graphismes, mais j'en suis quand même fière.

Escape Games VR

Objectifs du projet

Nous faire découvrir la VR sur Unreal Engine

Consigne

Créer un jeu VR d’Escape Game avec un environnement et au moins 5 énigmes.

Lien de Téléchargement

GitHub

Présentation du projet

Plongé dans l’atmosphère oppressante d’une vieille mine abandonnée, le joueur incarne un aventurier téméraire, attiré par le mystère des profondeurs. Mais alors qu’il explore les galeries sombres, un éboulement soudain l’emprisonne sous terre. Désormais seul et coupé du monde extérieur, il n’a qu’un seul objectif : rassembler les éléments nécessaires pour construire une bombe et se frayer un chemin vers la liberté.

Voici un aperçu de la première salle :

Le joueur commence dans le noir. Il n’a qu’une lampe pour s’éclairer.

Au fond, on peut voir des étincelles. Elles servent à indiquer la présence d’un élément électrique, qui pourrait — par hasard — allumer la lumière.

Pour y accéder, le joueur doit déplacer un wagonnet qui bloque l’entrée. Mais il est trop lourd : on peut l’attraper, mais pas le bouger.

Il faut alors vider le wagonnet de ses pierres. Une fois allégé, le joueur a accès à un bouton électrique qui allume les lanternes.

Aperçu de la salle une fois les lumières allumées :

---

Étape suivante : Exploration de la salle

Le joueur peut interagir avec plusieurs éléments :

– Un tiroir peut être ouvert. À l’intérieur se trouve un bâton de dynamite.

– Avec cette dynamite, il peut commencer à construire une bombe à partir du schéma de la maquette.

Un keypad est également présent. Le joueur peut appuyer physiquement sur les boutons.

Pour trouver le code du keypad, un livre est caché dans la salle. Une énigme s’y trouve :

Une fois le bon code entré, cela ouvre un casier contenant une clé.

Cette clé permet d’ouvrir la porte menant à la deuxième salle.

---

Deuxième salle

Aperçu de la deuxième salle :

Dans cette salle, un bâton de dynamite est caché derrière des livres de la bibliothèque.

Sur un mur, il y a trois lanternes. L’énigme est de les allumer dans le bon ordre.

Pour trouver l’ordre, un dé coloré est visible près des lanternes. Il faudra retrouver les deux autres dés dans la salle.

Une fois l’énigme résolue, cela ouvre une boîte.

Dans cette boîte, il y a deux choses : un coffre-fort et une plaque métallique.

Pour ouvrir le coffre, il faut entrer un code sur un autre keypad, qu’on peut trouver en analysant la plaque.

La plaque montre un emplacement précis dans la carte, où le code est visible.

Une fois le code saisi, le coffre s’ouvre et donne un dernier bâton de dynamite.

---

Construction de la bombe

Avec les trois bâtons de dynamite, on peut maintenant construire la bombe.

La bombe est placée sur l’éboulement, ce qui déclenche un compteur.

Cela permet de terminer la partie.

---

Objectif bonus : les diamants

Mais ce n’est pas la seule fin possible !

Un objectif caché existe. L’indice se trouve sur la main gauche du joueur :

En effet, des diamants sont dissimulés un peu partout dans la map.

Si vous les récupérez, un compteur s’affichera à la fin pour vous indiquer si vous les avez tous trouvés.

Il est même possible — mais peu probable — de finir la salle sans jamais en voir un seul !

Conclusion

Je suis relativement fier de mon projet, même si je pense que j’aurais pu faire mieux. Certaines fonctionnalités ne sont pas entièrement fonctionnelles, ce qui me laisse un peu sur ma faim.

ESP : Crusader’s Ordeal

ESP signifie « Épreuve Synthèse de Programmes ».

Ce projet de fin d’année nous laissait libre de choisir ce que nous souhaitions développer, à condition de mobiliser les compétences acquises pendant la formation. J’ai choisi de créer un jeu de duel en réseau local (LAN).

Deux grandes composantes :

Le projet se divise en deux grandes parties :

• La fonctionnalité en ligne : permettre à deux joueurs sur deux ordinateurs différents, dans le même réseau, de rejoindre une session commune.
• Le gameplay de combat répliqué : attaque, barre de vie, esquive, parade, combos, etc.

En plus de ces aspects, j'ai essayé de prendre en compte autant que possible la prévention de la triche dans mon jeu. J'ai conçu la logique en gardant cela à l'esprit, par exemple en empêchant la modification de la barre de vie depuis le client. Cette gestion est toujours effectuée par le serveur.

Planning du projet

Voir sur Notion

Lien de téléchargement

Code source sur GitHub

Vidéo de démonstration (avec les deux POV en simultané)

Conclusion

Je suis plutôt satisfait de ce projet. Même si je n’ai pas eu le temps d’approfondir le fun du gameplay, j’ai pu découvrir les bases du jeu réseau et du combat 3D. C’était un bon défi, d’autant plus que j’ai tout réalisé en autonomie.

Tower Defence

Consigne

Créer un Tower Defence. Les jeux de type *Tower Defence* permettent aux joueurs de stopper ou ralentir des vagues d'ennemis en plaçant des tours ayant des capacités offensives stratégiques sur le terrain. L'objectif est de défendre un objectif clé contre des attaques successives, tout en gérant les ressources et les capacités des tours.

Objectifs du projet

Ce projet a pour but de créer un jeu *Tower Defence* dynamique et stratégique, où les joueurs doivent défendre une base contre des vagues d'ennemis. L'objectif est d'acquérir des compétences en conception de niveaux, gestion des mécaniques de jeu, programmation des ennemis et optimisation du gameplay. Ce jeu impliquera :

• Conception de parcours : Créer des chemins multiples pour les ennemis, avec la possibilité d'ajouter des chemins supplémentaires à mesure que le jeu progresse.
• Gestion des ennemis : Développer des ennemis avec des caractéristiques variées (vitesse, résistance) et introduire des vagues de plus en plus difficiles, y compris des boss avec des capacités spéciales.
• Amélioration des tours : Implémenter un système d'amélioration des tours, permettant aux joueurs de les rendre plus puissantes en fonction de l'avancement du jeu (augmentation de la portée, de la rapidité, des dégâts, etc.).
• Stratégie et difficulté : Concevoir une courbe de difficulté progressive, obligeant le joueur à adapter sa stratégie en fonction des vagues d'ennemis. Il faudra équilibrer les différents types de tours et d'ennemis pour offrir un challenge optimal.
• Gestion des ressources : Intégrer un système de ressources (par exemple, de l'argent ou des points d'énergie) pour permettre au joueur de construire et d'améliorer ses tours, tout en maintenant l'équilibre entre les dépenses et les défenses.

Doc technique :

Télécharger le document

Rendu du projet :

Visuel

J'ai essayé de rendre cela aussi logique que possible en termes de couleurs et de formes, afin que les spécifications des tours soient aussi intuitives que possible. La boule verte représente la tour normale, le triangle bleu celle à grande portée et faibles dégâts, et l'hexagone violet celle à courte portée et gros dégâts. Le nombre de formes augmente en fonction du niveau de la tour. Il en va de même pour la taille et la couleur des ennemis.

Extrait du gameplay

Ce projet peut être divisé en deux parties : la construction des tours et l'attaque des ennemis par ces tours.

Le joueur peut, en bas à gauche, sélectionner une tour, puis la poser sur une des cases disponibles. Si le joueur clique sur une tour, sa zone d'effet apparaît, et un bouton devient visible en bas à droite pour améliorer la tour.

Une fois la tour construite, elle tire sur les ennemis qu'elle détecte. Les ennemis, quant à eux, rétrécissent lorsqu'ils reçoivent des dégâts.

Conclusion :

Je ne suis pas vraiment fier de ce projet, car je n'ai pas complètement réussi à le finir. Les tours fonctionnent mal, et je n'ai pas eu le temps d'équilibrer l'ensemble du jeu.

FPS - Environnement et Cibles

C'est le deuxième projet que j'ai réalisé durant ma scolarité.

Objectif du projet

Ce projet a pour but de créer un jeu où le joueur doit tirer sur des cibles dans un environnement en vue à la première personne. L'objectif est d'acquérir des compétences en création d'environnements interactifs, gestion des mécanismes de tir, affichage des statistiques en temps réel et utilisation de Quixel pour enrichir l'environnement.

Consignes du projet

Dans ce travail, vous devez créer un environnement en utilisant les outils de géométrie disponibles dans Unreal Engine.

Instructions

• Le personnage doit être en vue à la première personne.
• Des déclencheurs feront apparaître des cibles sur lesquelles il faudra tirer.
• Les munitions sont limitées (ajoutez un mécanisme de recharge si nécessaire).
• Affichez les statistiques en temps réel :
  • Nombre total de cibles
  • Nombre de cibles atteintes
  • Quantité de munitions restantes
• Utilisez des éléments de Quixel pour enrichir l'environnement (prenez une définition modérée pour économiser de l'espace).
• Créez un composant d'acteur en C++ pour animer les cibles.

Doc technique :

Télécharger le document

Lien de Téléchargement

Google Drive

Présentation vidéo du projet :

Conclusion :

Je suis plutôt fier de moi pour ce projet, surtout au niveau de l'ambiance, même si je pense que j'aurais pu aller plus loin à ce niveau-là. Mais j'ai aimé faire ce projet.

Course à Obstacles

Ceci est mon tout premier projet Unreal Engine. J'avais commencé Unreal Engine depuis moins d'un mois et demi.

Objectif du projet

Ce projet a pour but de concevoir un jeu de course à obstacles en utilisant Unreal Engine. L'objectif est d'acquérir des compétences de base en conception de niveaux, modélisation simple et programmation de mécaniques simples.

Consignes du projet

Créer un parcours composé de plusieurs obstacles dynamiques, avec un objectif clairement défini et visible. Le jeu devra inclure une minuterie et un personnage jouable en vue à la troisième personne. L'utilisation du Unreal Learning Kit est autorisée pour faciliter le développement.

Contraintes et fonctionnalités attendues

• Départ d’un niveau de base.
• L’objectif final doit être éclairé et accessible (ex : un objet dans un bâtiment fermé).
• Création d’un personnage simple.
• Ajout d’au moins 3 modèles et 3 matériaux personnalisés.
• Implémentation de différents types d’obstacles :
  • Se déplaçant latéralement ou longitudinalement.
  • Tournants.
  • Montant et descendant.
• Affichage d’une minuterie avec PrintString, qui se fige lorsque l’objectif est atteint.
• Conception d’un niveau avec au moins 3 étages et 5 obstacles.

Doc technique :

Télécharger le document

Lien de Téléchargement

GitHub

Rendu du projet :

Vidéo disponible dans la documentation technique si indisponible

Île de départ :

On peut voir le joueur sur le chemin avec le parcours en face. Le joueur peut avancer, sauter et sprinter. Lorsqu'il sprinte, ses pieds deviennent jaunes. Le saut est assez flottant, car j'ai réduit la gravité pour rendre le parcours plus confortable. En fond, on aperçoit de grandes torches avec une longue traînée de fumée, servant à indiquer clairement l'objectif du parcours.

Niveau 1

J’ai attribué un "thème" à chaque niveau. Pour ce premier niveau, il s’agit des plateformes qui se déplacent horizontalement (gauche/droite) et verticalement (haut/bas). J’ai assigné une couleur spécifique à chaque type de mouvement pour que le joueur puisse les identifier rapidement.

Niveau 2

Le thème de ce niveau est la rotation.

Niveau 3

Ce niveau est une fusion des deux thèmes précédents. J’ai conçu l’île finale avec trois îles côte à côte afin d’indiquer au joueur, lorsqu’il atteint la roue tournante, qu’il ne doit pas continuer tout droit.

Fin

Conclusion :

Je trouve ça relativement pas mal comme projet pour une première fois.