J'ai récemment lu le guide de pixel art de Juniper Dev et j'en ai tiré des notes qui résument l'essentiel, du choix du logiciel jusqu'à la mise en couleur avancée, pour les partager avec celles et ceux qui veulent aussi se lancer.
Côté logiciel, je recommande Aseprite : l'interface est accueillante, et les fonctions d'animation et de tilesets sont pensées pour le développement de jeux. Si vous ne voulez pas payer, LibreSprite, open source, ou Piskel, dans le navigateur, sont de bonnes alternatives gratuites. Pour les couleurs, je ne me suis pas prise la tête avec la théorie au début : j'ai directement utilisé des palettes toutes faites sur Lospec, puis je l'ai étudiée petit à petit en dessinant davantage. Prévoyez au moins trois couleurs par matière — teinte de base, ombre et reflet — et vous obtiendrez déjà un volume de base.
En traçant les lignes, pensez à retirer les pixels superflus ; activer Pixel Perfect dans Aseprite rend le tout bien plus propre. Pour les courbes, gardez des longueurs de segments de pixels symétriques (par exemple 1-2-3-2-1) et les lignes seront beaucoup plus fluides. À la mise en couleur, utilisez des teintes voisines sur le cercle chromatique pour les ombres ou les reflets : l'image sera plus éclatante. Évitez aussi le « pillow shading » : définissez d'abord la direction de la source lumineuse, puis éclairez tout de manière cohérente. Le tramage (dithering) et l'anticrénelage sont deux petites astuces très pratiques : l'un crée une impression de transition, l'autre adoucit les contours.
Le contour n'a pas besoin d'être noir pur : essayez une version plus sombre de la couleur de l'objet. Enfin, un conseil pour les développeurs : n'empilez pas trop de couleurs, au-delà de trois pour une même matière cela devient vite brouillon ; dézoomez souvent pour vérifier que l'image reste lisible en petit. Le plus important, c'est de prendre plaisir au processus, bien plus que de s'acharner sur une « œuvre parfaite ».
Le Pixelblog 62 porte sur les décors de paysage, et il défend un point avec lequel je suis d'accord : les décors ne devraient pas passer en dernier dans vos priorités de production. Ils posent le cadre et attirent le joueur dans le monde, mais ils doivent aussi servir le gameplay. Dans les platformers et les shmups, il faut parfois les atténuer pour que les sprites restent lisibles, tandis que dans les RPG au tour par tour ils peuvent être riches et immersifs.
Pour cette leçon, Raymond Schlitter se concentre sur les scènes de combat d'un JRPG au tour par tour imaginaire, inspiré de Dragon Quest et de Phantasy Star 4, avec de la place en bas pour des héros vus de dos. Le défi qu'il se donne est de créer une profondeur convaincante avec 16 couleurs ou moins.
Il choisit une toile de 192x144. Elle a un format 4:3, rentre dans les résolutions courantes des consoles 8 et 16 bits et se divise bien si l'on veut plus tard un défilement en parallaxe au pixel près. Le processus commence par des bandes horizontales de couleur unie qui définissent l'horizon, puis le sol et le ciel sont découpés en davantage de bandes. Son point clé est que la profondeur vient surtout du choix des couleurs, selon la perspective atmosphérique : le plan le plus proche est le plus saturé et au contraste le plus fort, et chaque plan qui recule perd en saturation, s'éclaircit et glisse vers la teinte du ciel. Dans un ciel bleu clair, l'herbe la plus proche est la plus chaude et les plans lointains tirent vers le bleu.
Après les plans de couleur, il ajoute deux couches de montagnes en réutilisant des couleurs des bandes de ciel, puis passe aux détails. L'herbe est faite de nombreuses petites traînées verticales d'un seul pixel, et l'essentiel est la régularité du regroupement et de l'échelle. Il montre chaque étape dans une image séparée pour que vous puissiez suivre à votre rythme. C'est une lecture utile si vos palettes vous semblent plates.
Sur Habr, je suis tombé sur un long article expliquant comment le Rubik's Cube est devenu un matériau artistique. Il y a beaucoup à glaner pour quiconque aime le pixel art. L'auteur réalise depuis plusieurs années des mosaïques de cubes et explique pourquoi ce genre est si proche de l'image numérique.
L'idée principale est simple : une case colorée sur la face d'un cube est en fait un pixel. Chaque face compte neuf carrés et la palette six couleurs, si bien que plusieurs cubes réunis forment une image basse résolution, qui rappelle l'écran d'un vieil ordinateur ou d'une borne d'arcade. Le calendrier colle aussi : l'âge d'or des jeux 8 bits comme Space Invaders, Pac-Man ou Donkey Kong coïncide avec la rubikmanie du début des années 1980. Selon l'auteur, l'expression « pixel art » a été utilisée pour la première fois en 1982 par Adele Goldberg et Robert Flegal, de Xerox.
L'article retrace ensuite l'histoire du genre. Les premiers essais sont attribués au Britannique Fred Holly, au milieu des années 1980. Dans les années 1990, le programmeur Jacob Devenport a documenté des mosaïques de quelques dizaines de cubes, dont la première à deux faces. La véritable percée vient de l'artiste de rue français Invader, qui en 2004 a composé son envahisseur de l'espace avec neuf cubes et a baptisé ce style Rubikcubism. Sa « Joconde » de 330 cubes s'est vendue aux enchères en 2020 pour 480 200 euros, et en 2022-2023 le musée MIMA de Bruxelles a accueilli une exposition de plus d'une centaine de ses œuvres cubiques.
Ce que j'ai le plus aimé, c'est la description du processus par l'auteur : d'abord un schéma de pixels en six couleurs, puis, pour les pièces plus complexes, Photoshop pour contrôler les couleurs. C'est le même chemin que suit tout pixel artiste, sauf que les « pixels » sont ici des cubes en plastique. Pour qui travaille avec une palette limitée, c'est une bonne occasion de revoir des techniques familières sous un autre angle.
Récemment, j'ai lu un long guide approfondi sur Aseprite, qui détaille le flux de travail pour la création de jeux en pixel art. J'ai noté les parties qui me semblaient les plus utiles, en particulier la configuration par défaut, qui est conçue pour minimiser les erreurs.
Toile : Les personnages commencent à 32x32 pixels, les ennemis, les objets et les icônes à 16x16 pixels, et le personnage principal peut être agrandi à 64x64 pixels si nécessaire. Lors de l'édition, le zoom par défaut peut être réglé à 800 %, mais il est important de maintenir un rendu 1:1 dans le jeu, et de ne pas se laisser tromper par le zoom de la toile dans l'éditeur.
Palette de couleurs : Commencez avec la palette DB32 disponible sur Lospec, puis augmentez le nombre de couleurs à 48-64 selon les besoins, mais essayez de limiter le nombre de couleurs utilisées dans chaque image à 16. La palette de couleurs n'est qu'une "sélection de couleurs possibles", et non une "liste de couleurs à utiliser obligatoirement". Il est préférable d'utiliser une seule palette de couleurs principale pour tout le projet, et d'éviter de la changer complètement au cours du développement, car cela pourrait entraîner des incohérences de style avec les anciens éléments.
Animation : 8 FPS pour l'état de repos, 12 FPS pour les attaques, et 24 FPS pour les compétences spéciales. Vous pouvez définir différentes durées pour chaque image dans le même fichier en utilisant la fonction "Frame Duration".
Exportation : Les feuilles de sprites sont organisées par lignes, accompagnées de données JSON, et les noms de fichiers sont associés par paires PNG + JSON en utilisant le format "nom_du_personnage_nom_de_l'action".
La principale difficulté rencontrée lors de l'importation dans le moteur de jeu est le mode de filtrage : utilisez impérativement le mode "Point", et non "Bilinear". Les images en pixels n'ont pas besoin de compression de textures. Unity peut importer directement les fichiers .aseprite en utilisant l'importateur officiel Aseprite, ce qui évite l'étape de l'exportation manuelle.
Voici également une suggestion à laquelle je souscris : identifiez les actions que vous effectuez plus de dix fois par jour, et utilisez un petit script Lua d'une vingtaine de lignes pour les automatiser, une fois par semaine. Au fil des mois, le temps économisé est bien supérieur à ce que l'on pourrait imaginer.
L'un des tutoriels Pixelblog de Raymond Schlitter, publié ce printemps, aborde un sujet que j'ai toujours trouvé délicat : un jeu de mechas au tour par tour dans le style de Front Mission, dessiné sur une grille isométrique. Il s'agit d'un concept à but pédagogique, pas d'un projet réel, et il renvoie à ses précédents billets sur la projection isométrique.
Les mechas sont dessinés en 32x32 pixels environ, plus petits que les 64x64 et plus qu'il utilise habituellement, si bien que les détails doivent être abstraits en très peu de pixels. Sa méthode consiste à partir de formes géométriques simples pour chaque partie et à construire d'abord le corps. Le torse doit avancer comme le front d'un char, les épaules sont massives et placées plus haut que la tête, et la tête reste basse et élancée, avec un ou deux pixels lumineux pour les optiques. Les pieds sont conçus pour la stabilité, en s'inspirant de serres, de pinces et de sabots, car des pieds humanoïdes classiques paraissent maladroits dans ce style. Les rayures d'accentuation viennent en dernier, et seulement là où elles renforcent les formes.
Il esquisse trois types d'unités : l'infanterie aux formes arrondies, l'artillerie avec un canon géant fusionné à la tête, et les chasseurs aux triangles acérés et aux jambes à articulation inversée, chacun accompagné d'une brève note tactique.
La partie environnement est tout aussi utile. La tuile de base est un cube de 32x32 dont le losange supérieur a des coins de 2 px, et les tuiles adjacentes doivent être superposées dans un ordre constant pour que les textures s'alignent. Les tuiles naturelles partent d'une tuile de terre avec diverses textures d'herbe par-dessus. L'eau mesure environ la moitié de la hauteur d'un cube normal, et son animation boucle sur 16 images en décalant une texture de lignes d'1 px vers le bas à chaque image, tandis que les reflets alternent.
Ma phrase préférée rappelle que les tuiles répétées doivent rester belles lorsqu'elles sont reproduites sur toute une carte, et qu'il vaut donc la peine de tester soi-même la superposition.
Le dernier Pixelblog de Raymond Schlitter sur SLYNYRD est une étude sur les platformers ninja en 8 bits, une lecture intéressante pour qui aime voir un ensemble complet de ressources de jeu construit autour d'une seule idée. Il s'inspire ouvertement de Ninja Gaiden et travaille avec la palette de la NES tout du long, sans pour autant respecter strictement les limites du matériel.
Le personnage joueur arrive en premier. Il part d'un simple mannequin de base pour que les animations soient calées avant tout détail de design, et le costume rouge vif a été choisi pour son effet visuel, même s'il n'est pas très discret. Le jeu de mouvements s'inspire de Ryu Hayabusa : une course vive, l'escalade de murs, la suspension aux plafonds, un saut retourné et une attaque aérienne. Ce que j'ai aimé, c'est le raisonnement selon lequel le personnage reste immobile lorsqu'il attaque au sol. Cela impose de la précision dans les affrontements au lieu de laisser marteler l'attaque en courant.
Vient ensuite l'ennemi : une tourelle-hélicoptère qui balaie son canon sur 180 degrés dans cinq directions, un char-araignée qui s'accroche aux murs et aux plafonds, et un gorille cyber lent qui sert d'éponge à dégâts. Pour le gorille, il a travaillé à partir de références de marche sur les phalanges, a dessiné des formes corporelles simples pour que le mouvement soit juste, puis a ajouté les détails robotiques. Fusionner la tête et le corps en une seule pièce lui donne une raideur volontaire.
La partie environnement est celle qui m'a paru la plus utile. Elle utilise des tuiles de 16x16 réparties en six couches, chacune défilant à sa propre vitesse pour le parallaxe, et une projection de type cabinet où les lignes de profondeur forment environ 67,5 degrés, avec deux pixels vers le haut pour un pixel de côté, ce qui fait des marches bien nettes. Le résultat est montré dans une maquette de 320x180.
Un autre point à savoir : c'est le premier Pixelblog où l'un des mini-tutoriels, la décomposition complète des images du ninja, se trouve derrière le mur payant de Patreon, tandis que la leçon principale reste gratuite. Les ressources et les fichiers source sont vendus dans un pack séparé. J'aimerais beaucoup voir quelqu'un intégrer ces sprites dans un vrai contrôleur de joueur.
Habr a publié une traduction d'un long article de Karl Svensson sur l'influence des tubes cathodiques (CRT) sur le pixel art. Le sujet prête à débat, et j'ai apprécié que l'auteur ne se contente pas de l'explication simple selon laquelle « les CRT floutaient tout ».
Il part d'une vidéo TikTok populaire affirmant que les anciens artistes tenaient compte du flou des CRT, qui adoucissait les bords irréguliers des pixels. Svensson reconnaît que c'est en partie vrai et convient que le pixel art moderne en gros blocs devient souvent une nostalgie imprécise. Mais il souligne que le vieux matériel présente bien d'autres aspects à prendre en compte. Il utilise toujours régulièrement d'anciens CRT ; il désactive donc les filtres CRT logiciels des émulateurs, car aucun, selon lui, ne reproduit fidèlement un vrai écran. Une photo d'un Commodore 64 sur un moniteur Commodore 1084S montre que les bords de pixels inégaux sont visibles aussi sur un CRT.
Il compare ensuite deux jeux C64. Maniac Mansion (1987) fonctionne en 160×200 et paraît anguleux, tandis que Mayhem in Monsterland (1993) utilise le tramage et le lissage, avec la même palette fixe de 16 couleurs, pour imiter une résolution et une profondeur de couleur plus élevées. Ces procédés reposent sur les propriétés des CRT : un léger flou, les lignes de balayage et une légère diffusion des couleurs.
L'auteur considère que l'âge d'or du pixel art est l'ère 16 bits : Amiga 500, SNES, Atari ST et Mega Drive. L'Amiga pouvait afficher 32 couleurs sur une palette de 4096, et les graphismes de jeux comme Silkworm ou Ruff'n'Tumble se sont peu à peu améliorés. Il évoque aussi les astuces de couleur du CGA et explique que, sur les écrans VGA au pas de point fin, les pixels individuels sont bien plus visibles.
Pour moi, cet article est un bon rappel : avant d'ajouter un « flou rétro », il vaut mieux comprendre pour quel écran l'original a été dessiné.
Dans le Pixelblog 63, Raymond Schlitter aborde le shoot 'em up horizontal et construit un ensemble de ressources autour d'avions de la Seconde Guerre mondiale qui s'affrontent au-dessus d'un paysage naturel. Après ses articles précédents sur les shmups verticaux, c'est sa première approche du genre horizontal, où les motifs de balles traversent l'écran au lieu de le descendre.
Il commence par l'avion du joueur, car il donne le ton et la résolution de tout le reste. Avec environ 48x32 pixels, il reste de la place pour le détail sans alourdir l'animation. L'appareil s'inspire du P-51 Mustang. Ce qui m'a intéressé, c'est qu'il anime le roulis plutôt que le tangage pour le mouvement vertical. Le nez reste horizontal, si bien que les balles partent toujours droit devant, et une rotation à si basse résolution laisse souvent des amas de pixels désordonnés. En résumé, le roulis garde le sprite propre et rend bien.
L'animation compte cinq orientations : une image neutre, deux positions de roulis vers le haut et deux vers le bas, plus une hélice qui tourne en permanence. Il donne aussi une règle de conception pour la sensation de jeu : une pression brève n'affiche que le premier degré de roulis, un maintien affiche l'inclinaison complète, et le relâchement repasse par la pose légère avant le neutre. Il déconseille d'ajouter de l'inertie au mouvement dans un genre fondé sur des réactions précises.
Les options, ces petites capsules qui orbitent autour du vaisseau, sont également traitées. Au-delà de leur rôle en jeu, il estime qu'elles renforcent la présence à l'écran, ce qui aide à sentir où se trouve votre vaisseau pendant que vos yeux suivent les trajectoires des balles.
Les ennemis sont des avions allemands et un véhicule d'artillerie Hummel. Son processus part d'un modèle en quelques couleurs de bloc, puis des vraies couleurs et du détail de base, ensuite l'éclairage et le détail fin, et enfin le contour. Un changement de palette permet de réutiliser l'animation de l'hélice d'un avion à l'autre, et il suggère de n'ajouter des images supplémentaires que lorsque le comportement le justifie. C'est une leçon pratique d'économie.
L'équipe d'Aseprite a annoncé le 22 juillet 2026 que la v1.3.18 est la nouvelle version stable. Elle comprend des corrections de bugs et de plantages, ainsi que les nouvelles fonctions introduites depuis la v1.3.18-beta1, et se télécharge depuis votre compte sur aseprite.org.
Les changements phares de la version principale sont une nouvelle séparation des tags dans les groupes de la timeline et une nouvelle option « taille de feuille en puissance de deux » pour l'export de feuilles de sprites. Il y a aussi des corrections pour la copie des données utilisateur (couleur et texte) des tags et des slices lors de la duplication d'un sprite, et pour plusieurs plantages, comme la suppression d'une sélection collée ou le masquage d'un calque pendant le déplacement de pixels.
Les versions correctives qui ont suivi comptent pour ceux qui travaillent avec des tiles. La v1.3.18.4 a corrigé l'alignement de Snap to Grid pour les pinceaux de plus d'un pixel, et amélioré le copier-coller de tiles entre calques de tilemap. Des versions ultérieures ont corrigé un plantage lors du collage de tilemaps et un plantage après l'export d'une feuille de sprites lorsque le sprite avait une sélection. Les exports de GIF animés utilisent désormais le bon en-tête 89a, et les fichiers PNG en niveaux de gris se chargent avec une palette de gris.
Les auteurs de scripts ont aussi droit à des nouveautés : la version de l'API Lua passe à 41, avec Dialog:samerow{} et de nouveaux événements de sauvegarde du sprite (save et beforesave).
J'aime ce genre de notes de version parce qu'elles montrent où se situent les frictions du quotidien : grilles, tilemaps, exports. Si vous repoussiez une mise à jour à cause d'un bug de copie de tiles, cette version semble valoir le coup d'essai.
Quand on dessine des personnages en pixel art, on finit tôt ou tard par tomber sur le terme « feuille de sprites » (sprite sheet). Je partage une explication destinée aux débutants que Keitaro a écrite sur note : elle décrit le fonctionnement étape par étape, et je l'ai trouvée utile.
Un sprite est une image 2D affichée à l'écran du jeu. Les personnages, les ennemis, les objets, les balles et les effets en font partie, et une feuille de sprites est le regroupement de tout cela dans une seule grande image. Pour un cycle de marche, on affiche une image avec le pied droit en avant, puis une image avec les deux pieds joints, puis une image avec le pied gauche en avant, en alternant rapidement pour donner l'impression de marcher. Autrement dit, le mouvement vient de l'enchaînement d'images fixes, pas d'une vidéo.
Le jeu n'affiche pas l'image entière. Il découpe les coordonnées pour n'extraire que la case nécessaire. Par exemple, si chaque case fait 128×128 px et que huit sont alignées, la zone d'affichage passe de 0 à 127 px, puis de 128 à 255 px, etc. L'article donne aussi un exemple où l'axe horizontal représente 8 directions et l'axe vertical les actions (marche, attaque, coup reçu, défense), soit 8 directions × 7 états, c'est-à-dire 56 images.
L'article insiste sur le point le plus important à l'usage : aligner la position de référence de chaque image. Si les pieds se décalent de quelques pixels d'une image à l'autre, le personnage semble trembler de haut en bas pendant l'animation. Garder le fond transparent est également indispensable.
Enfin, il distingue la feuille de sprites, simple regroupement d'images liées, de l'atlas de sprites, qui range plusieurs images dans une seule texture pour gagner en efficacité de rendu. Ce qui m'a le plus marqué est sa conclusion : fabriquer les images est moins difficile que de les mettre sous une forme que le jeu peut utiliser correctement. Je pense que cela servira aussi aux pixel artistes, surtout à l'étape de l'export.
Dans les décors en pixel art, les rochers demandent discrètement beaucoup de travail. Dans sa rubrique d'actualités pixel art du vendredi, l'auteur de note おかか容疑者 a présenté l'extension Aseprite « Rock Generator for Aseprite ».
Cette extension est publiée sur itch.io. C'est un outil de création entièrement dédié aux rochers : il importe des rochers sous forme de maillages 3D et permet de les utiliser comme pixel art. Rien que la page de téléchargement affiche de nombreux paramètres, et l'article explique que c'est justement parce que l'outil se concentre sur les rochers qu'un réglage aussi fin est possible.
Selon l'article, il propose 10 formes prédéfinies, 21 structures prédéfinies et 72 looks (apparences). On peut aussi créer des rochers couverts de mousse ou enneigés, ce qui le rend pratique pour construire des décors. L'interface prend en charge 27 langues, dont le japonais.
C'est un outil payant, à partir de 4,99 dollars US (environ 800 yens) en octobre 2026. Une version d'essai figure en bas de page, mais d'après l'article elle ne contient que des exemples d'images de rendu. Si vous voulez vérifier avant d'acheter, gardez cela à l'esprit.
Il était déjà possible de modéliser des rochers dans Blender ou un autre logiciel, puis de les importer dans Aseprite. Pouvoir ébaucher rapidement des rochers directement dans Aseprite paraît néanmoins très efficace, et utile quand il faut produire beaucoup de décors en pixel art. Je n'arrive jamais à décider comment peindre les différentes textures de roche, alors ce genre d'outil d'appoint me fait sincèrement plaisir.
Le festival de pixel art « Pixel Art Park 9 (PAP9) » se tiendra le dimanche 11 octobre 2026 au Pacifico Yokohama. Les exposants de cette année sont présentés dans un article note de M. Morita, de la société de développement de jeux Ixeal, située à Nerima.
Ixeal participe en tant qu'entreprise sponsor. Elle présentera deux jeux originaux entièrement nouveaux, développés pour le PAP9, et l'article en présente un, 『Magical Soup』.
Le principe consiste à attraper des « goûts cachés » pour préparer une soupe. Il existe trois types de goûts cachés, « normal », « dangereux » et « magique », et leur combinaison change les soupes que l'on peut préparer. Le joueur reçoit aussi un autocollant du même type que la soupe qu'il a faite. Le jeu vient de l'équipe qui a créé 『JUST Onigiri』, présenté lors du PAP8 précédent.
Le second jeu et les nouveaux goodies en pixel art seront présentés dans des articles ultérieurs.
Cela semble être un événement sympathique pour les amateurs de pixel art, où l'on peut jouer et toucher les créations. Voir comment le pixel art s'anime dans un jeu et pouvoir discuter directement avec les créateurs semble une occasion rare. Si vous habitez à proximité, cela vaut peut-être le détour.
