Avancé

PaperZD

Construis l'animation de personnages 2D dans PaperZD en la demandant simplement : flipbooks à partir d'une planche de sprites, sources d'animation, Animation Blueprints, state machines, personnages jouables et vérification en jeu.

PaperZD, de Critical Failure Studio, est le système d’animation qu’utilisent la plupart des jeux Paper2D : graphes d’animation et state machines pour des personnages en flipbooks. Il est gratuit sur Fab et sur GitHub.

Avec l’extension PaperZD, Ultimate Engine CoPilot construit ces montages pour toi, d’une planche de sprites à un personnage qui marche et attaque en jeu.

Elle a été testée avec PaperZD 2.2.4 sur Unreal Engine 5.7.

Ce qu’il te faut

PaperZD, installé et activé dans ton projet. Il utilise le plugin Paper2D d’Unreal, que PaperZD active avec lui.
Une planche de sprites pour ton personnage, ou des flipbooks existants.

Plus Ultimate Engine CoPilot avec l’extension PaperZD activée.

Sans PaperZD, l’extension ne fait rien de nuisible. Chaque outil PaperZD répond par un seul message qui dit si le plugin est installé, activé et chargé, et ce qu’il faut faire ensuite.

Mise en place

Installe PaperZD depuis Fab ou GitHub et active-le dans ton projet. Redémarre l’éditeur si Unreal le demande.
Dans le CoPilot, ouvre Paramètres > Extensions et active PaperZD. Elle est désactivée par défaut.
Demande à l’IA de vérifier l’état de PaperZD. Elle indique si PaperZD a été trouvé et, sinon, ce qui manque.

Ce que tu peux demander

“Voici ma planche de sprites du chevalier, 6 colonnes sur 13 lignes. Fais des flipbooks d’idle, de marche et d’attaque dans quatre directions et configure PaperZD pour eux.”
“Ajoute une state machine avec Idle, Walk et Attack. Walk quand le personnage bouge, retour à Idle quand il s’arrête, et Attack se joue une fois puis revient à Idle.”
“Fais en sorte que les animations regardent dans la direction où le personnage se déplace.”
“Fais un personnage jouable avec WASD pour se déplacer et Space pour attaquer, avec une caméra derrière lui et un game mode qui le fait apparaître.”
“Ajoute un bruit de pas à l’animation de marche.”
“Passe le personnage à la palette rouge pendant que le jeu tourne.”

Derrière ces demandes, l’IA peut :

Découper une planche de sprites en animations. Un seul appel transforme une planche en sprites, flipbooks, séquences d’animation, une source d’animation et un Animation Blueprint. Les animations à plusieurs directions deviennent une seule séquence multidirectionnelle.
Construire le graphe d’animation. Nœuds de lecture de séquence, de state machine, de direction, de slot d’override, de sélection par booléen, nombre ou enum, de lecteur aléatoire et d’animation en cache, et les relier.
Construire des state machines. États, conduits et sauts, avec des transitions qui se déclenchent sur une variable, quand l’animation en cours se termine, toujours ou jamais, avec une priorité et une séquence de transition facultative.
Ajouter des notifies. Événements personnalisés, sons et effets Niagara ou de particules sur une timeline, les notifies personnalisés devenant des fonctions que tu peux remplir.
Ajouter des skins. Des flipbooks de remplacement par animation, pour des tenues ou des changements de palette, appliqués pendant que le jeu tourne.
Créer des personnages. Un nouveau personnage PaperZD piloté par l’Animation Blueprint, ou brancher un acteur existant. Elle peut aussi ajouter une piste PaperZD à une Level Sequence.
Vérifier en jeu. Lire quelle séquence est en cours, où elle en est et les valeurs des variables d’animation, et lancer, arrêter ou sauter à une animation pour tester une transition à la main.

Erreurs qu’elle évite

PaperZD a quelques pièges qui compilent proprement et ne font pourtant rien. L’IA les connaît :

