Concept art Environnement
Concept art Ambiance
- Type de jeu : Exploration à la 3ème personne en vue en perspective.
- Nombre de personnes : 6
- Temps de réalisation : 8 mois
- Pitch :
Parcourez Athara 3 à l’aide de Gwido et de son véhicule. Apprenez les règles de ce monde les possibilités de chacune de vos capacités afin d’explorer cette planète, en éviter les
dangers et découvrir tous ses secrets !
dangers et découvrir tous ses secrets !
- Game Concept :
Dans Gwido, le joueur incarne un avatar et son véhicule qui doivent arpenter des structures jonchées d’ennemis. Le joueur peut récupérer des ressources qui sont nécessaires au bon fonctionnement du van et des différentes mécaniques associées à ce dernier.
L’avatar peut se déplacer et tirer sur les ennemis. Il peut changer de controller à distance et utiliser le véhicule. C’est alors au joueur d’explorer à intelligemment et de récolter les ressources pour continuer à s’aventurer dans cet univers.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Mes Rôles
Sur ce projet, j’ai réalisé à la fois les rôles de Game Designer et de Programmeur.
Mon objectif :
- Créer des mécaniques de jeu solides, compréhensibles et facilement modifiables pour toute l’équipe.
Grâce à Unity et à une approche modulaire du code, j’ai pu traduire efficacement les intentions de design en systèmes fonctionnels, tout en facilitant leur évolution au fil du développement.
Cette méthode nous a permis de gagné beaucoup de temps lors du développement du jeu et pour la réalisation des métriques des éléments de gameplay.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Camera Behaviour
Dans notre projet, un des problèmes majeurs est la visibilité réduite due à notre caméra car nous voulions une camera smooth. Nous avons donc dû trouver des moyens de redonner de la visibilité au joueur, afin qu’il puisse correctement voir lors de ses déplacements.
Pour cela, nous avons combiné deux systèmes :
- Un léger avancement de la caméra dans la direction du joueur :
Celui-ci permet au joueur de voir plus loin lorsqu'il avance peut importe la direction et en fonction de ça vitesse
- Un effet de compensation en fonction de l'orientation du joueur :
Celui-ci permet au joueur de voir mieux quand il se dirige vers le bas de l'écran
Camera centrer
Camera non-centrer
Compensation Fonctionnement
Vidéo :
Cependant, notre gameplay repose en grande partie sur l’infiltration. Nous voulions donc redonner le contrôle de la caméra au joueur lorsqu’il est en situation de "combat".
Lorsqu’il vise avec son arme, il peut alors diriger la caméra dans la direction de son choix.
Cette méthode permet au joueur de voir plus loin sans avoir à se déplacer, et dans la direction qu’il souhaite.
Camera Aim Position
Camera Behaviour Stick usage
Pour créer d'autres situations intéressantes lorsque le joueur entre dans des structures ou se déplace dans l'environnement, nous avons mis en place des caméras scriptées. Il y en a un total de trois, chacune nous permettant de mettre en scène des situations spécifiques et variées.
- Camera qui va fixé un point
- Camera qui va regarder ENTRE le joueur et un point
- Camera qui va tourner sur un autre angle
D'autre Camera trigger on été crée mais ne nécessitant pas un comportement différent mais uniquement des métriques différente alors on a centraliser les métriques de la camera pour pouvoir les changer en tout situation a l'aide de simple trigger qui vont appeler cette fonction.
On se retrouve avec des caméras scripter qui sont facilement plaçable avec des métriques facilement paramétrable dans l'inspecteur.
Trigger Between
Trigger Target
Trigger Rotation
Vidéo :
Pour le système de caméra, j’ai conçu un contrôleur centralisé chargé de gérer les paramètres clés et les fonctions principales.
Afin de faciliter l’expérimentation et la modularité, j’ai mis en place un système de states, permettant de changer dynamiquement le comportement de la caméra.
Tester une nouvelle logique de mouvement ne nécessitait que la création d’un nouveau state, sans altérer les systèmes déjà en place.
Par exemple certain comportement citer au dessus était des states alors que d'autre nécessite uniquement un changement de paramètre.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Ennemis
Dans notre projet, notre ennemi est conçu à l’aide d’une Finite State Machine (FSM). Nous utilisons également le NavMesh de Unity pour gérer leurs déplacements.
L'ennemi représentent un véritable défi, car il doit être bien réalisés, sous peine de ne pas correspondre à nos intentions de gameplay.
Pour répondre à cela, nous avons mis en place certains éléments dès les premières phases du développement afin de rendre leur comportement plus intéressant.
Pour répondre à cela, nous avons mis en place certains éléments dès les premières phases du développement afin de rendre leur comportement plus intéressant.
Nous avons notamment implémenté un système de détection basé sur une “Rage”, un mécanisme qui nous permet de lier directement la vision de l’ennemi à sa réaction face au joueur lorsqu’il entre dans son champ de vision.
Système de rage
L’ennemi dispose de quatre états distincts, chacun définissant un comportement spécifique dans la logique de la FSM.
State et Behaviour
State Machine Fonctionnement
Après avoir réalisé les états de base de mon ennemi ainsi que ses comportements classiques, j’ai développé le fonctionnement de ses attaques.
L’ennemi en possède deux :
Une attaque de mêlée simple : Courte range et attaque rapide avec petit temps de repos, petit distance parcours lors de l'attaque
Une attaque de type dash : Grande range et attaque rapide avec long temps de repos, longue distance parcourue lors de l'attaque
En réalité, les deux attaques partagent le même fonctionnement, mais utilisent des paramètres différents.
Elles sont donc fondamentalement similaires, mais leurs feedbacks et leur puissance varient en fonction des paramètres qui leur sont assignés.
Elles sont donc fondamentalement similaires, mais leurs feedbacks et leur puissance varient en fonction des paramètres qui leur sont assignés.
Grand Dash
Petit Dash
Vidéo :
Pour la patrol des ennemis, j’ai conçu un outil d’édition, directement intégré dans l’inspecteur Unity. Il permet d’ajouter, modifier ou supprimer des points de patrouille dynamiquement, même en mode Play.
Cet outil a grandement facilité l’itération sur le level design : les parcours pouvaient être ajustés en quelques clics, ce qui a permis à l’équipe de tester et d’équilibrer rapidement le comportement des ennemis dans l’environnement.
Grâce à ce système, la création de patrouilles était simple et rapide.
En complément, j’ai développé un éditeur personnalisé complet pour les ennemis, rendant l’inspecteur plus clair et structuré. Cela a simplifié le réglage des paramètres et a rendu la prise en main des ennemis plus intuitive pour toute l’équipe.
Patrol ennemis
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Un grand merci à toute mon équipe pour leur implication, leur créativité et leur confiance tout au long de ce projet. Ce fut un vrai plaisir de concevoir ce jeu ensemble.
Pour toute autre question liée au projet, que ce soit technique ou non, n'hésitez pas à me contacter, je répondrai avec joie.
