Féérik Games : programmeur gameplay & outils
Chez Féérik Games à Montpellier, le studio derrière Eredan Arena et OhMyDollz, j’ai passé six mois comme programmeur gameplay & outils aux côtés du directeur créatif Frédéric Markus, passé par Ubisoft, Nintendo, Rockstar, Disney, LucasArts et Epic Games.
Notre terrain de jeu : les jeux cinématiques, la recherche & développement, le prototypage rapide (un jeu de course mobile, et Viper, un prototype d’avion) et les outils pour les construire.
Ce que j’ai fait
Programmeur gameplay & outils · 6 mois- Prototypé un jeu de course cinématique sur mobile, puis Viper, un prototype d’avion
- Créé un outil de plans-séquences sur Cinemachine, avec des clés le long de la spline de course
- Fait marcher les outils en mode Play comme dans l’éditeur, avec une boucle de temps éditeur maison
- Créé une fenêtre d’édition globale : sélection et tooltips dans la Scene view, sans Inspector
- Créé les outils de level design sur spline : objets verrouillés sur la piste, 4 modes de rotation
- Présenté le travail au studio lors d’une présentation finale
Jouer l’action, pas les commandes
La question derrière le prototype de course : sur un téléphone, comment donner au joueur la sensation d’une course poursuite de cinéma, alors que son pouce ne fait presque rien ?
Nous avons comparé le fantasme (à quoi ressemble une course cinématique) à la réalité (ce que le joueur contrôle vraiment), et pris la voie du « moins de gameplay, plus de fun ? » : des commandes simples, et c’est la caméra et le replay qui racontent l’histoire.
Un outil de plans-séquences
Pour obtenir des plans-séquences dignes du cinéma, j’ai créé un outil sur Cinemachine qui permet de composer toute la séquence le long de la spline de course :
- créer des caméras et les prévisualiser en jeu instantanément,
- ajouter des clés le long de la spline : rotation du joueur, ralenti, ratio de vitesse, changement de caméra, modification de la spline.
L’outil de keyframes de la course
C’est le cœur des outils : une seule fenêtre d’édition qui pilote toute la course en temps réel. Elle gère les checkpoints, la position et l’angle de la caméra à chaque instant, et les glissades de la voiture, le tout sur une timeline que le designer peut parcourir, jouer et modifier pendant que le jeu tourne.
Comment ça marche : la course est échantillonnée. « Calculate Sample » simule la course le long de la piste à une
fréquence choisie (ici FPS_10, dix échantillons par seconde) et enregistre chaque frame : 251 frames pour ce tour.
Une voiture fantôme rejoue les échantillons, et quand un réglage change, l’outil prévient qu’il faut réinitialiser le
fantôme (« need to reset ghost, because settings has changed »), ou le recalcule tout seul avec « Recalculate
Auto ». « Simulate Player Action : 100 % » règle la part des actions du joueur jouées par la simulation, d’une course
parfaite à une course nonchalante.
La timeline (en bas à droite) va de la frame 0 à 251, avec un curseur (ici sur la frame 83) qui déplace ensemble la voiture, la caméra et la vue de jeu. Chaque ligne est une piste de clés, filtrées avec « Show Keys » :
- keys Laps : le début et la fin de chaque tour,
- keys transition camera : quand changer de caméra, et comment (ici un fondu vers la caméra DOLLY),
- keys checkpoints : les checkpoints de la course (en rouge), utilisés pour le classement et les temps au tour,
- keys camera state : l’état de la caméra active à chaque instant : sa position et son angle,
- keys drift : là où la voiture glisse dans les virages,
- keys speed change et keys slow motion : ratio de vitesse et moments de ralenti, chacun désactivable,
- keys UI Events : quand l’interface réagit (messages, effets).
La barre de lecture prévisualise tout (début, précédent, lecture, suivant, fin), avec des options de boucle et des marqueurs, et un bouton « Lock Player » pour garder la voiture sous la caméra. « Interpolate », le time scale et le zoom sont en bas.
Dans la Scene view, le panneau « Cam » choisit la caméra de la clé courante (ici DOLLY) et sélectionne son objet pour le déplacer directement ; la vue de jeu à gauche montre le résultat tel que le joueur le voit : position (2e), temps au tour, écart avec la voiture suivante (+91 m), vitesse, et les options « Cheat » et « Auto » qui servent à tester la course.
Des outils qui marchent en mode Play et dans l’éditeur
Les deux mondes ont leurs limites :
- mode Play : les modifications de prefabs et d’assets doivent être sauvegardées à la main, tester sur appareil (Vuforia) n’est pas si pratique, et les outils deviennent trop liés au build ;
- mode éditeur : le temps de l’éditeur n’est pas la boucle de jeu, il n’y a pas de blends Cinemachine, et les entrées sont différentes.
Les outils tournent donc dans les deux, avec des mouvements fluides aussi dans l’éditeur : [ExecuteInEditMode],
l’événement EditorApplication.update, QueuePlayerLoopUpdate(), et une classe maison pour le temps et le time scale
(l’idée derrière mon devlog Time, TimeScale et DeltaTime dans l’éditeur).
Un éditeur global
Tout au même endroit :
- sélection et tooltips directement dans la Scene view, sans passer par l’Inspector ni la Hierarchy,
- chaque éditeur est encapsulé dans sa propre fenêtre, qui retient sa position.
Le level design sur la spline
Les objets sont verrouillés sur la spline, avec quatre modes de rotation :
- suivre la spline,
- suivre la spline et rester droit,
- ne pas suivre la spline,
- ne pas suivre la spline et rester droit.
Les mêmes outils de spline et de caméra ont ensuite servi pour Viper, un prototype d’avion.
Ce que j’en retiens
- Une vision plus globale du milieu du jeu vidéo, aux côtés d’un directeur créatif expérimenté.
- Les outils éditeur, et une connaissance bien plus poussée d’Unity.
- Une approche divertissante du gameplay : ce que ressent le joueur compte plus que ce sur quoi il appuie.
- Côté personnel : les mathématiques appliquées, et l’architecture du code.
