Animation gameplay : comprendre les différences entre joueur et NPC

Quand je fais passer des entretiens ou que je regarde des portfolios, je vois souvent la même chose.

Des persos joueurs qui bougent super bien. Des combos fluides. Des dashs nerveux.

Mais presque jamais de NPCs.

Et c'est logique. En école, on apprend à animer “un personnage”.

On travaille sur un cycle, une attaque, une locomotion , sans contexte d’implémentation.

Mais en studio, la première mission est rarement celle qu’on imagine.

Ce n’est pas le héros. Ce n’est pas le boss final.

C’est souvent… un NPC.

Et là, beaucoup de juniors découvrent que les règles ont changé.

• Le joueur agit. Le NPC réagit.

• Le joueur contrôle. Le NPC signale.

• Le joueur doit se sentir puissant. Le NPC doit être lisible, juste, anticipable.

Ne pas comprendre cette distinction, c’est passer des semaines à corriger des animations qui “ne marchent pas en gameplay”… sans savoir pourquoi.

Ce n’est pas juste une question de style.

C’est une question de logique, de pilotage, de responsabilité.

Dans cet article, je partage les différences concrètes que j’aurais aimé connaître en début de carrière.

Celles qui ne sont pas dans les tutos.

Celles qui font que “ça marche en gameplay” , ou pas.

Télécharge la checklist Joueur VS NPC (section GameFeel)

Deux logiques d’animation : contrôle ou lisibilité

Côté joueur : priorité au contrôle

Le joueur est aux commandes. Chaque animation doit prolonger son intention, sans latence perceptible. Ce n’est pas la beauté qui prime , c’est le ressenti.

• Le déclenchement doit être immédiat. L’animation part dès l’input, pas dans 10 frames.

• L’anticipation est réduite au strict minimum. Pas de wind-up, pas de délai volontaire.

• Le recovery doit être interruptible, pour permettre les enchaînements ou les annulations.

• Le blend per bone permet de viser en courant, sauter en regardant ailleurs , le contrôle est prioritaire.

• Le root motion doit être maîtrisé : transitions propres entre anims sur place et en déplacement, sans glissement ni téléport.

• Le système doit gérer les cancel windows et l’input buffering pour fluidifier les enchaînements.

Tout est pensé pour que le joueur se sente puissant, réactif, et en contrôle. 

Et chaque micro-latence se voit , et se ressent.

Ori démontre parfaitement la notion de contrôle du player

Côté NPC : priorité à la lisibilité gameplay

Le NPC ne répond pas à un input. Il exécute une intention. Son animation ne sert pas à “faire joli” , elle sert à signaler une action.

• “Je vais attaquer.”

• “Je te cherche.”

• “Je suis vulnérable maintenant.”

Si ces intentions ne sont pas lisibles, le combat devient injuste. Le joueur ne peut pas anticiper, réagir, ou punir , et l’expérience devient frustrante.

Mais ce n’est pas qu’une question de lisibilité. Il y a des contraintes techniques que personne ne prend le temps d'expliquer.

• La zone d’impact est définie par le game designer : portée, timing, fenêtre de punition. Si l’animation fait bouger le NPC au mauvais moment ou dans la mauvaise direction, l’attaque devient soit trop permissive, soit trop punitive. Le joueur peut se faire toucher alors qu’il est hors de portée. C’est injuste.

• Les loops doivent être propres. Un joueur ne reste jamais idle plus de quelques secondes. Un NPC peut attendre longtemps. Si l’animation idle a un micro-glitch toutes les 3 secondes, ça se voit. Et ça casse l’immersion.

• Le root motion doit être précis. Le NPC doit s’arrêter au bon endroit, dans le bon angle, avec un contrôle exact de sa position. Si le personnage glisse après le stop, même légèrement, ses enchaînements seront décalés, ses interactions mal calibrées, et l’expérience devient bizarre.

Le NPC n’est pas là pour briller. Il est là pour servir le gameplay. Et ça demande une rigueur technique que beaucoup sous-estiment.

Les NPC dans TLOU2 sont particulièrement conscients de leur environnement

Implémentation moteur : deux chaînes de décision

On entend souvent : “le joueur a des blend spaces, le NPC a des state machines.”

C’est vrai, mais c’est trop vague. En production, ce sont deux logiques radicalement différentes.

