Animation Gameplay : Les 5 Décisions Techniques qui déterminent votre Prod
- Vanessa
- il y a 2 jours
- 10 min de lecture
Il y a quelques semaines, j'ai été contactée en urgence pour aider sur un projet d'animation gameplay.
Le jeu sort dans 3 mois. Les retours ont mis en lumière de nombreuses faiblesses sur les animations.
En analysant leur travail, j'ai vite compris : le problème n'était pas les animateurs.
Ce sont les décisions prises 18 mois plus tôt, en préproduction.
Des décisions techniques qui semblaient anodines sur le moment, mais qui avaient verrouillé toute la prod dans un système inadapté.
À 3 mois de la fin, il était trop tard pour changer quoi que ce soit. On ne pouvait que mettre des pansements.
Voici les 5 décisions techniques qui déterminent la réussite ou les galères d'une prod animation gameplay.
1. Framerate Target : La Décision Invisible qui Change Tout
Pourquoi c'est critique
30fps vs 60fps, ce n'est pas qu'une question de performance technique. C'est une question de perception du mouvement.
À 30fps, chaque image est espacée d’environ 33 millisecondes. Cela laisse le temps de construire des poses marquées, des anticipations lisibles, et des timings bien rythmés.
À 60fps, l’intervalle tombe à 16 millisecondes : les mêmes animations peuvent paraître trop lentes, trop molles, ou au contraire saccadées si les transitions ne sont pas ajustées.
Ce n’est pas juste une question de fluidité , c’est une question de perception du mouvement.
Le framerate change la façon dont le cerveau lit l’intention derrière chaque pose.
Et l'inverse est vrai : une animation pensée pour 60fps jouée en 30fps perd sa fluidité.
Mon expérience
Sur un projet récent, nous animions à 30fps dans Maya mais le moteur tournait à 60fps.
Les interpolations entre frames créaient des artefacts impossibles à prévoir dans notre logiciel d'animation.
Des objets disparaissaient pendant une frame, des contraintes se désynchronisaient, des rotations prenaient des chemins aberrants.
Résultat : plusieurs semaines perdues à débugger des problèmes invisibles dans Maya.
On exportait, on testait en jeu, on constatait le bug, on retournait dans Maya sans pouvoir le voir, on tentait des corrections à l'aveugle.
La décision de viser du 60fps avait bien été évoquée dès le départ… mais sans test concret ni validation technique.
Elle a été officiellement confirmée six mois après le début de la production, alors que plus de 200 animations étaient déjà en cours.
À ce stade, on ne pouvait plus techniquement revenir sur notre façon de procéder. Les ajustements nécessaires pour adapter les timings et corriger les artefacts liés à l’interpolation étaient devenus très coûteux , et souvent invisibles dans notre logiciel d’animation. On a galéré jusqu'à la fin de la production avec les mêmes soucis.
Red flags
🚩 Le framerate n'est pas défini en début de préproduction
🚩"On optimisera le framerate plus tard"
🚩 Pas de pipeline de test direct dans le moteur depuis Maya/Blender/Mobu
🚩 L'équipe technique dit "ça devrait passer" sans test concret
Ce qu'il faut poser comme questions
Quel est le framerate TARGET définitif ?
Est-ce que je travaille au même framerate que le moteur ?
Quel est le workflow de test en temps réel ?
Qui gère l'interpolation à l'export ?
2. Choix de Mocap : Économiser au Mauvais Endroit
Pourquoi c'est critique
Il existe plusieurs technologies de capture de mouvement, chacune adaptée à des usages spécifiques :
• Optique : basée sur des caméras infrarouges (type Vicon), elle offre une grande précision mais nécessite un espace dédié et peut être sensible aux occlusions.
• Inertielle : repose sur des capteurs IMU (comme Xsens), plus mobile et rapide à mettre en place, mais parfois moins précise sur les mouvements complexes.
• Vidéo : utilise l’analyse d’images pour extraire le mouvement, souvent moins coûteuse mais limitée en qualité et en fiabilité.
Chaque système a ses avantages et ses limites , le choix dépend du type d’animations à capturer, du budget, et du niveau de qualité attendu en post-production.
Le piège ? Choisir un système "économique" sans mesurer le coût réel en post-production.
Parce que la mocap, c'est jamais "tourner et utiliser direct".
C'est toujours : tourner → clean les données → retoucher → intégrer.
Et selon le système, le ratio tournage/clean peut exploser.
Mon expérience
Sur un gros projet AAA, le choix s'est porté sur un système de mocap inertiel (Xsens) pour faire de la locomotion en pente et en terrain varié.
L'idée : économiser sur les coûts de tournage.
La réalité : des pieds et bassins qui tremblent à chaque frame. Le tracking des hauteurs approximatif (crucial pour la locomotion en pente).
Des données globalement utilisables mais qui demandaient un énorme travail de clean.
On a économisé environ 20% sur le tournage pour perdre 200% en temps de post-prod.
Des semaines d'un animateur senior à nettoyer des datas frame par frame sans obtenir le niveau de qualité qu'on aurait eu avec un système optique.
Le problème n'était pas le système en soi , Xsens fonctionne très bien pour certains usages. Le problème, c'était de l'utiliser pour un cas d'usage où il n'était pas optimal.
Red flags
🚩 Quelqu'un dit "on va économiser sur la mocap"
🚩 Le choix du système se fait uniquement sur le coût du tournage
🚩 Pas de test de qualité avant de lancer toute la prod
🚩 Le budget post-prod n'est pas clairement défini
Ce qu'il faut poser comme questions
Quel type d'animations on doit capturer ? (combat rapide, locomotion, acrobatie...)
Quel système est optimal pour ce type ?
Quel est le budget TOTAL (tournage + post-prod) ?
Qui va gérer le clean et combien de temps c'est budgété ?
3. Blending & State Machines : Une Fois Choisi, Impossible de Revenir en Arrière
Pourquoi c'est critique
Ton système de state machines, d'animation graph, de blend trees... c'est la colonne vertébrale de tout ton gameplay.
C'est ce qui gère comment les animations s'enchaînent, se mélangent, se superposent.
Une fois que tu as 500 animations intégrées dans un système, tu ne peux plus tout refaire. Le système devient structurel.
Si tu te rends compte à mi-prod qu'il est limitant, il est déjà trop tard.
Trois expériences opposées
Le système flexible (Beyond: Two Souls)
Système maison chez Quantic Dream qui permettait d'ajouter autant de transitions que nécessaire, à n'importe quel moment de la prod. Blend trees sophistiqués, gestion automatique des pieds, possibilité de passer de gameplay à cinématique de manière seamless.
Résultat : aucun pied qui glisse, aucune transition cassée, possibilité d'ajuster et d'améliorer jusqu'au dernier jour.
Le système rigide catastrophique (projet indépendant)
Choix de séquences d’animations simples dans Unreal, déclenchées directement via les Blueprints, sans passer par un State Machine.
L’idée de départ : “On fera simple, on n’a pas besoin de complexité.”
Concrètement, chaque animation (idle, walk, jump…) est appelée manuellement, sans logique de transition ni blending.
Pas de conditions, pas de visualisation du flow, juste des appels directs comme "Play animation" ou "Set animation".
À trois mois de la fin, impossible d’ajouter des transitions sans tout casser.
Les personnages glissent dans tous les sens, les passages idle → walk ont des vitesses mal gérées, les arrêts sont brusques.
Et surtout : structurellement impossible à corriger sans tout refaire, car aucune couche intermédiaire ne permet de gérer les interruptions, les blend times ou les priorités.
Ce genre de système peut suffire pour un prototype, mais en production, il devient vite un piège : chaque animation est isolée, et le moindre ajustement demande de rebrancher manuellement chaque séquence.
Le jeu est sorti avec ces défauts. Les reviews ont massacré les animations...
Le système limitant (projet AAA)
Pas de système de détection automatique des pieds pendant deux productions consécutives.
Conséquence directe : impossible de garantir des arrivées propres sur le bon pied, ni de calibrer précisément la vitesse des NPCs pour qu’ils s’arrêtent exactement là où on le souhaite.
Sans cette détection, on peut certes faire du blending entre deux animations de vitesses différentes, mais on ne peut pas adapter dynamiquement la vitesse en fonction du rythme des pas.
Or, cette adaptation est bien plus qualitative visuellement qu’un simple blend linéaire.
Résultat :
• Des arrêts imprécis, des glissements visibles, des transitions bancales.
• Et pour compenser, des dizaines d’animations “stops orientés” manuelles, multipliant le travail par trois.
Aujourd’hui, les blueprints d’Unreal Engine sont largement connus et maîtrisés dans l’industrie. Mais il existe une grande diversité de systèmes , de Unity aux moteurs propriétaires , chacun avec ses spécificités techniques et ses contraintes d’intégration.
Au fil des projets, j’ai eu la chance de travailler sur des technologies très variées. Cette expérience me permet aujourd’hui d’anticiper les pièges liés à chaque pipeline, de poser les bonnes questions dès la préproduction, et d’adapter les choix techniques aux besoins réels du gameplay.
Red flags
🚩 Le lead tech dit "on verra pour les transitions plus tard"
🚩 Pas de state machine, blueprint ou système de blending défini en préproduction
🚩 "On fera simple" sur un jeu d'action
🚩 Les premiers tests montrent déjà des glissements de pieds
Ce qu'il faut poser comme questions
Le système permet-il d'ajouter des transitions facilement en cours de prod ?
Y a-t-il un système de détection de pieds / foot IK ?
Comment on gère les blends entre animations très différentes ?
Y a-t-il des outils de debug pour visualiser les transitions ?
4. Gestion des Props/Armes : L'Enfer Quotidien Mal Anticipé
Pourquoi c'est critique
Prendre un objet. Le tenir. Le poser. Changer de main. Le lancer. Le ranger.
Ces actions représentent potentiellement 30-40% de tes animations gameplay.
Si le système technique derrière est bancal, c'est un cauchemar quotidien pendant toute la prod.
Et contrairement à d'autres systèmes, celui-ci tu le testes vraiment qu'en prod, quand tu commences à avoir des dizaines d'objets différents, des cas limites, des interactions complexes.
Trois implémentations, trois expériences
Le système fluide
Système ultra bien pensé. Sockets multiples sur le personnage, système de contraintes stable, possibilité de switcher facilement d'un objet à un autre.
Jamais eu un seul problème pour prendre, poser, manipuler des objets.
Des centaines d'animations avec props, aucun bug. Ça fonctionnait, point.
Le système rigide
Système complexe dans MotionBuilder censé simplifier le process.
Dans les faits : trop rigide.
Dès qu'on voulait changer l'arme de main après coup, galère.
Dès qu'on voulait remplacer le modèle d'arme sur une anim existante, ça cassait tout.
Et les interactions entre personnages (passer un objet, etc.) étaient quasi impossibles.
Résultat : on évitait certaines animations pourtant pertinentes en gameplay parce qu'on savait que techniquement, ce serait l'enfer.
Le chaos permanent
Pas assez réfléchi en préproduction.
Toute la prod à gérer des problèmes de contraintes qui pètent.
Des objets qui se téléportent d'une frame à l'autre. Qui disparaissent. Qui font des 360° en une frame.
Des heures perdues chaque semaine à débugger, à trouver des workarounds, à refaire des animations qui marchaient la veille.
C'est une perte de temps colossale à l'échelle d'un projet.
Red flags
🚩 Les premiers tests d'objets montrent des téléportations bizarres
🚩 "On verra ça plus tard" quand tu poses la question du workflow props
🚩 Le système n'a jamais été testé avec plusieurs types d'objets différents
🚩 Pas de pipeline clair pour attacher/détacher les props
Ce qu'il faut poser comme questions
Comment on attache/détache un prop techniquement ?
Peut-on changer d'objet sur une anim existante ?
Le système gère-t-il les interactions entre personnages ?
Y a-t-il déjà eu des tests avec différents types d'objets ?
5. Choix des Rigs/Squelettes : Le socle technique à ne pas négliger
Pourquoi c'est critique
Un rig, c'est la structure technique de ton personnage. Sa hiérarchie de bones, ses contrôleurs, ses déformations.
Changer un rig = refaire toutes les animations qui l'utilisent. Plus tu es avancé dans la prod, plus c'est catastrophique.
Le piège ? Un rig peut sembler "bon" en tests basiques, et révéler ses limitations seulement quand tu commences à faire des animations complexes, des poses extrêmes, des interactions.
Le choix du nombre de squelettes, leur définition (taille, proportions), et la stratégie de retargeting sont tout aussi critiques.
Décider en préproduction combien de squelettes distincts le jeu aura (un squelette unique pour tous les personnages ? Un par type de morphologie ? Un par personnage ?) impacte directement le volume de travail d'animation.
Un squelette universel bien pensé permet de partager un maximum d'animations entre personnages, réduisant drastiquement les coûts de production.
À l'inverse, multiplier les squelettes sans stratégie de retargeting claire peut exploser le budget animation : chaque nouvelle morphologie nécessite de refaire ou d'adapter manuellement des dizaines d'animations.
Sans oublier que les différences de proportions (personnage petit vs grand, fin vs massif) influencent la qualité du retarget : ce qui fonctionne parfaitement sur un squelette peut sembler cassé sur un autre.
Ces décisions structurelles doivent être prises dès la préproduction, car une fois 200+ animations produites sur des squelettes incompatibles, il est trop tard pour unifier.
Mon expérience
Sur un projet récent, le rig du personnage principal a été refait 3 fois.
La première fois à 6 mois : on a découvert que certaines déformations ne fonctionnaient pas bien.
La deuxième fois à 12 mois : certaines poses poussées cassaient encore le rig.
La troisième fois à 18 mois : refonte complète pour des raisons d'optimisation du squelette.
À chaque fois : refaire des dizaines d'animations déjà validées, déjà intégrées, déjà testées.
Le pire ? Ces problèmes de rig étaient prévisibles. Mais personne n'avait pris le temps de les tester à fond en préproduction.
Red flags
🚩 Le rigger dit "je vais améliorer le rig pendant la prod"
🚩 Tests limités à des poses statiques ou des cycles simples
🚩 Pas de validation fonctionnelle avant le démarrage des animations
🚩 Pas de vérification des extrêmes (stretch, twist, contact)
Ce qu'il faut poser comme questions
Le rig est-il définitif ou va-t-il évoluer ?
A-t-il été testé sur tous les types d'actions du jeu ?
Qui valide que le rig ne change plus ?
Quelle est la deadline absolue pour les changements de rig ?
Conclusion : 20% du Temps, 80% de l'Impact
Ces 5 décisions techniques se prennent en quelques semaines de préproduction.
Elles déterminent 2 ans de production.
La différence entre une prod fluide et une prod cauchemardesque ne se joue pas dans le talent des animateurs.
Elle se joue dans la qualité des décisions techniques prises avant même de commencer à animer.
La préproduction, ce n'est pas "le moment où on fait des tests".
C'est le moment où on verrouille les fondations pour ne plus jamais y revenir.
Parce qu'en animation gameplay, on ne peut pas "patcher" un mauvais système technique en cours de route.
On peut juste vivre avec pendant toute la prod.
Et parfois, comme pour mon client à 3 mois de la sortie, on se rend compte trop tard que les fondations étaient bancales.
À ce stade, on ne peut que mettre des pansements.
Dans un prochain article j'aborderai les décisions stratégiques clés en préproduction (scope, équipe, ...), celles qui influencent profondément la stabilité et la cohérence d'un projet.
-----------------------------------------------------------------------------------------------------------
Formation Animation Gameplay de Combat
le 28 novembre 2025
Seulement 10 places disponibles !
👉 Infos et inscriptions ici : Formation Animation gameplay combat
-----------------------------------------------------------------------------------------------------------
AniMatch : La version beta est ouverte aux testeurs : AniMatch