bang-motion

Bang Motion — le motion graphic web qui n'est pas un PowerPoint

---

Dans la bibliothèque motion-explainer. Le corps ci-dessous est le manuel de réalisation Bang Motion autonome pour un fichier index.html unique (HTML + CSS + GSAP). Dans cette bibliothèque, le même look est également disponible sous forme de trois moteurs, intégrés au pipeline normal, de sorte qu'une bande-annonce puisse l'adopter comme n'importe quel autre style :

• style.json : le manifeste (bang-motion, canvas 1080×1920 à 30 ips, moteurs remotion, fframes et kyfram)
• remotion/ : kit/ (GlowHorizon, GrainyMeshBlob, GlassCard, KineticTitle, StatusPill, BangBanner, GlassCaptions, LivingGrain), template/, sync_kit.sh, CATALOG.md, AGENT_BRIEF.md
• fframes/ : Cargo.toml, src/ (lib, tokens, kit, look, video, main), tools/ff.sh
• kyfram/PRELUDE.lgv : jetons de palette et le mobilier de mesure (drawBackdrop, drawBanner, drawCaptions, drawPanel, drawDot, drawFrame) pour les scènes .lgv
• docs/style-guide.md et docs/style-prompt.md : la fiche de style compressée et le prompt portable

Créez un épisode avec ./core/new_episode.sh <series-dir> 01-slug Episode out-name --style bang-motion --engine remotion (ou --engine fframes|kyfram). Les compétences du pipeline prennent le nom du style comme $MOTION_STYLE, donc rien d'autre dans le workflow ne change.

L'ADN du style, en une phrase : un monde continu, un fond d'au moins deux couches (base profonde plus un horizon lumineux) qui bouge toujours, un grain qui se décale de t plutôt qu'un bruit aléatoire, une caméra qui respire au lieu d'un cadre fixe, des transitions motivées plutôt qu'un seul fondu répété, et un seul énoncé par plan au lieu d'une quantité d'informations digne d'une diapositive.

v1.19.0 · par Bang Tutorial · MIT. Historique des modifications dans CHANGELOG.md ; installation dans README.md.

Cette compétence est destinée à tout agent de codage IA (format Agent Skills ouvert). Son contenu correspond aux lois et recettes pour un motion graphic qui bouge comme une vidéo, pas comme une présentation — à respecter avant d'écrire du code.

Prérequis — navigateur uniquement

Le livrable (index.html) nécessite uniquement un navigateur moderne + une connexion Internet pour les CDN (GSAP, polices). Python et Node sont optionnels, utilisés uniquement pour les outils de travail : scripts/serve.py (serveur sans cache, nécessaire uniquement si des modules locaux sont utilisés), puppeteer (instantanés/vérification automatique, scripts/export-frames.mjs → MP4). Si l'utilisateur ne dispose ni de l'un ni de l'autre : (1) construisez quand même un fichier unique, ouvrez-le en double-cliquant ; (2) vérifiez visuellement avec ?debug=1 (panneau de défilement) et des captures d'écran manuelles par seconde clé ; (3) MP4 via l'enregistrement d'écran (OBS / enregistrement de l'onglet du navigateur) — expliquez que l'enregistrement d'écran peut perdre des trames et que le rendu image par image nécessite Node. Ne créez jamais un livrable qui nécessite npm install pour être VISIONNÉ.

ffmpeg est également optionnel. Vérifiez d'abord (ffmpeg -version) ; s'il n'est pas disponible :

Besoin	Avec ffmpeg	Sans ffmpeg
Synchronisation VO (limite de phrase/paragraphe)	silencedetect	scripts/vo-pauses.html — ouvrir dans le navigateur, sélectionner l'audio, copier SEG/PARA ; résultat identique (Web Audio, sans installation)
Durée/format audio	ffprobe	nombre DUR depuis vo-pauses.html ; le navigateur lit directement wav/mp3/m4a/ogg
Export MP4	fusion des PNG de export-frames.mjs	pas de MP4 — proposer une installation en une commande (winget install Gyan.FFmpeg / brew install ffmpeg) ou l'enregistrement d'écran
Analyse d'une vidéo de référence (extraction d'images)	fps= + tile=	demander à l'utilisateur d'envoyer des captures d'écran aux secondes clés, ou ouvrir la vidéo dans le navigateur et capturer à une seconde donnée

Sans ffmpeg, le flux de l'explicateur reste complet jusqu'à la synchronisation VO ; seul le MP4 nécessite une installation.

Lecteur — aucun, lecture automatique, boucle

Livrable par défaut : sans panneau ni lecteur à l'écran, lecture immédiate à l'ouverture, bouclage à la fin (onComplete → play(0) ; s'il y a du son, l'audio boucle également). Contrôles cachés : R pour redémarrer, Espace pour pause. Le panneau de défilement/horloge n'apparaît qu'avec ?debug=1 (outil de révision), et ?clean=1 bloque la lecture automatique pour l'export. Du son ? Essayez play() directement ; s'il est bloqué par le navigateur, mettez en pause à l'image 0 et démarrez au premier clic — sans texte « appuyez pour démarrer ». Ceci est déjà intégré dans les deux starters.

