Di recente ho letto la guida alla pixel art di Juniper Dev e ho raccolto i punti chiave, dalla scelta del software alla colorazione avanzata, in una serie di appunti da condividere con chi, come me, vuole iniziare.
Come software consiglio Aseprite: l'interfaccia è intuitiva e le funzioni per animazioni e tileset sono pensate per lo sviluppo di videogiochi; se non volete pagare, potete usare come alternative gratuite LibreSprite, open source, o Piskel, che funziona nel browser. Per i colori, all'inizio ho lasciato perdere la teoria del colore e ho usato direttamente le palette già pronte di Lospec; l'ho approfondita poco a poco, man mano che disegnavo. Per ogni materiale preparate almeno tre colori (base, ombra e luce) e otterrete già un senso di volume di base.
Quando tracciate le linee, ricordatevi di eliminare i pixel superflui: attivando Pixel Perfect in Aseprite il risultato è molto più pulito. Nelle curve mantenete simmetriche le lunghezze dei segmenti di pixel (ad esempio 1-2-3-2-1) e le linee saranno molto più fluide. In fase di colorazione, usate per ombre e luci colori adiacenti sulla ruota cromatica e l'immagine risulterà più vivace; evitate anche l'«ombreggiatura a cuscino»: decidete prima la direzione della fonte di luce e poi illuminate tutto in modo coerente. Dithering e anti-aliasing sono due piccoli trucchi molto utili: il primo crea texture di transizione, il secondo rende i bordi più morbidi.
Il contorno non deve per forza essere nero puro: provate con una versione più scura del colore dell'oggetto stesso. Infine, un consiglio per gli sviluppatori: non accumulate troppi colori, perché con più di tre per lo stesso materiale si rischia il caos; rimpicciolite spesso l'anteprima per assicurarvi che tutto resti nitido anche a dimensioni ridotte. La cosa più importante è godersi il processo, che conta più dell'ossessione per il «risultato perfetto».
Il Pixelblog 62 parla di sfondi paesaggistici e sostiene un punto con cui concordo: gli sfondi non dovrebbero finire in fondo alle priorità di produzione. Stabiliscono l'ambientazione e attirano il giocatore nel mondo, ma devono anche servire il gameplay. In platform e shmup possono dover essere attenuati perché gli sprite restino leggibili, mentre negli RPG a turni possono essere ricchi e immersivi.
Per questa lezione Raymond Schlitter si concentra sulle scene di battaglia di un JRPG a turni immaginario, ispirato a Dragon Quest e Phantasy Star 4, con spazio in basso per gli eroi visti di spalle. La sfida che si pone è creare una profondità convincente usando 16 colori o meno.
Sceglie una tela di 192x144. Ha proporzioni 4:3, rientra nelle risoluzioni comuni delle console a 8 e 16 bit e si divide bene se in seguito si vorrà un parallasse con scorrimento pixel-perfect. Il processo parte da fasce orizzontali di colore pieno che definiscono l'orizzonte, poi terra e cielo vengono suddivisi in altre fasce. Il suo punto chiave è che la profondità deriva soprattutto dalla scelta dei colori, secondo la prospettiva atmosferica: il piano più vicino è il più saturo e con il contrasto più forte, e ogni piano che arretra perde saturazione, si schiarisce e sposta la tinta verso il colore del cielo. Con un cielo azzurro limpido, l'erba più vicina è la più calda e i piani lontani virano verso il blu.
Dopo i piani di colore aggiunge due strati di montagne riutilizzando colori delle fasce del cielo, quindi passa ai dettagli. L'erba è fatta di tanti tratti verticali corti di un solo pixel, e la chiave è la coerenza nel raggruppamento e nella scala. Mostra ogni passaggio come immagine separata, così si può seguire al proprio ritmo. Una lettura utile se le palette sembrano piatte.
Su Habr ho trovato un lungo articolo su come il cubo di Rubik sia diventato un materiale artistico, con molti spunti per chi ama la pixel art. L'autore realizza da anni mosaici con i cubi e spiega perché questo genere sia così vicino alla grafica digitale.
L'idea di fondo è semplice: una tessera colorata sulla faccia di un cubo è, in sostanza, un pixel. Ogni faccia ha nove quadrati e la tavolozza sei colori, quindi più cubi insieme formano un'immagine a bassa risoluzione, simile allo schermo di un vecchio computer o di una sala giochi. Anche la cronologia coincide: l'età d'oro dei giochi a 8 bit come Space Invaders, Pac-Man e Donkey Kong è stata la stessa della mania del cubo di Rubik dei primi anni Ottanta. Secondo l'autore, il termine "pixel art" fu usato per la prima volta nel 1982 da Adele Goldberg e Robert Flegal di Xerox.
L'articolo ripercorre poi la storia del genere. I primi esperimenti sono attribuiti all'artista britannico Fred Holly, a metà degli anni Ottanta. Negli anni Novanta il programmatore Jacob Devenport documentò mosaici di qualche decina di cubi, tra cui il primo bifacciale. La svolta vera arrivò con lo street artist francese Invader, che nel 2004 costruì il suo alieno di Space Invaders con nove cubi e chiamò lo stile Rubikcubism. La sua "Gioconda" da 330 cubi fu venduta all'asta nel 2020 per 480.200 euro, e nel 2022-2023 il museo MIMA di Bruxelles ospitò una mostra di oltre cento sue opere a cubi.
La parte che ho apprezzato di più è la descrizione del processo: prima uno schema a pixel in sei colori, poi, per i lavori più complessi, Photoshop per controllare i colori. È la stessa strada di ogni pixel artista, solo che qui i "pixel" sono cubi di plastica. Per chi lavora con una tavolozza limitata è un buon motivo per guardare tecniche familiari da un'altra prospettiva.
Recentemente, ho letto una guida molto dettagliata su Aseprite, che analizza in modo approfondito il flusso di lavoro per la creazione di giochi in pixel art. Ho annotato le parti che mi sono risultate più utili, in particolare la configurazione predefinita che definisce un punto di partenza solido.
Tela: i personaggi partono da una risoluzione di 32x32 pixel, i nemici, gli oggetti e le icone da 16x16 pixel, e il personaggio principale può essere ingrandito a 64x64 pixel se necessario. Durante la modifica, lo zoom predefinito può essere impostato all'800%, ma nel gioco è importante mantenere un rendering 1:1. Non lasciatevi ingannare dallo zoom della tela nell'editor.
Palette di colori: si può partire dalla palette DB32 disponibile su Lospec, definire i colori principali e poi espandere la palette a 48-64 colori se necessario, ma cercate di limitare il numero di colori utilizzati in ogni singolo frame a 16. La palette di colori è solo un insieme di "colori disponibili", non un elenco di "colori che devono essere utilizzati". È meglio utilizzare un'unica palette principale per l'intero progetto ed evitare di cambiarla durante lo sviluppo, altrimenti lo stile degli asset esistenti potrebbe non essere coerente.
Animazione: la frequenza di fotogrammi per l'animazione di inattività è di 8 FPS, per l'attacco è di 12 FPS e per le abilità speciali è di 24 FPS. All'interno dello stesso file, è possibile impostare durate diverse per i singoli fotogrammi utilizzando l'opzione "Frame Duration".
Esportazione: i fogli di sprite (sprite sheet) vengono disposti per righe e accompagnati da dati JSON. I nomi dei file vengono creati abbinando un file PNG a un file JSON, utilizzando la convenzione "nome_personaggio_nome_azione".
Il problema più comune che si incontra quando si importa in un motore di gioco è la modalità di filtraggio: è fondamentale utilizzare la modalità "Point" e non "Bilinear". Le immagini in pixel non richiedono la compressione delle texture. Unity può importare direttamente i file .aseprite utilizzando l'Aseprite Importer ufficiale, evitando così la necessità di esportare manualmente.
Un'altra raccomandazione a cui mi associo è la seguente: identificate le operazioni che eseguite più di dieci volte al giorno e utilizzate un piccolo script Lua di circa venti-trenta righe per automatizzarle, una volta alla settimana. Nel corso di alcuni mesi, il tempo risparmiato sarà molto maggiore di quanto si possa immaginare.
Uno dei tutorial Pixelblog di Raymond Schlitter di questa primavera affronta qualcosa che ho sempre trovato complicato: un gioco di mech a turni in stile Front Mission, disegnato su una griglia isometrica. È un concept a scopo didattico, non un progetto vero, e rimanda ai suoi post precedenti sulla proiezione isometrica.
I mech sono disegnati intorno ai 32x32 pixel, più piccoli dei 64x64 e oltre che usa di solito, quindi i dettagli vanno astratti in pochissimi pixel. Il suo metodo parte da forme geometriche semplici per ogni parte e costruisce prima il corpo. Il torso deve sporgere in avanti come il fronte di un carro armato, le spalle sono massicce e più alte della testa, e la testa resta bassa e slanciata, con uno o due pixel luminosi per le ottiche. I piedi sono progettati per la stabilità, prendendo spunto da artigli, chele e zoccoli, perché i piedi umanoidi normali risultano goffi in questo stile. Le strisce di accento arrivano per ultime e solo dove rafforzano le forme.
Schizza tre tipi di unità: fanteria dalle forme arrotondate, artiglieria con un cannone gigante fuso alla testa e caccia con triangoli taglienti e gambe a giunture invertite, ognuno accompagnato da una breve nota tattica.
La parte sull'ambiente è altrettanto utile. La tessera base è un cubo di 32x32 il cui rombo superiore ha angoli da 2 px, e le tessere adiacenti devono essere sovrapposte in un ordine coerente, così le texture combaciano. Le tessere naturali partono da una tessera di terra con diverse texture d'erba sopra. L'acqua sta a circa metà altezza di un cubo normale, e la sua animazione si ripete su 16 fotogrammi spostando una texture a linee di 1 px verso il basso a ogni fotogramma, mentre i riflessi si alternano.
La mia frase preferita è il promemoria che le tessere ripetute devono apparire bene quando si ripetono su tutta la mappa, quindi vale la pena provare da sé la sovrapposizione.
L'ultimo Pixelblog di Raymond Schlitter su SLYNYRD è uno studio sui platform ninja a 8 bit, una lettura utile per chi ama vedere un intero set di asset di gioco costruito attorno a un'unica idea. Si ispira apertamente a Ninja Gaiden e lavora con la palette del NES per tutto il tempo, pur senza rispettare rigidamente i limiti dell'hardware.
Per primo arriva il personaggio giocatore. Parte da un semplice manichino di prova, così le animazioni sono definite prima di aggiungere qualsiasi dettaglio di design. La tuta rosso acceso è stata scelta per farlo risaltare, anche se non è molto furtiva. Il repertorio di mosse è ispirato a Ryu Hayabusa: una corsa rapida, arrampicata sui muri, appendersi ai soffitti, un salto mortale e un fendente in aria. Ciò che ho apprezzato è il ragionamento per cui il personaggio resta fermo quando attacca a terra: questo costringe alla precisione negli scontri invece di lasciare che si spammi il colpo mentre si corre.
Seguono i nemici: una torretta-elicottero che spazza il cannone per 180 gradi in cinque direzioni, un carro-ragno che si attacca a pareti e soffitti, e un gorilla cyber lento che fa da spugna per i danni. Per il gorilla ha usato riferimenti di camminata sulle nocche, ha abbozzato forme semplici del corpo per azzeccare il movimento e solo dopo ha aggiunto i dettagli robotici. Unire testa e corpo in un unico pezzo gli dà una rigidità voluta.
La parte sull'ambiente è quella che ho trovato più utile. Usa tile 16x16 su sei livelli, ciascuno con una propria velocità di scorrimento per l'effetto parallasse, e una proiezione in stile cabinet in cui le linee di profondità formano circa 67,5 gradi, salendo di due pixel per ogni pixel in orizzontale, così i gradini vengono puliti. Il risultato è mostrato in un mockup da 320x180.
Un'ultima cosa da sapere: è il primo Pixelblog in cui uno dei mini tutorial, la scomposizione completa dei fotogrammi del ninja, sta dietro il paywall di Patreon, mentre la lezione principale resta gratuita. Gli asset e i file sorgente sono venduti in un pacchetto a parte. Mi piacerebbe vedere qualcuno inserire questi sprite in un vero controller del giocatore.
Habr ha pubblicato la traduzione di un lungo articolo di Karl Svensson sul modo in cui i tubi a raggi catodici (CRT) hanno influenzato la pixel art. Il tema è controverso, e mi è piaciuto che l'autore non accetti la spiegazione semplice secondo cui «i CRT sfocavano tutto».
L'articolo parte da un popolare video su TikTok, secondo cui gli artisti di un tempo tenevano conto della sfocatura dei CRT, che rendeva più morbidi i bordi grezzi dei pixel. Svensson ammette che è in parte vero e concorda sul fatto che la pixel art moderna a blocchi spesso diventa una nostalgia imprecisa. Fa però notare che il vecchio hardware presenta molti più aspetti da considerare. Lui stesso usa ancora regolarmente vecchi CRT, quindi disattiva i filtri CRT software degli emulatori, perché nessuno di essi riproduce fedelmente uno schermo reale. Una foto di un Commodore 64 su un monitor Commodore 1084S mostra che anche sui CRT si vedono i bordi irregolari dei pixel.
Poi confronta due giochi per C64. Maniac Mansion (1987) gira a 160×200 e appare spigoloso, mentre Mayhem in Monsterland (1993) usa dithering e smussamento, con la stessa palette fissa a 16 colori, per imitare una risoluzione e una profondità di colore maggiori. Queste tecniche si basano sulle proprietà del CRT: una leggera sfocatura, le linee di scansione e una piccola fuoriuscita dei colori.
L'autore considera l'età d'oro della pixel art l'era dei 16 bit: Amiga 500, SNES, Atari ST e Mega Drive. L'Amiga poteva mostrare 32 colori su una tavolozza di 4096, e la grafica di giochi come Silkworm o Ruff'n'Tumble è migliorata gradualmente. Tratta anche i trucchi di colore del CGA e spiega che, sugli schermi VGA a passo fine, i singoli pixel si vedono molto meglio.
Per me l'articolo è stato un buon promemoria: prima di aggiungere una «sfocatura retrò» conviene capire per quale schermo era stato disegnato l'originale.
Nel Pixelblog 63 Raymond Schlitter passa allo sparatutto orizzontale e costruisce un insieme di asset attorno ad aerei della Seconda guerra mondiale che combattono sopra un paesaggio naturale. Dopo i precedenti approfondimenti sugli shmup verticali, questo è il suo primo approccio al genere orizzontale, dove le traiettorie dei proiettili attraversano lo schermo invece di scendere.
Inizia dall'aereo del giocatore, perché stabilisce il tono e la risoluzione per tutto il resto. Con circa 48x32 pixel c'è spazio per i dettagli senza che l'animazione diventi troppo costosa. L'aereo è modellato sul P-51 Mustang. Un punto che ho trovato interessante è che per il movimento verticale anima il rollio invece del beccheggio. Il muso resta livellato, così i proiettili partono sempre dritti, e a una risoluzione così bassa la rotazione tende comunque a produrre grappoli di pixel rumorosi. In breve, il rollio mantiene lo sprite pulito e rende bene.
L'animazione usa cinque orientamenti: un fotogramma neutro, due posizioni di rollio verso l'alto e due verso il basso, più un'elica che gira di continuo. Dà anche una regola di design su come deve sentirsi in gioco: un tocco mostra solo il primo grado di rollio, tenere premuto mostra l'inclinazione completa, e il rilascio torna alla posa neutra passando per quella leggera. Sconsiglia di aggiungere inerzia al movimento in un genere fondato su reazioni precise.
Si parla anche delle opzioni, le piccole capsule che orbitano intorno alla nave. Oltre alla funzione di gioco, sostiene che aggiungano presenza a schermo, aiutando a percepire dove si trova la propria nave mentre gli occhi seguono le traiettorie dei proiettili.
I nemici sono aerei tedeschi e un veicolo d'artiglieria Hummel. Il suo flusso di lavoro parte da un modello con pochi colori a blocchi, poi colori veri e dettagli di base, quindi luce e dettagli fini, e per ultimo il contorno. Uno scambio di palette permette di riusare l'animazione dell'elica tra più aerei, e suggerisce di spendere fotogrammi extra solo dove il comportamento lo giustifica. È una lezione pratica di economia.
Il team di Aseprite ha annunciato il 22 luglio 2026 che la v1.3.18 è la nuova versione stabile. Include correzioni di bug e crash oltre alle nuove funzioni introdotte dalla v1.3.18-beta1, ed è scaricabile dal proprio account su aseprite.org.
Le novità principali della versione base sono una nuova separazione dei tag nei gruppi della timeline e una nuova opzione «dimensione foglio a potenza di due» per l'esportazione dei fogli di sprite. Ci sono anche correzioni per la copia dei dati utente (colore e testo) di tag e slice quando si duplica uno sprite, e per diversi crash, come l'eliminazione di una selezione incollata o il nascondere un livello mentre si spostano dei pixel.
Le release successive sono importanti per chi lavora con i tile. La v1.3.18.4 ha corretto l'allineamento di Scatta alla griglia per i pennelli più grandi di un pixel e ha migliorato copia e incolla dei tile tra livelli tilemap. Build successive hanno corretto un crash durante l'incollaggio di tilemap e uno dopo l'esportazione di un foglio di sprite quando lo sprite aveva una selezione. Le esportazioni di GIF animate ora usano l'header 89a corretto, e i PNG in scala di grigi vengono caricati con una tavolozza in grigi.
Anche chi scrive script ha novità: la versione dell'API Lua è passata alla 41, con Dialog:samerow{} e nuovi eventi di salvataggio dello sprite (save e beforesave).
Mi piacciono note di rilascio come questa perché mostrano dove si annidano gli attriti di tutti i giorni: griglie, tilemap ed esportazioni. Se stavi rimandando un aggiornamento per un bug nella copia dei tile, questa versione sembra quella da provare.
Quando si disegnano personaggi in pixel art, prima o poi ci si imbatte nel termine "sprite sheet". Condivido una spiegazione per principianti scritta da Keitaro su note, che ripercorre passo dopo passo come funziona il sistema e che ho trovato molto utile.
Uno sprite è un'immagine 2D mostrata sullo schermo del gioco. Personaggi, nemici, oggetti, proiettili ed effetti rientrano in questa categoria, e uno sprite sheet è il risultato di raccoglierli in un'unica immagine grande. Per un'animazione di camminata si mostrano in sequenza un fotogramma con il piede destro avanti, uno con i due piedi uniti e uno con il piede sinistro avanti, cambiandoli rapidamente perché sembri che il personaggio cammini. In altre parole, il movimento nasce dal cambio di immagini ferme, non da un video.
Il gioco non mostra l'immagine grande per intero. Ritaglia con le coordinate solo il fotogramma che serve. Per esempio, se ogni fotogramma è 128×128 px e ce ne sono otto affiancati, l'area visualizzata passa da 0–127 px a 128–255 px, e così via. L'articolo fa anche un esempio in cui l'asse orizzontale rappresenta 8 direzioni e quello verticale le azioni (camminare, attaccare, subire un colpo, difendersi), quindi 8 direzioni × 7 stati, cioè 56 fotogrammi.
Nell'uso pratico, secondo l'articolo, la cosa più importante è allineare la posizione di riferimento in ogni fotogramma. Se i piedi slittano di qualche pixel da un fotogramma all'altro, il personaggio sembra tremare su e giù durante l'animazione. Anche tenere lo sfondo trasparente è indispensabile.
Infine, viene chiarita la differenza tra uno sprite sheet, cioè semplicemente un insieme di immagini correlate, e un atlas di sprite, che impacchetta più immagini in un'unica texture per migliorare l'efficienza del rendering. Mi ha colpito soprattutto la conclusione: creare le immagini è meno difficile che darle una forma che il gioco possa usare correttamente. Credo sia utile anche per chi fa pixel art, soprattutto in fase di esportazione.
Nei fondali in pixel art, le rocce sono un lavoro piccolo ma sorprendentemente laborioso. Nelle notizie di pixel art del venerdì, l'autore di note おかか容疑者 ha presentato l'estensione per Aseprite «Rock Generator for Aseprite».
L'estensione è pubblicata su itch.io. È uno strumento di produzione dedicato esclusivamente alle rocce: importa le rocce come mesh 3D e permette di usarle come pixel art. Già dalla pagina di download si vedono moltissimi parametri, e l'articolo spiega che proprio perché lo strumento è dedicato alle rocce è possibile regolarle con tanta precisione.
Secondo l'articolo, include 10 forme predefinite, 21 strutture predefinite e 72 look (aspetti visivi). Si possono creare anche rocce ricoperte di muschio o innevate, quindi sembra facile da usare per costruire sfondi. L'interfaccia supporta 27 lingue, tra cui il giapponese.
È uno strumento a pagamento, a partire da 4,99 dollari USA (circa 800 yen) a ottobre 2026. In fondo alla pagina c'è una versione di prova, ma secondo l'articolo contiene solo immagini di esempio del risultato. Se volete verificarla prima di acquistare, tenetelo presente.
Fino ad ora era già possibile modellare rocce in Blender o in un altro programma e importarle in Aseprite. Tuttavia, poter abbozzare rapidamente delle rocce direttamente in Aseprite sembra molto efficiente e può tornare utile quando servono molti sfondi in pixel art. Non so mai come distinguere le diverse texture delle rocce, quindi notizie su strumenti di supporto come questo mi fanno davvero piacere.
Il festival di pixel art “Pixel Art Park 9 (PAP9)” si terrà domenica 11 ottobre 2026 al Pacifico Yokohama. Le novità di quest'anno sono presentate in un articolo su note scritto dal signor Morita, della società di sviluppo videogiochi Ixeal di Nerima.
Ixeal partecipa come azienda sponsor. Presenterà due giochi originali inediti sviluppati per il PAP9, e l'articolo ne descrive uno: 『Magical Soup』.
Il gioco consiste nel catturare “gusti nascosti” per preparare una zuppa. Esistono tre tipi di gusti nascosti, “normale”, “pericoloso” e “magico”, e la combinazione cambia le zuppe che si possono preparare. Chi gioca riceve anche un adesivo dello stesso tipo della zuppa preparata. Il gioco viene dal team che ha realizzato 『JUST Onigiri』, presentato al PAP8 dell'anno scorso.
Il secondo gioco e i nuovi gadget di pixel art saranno presentati in articoli successivi.
Sembra un evento divertente per chi ama la pixel art, con cose da giocare e da toccare con mano. Vedere come la pixel art si muove dentro un gioco e parlare direttamente con chi lo crea sembra un'occasione rara. Se vivete in zona, potrebbe valere la pena passare.
