Création graphique · Méthode de préparation
Livrer des sprites et leur atlas avec une correspondance vérifiable
Un atlas de sprites, ses images sources et sa table de découpe doivent décrire la même version. Avant remise au développeur, fixez une convention de coordonnées et d’identifiants, puis contrôlez une animation courte dans l’environnement cible plutôt que de vous fier à une planche visuellement correcte.
Décrire le contrat de lecture de l’atlas
Demandez au développeur le format attendu pour l’image et les données de découpe. Précisez l’origine des coordonnées, l’unité, l’ordre des frames, les dimensions et les points de repère utiles. Une table correcte pour un outil peut être interprétée différemment par un autre si ces conventions restent implicites.
Godot documente plusieurs manières d’utiliser une feuille de sprites en animation. Ce guide n’impose pas un moteur : relevez le moteur et sa version réellement utilisés et faites confirmer le format de remise. Le nom d’une animation dans votre logiciel de dessin ne garantit pas qu’il sera repris à l’import.
Relier chaque frame à une source et une région
Attribuez un identifiant stable à chaque pose puis indiquez sa source et son rectangle dans l’atlas. Dans l’exemple, trois régions de 32 × 32 pixels occupent un atlas fictif de 96 × 32, sans marge : x vaut 0, 32 puis 64, et y vaut 0. Les rectangles servent de données d’exercice, pas de spécification universelle.
Si votre outil retire les zones transparentes, tourne les éléments ou ajoute des marges, notez-le et utilisez les données qu’il produit. Ne remplacez pas sa table par un découpage régulier supposé identique. Vérifiez aussi l’ordre de lecture et la correspondance entre le nom demandé par le code et celui du livrable.
Faire un contrôle de bout en bout
Préparez un lot figé qui comprend l’atlas exact, la table correspondante et un fichier de consignes. Demandez au développeur d’ouvrir ce lot dans un projet d’essai et de vérifier les frames, la transparence et les repères. Si une pose change, régénérez l’atlas et la table ensemble et identifiez le nouveau lot.
La ressource TXT contient une table de coordonnées complète pour l’exercice fictif et sa convention de lecture. Elle ne contient pas de bitmap de personnage ni de fichier natif de moteur. Remplacez les références par vos propres sprites autorisés avant de tester un import effectif.
EXEMPLE FICTIF
Cas pratique fictif
Exemple fictif : le personnage Galet utilise trois frames de repos. La deuxième image a été corrigée, mais une ancienne table est restée dans le dossier remis. Le développeur constate un décalage. L’illustratrice réunit atlas A02 et table A02 dans le même lot et conserve A01 comme ancien ensemble au lieu de mélanger les deux.
- Confirmer origine en haut à gauche et coordonnées en pixels.
- Contrôler les trois rectangles et les identifiants.
- Faire tester atlas et table du même lot dans le moteur cible.
Avant de poursuivre
- Moteur, version et format de remise précisés.
- Origine, unités et rectangles documentés.
- Sources reliées aux identifiants de frames.
- Atlas et table remplacés ensemble.
Fiche de travail — Livrer des sprites et leur atlas avec une correspondance vérifiable
Les questions utiles
Une table de coordonnées suffit-elle à importer ?
Non. Le développeur a besoin de l’image correspondante et du format attendu par son moteur. Cette ressource est un exercice de correspondance.
DesignLockr rend-il l’animation du moteur ?
Aucune lecture native de jeu vidéo n’est supposée ici. Préparez des fichiers admis et gardez le projet de test dans votre propre environnement.
Sources et repères
Godot — Animation de sprites 2D, documentation stable