Interdictions structurelles — test PPT vérifiable mécaniquement

D'autres modèles (et toi, si tu es fatigué) tomberont dans ces schémas même après avoir lu les lois ci-dessous. Avant de livrer, vérifie le CODE, pas les sentiments :

1. grep -c "class=\"scene\"\|\<section" index.html — si ≥ 3 scènes sont des <section> activées/désactivées avec autoAlpha/opacity → c'est un diaporama. Les scènes doivent changer parce que le MONDE/LA CAMÉRA bouge (la caméra se déplace, whip vers un autre angle, push-through, changement de décor), pas parce que les sections sont fondues. Exception valide : dessin animé de scène (references/kartun-panggung.md) utilise un cut/glissement de 96 px entre les scènes — ok, car chaque scène est vivante (≥10 éléments en action), pas une image fixe fondue.

2. Un fil rouge visuel persiste : un sujet (action continue) OU un monde collage/papier/blanc exploré par la caméra (dessin animé, photo, catalogue, croquis). Des photos plein écran qui changent sans monde commun → PPT. Une image + une phrase par scène, changeant à chaque scène → reste un diaporama même si la caméra bouge : chaque scène a 3 à 5 éléments qui entrent progressivement par phrase (explainer.md "Une scène = 3 à 5 éléments").

3. Par scène, comptez les nœuds de texte : sourcil/accroche + titre + corps/crédit = 3 niveaux → PPT. Maximum deux : un chiffre/grand mot + un label du monde. Documents/tampons/blocs de date contenant ≤ 3 lignes courtes sont comptés comme objets, pas comme niveaux de texte.

4. Ken Burns (échelle 1.0→1.05 sur une photo) comme seul mouvement → PPT. Le mouvement à chaque seconde doit provenir du LANGAGE DE MOUVEMENT DE FOND choisi dans le brief de style du menu techniques.md §7c (caméra qui respire sur fond texturé, dégradés qui se déplacent, blobs flottants, grain vivant, balayages lumineux par segment, grosses formes tournant lentement, particules montantes, grille qui respire, texte fantôme qui glisse, Ken Burns + parallaxe…). Les barres/lignes/morceaux qui traversent latéralement (« lane », « range », « streak », pluie de particules horizontale) ont DÉJÀ été utilisés pour deux projets consécutifs sous des noms différents — ce n'est pas un défaut ; uniquement si le thème est vraiment la vitesse/le flux, et pas deux projets consécutifs.

5. Transitions uniquement par fondu + bump d'échelle + fuite de lumière sur tous les cuts → modèle PPT. Whip vers un autre angle, cut vers un instrument (carte/compteur/profil), push-through.

6. L'explicateur démarre à partir du starter de SON STYLE : starter-explainer-kartun, -jurnalisme, -katalog, -sketsa (mode collage : la caméra explore des actifs fixes), starter-explainer (action continue : le monde coule), ou starter-explainer-panggung (dessin animé de scène : une scène par acte, rig articulations, caméra uniquement dans la scène). Ceux en collage ont un rig ; ceux en scène en ont un autre. PAS à partir de assets/starter-opener.html (opener de texte), et pas à partir de zéro.

7. Les miniatures sont des diapositives. Zoom caméra < 1,08 donc la maison est de la taille d'un pouce et le sol vide remplit la moitié de l'écran → PPT même si tout bouge. Le monde est divisé en scènes à la taille du cadre, pas une grande carte explorée (kartun-panggung.md Loi 1).

8. Squelette de modèle (opener/promo). Vérifiez le conducteur et le code : première scène avec un texte qui grossit puis sort à gauche ; trois tuiles/cartes de fonctionnalités alignées ; champ de saisie/recherche tapé ; séquence accroche → fonctionnalité → fonctionnalité → promesse → logo → CTA. Deux ou plus sans exigence de concept → modèle, même avec une nouvelle apparence. Rechoisissez un squelette à partir de references/opener-konsep.md.

Échouez sur un seul point → refaites avant de montrer à l'utilisateur.

Types de travaux couverts

Cette compétence est pour le motion graphic web en GÉNÉRAL. L'explicateur n'est qu'un type — il a son propre document car sa structure est différente, pas parce qu'il est le principal.

Les starters sont nommés selon leur catégorie : starter-opener.html pour les openers, promos, bumpers, intros et typographies cinétiques ; starter-explainer-*.html pour les explicateurs, avec un suffixe de mode/style (-kartun, -jurnalisme, -katalog, -sketsa = collage ; sans suffixe = action continue ; -panggung = dessin animé de scène). Le dessin animé de scène est un mode d'explicateur (style 6), pas une catégorie à part : l'objectif reste d'expliquer avec une VO, seule la méthode de production diffère.