Le joueur : pilotage direct

Le joueur appuie sur une touche. Le système détecte l’input. Il déclenche l’animation.

C’est direct. C’est rapide. C’est réactif.

Pour gérer ça, on utilise :

• Motion matching : sélection dynamique dans une base d’animations selon l’état du joueur

• Blend per bone : le torse peut viser indépendamment des jambes

• Cancel windows : frames dédiées à l’interruption ou à l’enchaînement

• Input buffering : anticipation du prochain input pour fluidifier les transitions

• Root motion maîtrisé : transitions propres entre anims sur place et en déplacement

Tout est optimisé pour que le joueur ne sente aucune latence.

L’animation est au service du contrôle.

Le NPC : pilotage indirect

Le NPC ne répond pas à un input. Il exécute une intention.

Et cette intention passe par plusieurs couches :

• IA : perception → décision (“attaquer le joueur”)

• Behavior tree : sélection du comportement approprié

• State machine : transition entre états (“patrol” → “attack”)

• NavMesh : calcul de trajectoire si déplacement requis

• Animation : déclenchée en fonction du comportement et de la position

Le NPC ne peut pas être aussi réactif que le joueur et ce n’est pas un problème.

C’est une logique systémique, pensée pour la lisibilité et la cohérence.

Une complexité interdisciplinaire

Implémenter un NPC, ce n’est pas juste poser des clés dans un cycle.

C’est collaborer avec :

• Programmeurs : pilotage IA, transitions, synchronisation moteur

• Game designers : calibration des navmesh, logique d’interaction, intention gameplay

• Level designers : positionnement des points d’intérêt, cohérence spatiale

• Animation : lisibilité, anticipation, cohérence avec les timings gameplay

C’est pourquoi implémenter un NPC seul est rarement viable.

Le joueur peut être animé en autonomie relative , mais le NPC est un objet systémique, dépendant de toute la chaîne de production.

Et l’agenda ?

On parle parfois d’agenda pour les NPCs , mais en réalité, il s’agit le plus souvent d’états simulés ou déclenchés contextuellement, pas de routines horaires rigides.

• Dans la majorité des projets, les transitions entre états (“patrol”, “idle”, “interact”, “alert”) sont pilotées par le gameplay, pas par l’heure du jour

• Ces transitions doivent être interruptibles proprement (ex. : si le joueur attaque pendant une interaction)

• Chaque état peut nécessiter des animations spécifiques, mais l’agenda est généralement systémique, pas scripté

Cela dit, certains projets vont plus loin.

Sur Ghost Recon Wildlands, par exemple, les civils avaient un agenda horaire réel : travail, pause déjeuner, repos , en fonction de l’heure du jour.

Mais la plupart des productions ne disposent pas de cette granularité.

Le joueur, lui, n’a pas d’agenda. Il agit librement, sans contrainte de routine.

Le NPC, en revanche, doit s’intégrer dans le monde, avec des comportements cohérents, interruptibles et parfois simulés.

Les NPC de RDR2 ont leur propre vie

Interactions : là où les NPCs deviennent complexes

C’est rarement abordé en formation, et pourtant, c’est là que vous passerez une bonne partie de votre temps en production.

Les NPCs ne font pas que se déplacer. Ils interagissent avec le monde : objets, personnages, décor , et chaque interaction pose des contraintes spécifiques.

Interaction avec les objets

Prenons un exemple simple : ouvrir une porte.

• Le NPC doit se positionner précisément devant la porte (snap to position)

• L’animation doit finir au bon endroit, sinon il traverse la porte

• Si la porte est battante, il faut synchroniser l’ouverture avec le mouvement du bras

• S’il y a plusieurs types de portes (simple, double, coulissante), il faut des variantes ou des systèmes adaptatifs

Côté joueur :

• L’interaction est souvent plus souple, avec des systèmes qui tolèrent une légère imprécision

• L’animation peut s’adapter dynamiquement, mais reste pilotée par le contrôle joueur

• L’objectif est de préserver la fluidité et le ressenti, sans casser le gameplay

Côté NPC, on attend une précision spatiale et temporelle.

ouvrir des portes dans les jeux vidéos...

Interaction avec les personnages

Deux NPCs qui discutent. Ou un NPC qui vous parle.

• Proxémique : ni trop près (malaise), ni trop loin (perte de lisibilité)