La règle d’une nouvelle transition est “jamais” tant qu’elle n’est pas définie, donc le personnage ne quitterait jamais Idle.
Une variable que lit une règle doit être écrite quelque part, en général dans le tick de l’Animation Blueprint. Une compilation propre ne prouve pas que la règle change un jour, donc l’IA vérifie en jeu.
Une séquence ne se joue que dans un Animation Blueprint de sa propre source d’animation, donc elle garde ensemble les assets de chaque personnage.
Les états et les transitions sont compilés en un seul lot à la fin d’un groupe de modifications, pas après chacune.
La grille de la planche de sprites se lit de gauche à droite en partant du haut, donc l’IA compte les cellules comme PaperZD.

Trucs et astuces

Ils viennent de la construction d’un petit village jouable avec PaperZD et le CoPilot : un héros, un villageois, des ennemis squelettes et des loups qui rôdent. Il a été testé avec PaperZD 2.2.4 sur Unreal Engine 5.7.

Les trois qui comptent le plus :

Donne à l’IA la vraie disposition des lignes de ta planche. Numérote les lignes à partir de 0, dis quelles lignes sont des animations et quelle ligne est autre chose, et ouvre la première image de chaque flipbook pour vérifier.
Ne fais jamais pivoter l’acteur. Un flipbook est une carte plate, donc la direction doit venir de l’animation qui joue, pas de la rotation de l’acteur.
Ne te fie pas à une compilation propre. Demande un test en jeu qui indique l’animation en cours et ses variables.

Décris la planche exactement

L’IA ne peut pas voir quelle ligne de ta planche contient quelle animation. C’est à toi de le lui dire.

Une planche exportée depuis PixelLab a 6 colonnes et 13 lignes de cellules de 92 pixels, avec quatre directions dans chaque animation dans l’ordre sud, ouest, est, nord. La ligne 0 est une ligne de poses de rotation, pas une animation.
L’export est fourni avec un fichier de disposition qui indique quelle ligne contient quelle animation. Utilise-le. L’ordre change d’un personnage à l’autre : dans le village, le héros et le mage avaient la marche en premier, le squelette l’attaque en premier et le loup l’idle en premier.
Compte à partir de 0 et nomme la ligne de rotation. Dans une session, le prompt disait “les lignes 1 à 4 sont la marche”. L’IA a compté à partir de 1, donc chaque animation était décalée d’une ligne et le héros regardait dans la mauvaise direction.

Écris les lignes ainsi :

Chaque planche fait 6 colonnes sur 13 lignes de cellules de 92 pixels. Numérote les lignes à partir de 0. La ligne 0 est la ligne de rotation, ignore-la. Les lignes 1 à 4 sont la marche (sud, ouest, est, nord, 6 images), les lignes 5 à 8 l’attaque, les lignes 9 à 12 l’idle (4 images).

Réglages qui comptent

Pixel art activé. Les textures utilisent le filtrage nearest et pas de mips, pour que les pixels restent nets.
Pivot en bas au centre. Les pieds restent au même endroit dans chaque image.
Images par seconde. Demande les vitesses que tu veux. L’IA a utilisé 15 pour tout, ce qui bouclait un idle de 4 images en environ un quart de seconde. Idle 6, marche 12 et attaque 14 donnaient un bon résultat.
Ordre des directions. Une séquence multidirectionnelle tourne dans le sens horaire à partir du haut : nord, est, sud, ouest.
Les valeurs d’un acteur placé l’emportent. Un cooldown ou une vitesse définis sur un acteur du niveau l’emportent sur la valeur par défaut du Blueprint, donc vérifie les copies placées quand un changement semble ne rien faire.

Garder le sprite face à la caméra

C’est la configuration qui a empêché le sprite de tourner, de pencher ou de se retrouver de chant :

Désactive la rotation de l’acteur. Controller yaw désactivé, orient rotation to movement désactivé, controller desired rotation désactivé. Laissés actifs, la carte tourne avec l’acteur et peut se retrouver de chant.
Fais apparaître avec un yaw de 0. Un yaw d’apparition de 180 fait pencher la carte à l’opposé d’une caméra fixe dans le monde.
Fixe le spring arm au monde. Pawn control rotation désactivé, hériter du pitch, du yaw et du roll désactivé, test de collision désactivé. Un pitch de -40 et un yaw de -90 ont fonctionné.
Incline la carte une seule fois. Avec la caméra qui regarde vers le bas de 40 degrés, donne au sprite un roll de -40 et remonte-le pour que les pieds touchent le sol.
Déplace-toi selon les axes du monde, pas le long du vecteur avant ou droite de l’acteur.
Montre la direction avec Set Directionality. Alimente-le avec une variable Vector2D nommée Facing. Écris Facing à chaque tick à partir de la vitesse et garde la dernière valeur quand le personnage s’arrête.

