KrostyMall/Landing-SENSORITY

Guide complet pour les assets d'animation de jeu : cycles de mouvement, keyframes d'action, séquences d'effets et feuilles de sprites d'animation — construit autour d'un pipeline vidéo.

Qu'est-ce que Landing-SENSORITY ?

Ce skill est une doctrine technique dédiée à la production d'animations 2D pour le jeu vidéo, en s'appuyant sur un pipeline vidéo plutôt que sur la génération image par image. Il définit des lois de mouvement (continuité, physique, bouclage) et un test de vérification (flip test) pour garantir que les séquences d'images produites sont fluides et bouclables. Le skill fonctionne dans un environnement de type app-builder, où il est utilisé conjointement avec les skills `video2dsprite` et `generate2dsprite` (fond magenta `#FF00FF` et scripts chroma key). Il est utile pour tout asset animé : cycles de marche/course, attaques, animations au repos, effets, drapeaux, feu, feuilles de sprites. Il complète le skill game-asset-core en fournissant des règles de post-production et de sélection de frames. Le but est de remplacer les méthodes manuelles (comme ffmpeg ad-hoc) par une automatisation cohérente, en préférant la vidéo pour ses propriétés naturelles de continuité.

Compatible avec✓Claude Code~Codex CLI~Cursor

npx skills add https://github.com/KrostyMall/Landing-SENSORITY/tree/HEAD/.grok/skills/game-animation-frames

Documentation

Images d'animation — priorité à la vidéo

Le générateur d'images dessine des poses ; le générateur de VIDÉO comprend le mouvement — alternance des jambes, continuité des arcs, dynamique des tissus et du feu viennent gratuitement parce que la vidéo doit les animer. Ne demandez donc pas au modèle d'image d'imaginer des poses en plein mouvement : animez la base et récoltez les images réelles.

Exécution dans l'app-builder (à lire en premier)

Ce skill est une doctrine (lois du mouvement, qualité du bouclage, quand utiliser la vidéo). Dans le bac à sable de l'app-builder, n'exécutez pas une récolte libre avec ffmpeg ou n'inventez pas un arrière-plan #hex cléable au hasard.

Étape	Action
Sprites de production / grilles fixes	`generate2dsprite` — feuilles magenta solides `#FF00FF` + scripts chroma
Locomotion plus dense à partir de la vidéo	`video2dsprite` — image de base sur `#FF00FF` → `imagine_image_to_video` → scripts du skill (ffmpeg + chroma)
Arrière-plan cléable	Toujours `#FF00FF` lorsque vous utilisez l'un des pipelines (obligatoire pour le chroma)
Ce skill	Bouclage / flip-test / lois du mouvement ci-dessous — appliquez après l'exécution du pipeline

Ouvrez .grok/skills/video2dsprite/SKILL.md ou .grok/skills/generate2dsprite/SKILL.md et suivez leurs workflows pour la génération et le post-traitement. Appliquez ensuite les lois et le flip test ici avant de livrer les images dans le jeu.

Pipeline par défaut (intention)

Image de base. Sujet dans une pose neutre/départ, mots de style complets, vue de côté ou adaptée au jeu, arrière-plan #FF00FF solide (chroma key de l'app-builder). Les valeurs par défaut de game-asset-core s'appliquent.
Animer. imagine_image_to_video à partir de la base : un mouvement clair, sur place, caméra fixe ("le chevalier marche sur place, vue de côté, caméra verrouillée", 6s). Gardez la prise simple — un sujet, un mouvement. Préférez passer cette étape via video2dsprite pour que la récolte et le chroma soient cohérents.
Récolter + nettoyer. Utilisez les scripts video2dsprite (pas de ffmpeg -i … fps=12 seul). Le remplissage magenta / dédespillage se trouve là ; ne re-cléez pas avec un #hex plat différent à moins de quitter entièrement le pipeline magenta.
Sélectionner. Choisissez les images qui (a) capturent les phases distinctes du mouvement et (b) BOUCLENT — la fin de la séquence doit renouer avec son début. N'imposez pas un nombre : si le mouvement est meilleur avec 8, 10 ou 12 images, livrez-en ce nombre (plus d'images = plus fluide dans le moteur). Pour un cycle, sélectionnez une période complète en utilisant les repères de mouvement (contacts au sol des pieds, positions extrêmes des ailes, pics des flammes).
Empaqueter. Livrez les images dans l'ordre du jeu (noms avec zéros de remplissage) et/ou une feuille selon les règles de game-asset-core (cellules uniformes, sans séparateurs) — ou les bandes/grilles transparentes émises par video2dsprite / generate2dsprite. Indiquez le fps prévu.

Revenez à la méthode image par image avec imagine_text_to_image (toujours sur #FF00FF lorsque vous post-traitez avec les scripts de sprites) seulement lorsque la vidéo échoue à produire le mouvement (rare : poses très stylisées, keyframes dramatiques uniques) — et planifiez alors les phases vous-même et respectez les lois ci-dessous. Préférez generate2dsprite pour les grilles multi-images nettes de production.

Lois du mouvement (vérifiez par rapport à celles-ci, quel que soit le pipeline)

Les cycles bouclent ; les allures en alternance passent la moitié de la période en miroir.
Continuité : les membres, accessoires, anatomie, effets se déplacent sur des trajectoires continues — rien ne se téléporte, ne disparaît ni ne se duplique entre des images adjacentes.
La physique se lit dans les images fixes : l'airborne montre l'air, l'anticipation compresse, le follow-through dépasse ; les effets restent ancrés à leur origine sauf si la demande les déplace.
L'énergie correspond à la demande : au repos/subtile signifie des images à peine différentes.

Vérification — le flip test

Visualisez les images finales strictement dans l'ordre et racontez le mouvement ; vérifiez la fermeture du boucle explicitement (dernière→première). Une hésitation dans votre narration est une image échouée. Le pipeline vidéo réussit généralement ce test du premier coup — c'est pourquoi il est le pipeline par défaut.