• Regard : le NPC doit suivre votre personnage du regard, pas fixer dans le vide

• Posture : le torse doit s’orienter vers vous, pas juste la tête , sinon l’angle devient trop restreint

Ces éléments sont généralement gérés par des systèmes de look-at améliorés, combinés à des règles de priorité et du blend per bone.

Mais leur calibration varie énormément d’un projet à l’autre :

• Trop discret, le regard devient invisible , voire dérangeant (le perso semble parler dans le vide, sans connection)

• Trop rigide, la posture devient irréaliste ou impossible à tenir

• Mal synchronisé, le torse reste figé et casse la cohérence de l’interaction

 Ce n’est pas une technologie rare , c’est sa qualité d’implémentation qui fait la différence.

Ces interactions, lorsqu’elles concernent le joueur, sont généralement limitées ou prises en charge par des cinématiques.

Pour les NPC, elles doivent fonctionner en temps réel, dans tous les cas de figure , avec des contraintes de distance, de regard, de posture et de synchronisation moteur.

Interaction avec le décor

Un NPC s’assoit sur un banc.

Mais dans le jeu, il y a 15 variantes visuelles : hauteurs différentes, accoudoirs, longueurs, styles.

Et pourtant, vous ne pouvez pas faire une seule animation “s’asseoir” générique.

Il faut choisir une stratégie :

• Créer une animation par type de banc → lourd en production

• Utiliser de l’IK procédurale pour adapter la pose → complexe à stabiliser

• Accepter une approximation → souvent rejetée par le game designer

Une quatrième option consiste à normaliser les meshes :

On garde une géométrie identique (hauteur, profondeur, position d’assise), et on varie uniquement le visuel.

Cela permet de réduire le nombre de variations d’animation, tout en conservant la diversité esthétique.

C’est une solution efficace, mais elle doit être anticipée en amont, d’un point de vue design,  tech, et animation.

Le joueur ? Il s'assoit rarement. Et quand il le fait, c'est une cinématique. Pas du gameplay.

Expérience terrain : quand la différence devient concrète

J’ai eu l’occasion d’animer à la fois des personnages joueurs et des NPCs sur plusieurs productions.

Et c’est en studio que la distinction devient évidente , non pas théorique, mais systémique.

Personnage joueur : variations riches, intégration exigeante

Sur le personnage principal, chaque contexte de gameplay peut modifier la locomotion.

Fatigue, tension, environnement, blessure, tout se reflète dans l’attitude du personnage.

• Le joueur peut marcher plus lentement pour ne pas faire de bruit

• Il peut boiter s’il est blessé, ou accélérer s’il est en danger

• Ces variations renforcent l’immersion, mais elles doivent rester cohérentes entre elles

Et c’est là que le vrai défi commence :

Une marche bras croisés ne blendera pas proprement avec un start/stop bras le long du corps.

Il faut savoir implémenter intelligemment, pour enrichir sans multiplier les animations.

 Ce n’est pas juste “plus de contenu”. C’est plus de logique d’intégration.

variations de locomotion sur Beyond Two Souls

NPCs : simplification stratégique, crédibilité ciblée

Les NPCs sont souvent plus nombreux, moins visibles, moins prioritaires.

Mais leur rôle reste essentiel : ils peuplent le monde, donnent du rythme, soutiennent le gameplay.

• Une ou deux variantes suffisent dans la majorité des cas

• Leur priorité : être lisibles, cohérents, crédibles , sans surcharger la production

• Trop d’animations mal maintenues = loops qui sautent, bugs visuels, immersion cassée

Cela dit, la tendance actuelle évolue.

On cherche à rendre les NPCs plus conscients de leur environnement, plus réactifs, plus crédibles.

Sans tomber dans l’usine à gaz.

 Le bon NPC, c’est celui qui fonctionne bien, même avec peu d’animations.

Ghost Recon Breakpoint : fluidité maximale côté joueur

Sur Ghost Recon, le personnage principal utilisait du motion matching :

des milliers d’animations sélectionnées dynamiquement selon l’état du joueur.

• Fluidité exceptionnelle

• Réactivité frame-perfect

• Ressenti prioritaire

Le système était pensé pour prolonger l’intention du joueur sans latence.

Chaque input devait déclencher une réponse immédiate, cohérente, et fluide.