Type	Durée courante	Caractéristiques	Recette
Opener / promo produit	25–40 s	un concept du menu (squelette né du produit, pas d'une séquence standard), un moment spécial, fin sur la marque	references/opener-konsep.md + flux de travail ci-dessous + references/techniques.md
Bumper / ident / logo sting	3–8 s	construction du logo, un mouvement signature, fini avant que le spectateur ne s'en rende compte	techniques.md (construction du logo, fuite de lumière)
Intro / outro de chaîne	5–12 s	nom de la chaîne + mouvement signature identique à chaque épisode	flux de travail ci-dessous
Typographie cinétique / paroles	15–60 s	le texte est le sujet ; découpage par mot/lettre ; rythme suivant l'audio	techniques.md (split + flou directionnel, panoramique 3D par mot)
Titre / lower third / bumper de segment	2–6 s	petit élément sur les images, entrée-sortie propre, fond transparent	techniques.md
Explainer / vidéo explicative	30–90 s	faits sourcés, entités apparaissent, point de vue change, cinq styles	references/explainer.md + starter par style

Explainer et personnages : à lire avant de déterminer les plans

Pour un explainer dessin animé éducatif plat avec personnages (sixième style, dessin animé de scène), ou une révision ressemblant à un diaporama/miniature, lisez references/kartun-panggung.md : une scène par acte, zoom 1,08–1,95, continu à l'intérieur de la scène et cut/glissement de 96 px entre elles, rig articulations avec transformation manuelle, zéro sous-titre, palette plate et lumineuse. Différenciez les phrases, les beats visuels, le cadrage et les changements de scène. Pour construire directement dans After Effects, lisez references/ae-bridge-higgsfield.md. Les directives spécifiques de l'explicateur clarifient les règles de l'opener ci-dessous ; les exemples de polices, le nombre de scènes et les effets ne sont pas une recette universelle.

Loi #1 — C'est une vidéo, pas une diapositive

Maladie la plus courante : le modèle organise les scènes comme des diapositives — titre + sous-titre + corps de texte + rangée de badges. Cela se lit immédiatement comme « PPT » et sera rejeté.

Règles strictes :

• Pour un opener : une phrase courte + au maximum un objet principal par scène. Pas d'accroche (« 01 — FONCTIONNALITÉ »), de sous-titre, de paragraphe de description, de chip/badge de fonctionnalité, ou de métadonnées techniques (nom du package, longue URL). Les chips, boutons et étiquettes qui font partie de l'interface du produit en cours d'utilisation ne sont pas inclus.
• Nouvelle information = nouvelle réponse visuelle. Dans un explainer, changez l'état/l'action dans le même monde si cela reste pertinent ; un changement de phrase n'oblige pas à changer de plan.
• Une liste de points est remplacée par un visuel, pas automatiquement trois tuiles. Choisissez une méthode dans le menu de fonctionnalité de references/opener-konsep.md (une fonctionnalité démontrée, mot qui change, objet qui se transforme, carte mélangée, grille de tuiles…) ; deux openers consécutifs n'utilisent pas la même méthode.
• Les scènes doivent être vivantes. La caméra peut rester fixe pendant que les objets portent l'action. Déplacez la caméra pour suivre ou révéler quelque chose ; ne comptez pas sur un fondu/glissement de texte sur un fond fixe, ou un panoramique/zoom répété sur tous les segments.
• « Zoom in-out » = taille du plan, pas respiration de la caméra. Si la vidéo semble statique ou si l'utilisateur demande un zoom, la caméra se rapproche de l'élément qui raconte l'histoire (plan moyen / gros plan) puis recule en grand angle en suivant le rythme du contenu ; la respiration de quelques pourcents est presque invisible (techniques.md §3b).

Lisez references/anti-ppt.md AVANT de concevoir les scènes — il contient une liste d'infractions réelles avec leurs corrections.

Loi #2 — Déterministe ou mort

Pas une seule ligne ne lit l'horloge système. Tous les visuels sont des fonctions pures de tl.time() (temps de la timeline GSAP) : spectre, compteur, particules, tremblement de la caméra (sinus haute fréquence, pas Math.random()), position des objets qui « coulent » (tween de DISTANCE, pas d'accumulation de vélocité par trame). Conséquence : le défilement est aussi précis qu'une timeline After Effects, et le rendu image par image en MP4 produit des images identiques à chaque fois.

Loi #3 — Le style naît du thème, pas du starter, pas de la référence

Échec courant : un opener pour un autre produit sort avec l'apparence EXACTE du précédent — sombre, accent bleu, lueur, nébuleuse, mêmes polices — parce que le modèle a pris le style du starter. Les animations peuvent être bonnes, ça reste un échec : l'opener est le visage du produit, et deux produits ne peuvent pas avoir le même visage.

1. Brief de style d'abord, code après. Avant de toucher au starter, écrivez ces six lignes et montrez-les à l'utilisateur avec le conducteur des scènes :
   • thème/produit + …