Dual Gates
Dual Gates est un prototype AAA d'un puzzle game mettant en lumière la balistique et des portails
Avant-Propos
Pour réaliser le jeu, nous avions 2 contraintes techniques obligatoire :
-
Balistique : simuler des trajectoire d'objets réalistes sans se reposer sur un moteur physique existant
-
Portails : Relier deux zones éloignée sans perte de qualité, traversable par un objet ou un personnage
Le problème de la contrainte "Portails" est l'obligation de ne pas sortir un Portal-like en proposant notre propre concept des portails. La problématique qui m'a servit de fil rouge était :
Comment se différencier de Portal ?
Pour réaliser ce prototype, j'ai eu une équipe composé de 5 Artistes et 3 programmeurs.​
-
Artistes : DEJAN-DORR Marie-Charline / DELBARRE Tanguy / NABOULET Romain / PIAUD Aurélien
-
Programmeurs : DE NOMBEL Louis / PENA Maël / ROUYRE Peio
En tant que game designer, j'ai penser et intégrer le level design, définit les mécaniques de jeu ainsi que le paramétrages de toutes les features.
1. Définition du concept
Avant d'arriver au concept final, nous sommes parti sur un jeu plus orienté sur de l'action pur et du combat dans une arène. Les portails serbaient principalement à se déplacer. Cependant, nos intervenants nous ont dit que le jeu était beaucoup trop ambitieux pour une production de 5 mois.
Nous sommes donc parti sur d'autres recherches et d'autres idées pour garder notre ambition AAA en le gardant réalisable, l'idée retenue est l'idée que j'ai proposé : l'idée d'un puzzle game.
​
Une fois l'idée validée, je me suis concentré sur l'expérience que je voulais proposer aux joueurs :
-
Utiliser la recherche et l'observation pour trouver comment résoudre les énigmes
-
Offrir au joueur une vision des portails autres que le jeu Portal qui est LA référence en la matière
-
Le doit apprendre à utiliser et contrôler son clone, ce n'est pas intuitif et le prendre en main fait parti de l'expérience.
Par rapport au 3C, éléments importants pour notre jeu qui met en scène la balistique en tant que contrainte​
-
Pour la caméra : Nous sommes partis sur un jeu en First Person View, plus pratique et plus facilement utilisable pour la balistique et offre plus de précision.
-
Pour le Character : Nous sommes partis sur un robot, pouvant tirer des projectiles avec sa main droite et initialement tirer des portails de la main gauche, mais cette partie a été coupé dut au manque de temps. Il peut aussi attraper des différents objets.
-
Pour les contrôles nous sommes partis sur les contrôles basiques des FPV :
​​
​
2. Références
Par rapport aux références, la principale références reste portails, mais nous avons aussi pris des idées d'autres jeux utilisant des portails comme Le portail de symmétra de Overwatch. Niveau balistique, c'est principalement vers des tirs avec une physique réelle et des jeux comme Angry bird qui affichent une prévisualisation de la trajectoire.
Portal
Overwatch - Portails de Symetra
Angry Bird
3. Boucles et Objectifs
Boucle Macro
Boucle Middle
Boucle Micro
Objectif court, moyen et long terme
Système de jeu : Portail Cloneur
1. Principe
Le portail cloneur est un des deux portails présent dans le jeu (je reviendrais sur l'autre plus tard). il suit 3 règles strictes :
-
Le portail donne la possibilité de créer un Clone lorsque le joueur passe à travers
-
Le clone refait toutes les actions du joueurs
-
Le portail ne marche qu'a sens unique : Si le joueur repasse à travers, le clone disparait
2. Fonctionnement et mouvements du clone
Le portail fonctionne grâce à 3 portails, un portail d'entrée, un portail de sortie pour le joueur et un portail de sorti pour le Clone.
Au début du développement, le joueur pouvait poser, les portails "Out clone" et "Out joueur" la où il voulait pour optimiser ses déplacements et on voulait donner un sentiment de liberté au joueur.
Cependant, après quelques tests, les joueurs plaçaient les portails n'importe ou et cassait le jeu. Sous les conseils de Lou-André Trillot (notre professeur de game Design et intervenant en suivit de projet). il nous a conseillé de placé ns portails afin de faire respecter le Level design et surtout réduire la dose de travail derrière car il y avait la contrainte des 5 mois de production. Au final, le résultat du portail cloneur a donné :
​
Schéma de fonctionnement du portail cloneur
Maintenant que vous avons le fonctionnement du portail, je devais trouver comment faire bouger le clone de manière agréable et intuitive. Le premier mouvement est celui principalement utilisé est le comportement Miroir, le clone fait exactement les même mouvements que le joueur. Plusieurs autres déplacements sont disponibles dans le jeu mais non intégré par manque de temps, que je présente quand même dans la suite de ce blog.
​
-
Mouvement miroir
Le mouvement miroir est le premier et le plus intuitif des mouvements du clone. Comme son nom l'indique, le clone fait les mouvements en miroir du joueur, facilitant la compréhension du level design et la première prise en main de notre mécanique
Schéma et gif du mouvement miroir du clone
2. Mouvement symétrique inversé
Le deuxième mouvement présent dans le jeu est le mouvement symétrique inversé. Le mouvement est un peu plus compliqué à prendre en main surtout après le mouvement miroir. Le choix d'utiliser un mouvement plus compliqué est prévu, cela permet de montrer une autre manière d'aborder le clone et montrer d'autres possibilités. Dans la partie juste après, je présenterais rapidement des mouvements programmé, fonctionnel mais non intégré au jeu final.
Schéma et gif du mouvement en symétrie inversée
3. Mouvements développés mais pas intégrés
Les deux mouvements que je présente ci-dessous, sont les mouvements qui n'ont pas pu être dans le prototype à cause du manque de temps. Ceux sont les mouvements les moins intuitifs d'après les différents play test réalisé et surtout amenant un pic de difficulté beaucoup trop élevé.
De plus, les portails Out sont face à face et non côte à côte, changeant toute la perspective et la prise en main du clone
Schéma du mouvement en miroir inversé
Schéma du mouvement symétrique
3. Destruction du clone
Pour terminer le niveau, le joueur doit trouver le moyen de tuer son clone. Cela fait partie intégrante de la résolution d'une énigme. Le joueur va devoir soit :
-
Tuer le clone soi-même
-
Utiliser un piège présent dans la salle pour tuer le clone. (Celui présent dans le jeu)​
Initialement il existait plus de manière pour tuer le clone mais elles fut retirée car plus difficile à mettre en place d'un point de vu Artisitique et Level design, comme par exemple utiliser le tir du joueur, ou utiliser la physique des objets.​
Mort du clone = Obtention de la clé
2 signes et feedback étaient initialement prévu, mais à cause d'un problème d'équipe, un seul est disponible dans le jeu. Il s'agit d'une porte qui s'ouvre et se ferme en fonction de l'état du clone.
La porte est accompagnée d'une UI indiquant au joueur le fonctionnement de la porte.
Porte fermée = Clone vivant
Porte Ouverte = Clone Mort
Principale référence : Portal 2 : La coop gate
3. Problèmes rencontrés
Jouer avec un clone apportait son lot de problème dont un qui a mit du temps à être résolu : La désynchronisation.
Comme le montre le gif, dès qu’un objet venait bloquer la trajectoire du clone ou du joueur, celui sans obstacle continuait son chemin créant ainsi une différence de position et rendait la création de LD plus dure pour nous et on perdait en agréabilité de jeu.
3 solutions ont été pensée, toutes marchaient avec des avantages et des désavantages.
​
La première solution a été un point de resynchronisation. Si le clone et le joueur se désynchronisait, le joueur devait retourner à un point de respawn au début de la zone afin de retenter l'avancée. Cela, fonctionnait comme un checkpoint.
L’avantage de cette méthode est qu’elle obligeait le joueur à faire attention à son déplacement mais cela rajoutait du backtracking non néglideant.
Avantages
-
Permet de garder la désynchronisation comme feature et énigme
-
Offre une seconde chance si le clone meurt, sans repasser par le portail
​
Désavantages
-
Oblige le joueur à faire du "backtracking" s'il y a une désynchronisation
-
Compliquer à gérer d'un point de vu programmation
-
Compliquer à gérer d'un point de vu Game et Level Design
-
Loin d'être agréable en jeu
​
Une deuxième solution à était de faire fonctionner le clone et le joueur comme deux élastiques, dès qu’un des deux s’éloignait trop, le personnage le plus loin derrière était toujours ramené à la position du joueur. Cela était assez contre intuitif et retirait tout réalisme au jeu. De plus, c'était long à faire et demandait beaucoup, beaucoup de signes et feedback pour le rendre ergonomique et agréable
Avantages
-
Empêche toute désynchronisation avec le clone
-
Oblige le joueur à faire attention a ses déplacements
-
Permet d’ajouter des énigmes sur une désynchronisation temporaire
​
Désavantages
-
Empêche toute désynchronisation avec le clone
-
Oblige le joueur à faire attention a ses déplacements
-
Permet d’ajouter des énigmes sur une désynchronisation temporaire
​
La troisième et dernière solution était de forcer la synchronisation. Il est devenu impossible de se désynchroniser avec le clone ce qui retirait toute possibilité de créer des désynchronisations voulue pour la résolution des énigmes, cependant. La synchronisation parfaite, permettait au joueur de se concentrer beaucoup plus sur les énigmes en elle-même et non sur l’état de son clone.
De plus, elle permet un contrôle total du clone et une meilleur appréhension de l'environnement. Après tout les tests, il s'agit de cette solutions qui a le plus plût aux testeurs et surtout la plus agréable contrôles en main.
Avantages
-
Synchronisation parfaite entre le clone et le joueur
-
Aucune désynchronisation possible
-
Permet d’ajouter un layer de compréhension d’environnement au jeu
-
Plus agréable de naviguer dans les niveaux avec son clone
​
Désavantages
-
Moins de libertée pour le Level Design
-
Perte d’une partie des énigmes basé sur la désynchronisation
-
Un peu moins réaliste que les autres et difficulté à comprendre ce qui bloquait, quand on avait pas la vision sur le clone
​
4. Nouveaux problèmes !
Malgré la solution trouvée avec les mouvements du clone, cela a ajouté d'autres problèmes d'UX mais surtout de confort de jeu. Les deux principaux problèmes survenus étaient :
Frustration lors d’une collision qu’on ne voit pas, nous bloque.
On ne repère pas quand le clone récupère un objet ou interagit avec un objet qu’on ne voit pas
​
Pour pallier à ce problème, j'ai trouvé une solution pour les deux coquilles. Cette solution est directement inspiré d'un jeu du jeu d'horreur : Perception.
Le joueur contrôle un aveugle et se sert du son de son bâton de marche comme un radar afin d'avoir une idée des objets qui l'entourent. Reprenant cette idée la, je l'ai adaptée pour la rendre compatible avec notre jeu.
​
Dans notre cas, nous avons appelé la mécanique "Scan Effect" et a pour but de montrer au joueur ce qui bloque le clone avec un principe simple
​
Si le clone collisionne contre un obstacle qui n’est pas visible par le joueur, une prévisualisation affiche l’objet avec lequel le clone a eu une collision.
​
Perception - The Deep End Game
Dual Gates
Je vais vous présenter le fonctionnement du scan en vous montrant les schéma que j'ai donné à mes programmeurs. Le résultat final est un peu différent des schémas donnés aux programmeurs, vu qu'il n'y a plus de désynchronisation, créer un Level design entièrement en miroir (comme le schéma ci-dessous) n'est plus utile. Cependant, cela ajoute une asymétrie que le joueur doit prendre en compte et proposant une nouvelle appréhension du niveau.
En ayant adapté la mécanique du jeu Perception à notre propre jeu, nous avons réglé deux problèmes d'un coup, le "scan effect" est intuitif et pallie les problèmes de lectures du jeu. Les énigmes étaient plus agréables à résoudre et il n'y avait pas le risque d'incompréhension présent au début des play test.
Dans les deux exemples présentés, malgré la porte ouverte le joueur est bloqué par la barrière qui bloque le clone. dans le deuxièmes cas, le joueur n’a initialement pas de cube visible, et lorsque clone rentre en collision avec celui ci, il va s’afficher à la symétrie exacte de sa position
Gif du scan indiquant la barrière répliquée en scan
Gif du scan de la caisse après la collision avec le clone
4. Contenu cut
Deux portails ont été cut avec le manque de temps, un portail qui dupliquait les objets et un portail qui traversait certains murs.
Le choix du portail portail cloneur était plus dangereux que ces deux la et se différenciait beaucoup plus de portal. D’un point de vue game design, le portail cloneur apportait aussi une vision et construction de LD originale et différentes des jeux habituel.
Schéma de fonctionnement du portail Traverse-Mur
Schéma du fonctionnement du portail dupliquant
Deuxième point cut , mais cette fois-ci plus par manque de temps, est l’UI indiquant l’état du clone.
Le bras du personnage devait indiquer un des trois états du clone :
​
-
Portant un objet
-
Clone mort
-
Clone vivant
​
L’abandon de notre Chara Designer à forcé un de nos artistes à réaliser un personnage en moins d’une semaine, faisant passer à la trappe ces feedback importants. Cependant, ils sont compenser par l’effet de scan et la porte “Anti clone" (Porte qui s'ouvre uniquement à la mort du clone).
Indicateur sur le bras de l’état du clone et de la surcharge du tir balistique
UI indiquant que le clone porte un objet
Système de jeu : Balistique
Les projectiles donnent la possibilité au joueur d’activer différents interrupteurs afin de lui permettre d’avancer dans les niveaux.
La difficulté du design du projectile s’est plus basée sur son paramétrage que la mécanique elle même.
Les changements appliqués, ont tous était fait en fonction des play test et feedback que recevions.
1. Intentions
Le but principal de la balistique est d'offrir un tir réaliste mais agréable reposant sur 2 paramètres.
La cadence de tir
​
Initialement nous pouvions tirer 1 balles toutes les 0.3 secondes. Cependant, les joueurs tiraient à tout va et surtout ne faisait pas attention à la trajectoire que la balle empruntait. Ils laissaient le hasard décider si la balle toucherai ou non. Nous avons donc réduit la vitesse de tir a 0.6 secondes.
Réduire la cadence de tir permet au joueur de mieux voir sa balle, et donc réfléchir au bon angle et à la bonne trajectoire afin d'être sur de toucher.
1 tir toutes les 0.3 secondes
1 tir toutes les 0.6 secondes
L'angle de tir
​
Nous étions partis sur un angle initial de 0° comme cela ferait dans la vraie vie, mais la balle manquait de "punch" et la trajectoire du projectile n’avait rien d’extraordinaire. Nous avons donc un peu augmenter l’angle de tir initialDonne plus de punch à la balle sans casser l’immersion et la recherche de réalité.
Trajectoire du projectile schématisée α = 0°
Trajectoire du projectile en jeu avec un angle α = 0°
Augmenter seulement de 10° l’angle initiale du tir à permit des tirs plus beaux, plus punchy et plus agréable à l’oeil qu’avant, et le tout sans perdre le réalisme recherché comme le montre le gif ci-dessous.
Trajectoire du projectile schématisée α = 10°
Trajectoire du projectile en jeu avec l'angle α = 10°
2. Fonctionnement
Paramètres à prendre en compte pour tir parabolique :
Angle de tir : α + β
Vitesse du tir : 13 m/s
Gravité : 9.8 N/Kg
Paramètres du tir à prendre en compte pour le rebond :
Angle d'impact : Δ
Vitesse du tir : 13 m/s
Bounciness : 0.4
Equation de trajectoire suivit par la balle :
La balistique se base principalement sur de la mécanique réelle avec l'effet d’une balle tout aussi réelle.
J’ai travailler en étroite collaboration avec Mael, le programmeur chargé de la balistique.
Le tir suit d’abord une trajectoire parabolique puis, s'il rencontre un mur rebondira selon son angle d'impact.
3. Trajectoire
Notre jeu n’est pas initialement destiné aux gros joueurs de FPS, il doit être accessible à tout le monde. Pour cela nous avons ajouter une prévisualisation de la trajectoire qu’empruntera la balle au moment du tir.
De grosses discussions ont eu lieu sur la taille de la prévisualisions mais surtout si on la mettait ou pas. J’ai finit par avoir gain de cause en faisant passer le joueur en priorité, l’affichage d’un trajectoire ne change pas l’énigme en elle même et permet une meilleur approche du tir surtout par le clone
Nous avons donc tester plusieurs longueur trajectoire :
-
8M : La trajectoire était beaucoup trop courte et induisait le joueur en erreur. Les tirs étaient imprécis et se basaient sur la chance.
-
15M : La trajectoire était trop longue et ne proposait aucun challenge.
-
11M : L'entre deux, proposait le challenge du 8M mais avec la trajectoire plus longue du 15M, c'était plus agréable pour le joueur
Le clone aussi a le droit à une trajectoire. Au départ, elle était exactement la même que le joueur mais pour mieux les différencier nous avons changer la couleur de sa trajectoire en la passant rouge/rose.
Il n’y a pas une grande différence une grande différence, le changement de couleur permet principalement de bien différencier les deux trajectoires et éviter des situations de superposition.
Ancienne trajectoire du clone
Nouvelle trajectoire du clone
4. Environnement
L'environnement est un point important de notre balistique, c'est l'élément le plus important de notre trajectoire. Le rebond va dépendre du mur et la trajectoire générale par l'impact d'une vapeur.
Rebond réaliste sur les murs
Déviation de la trajectoire avec le vent
On va se concentrer sur la feature de déviation de la balle avec les vents, c’est la clé de voute de nos énigmes intégrées. Le vent est un choix réfléchit faisant écho aux vapeurs caractéristiques d'un univers SteamPunk. De plus, le vent est un élément simple à utiliser et à mettre en place d'un point de vu LD et GD.
Dans un premier temps, voici le schéma explicatif que j’ai demandé à Maël pour ses vents. Le schéma est suivit du résultat sur l'éditeur et en jeu. La vapeur, dépend de deux paramètres : La Force et la Direction du vent
Schéma explicatif de l'effet du vent
Résultât dans l'éditeur Unreal
Résultât en jeu
Voici plusieurs situations qui ont été designée avec le vent mais non intégrée.
-
La première, il s’agit de deux vent contraire où il faut trouver la bonne trajectoire pour atteindre le boutonau bout.
-
Le deuxième met en place toutes les directions en même temps et comme pour la première la bonne trajectoire amène au bouton en plus d’être agréable à voir.
​
-
Le troisième fait plus travailler la précision et l’angle de tir du joueur. Un vent souffle au dessus du joueur et le bon angle va lui permettre de faire tomber la balle de l’autre coté.
Notre environnement a aussi ses signes et feedback. La où la vapeur faisait l'unanimité, la valve permettant d'activer et désactiver la vapeur est passé par plusieurs étapes de conception. La première itération était une réelle valve, mais le feedback correspondant n'était pas assez visible, que ce soit par une rotation, ou un changement de couleur, trop irréaliste pour notre jeu. Nous sommes donc parti sur les robinets de jardins, ayant un statut "Ouvert" et "Fermé" totalement compatible avec ce que nous recherchions
​
Robinet de jardin qui a servit d'inspiration
Valve utilisée en jeu
Signes ​
Valves
Screenshot d'une valve activée avec sa vapeur correspondante
Screenshot d'une valve désactivée.
Pour facilité la compréhension et garder le réalisme, nous avons liés la valve et la vapeur par un tuyau commun. Si le joueur voit un valve il devra remonter le tuyau pour trouver la vapeur qu'il active et réciproquement.
La couleur de la valve indique au joueur l’état du vent avec bleu activé et rouge désactivé. Pour accompagner la valve, le bout de tuyau qui émet la vapeur à un modèle différent.
Tuyaux Normaux
Tuyaux libérant de la vapeur
Feedback
Niveau feedback, nous avons utilisé une méthode simple de rotation. Cela faisait gagner du temps niveau animation et programmation.
Lorsque le projectile touche la valve, celle-ci fait une rotation de 180° et change de couleur. De plus, la vapeur s'active et se désactive une fois la rotation finie.
5. Contenus cut
Initialement nous avions 2 fonctionnalités supplémentaires, elles sont designées, programmées et dans le jeu, mais nous n'avons pas eu le temps de bien les mettre en place dans le jeu.
Tir à travers le portail : Le joueur peut tirer à travers le portail pour atteindre un objectif inaccessible. Designer mais pas eu le temps de le mette en place de manière propre. Il est présent dans le niveau mais optionnel
Cooldown et munition : Le joueur ne pouvait tirer que x munition avant que la surchauffe bloque le tir.
A cause de l'abandon de notre chara designer, nous n'avons pas eu le temps d'appliquer ce feedback sur notre nouveau personnages. Cependant, il est fonctionnel et intégré mais non utilisé officiellement.
Level Design
1. Philosophie
Déroulé d’un niveau
-
Trouver le portail qui permet de créer un clone
-
Comprendre l’utilité du clone dans le niveau
-
Utiliser le clone pour avancer et atteindre les objectifs inaccessibles au joueur
-
Tuer le Clone d’une horrible manière pour obtenir la clé
-
Sortir et continuer son chemin sans se retourner pour son clone.
2. Brick de Level Design
Les interrupteurs
La brick la plus présente dans le jeu est l’interrupteur, c’est la cible principale des joueurs et va permettre d’activer les autres brick de Level design.
L’interrupteur est rouge quand il est désactivé et un contour jaune indique au joueur ou il doit tirer.
Une fois que l’interrupteur est touché, la lumière devient bleue et la balle se snap en son centre
Signes ​
Feedback
-
Rouge = Désactivé
-
Cadre jaune : zone de tir dans cage
-
Bleu = Activé
-
La balle se snap à l'intérupteur
Plaque de pression
La plaque de pression est la deuxième brick avec laquelle le joueur va pouvoir interagir, elle est liée à une caisse et permet d’ouvrir les bouches d’aération bloquant un interrupteur.
Pour indiquer au joueur la correspondance entre la caisse et la plaque, la même main est présente sur les deux.
Signes ​
Feedback
-
La caisse à une main pour indiquer la possibilité d'attraper
-
La plaque à une main et la même texture que la caisse pour indiquer la correspondance
-
La caisse se snap à la plaque de pression quand celle-ci est dessus
-
La bouche d'aération s'ouvre quand la caisse est sur la plaque par une animation.
Barrières
Les barrières sont nos portes principales, elles agissent en tant que blocker et bloquent l’avancée du joueur.
Elle s’ouvre avec l’interrupteur correspondant, reliée à la loupiote à proximité de la porte. Quand le joueur à touché l’interrupteur, la lumière devient verte et la porte s’ouvre avec une animation et un feedback sonore
Signes ​
Feedback
-
Lumière rouge proche de la porte
-
Cable relie interrupteur et lumière de porte
-
La barrière est fermée
-
La lumière devient verte quand l'interrupteur est touché
-
La porte s'ouvre avec un feedback sonore
Le socle de la clé
Le socle a deux fonctions :
-
la première utilisation est en tant que "serrure". La clé permet d'ouvrir la porte menant au niveau suivant. Initialement rouge il devient bleu quand la clé est posée dessus. Quand la clé est sur le socle, celui-ci est illuminé en bleu, quand on la retire, elle devient rouge.
-
La seconde utilisation est en tant que "piédestal". Il s'agit d'un piédestal non actif qui donne la clé au joueur.
​​
Pour mieux différencier les deux piédestaux​, celui qui s'utilise en tant que serrure, fait tourner la clé sur elle-même.
Signes ​
Feedback
-
Quand la clé est sur le socle, celui-ci est bleu
-
L'inverse est rouge
-
Quand on retire la clé du socle, il devient rouge
-
Quand on met la clé sur la serrure, la clé tourne sur elle même et la porte finale s'ouvre
Pince et containeur
La pince permet au joueur de passer des trous en sautant sur le container qui y est accroché. Quand le joueur ne peut pas interagir avec la pince, celle-ci émet une faible lumière rouge et quand il peut, l’intensité augmente et un levier apparait.
Signes ​
Feedback
-
La lumière autour de la pince et faible et clignote
-
Quand la pince arrive à sa position “max” la lumière s’intensifie et un levier apparaît
-
Quand le joueur tire sur le levier, le container retenu, tombe de la pince
-
La lumière autour du levier devient verte
-
Le levier est abaissé
Pistons
Dernière brick de gameplay est le "piston", qui fait office de pont au joueur. Initialement remonté, le joueur ne peut ni tomber passer à travers. Initialement, le piston allait de bas en haut, mais les joueurs passaient les pistons et se retrouvaient bloqués.
Signes ​
Feedback
-
Le piston levé bloque le joueur
-
Le piston à une animation de descente quand le joueur touche l'interrupteur correspondant aux pistons
