CommunityImagegithub.com

générateur-de-sprites

Créer, réparer, valider, prévisualiser et empaqueter des assets sprite prêts pour le jeu dans Godot à partir de références ou de descriptions détaillées.

Qu'est-ce que générateur-de-sprites ?

Cette compétence est conçue pour les développeurs de jeux utilisant Godot qui ont besoin de produire des assets 2D prêts pour la production : sprites, personnages, meubles, décors, etc. Elle ne génère pas elle-même les images artistiques, mais orchestre leur création en déléguant la génération visuelle à un outil externe (comme un modèle d'image ou une compétence `$imagegen`). Le véritable travail de cette compétence réside dans la planification systématique des prompts, le nettoyage des arrière-plans par chroma-key, l'extraction des frames, la composition d'atlas, l'assurance qualité, les prévisualisations (incluant des GIF d'animations) et l'empaquetage final pour Godot. Elle supporte les personnages, les accessoires, les meubles, les cartes, les pièces de type maison de poupée, et les variations d'états ou d'animations. L'utilisateur peut fournir des images de référence pour capturer un style, et la compétence verrouille ce style pour toutes les variations. Le workflow est guidé par des scripts Python déterministes et une checklist visible, assurant des noms de fichiers prévisibles, des fonds transparents, des atlas propres, des métadonnées de frames, des planches de contact QA, et des ressources `SpriteFrames` prêtes pour Godot. La compétence est agnostique en termes de style artistique et s'adapte aux besoins du projet.

Compatible avec~Claude Code✓Codex CLI~Cursor
npx skills add https://github.com/Vel-Labs/Vel-Skills/tree/HEAD/skills/game/sprite-generator

Installed? Explore more Image skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Générateur de Sprites

Sorties

Sprites générés et validés, prévisualisations et artefacts d'intégration Godot.

Non-objectifs

Utiliser des scripts de dessin locaux comme substitut à la génération d'images réelles.

Objectif

Créer des sprites 2D orientés production à partir d'un concept, d'une ou plusieurs images de référence, ou d'un brief de direction artistique détaillé. La compétence est intentionnellement agnostique en matière de style : l'utilisateur peut fournir une image de référence, une fiche de style, une capture d'écran ou une description vivante, et le flux de travail transforme cela en un cycle de génération de sprite réutilisable avec des prompts, des images d'ancrage, une référence de base générée, des jobs d'animation/état, une extraction déterministe, une QA et des fichiers de démarrage Godot.

Le but n'est pas simplement de créer une jolie image. Le but est de produire des actifs qui peuvent être placés dans un projet Godot avec des noms de fichiers prévisibles, des fonds transparents, des atlas propres, des métadonnées de frames, des planches de contact QA et des ressources SpriteFrames de démarrage.

Utilisez cette compétence pour des demandes comme :

  • "Créez un meuble pour une maison avec des versions propres et sales."
  • "Faites un personnage dans ce style artistique avec des animations d'attente, de marche, de pointage et de nettoyage."
  • "Créez un plan de pièce de maison de poupée dans le même style que cette référence."
  • "Générez des tenues alternatives/des variantes de couleur et conservez les mêmes proportions corporelles."
  • "Transformez ce croquis d'objet en un sprite d'accessoire transparent prêt pour le jeu."

Entrées

Acceptez toute combinaison de ces entrées :

  • Images de référence : feuille de style, personnage existant, accessoire, capture d'écran, tableau d'humeur, palette, sprite généré précédemment ou capture de jeu.
  • Description vivante : nom de l'actif, rôle, forme, matière, couleur, échelle, angle de caméra, utilisation prévue et adjectifs de style.
  • Type d'actif : character, npc, player, furniture, prop, object, map, room, dollhouse, ou sprite générique.
  • Animations : actions nommées, nombres de frames, directions, comportement de boucle/one-shot, durées ou FPS, et notes de pose spéciales.
  • États et variantes : propre/sale, ouvert/fermé, sain/fané, vide/plein, tenue A/B, ensemble de couleurs, niveaux de dégâts, etc.
  • Cible d'intégration : version de Godot, taille de cellule, colonnes de l'atlas, échelle, caméra de dessus/isométrique/de côté, et chemin d'importation préféré.

Si l'utilisateur omet des détails, déduisez des valeurs par défaut raisonnables et facilitez l'itération. Ne bloquez pas sur chaque détail manquant. Posez une question de clarification uniquement lorsque l'omission entraînerait un travail coûteux et erroné, comme un style inconnu, une identité de personnage inconnue ou une liste d'animations requise.

Délégation de la Génération Visuelle

L'art réel doit être généré avec la capacité de génération d'images de l'environnement, et non avec des scripts locaux. Dans un environnement de compétence de type Codex, déléguez à la compétence $imagegen installée si elle est disponible. Dans ChatGPT, utilisez l'outil de génération d'images natif lorsque l'utilisateur demande de créer réellement l'actif visuel. Les scripts Python fournis sont destinés uniquement aux étapes de production déterministes.

Étapes déterministes autorisées :

  • créer des dossiers de cycle et des fichiers de prompt
  • copier des références stables dans le cycle
  • créer des images guides de mise en page
  • enregistrer les sorties générées sélectionnées
  • supprimer un arrière-plan chroma-key plat
  • diviser les bandes en frames
  • recadrer, redimensionner, remplir et centrer les frames dans des cellules cohérentes
  • composer des atlas PNG/WebP
  • générer des planches de contact et des prévisualisations GIF
  • écrire des manifestes JSON et des ressources de démarrage Godot

Limite stricte : ne pas dessiner, peindre, synthétiser, carreler, déformer ou inventer l'art du sprite avec Pillow, SVG, CSS, canvas HTML ou des formes programmatiques comme substitut à la génération d'images. Les scripts peuvent traiter des images générées ; ils ne peuvent pas être utilisés comme un générateur d'art caché.

Capture de Style et Verrouillage de Style

Lorsqu'une référence de style est fournie, traitez-la comme la source de vérité. Extrayez ces qualités dans le plan de prompt :

  • angle de caméra et perspective : face, côté, dessus, isométrique, 3/4, maison de poupée, orthographique
  • proportions : chibi, réaliste, trapu, grand, jouet, pixel, pictural, vecteur plat, rendu low-poly
  • traitement des lignes et des bords : pas de contour, contour épais, bord rendu doux, bord pixel, bord cel-shaded
  • matériaux et éclairage : argile, peluche, jouet en plastique, 3D peint, plat cel, brillant, mat, aquarelle, etc.
  • palette et saturation
  • politique d'ombre : aucune pour les sprites transparents sauf si explicitement conservée dans le cadre de l'objet
  • politique d'arrière-plan : transparent ou chroma-key plat pour l'extraction
  • échelle et lisibilité à la taille de cellule cible

Une rangée ou un état échoue s'il ressemble à un actif connexe dans un style différent plutôt qu'au même actif dans le style cible.

Valeurs par Défaut du Type d'Actif

Personnages/PNJ/Joueurs

Sorties par défaut si l'utilisateur ne spécifie pas d'animations :

AnimationFramesObjectif
idle4boucle de respiration/clignement ; la première frame fonctionne comme pose statique
walk_down6mouvement de face/vers le bas
walk_up6mouvement de dos/vers le haut
walk_left6mouvement de côté face à gauche
walk_right6mouvement de côté face à droite

Actions communes optionnelles : point, talk, pickup, carry, clean, use_item, sit, sleep, cry, celebrate, fail, interact, attack, cast, jump, push, pull.

Meubles/Accessoires/Objets

Sorties par défaut si l'utilisateur ne spécifie pas d'états :

ÉtatFramesObjectif
clean1état normal/rangé
dirty1état sale/en désordre du même objet

États communs optionnels : empty, half_full, full, overflowing, open, closed, on, off, healthy, wilted, broken, repaired, selected, highlighted, locked, unlocked.

Cartes/Salles/Maisons de Poupée

La sortie par défaut est un grand sprite map_base ou un arrière-plan. Pour les salles, spécifiez si vous avez besoin d'une seule couche artistique aplatie ou de couches séparées telles que floor, walls, furniture, interactables, path_overlay et collision_reference. N'incluez pas d'étiquettes d'interface utilisateur, de flèches, de lignes de chemin ou de superpositions de tutoriel dans l'art de la carte de production, sauf si elles sont demandées comme superposition séparée.

Règles d'Arrière-Plan et de Transparence

Préférez les arrière-plans chroma-key plats pour la génération lorsque l'outil d'image ne produit pas de manière fiable un alpha véritable. La clé par défaut est #00ff00. L'atlas final doit être un PNG/WebP transparent après extraction.

Pour les images sources générées :

  • utilisez une couleur d'arrière-plan plate sur toute la bande ou le rendu d'objet
  • gardez l'actif visuellement séparé du chroma key
  • évitez les reflets/matériaux verts lors de l'utilisation d'une clé verte ; choisissez une clé magenta ou bleue à la place si l'actif nécessite du vert
  • pas d'arrière-plan blanc, d'arrière-plan en damier, de panneau d'interface utilisateur, d'étiquettes, de numéros de frame, de grille visible, de bordure ou de décor
  • pas d'ombres portées, d'ombres au sol, de lueurs, de halos transparents doux, de nuages de poussière, de lignes de vitesse, de traînées de mouvement ou d'effets détachés lâches, sauf si un petit effet opaque attaché fait explicitement partie du sprite
  • chaque frame doit être complète, séparée, non coupée et à l'intérieur de son emplacement

Règles de Prompt d'Animation

Pour chaque rangée/bande d'animation :

  • demandez exactement le nombre de frames déclaré
  • spécifiez la disposition : généralement une bande horizontale de gauche à droite
  • utilisez une image de base canonique et des images de référence comme entrées d'ancrage
  • gardez l'identité, les proportions, la palette, le matériau, le style de contour/bord et l'angle de caméra cohérents
  • communiquez le mouvement par des changements de pose, pas par du flou, des lignes de vitesse, de la poussière ou des ombres
  • la première et la dernière frame doivent boucler proprement lorsque loop=true
  • pour les animations directionnelles, demandez la direction explicitement et évitez les détails miroirs accidentels si le personnage a des accessoires spécifiques au côté

N'acceptez pas une rangée si elle modifie le visage, la forme du corps, la tenue, la conception de l'accessoire, le style du matériau ou l'échelle par rapport à la base.

Plan de Progression Visible

Pour un cycle d'actif normal, conservez une checklist visible pour l'utilisateur :

  1. Préparation de la demande d'actif.
  2. Création de l'apparence canonique.
  3. Création des états et des rangées d'animation.
  4. Empaquetage pour Godot.

Ce que chaque étape signifie :

  • Préparation de la demande d'actif : établir le nom de l'actif, le type d'actif, la source de style, les sorties, la taille de cellule, le chroma key et le répertoire de cycle.
  • Création de l'apparence canonique : générer ou choisir la référence de base qui devient l'identité/le verrouillage de style.
  • Création des états et des rangées d'animation : générer chaque job de sortie en utilisant la base et les références ; ne réparer que les rangées/états défaillants.
  • Empaquetage pour Godot : extraire les frames, composer l'atlas, créer une planche de contact QA, écrire les manifestes, écrire la ressource de démarrage SpriteFrames et signaler les chemins de fichiers.

Ne marquez une étape comme terminée que lorsque le vrai fichier ou la vraie décision existe.

Flux de Travail

1. Préparer un dossier de cycle

python3 ./scripts/prepare_sprite_run.py \
  --asset-name "Caisse du Marché" \
  --asset-type prop \
  --description "caisse en bois lisible avec un contenu coloré" \
  --style-notes "correspondre à la référence d'art de jeu fournie" \
  --reference /chemin/absolu/vers/style_reference.png \
  --state full:1:"caisse pleine d'objets":single:once \
  --state empty:1:"même caisse vide":single:once \
  --cell-size 256x256 \
  --columns 2 \
  --output-dir /chemin/absolu/vers/run

Pour un personnage :

python3 ./scripts/prepare_sprite_run.py \
  --asset-name "Joueur" \
  --asset-type character \
  --description "personnage joueur amical avec une silhouette claire" \
  --reference /chemin/absolu/vers/style_reference.png \
  --animation idle:4:"respiration douce et clignement" \
  --animation walk_down:6:"marche vers la caméra" \
  --animation walk_up:6:"marche loin de la caméra" \
  --animation walk_left:6:"marche de côté vers la gauche" \
  --animation walk_right:6:"marche de côté vers la droite" \
  --cell-size 256x320 \
  --columns 6 \
  --output-dir /chemin/absolu/vers/run

Les cycles avancés peuvent être décrits avec un fichier de configuration JSON et passés avec --config.

2. Inspecter les jobs prêts

python3 ./scripts/sprite_job_status.py --run-dir /chemin/absolu/vers/run

Le job base doit être généré en premier. Enregistrez l'image de base générée sélectionnée avant de générer les jobs dépendants. L'enregistreur écrit references/canonical-base.png, que les jobs suivants doivent utiliser comme image d'entrée.

3. Générer chaque job visuel

Pour chaque job prêt, utilisez le fichier de prompt listé dans imagegen-jobs.json plus toutes les images d'entrée listées. Sélectionnez la meilleure image générée originale, puis enregistrez-la :

python3 ./scripts/record_imagegen_result.py \
  --run-dir /chemin/absolu/vers/run \
  --job-id job-id-depuis-le-status \
  --source /chemin/absolu/vers/sortie-generee.png

N'enregistrez pas de fixtures éditées à la main, de vignettes ou de fichiers provenant des dossiers final/frames du cycle comme art source. Enregistrez la sortie générée originale sélectionnée.

4. Finaliser

python3 ./scripts/finalize_sprite_run.py --run-dir /chemin/absolu/vers/run

Sortie attendue :

run/
  asset_request.json
  imagegen-jobs.json
  prompts/
  references/
  decoded/
  frames/frames-manifest.json
  final/spritesheet.png
  final/spritesheet.webp
  final/validation.json
  qa/contact-sheet.png
  qa/previews/*.gif
  qa/run-summary.json
  godot/<asset>_spriteframes.tres
  godot/<asset>_animated_sprite_2d.tscn
  godot/godot_import_manifest.json
  godot/README_GODOT.md

5. Copier dans Godot

python3 ./scripts/package_godot_assets.py \
  --run-dir /chemin/absolu/vers/run \
  --project-dir /chemin/absolu/vers/projet-godot \
  --dest assets/sprites

Consultez godot/README_GODOT.md après empaquetage. Si vous copiez des fichiers vers un emplacement res:// différent, mettez à jour le chemin de texture dans le fichier .tres généré.

Flux de Travail de Réparation

Si la QA échoue, réparez d'abord la plus petite portée :

  1. Un seul mauvais état ou rangée d'animation.
  2. Une seule mauvaise frame uniquement si votre outil d'image prend en charge de manière fiable l'édition au niveau de la frame.
  3. La base canonique uniquement si l'identité/le style est erroné partout.
  4. L'atlas complet uniquement en dernier recours.

Prompts de réparation courants :

  • "Régénérez uniquement walk_left ; conservez le personnage canonique exact, la tenue, les proportions et le style de rendu jouet."
  • "Régénérez uniquement dirty ; il doit s'agir du même canapé que clean, mais avec la couverture/les oreillers en désordre."
  • "Régénérez la bande avec exactement 6 frames et aucun numéro de frame ou étiquette."
  • "Utilisez une clé chroma magenta car l'objet nécessite un matériau vert."

Après avoir enregistré l'image de réparation, relancez la finalisation.

Rubrique QA

N'acceptez pas un actif tant que ces vérifications ne sont pas réussies :

  • La base générée correspond au style demandé ou aux références de style fournies.
  • Chaque état/animation est la même identité d'actif, pas une refonte.
  • Les nombres de frames exacts sont présents.
  • L'extraction transparente ne supprime pas les parties importantes du sprite.
  • Les frames sont complètes, centrées, rembourrées et non coupées.
  • Aucune étiquette, numéro de frame, ligne de grille, filigrane, panneau d'interface utilisateur ou décor ne s'est infiltré dans l'art de production.
  • Aucune ombre, lueur, poussière, ligne de vitesse, flou ou effet détaché indésirable ne subsiste après l'extraction.
  • La planche de contact se lit visuellement correctement à la taille cible.
  • final/validation.json n'a aucune erreur ; les avertissements ont été examinés visuellement.
  • Les noms du manifeste Godot correspondent aux noms d'animation que vous prévoyez d'appeler dans le code.

Critères d'Acceptation

Un cycle terminé doit inclure :

  • une référence de base canonique dans references/canonical-base.png
  • les sources générées sélectionnées enregistrées dans imagegen-jobs.json
  • des PNG de frame transparents extraits
  • final/spritesheet.png et, lorsqu'il est pris en charge, final/spritesheet.webp
  • qa/contact-sheet.png
  • des prévisualisations GIF pour les animations multi-frames
  • final/validation.json sans erreurs
  • des fichiers de démarrage Godot sous godot/
  • un court rapport destiné à l'utilisateur nommant les rangées/états réparés ou acceptés manuellement malgré les avertissements

Règles

  • Utilisez la génération visuelle pour les visuels ; utilisez les scripts uniquement pour le traitement déterministe.
  • Utilisez toujours une base canonique pour les actifs multi-sorties.
  • Gardez les références attachées pour chaque job visuel dépendant lorsque l'outil d'image prend en charge les références.
  • Préférez les sorties transparentes ou compatibles chroma-key aux illustrations de scène.
  • Ne mettez pas d'étiquettes d'interface utilisateur, de flèches de instruction, de lignes de chemin ou de guides de collision dans les sprites de production, sauf s'ils sont demandés comme actifs de superposition séparés.
  • Pour Godot, conservez les noms d'animation stables et en minuscules avec...

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

Skills associés