Côté NPCs, on restait sur des state machines classiques :

cycles calibrés, mocap optimisée, logique robuste.

Pourquoi ? Parce que :

• Le joueur ressent chaque micro-latence

• Le NPC, personne ne remarque s’il a 100 ms de délai

• Implémenter du motion matching pour 50 types de NPCs, c’est une usine à gaz

Deux architectures. Deux logiques. Deux niveaux d’exigence.

Déplacement du joueur, et des NPC dans GRBreakpoint

Prince of Persia: The Lost Crown : calibrer la menace

Sur PoP, la question revenait souvent :

“Ce NPC doit-il se déplacer plus vite ou moins vite que le joueur ?”

• Plus rapide → pression constante, menace directe

• Plus lent → le joueur peut gérer la distance, anticiper

La vitesse n’était pas un détail.

Elle définissait le type de menace, le rythme du combat, la marge de réaction.

Et l’animation suivait cette intention :

anticipation claire, fenêtre de punition visible, cohérence avec les hitboxes.

 L’animation n’est pas décorative. Elle est au service du gameplay.

Prince of persia, au service du gameplay

Bonnes pratiques : ce qu’il faut viser

Personnage joueur

• Réactivité fluide : transitions sans latence, input toujours prioritaire

• Blend per bone : actions indépendantes (torse, bras, jambes) pour préserver le contrôle

• Root motion maîtrisé : transitions propres entre anims sur place et en déplacement

• Cancel windows et buffering : logique frame-perfect pour les enchaînements

• Tests en contexte gameplay : validation avec input, caméra, feedback

NPC

• Lisibilité comportementale : anticipation claire, posture explicite, recovery visible

• Loops robustes : idle sans glitch, cycles stables sur longue durée

• Interactions calibrées : regard, posture, distance sociale, synchronisation décor

• Root motion précis : cohérence spatiale pour les transitions et les hitboxes

• Agenda respecté : transitions propres entre états, interruptions gérées

Ces bonnes pratiques ne sont pas des “tips” , ce sont des critères de validation.

En studio, c’est ce qui fait la différence entre une animation “jolie” et une animation fonctionnelle.

Red flags : ce qu’il faut éviter

Joueur

• ❌ Animation “jolie” mais non testée en gameplay → rupture de contrôle

• ❌ Blend mal calibré → glissement, téléport, incohérence visuelle

• ❌ Pas de cancel window → input bloqué, frustration immédiate

• ❌ Anticipation visuelle inutile → ralentit le ressenti sans bénéfice gameplay

• ❌ Root motion négligé → transitions cassées entre anims sur place et en mouvement

NPC

• ❌ Pas d’anticipation → attaque injuste, illisible

• ❌ Loop idle avec micro-glitch → effet “bug visuel”, perte d’immersion

• ❌ Regard figé ou mal orienté → effet creepy, incohérence sociale

• ❌ Interaction décor non synchronisée → NPC traverse un banc, une porte, un

Conclusion : deux rôles, deux responsabilités

Animer un personnage joueur et animer un NPC, ce n’est pas “le même métier avec moins de budget”.

C’est une différence de logique, de pilotage, de fonction.

• Le joueur agit : il exige du contrôle, de la réactivité, du feedback immédiat

• Le NPC réagit : il doit être lisible, crédible, cohérent avec le système

• Le joueur traverse le monde. Le NPC vit dedans — avec un agenda, des interactions, des contraintes

Ce n’est pas une question de complexité.

C’est une question de fonction.

Et en entretien ?

Ne dites pas simplement “j’ai animé un personnage”.

Formulez la logique métier:

“J’ai animé un personnage joueur, donc j’ai optimisé pour la réactivité : pas d’anticipation, recovery minimale, blend spaces pour la fluidité.

Mais je comprends que pour un NPC, les priorités sont différentes : lisibilité, anticipation visible, cohérence avec les zones d’impact définies par le design”

Vous venez de montrer que vous comprenez les enjeux du gameplay.

Et vous passez devant 90 % des candidats qui disent juste “j’aime bien animer”.

Comprendre cette distinction, c’est non seulement mieux animer mais

c’est aussi mieux collaborer avec le design, le code, le QA, et mieux défendre ses choix en production comme en entretien.

Télécharge la checklist Joueur VS NPC (section GameFeel)