La marche : première contrainte de l’animation gameplay
- Vanessa
- il y a 4 jours
- 11 min de lecture
Quand l’animation doit fonctionner pour le gameplay et avec le système
L’Idle pose le personnage.
Mais dès qu’il commence à marcher, tout change : le jeu réagit.
Des éléments invisibles jusque‑là s’activent : vitesses, distances, transitions, règles moteur.
Tu n’es plus dans un DCC. Tu entres dans un système.
La marche est la première animation qui doit fonctionner avec le gameplay, dans le moteur, pour le joueur.
C’est le moment où l’animation cesse d’être un mouvement isolé et devient une réponse à des contraintes qui se révèlent une par une.
Et c’est là que les vraies questions commencent :
Pourquoi une marche fonctionne dans un DCC mais pas en moteur ?
Comment une simple vitesse peut changer la personnalité d’un personnage ?
Pourquoi c’est souvent la première animation où animateurs, designers et moteur doivent vraiment s’accorder ?
Télécharge le PDF Gameplay Animation Framework – Walk (section Frameworks)
Comprends la marche comme un système dynamique
5 pages pour créer des marches gameplay robustes : décisions clés avant production, métriques pour le gameplay, checklist V0→V2, schéma du système Walk, et liste complète des états liés à la locomotion.
Compact, clair et pensé pour la production réelle.
Première vraie contrainte moteur
Après plusieurs années à travailler sur des locomotions, j’avais déjà vu des marches réagir différemment entre un DCC et un moteur.
Mais sur Assassin’s Creed Syndicate, on a eu un cas assez parlant.
On intègre la mocap brute.
Dans MotionBuilder, tout semble propre : fluide, lisible, rien qui déclenche une alarme.
Puis on prend le pad.
Et là… c’est mou. Pas “mauvais”, pas “cassé”, juste mou.
Pas du tout la sensation qu’on attend d’un personnage capable de grimper, sauter, s’accrocher partout.
Un assassin athlétique qui marche comme s’il sortait de sa sieste, ça ne fonctionne pas.
On a donc ouvert la Story pour resserrer les timings, réinjecter du rythme, et redonner un peu de nerf à la marche.
MotionBuilder est parfait pour ça : on peut vraiment monter l’animation comme une séquence, jusqu’à retrouver une sensation crédible en gameplay.
Et ce n’était que le début.
Sur Ghost Recon, ce n’était pas l’animation qui posait problème.
Quand l’IA reprenait le contrôle, le moteur “hackait” la vitesse : accélération, ralentissement…
Résultat : un léger glissement sur une courte distance , rien de dramatique, mais suffisant pour rappeler que le moteur a toujours le dernier mot.
Sur Prince of Persia, c’était encore autre chose.
Si les game designers et les animateurs ne s’accordaient pas sur les vitesses de marche, tout le système devenait incohérent.
Une vitesse trop lente, et Sargon semblait flotter. Trop rapide, et il perdait son poids.
Toutes ces situations ont un point commun : la marche est la première animation qui dépend d’éléments extérieurs à l’animation elle‑même.
La vitesse, le code, l’IA, les distances, les transitions… tout commence à peser dessus.
C’est la première fois que ton animation doit s’adapter à un système qui a ses propres règles, ses propres besoins, et parfois ses propres décisions.
À ce stade, la marche n’est plus un cycle qu’on regarde dans un viewport.
C’est un contrat moteur.
Un accord entre l’animation, le gameplay et les règles du système , un accord qui se voit immédiatement dès qu’on prend le pad.
Penser en système : métriques et calibrage
La marche est la première animation directement impactée par les métriques, ces valeurs définies par les game designers pour encadrer le comportement du personnage : vitesse de marche, vitesse de course, accélération, distances d'engagement, poids perçu, inertie.
Ces chiffres ne sont pas décoratifs : ils déterminent comment ton animation doit bouger pour être cohérente avec le gameplay.
Et c'est souvent à ce moment-là que les designers et les animateurs découvrent s'ils parlent vraiment la même langue.
Sur Prince of Persia, on avait des métriques théoriques pour Sargon. Une vitesse de marche définie, un cycle calibré.
Mais tant que les vrais NPC n'étaient pas en place, impossible de savoir si tout ça fonctionnerait vraiment.
Et quand les vrais NPC sont arrivés, tout s’est ajusté naturellement :
plus lent que les grands ennemis comme le Jailer
plus rapide que les zombies de sa taille
compatible avec la difficulté
cohérent avec les distances d’engagement
Ce calibrage n’était pas un “retard” : c’était simplement le moment où le système devenait vivant.
Comme je le disais dans l’article précédent : dans un projet, le changement n’est pas une exception , c’est la règle.
C’est là que tu réalises que la marche (ou la course) n’est pas un cycle isolé.
C’est un métronome qui impose un tempo au jeu entier.
Le pivot de la locomotion
La marche, c’est la charnière de tout le système de déplacement.
C’est elle qui donne le tempo, l’inertie, la direction, la lisibilité.
Tout passe par elle, même si on ne s’en rend pas toujours compte.
Elle influence directement :
l’Idle (comment on en sort, comment on y revient)
le Run (le rythme, l’amplitude, la poussée)
le Sprint (l’énergie, la direction)
les Starts (la première impulsion)
les Stops (le freinage, l’inertie)
les pivots et transitions directionnelles (poids, orientation, engagement)
Si ta marche est bancale, tout le système locomotion l’est aussi.
Une marche trop lente → un run qui semble forcé Le joueur a l’impression que le personnage “passe une vitesse” trop brusquement.
Une marche trop stylisée → des transitions qui cassent Le blending devient visible, les poses ne s’alignent plus.
Une marche trop ancrée → un personnage lourd même en course Le tempo de la marche contamine tout le moveset.
Une marche trop flottante → un personnage sans poids Même un sprint puissant semblera léger.
Je n’ai jamais vécu une production où “toute la locomotion” dépendait littéralement de la marche. Ce serait exagéré.
Mais j’ai vécu l’inverse : des marches impossibles à partager entre personnages, parce qu’elles ne racontaient pas la même chose.
Sur Ghost Recon, on a essayé de retargeter la même marche sur plusieurs gabarits. Ça ne fonctionnait pas du tout.
Le soldat qui portait la gatling, par exemple : avec la marche standard, il semblait… léger. Comme si l’arme ne pesait rien.
On a dû refaire une marche entièrement différente : plus ancrée, plus lente, plus lourde.
La marche est une signature physique. Elle doit refléter le poids, la taille, l’armement, le rôle , tout ce qui définit le personnage dans le système.
Là où tu deviens Animateur Gameplay
La marche, c’est aussi la première animation qui t’oblige à faire des choix de système, pas seulement des choix d’animation.
C’est là que tu découvres que tu ne travailles plus “dans ton DCC”, mais dans un écosystème.
Tu es en train de choisir comment ton personnage existe dans le jeu.
Dès que tu poses une marche dans le moteur, tu dois prendre des décisions qui dépassent complètement le posing. Et ces décisions, ce sont elles qui vont définir tout ton système de locomotion.
Qui contrôle le déplacement ?
Est‑ce que c’est l’animation (root motion) ou est‑ce que c’est le moteur qui déplace le personnage ?
C’est un choix de ressenti, de réactivité, de philosophie de gameplay.
Sur certains projets comme Heavy Rain, Beyond Two Souls, Assassin’s Creed ou Ghost Recon, le déplacement était géré dans l’animation.
On travaillait en mocap : l’allure était donnée par l’acteur sur le plateau, puis on la retravaillait dans le DCC pour la rendre cohérente, lisible, et adaptée au personnage.
Mais une fois validée, cette allure devenait la référence.
Le moteur suivait l’animation, pas l’inverse.
C’était une philosophie très “cinématique” : fluide, organique, fidèle à l’intention du plateau.
Mais elle impose une contrainte : la réactivité dépend de ce que tu peux corriger en animation, pas en moteur.
Sur Prince of Persia, la situation était différente.
Tout était en keyframe, et dès le début, le game director voulait un contrôle maximal : toutes les animations devaient être faites “sur place”, et le moteur devait gérer les déplacements.
J’ai râlé (évidemment), pour défendre la qualité, avant même que la production ne commence.
Je savais exactement ce que ça impliquait si on acceptait ça dès le départ : des glissements de pieds, une perte de poids...
Et surtout : une base d’animation qu’on ne pourrait jamais rattraper plus tard.
On a donc trouvé un compromis intelligent : définir précisément quelles animations devaient être drivées par l’anim, et lesquelles pouvaient être confiées au moteur.
Résultat :
les vitesses, accélérations et décélérations sont gérées par le moteur,
les actions (attaques, interactions, impulsion du saut) restent pilotées par l’anim,
la marche/course sert de référence pour tout ce système hybride.
C’est la marche/course qui nous a montré ce que cette décision impliquait, et où il fallait protéger la qualité pour ne pas tout perdre en route.
On est resté concentré sur trois piliers : la beauté de l’animation, la réactivité du moteur et le contrôle du joueur.
Comment gère‑t‑on les pieds ?
La marche, c’est aussi le moment où tu dois décider comment le système sait sur quel pied se trouve ton personnage.
Et selon les moteurs sur lesquels j’ai travaillé, les approches ont été radicalement différentes.
Heavy Rain : l’époque “old school”
Sur Heavy Rain, il n’y avait aucune détection de pieds. Pas de notifies, pas de foot planting, pas d’IK runtime. On définissait manuellement la plage de blend de chaque animation, une par une.
C’était un pipeline très artisanal : on compensait avec du soin, de la précision, et beaucoup de retouches.
Mais on n’avait aucun moyen systémique de savoir sur quel pied on était.
Beyond Two Souls : la révolution interne
Pour Beyond, on a refondu tout le moteur.
On est passé aux state machines et au nodal, et surtout : on a ajouté un système d’events automatiques dans Maya.
Un bouton analysait l’animation et posait les events “pied gauche au sol / pied droit au sol” au bon endroit. En runtime, on avait du foot planting propre et stable.
Résultat : on savait toujours sur quel pied on était.
Les transitions étaient nettes, les QTE se synchronisaient parfaitement, et même les passages gameplay ↔ cinématiques étaient fluides.
On a testé l’IK temps réel (en 2012), mais ça détruisait trop la mocap. On l’a utilisé avec parcimonie, surtout sur les pentes.
Ghost Recon & Assassin’s Creed : le moteur Ubisoft
Sur ces projets, on pouvait poser des events dans le moteur pour détecter les pieds. C'était une approche différente , plus manuelle, moins automatisée que ce qu'on avait sur Beyond.
En pratique, ça demandait plus d'ajustements tout au long de la production : des cuts pour gérer les passages gameplay ↔ cinématiques, des transitions supplémentaires pour couvrir les cas limites, un travail permanent pour garder la cohérence du système.
Ce n'était pas la même philosophie que Beyond , mais c'était cohérent avec la nature de ces projets : des productions très larges, avec des pipelines partagés entre de nombreuses équipes, où la flexibilité prime sur la précision chirurgicale.
Chaque moteur fait des choix.
Et ces choix définissent ce que tu peux faire , et ce que tu dois compenser.
Prince of Persia : Unity et le choix assumé
Sur PoP, on a fait un choix volontaire : pas de détection de pieds.
C’était un jeu 2D side‑scrolling, très nerveux, sans starts ni stops. Les transitions étaient volontairement brutales pour maximiser la réactivité.
On a donc travaillé sur des poses hybrides, capables de blender sur n’importe quel pied.
À la vitesse du jeu, les micro‑incohérences deviennent invisibles. Et ce choix servait parfaitement le gameplay.
La gestion des pieds est un choix de philosophie, de pipeline, de moteur, de priorités.
Et c’est encore une fois la marche qui t’oblige à trancher : entre précision, flexibilité, robustesse, ou réactivité pure.
Et derrière tout ça, il y a une contrainte incontournable :
la marche doit pouvoir être coupée à n’importe quel moment.
Si ton système ne sait pas sur quel pied tu es, ou si tes poses ne supportent pas un cut propre, tu le payes immédiatement : départs bancals, pivots qui glissent, transitions forcées.
L’interruptibilité c’est le test de robustesse de ton système.
S'adapter aux vitesses ?
L’adaptation de la marche aux vitesses dépend entièrement du moteur et du pipeline.
Sur certains projets, la marche avait une vitesse fixe.
Sur d’autres, on avait des systèmes plus sophistiqués capables d’ajuster la vitesse ou la taille des pas.
Et parfois, c’est le moteur qui compensait , à condition que l’animation le supporte.
Sur Heavy Rain, la marche avait une vitesse unique : celle de la mocap. Une seule marche, une seule allure. Le moteur ne modifiait rien, et tout le système devait s’aligner dessus.
Sur Beyond, on avait beaucoup plus de liberté.
La marche restait basée sur la vitesse de la mocap, mais on avait une surcouche de blending qui permettait d’ajuster très finement la vitesse et la taille des pas. Un blend idle/marche pouvait générer toutes les vitesses intermédiaires, parfaitement cohérentes grâce aux events de pieds.
Ce système a permis des choses très précises : amener le joueur exactement au bon endroit, sur le bon pied, pour déclencher un QTE, ou gérer des comportements complexes de NPC (comme la scène de la fête où les ados se cachent, sortent, reviennent, etc.).
Sur Ghost Recon, on blendait plusieurs vitesses (marche, jog, course, sprint), mais sans détection de pieds.
C’était un blend basique : ça fonctionnait, mais sans la finesse d’un système basé sur les contacts.
Sur Prince of Persia, c’était encore autre chose. On avait une vitesse de marche, une vitesse de course, et le moteur adaptait le reste.
Comme le jeu est en 2D, très nerveux, et que les anims étaient parfaitement raccord, les micro‑variations étaient invisibles.
La communication entre équipes a été essentielle pour que tout reste cohérent en jeu.
Dans tous les cas, la marche est un équilibre entre :
ce que le moteur peut adapter,
ce que l’animation peut supporter,
et ce que le gameplay exige.
Et c’est encore une fois la marche qui révèle si ton système est capable d’encaisser ces variations… ou si tu vas devoir créer des anims dédiées, ajuster le pipeline, ou revoir la logique de blending.
Se mélanger avec le reste du moveset ?
La marche n’existe jamais seule : elle doit se fondre dans tout le moveset.
C’est là que tu dois penser blending, direction, inertie, transitions, anticipation du joueur.
Une marche peut être très belle dans ton DCC, mais si elle ne se mélange pas proprement avec le reste , changements d’allure, pivots, actions, variations de vitesse , les ruptures deviennent visibles immédiatement.
Le mélange dépend du moteur, du pipeline, et de la manière dont les pieds sont gérés.
Si les poses ne supportent pas un cut propre, si les transitions ne sont pas pensées pour absorber les variations, ou si le système ne sait pas sur quel pied tu es, tout le moveset en souffre.
La marche est donc un point d’ancrage : si elle se mélange bien, tout devient fluide. Si elle se mélange mal, tout casse.
C’est là que tu deviens animateur gameplay
La marche, c’est le moment où tu changes vraiment de posture.
Tu ne penses plus seulement posing ou intention : tu penses réactivité, anticipation, cohérence système, dialogue avec le moteur.
Tu comprends que ton animation n’existe plus seule, mais dans un ensemble qui doit rester fluide, contrôlable et lisible.
À partir de là, ce n’est plus “faire une belle marche”.
C’est définir comment ton personnage vit dans le jeu.
La marche t’oblige à faire des compromis, à prendre des décisions, à collaborer avec les autres équipes.
C’est ton premier vrai contact avec la logique gameplay , celui où tu deviens vraiment animateur gameplay.
Conclusion : la marche n’est pas un cycle , c’est un carrefour
La marche gameplay est le premier moment où ton animation doit vraiment exister dans un système.
Elle doit respecter un moteur, servir un joueur, rester cohérente avec un moveset, fonctionner dans toutes les directions, refléter le poids et le rôle du personnage, rester lisible à distance, et être calibrée pour la difficulté du jeu.
L’Idle posait la fondation statique.
La marche pose la fondation dynamique.
C’est là que ton personnage commence réellement à vivre dans le jeu.
Et c’est là que toi, en tant qu’animateur gameplay, tu commences à faire des choix qui dépassent l’animation elle‑même : des choix de système, de ressenti, de contrôle.
La marche n’est pas un cycle. C’est un carrefour. Et tout ton gameplay passe par là.
Si tu devais refaire ta marche en partant non pas d’un cycle “propre”, mais de toutes les contraintes gameplay que tu viens de parcourir : les pieds, la vitesse, l’interruption, le blending, la direction, le moteur ...Est‑ce que tu ferais les mêmes choix ?
C’est exactement ce que le défi du mois te propose d’explorer.
Télécharge le PDF Gameplay Animation Framework – Walk (section Frameworks)
Comprends la marche comme un système dynamique
5 pages pour créer des marches gameplay robustes : décisions clés avant production, métriques pour le gameplay, checklist V0→V2, schéma du système Walk, et liste complète des états liés à la locomotion.
Compact, clair et pensé pour la production réelle.
Commentaires