Avec cette caméra, les touches correspondent ainsi :

D déplace le long de +X, Facing (1, 0).
W déplace le long de -Y, Facing (0, 1).
A déplace le long de -X, Facing (-1, 0).
S déplace le long de +Y, Facing (0, -1).

Si la gauche et la droite ou le haut et le bas sont inversés, inverse le signe de cette partie de Facing. Ne fais pas pivoter l’acteur pour compenser.

Le tester en jeu

Une transition ne fait rien tant que sa règle ne peut pas changer. Une nouvelle règle est “jamais”, et une règle qui lit une variable a besoin de quelque chose qui écrive cette variable, en général le tick de l’Animation Blueprint. Demande un test en jeu qui indique l’animation en cours.
Donne une valeur de départ à Facing. Elle n’est écrite que pendant que le personnage bouge, donc une attaque avant le premier pas lit zéro. Une valeur par défaut au sud règle le problème.
Fais regarder la cible au héros. Si l’attaque doit toucher quelque chose sur le côté, demande à l’IA de mettre Facing vers l’ennemi le plus proche avant le coup.

Une vraie session

Le clip de collaboration a été construit en quatre prompts dans le chat du CoPilot, avec l’agent Claude Code. L’IA a lancé ses propres tests en jeu et réparé ce qu’elle trouvait. Les durées viennent d’une seule machine.

Deux personnages importés, avec des state machines d’idle, de marche et d’attaque : environ 2,5 minutes.
Un héros jouable (WASD pour se déplacer, Space pour attaquer), une caméra à spring arm, un game mode et un villageois qui marche entre trois points : environ 7 minutes.
Un ennemi squelette qui poursuit et attaque, des points de vie et un compteur de santé à l’écran : environ 7 minutes.
Des loups qui rôdent, des herbes à ramasser et un compteur d’herbes : environ 7 minutes.

Le rendu est un travail à part

L’IA construit l’animation et le gameplay. Le rendu du clip a été mis en place dans le niveau, pas par l’IA :

Une lumière chaude de soleil et de lanternes.
Du bloom, une vignette et une faible profondeur de champ pour un effet tilt-shift.
Un matériau émissif non éclairé sur les personnages.

Commence par le matériau non éclairé et une exposition fixe. Régler l’exposition à l’œil sur de nombreux essais a coûté plus de temps que cela n’en a rapporté.

Limites

L’IA ne sait pas quelle animation contient chaque ligne de ta planche. C’est à toi de le lui dire.
Les ennemis marchent droit sur le héros, sans recherche de chemin autour des accessoires.
À un angle exact de 45 degrés, deux axes sont à égalité et l’animation choisit l’est.
La santé s’arrête à 0. Rien d’autre ne se passe tant que tu ne demandes pas une mort.
Elle n’a pas pu lire un état d’animation au milieu d’une touche maintenue, et elle l’a dit au lieu de deviner.

Autorisations

La lecture est gratuite : inspecter un asset, un graphe ou une animation en cours ne demande jamais rien. Les modifications suivent ton réglage Ask Before Edit ou Auto Edit, comme tous les autres outils.

Comment ça marche

Aucun lien entre les plugins. L’extension atteint PaperZD uniquement par réflexion, donc Ultimate Engine CoPilot se construit et tourne de la même façon avec ou sans PaperZD installé, et l’extension continue de fonctionner d’une version de PaperZD à l’autre tant que la conception reste la même. Si une mise à jour renomme quelque chose, l’outil nomme le champ manquant au lieu de deviner.
Partout à la fois. Les outils fonctionnent dans le chat du CoPilot, dans des clients MCP externes comme Claude Code et Cursor, et dans les agents de programmation. Voir Intégration MCP.
39 outils. Des outils de création, d’inspection et de temps de jeu pour les sources, séquences, notifies, skins, Animation Blueprints, graphes, state machines, personnages et Sequencer.

Voir Extensions pour le fonctionnement des extensions, et Tests de jeu pour savoir comment l’IA vérifie un jeu en cours d’exécution.