Recentemente li o guia de pixel art do Juniper Dev e organizei os pontos principais, da escolha do software à coloração avançada, em um conjunto de notas para compartilhar com quem também quer começar.
Em termos de software, recomendo o Aseprite: a interface é amigável e os recursos de animação e tilesets foram pensados para o desenvolvimento de jogos; se não quiser pagar, dá para usar o LibreSprite, de código aberto, ou o Piskel, versão para navegador, como alternativas gratuitas. Quanto às cores, no começo deixei a teoria das cores de lado e usei direto as paletas prontas do Lospec; depois de desenhar bastante, fui estudando aos poucos. Para cada material, prepare pelo menos três cores (base, sombra e luz) e já dá para criar uma noção básica de volume.
Ao desenhar linhas, lembre-se de remover os pixels sobrando; ativar o Pixel Perfect no Aseprite deixa tudo bem mais limpo. Nas curvas, mantenha simétricos os comprimentos dos segmentos de pixels (por exemplo, 1-2-3-2-1) e as linhas ficarão muito mais fluidas. Na hora de colorir, use cores vizinhas no círculo cromático para as sombras ou luzes, e a imagem ficará mais vibrante; evite também o “sombreamento de travesseiro”: defina primeiro a direção da fonte de luz e ilumine tudo de forma consistente. Dithering e anti-aliasing são duas técnicas bem úteis: uma cria texturas de transição, a outra deixa as bordas mais suaves.
O contorno não precisa ser preto puro; experimente uma versão mais escura da cor do próprio objeto. Por fim, um conselho para desenvolvedores: não acumule cores demais, porque mais de três para o mesmo material costuma virar bagunça; reduza a visualização com frequência para garantir que tudo continue nítido em tamanho pequeno. O mais importante é aproveitar o processo, que vale mais do que se prender a uma “obra perfeita”.
O Pixelblog 62 trata de fundos de paisagem e defende um ponto com o qual concordo: os fundos não deveriam ficar por último na lista de prioridades de produção. Eles estabelecem o cenário e puxam o jogador para dentro do mundo, mas também precisam servir à jogabilidade. Em plataformas e shmups podem precisar ser atenuados para que os sprites continuem legíveis, enquanto em RPGs por turnos podem ser ricos e imersivos.
Nesta aula, Raymond Schlitter se concentra nas cenas de batalha de um JRPG por turnos imaginário, inspirado em Dragon Quest e Phantasy Star 4, com espaço embaixo para heróis vistos de costas. O desafio que ele propõe é criar uma sensação convincente de profundidade usando 16 cores ou menos.
Ele escolhe uma tela de 192x144. Tem proporção 4:3, cabe nas resoluções comuns de consoles de 8 e 16 bits e se divide bem caso depois se queira um parallax com rolagem pixel a pixel. O processo começa com faixas horizontais de cor sólida que definem o horizonte, e depois o chão e o céu são divididos em mais faixas. O ponto central é que a profundidade vem sobretudo da escolha de cores, seguindo a perspectiva atmosférica: o plano mais próximo é o mais saturado e de maior contraste, e cada plano que recua perde saturação, clareia e desloca o matiz em direção à cor do céu. Em um céu azul limpo, a grama mais próxima é a mais quente e os planos distantes vão ficando azulados.
Depois dos planos de cor, ele acrescenta duas camadas de montanhas reaproveitando cores das faixas do céu e então entra nos detalhes. A grama é feita de muitos traços verticais curtos de um pixel, e o segredo está na consistência do agrupamento e da escala. Ele mostra cada etapa como uma imagem separada, para que você acompanhe no seu ritmo. É uma leitura útil se suas paletas estão parecendo chapadas.
Encontrei no Habr um artigo longo sobre como o cubo mágico virou material artístico, e há muita coisa interessante para quem gosta de pixel art. O autor vem montando mosaicos com cubos há alguns anos e explica por que esse gênero está tão próximo dos gráficos digitais.
A ideia principal é simples: um bloco colorido na face de um cubo é, na prática, um pixel. Cada face tem nove quadrados e a paleta tem seis cores, então vários cubos juntos formam uma imagem de baixa resolução, parecida com a tela de um computador antigo ou de um fliperama. A cronologia também bate: a época de ouro dos jogos de 8 bits, como Space Invaders, Pac-Man e Donkey Kong, coincidiu com a febre do cubo mágico no começo dos anos 1980. Segundo o autor, o termo "pixel art" foi usado pela primeira vez em 1982 por Adele Goldberg e Robert Flegal, da Xerox.
Depois, o texto traça a história do gênero. Os primeiros experimentos são atribuídos ao artista britânico Fred Holly, em meados dos anos 1980. Nos anos 1990, o programador Jacob Devenport documentou mosaicos de algumas dezenas de cubos, incluindo o primeiro de dois lados. A grande virada veio com o artista de rua francês Invader, que em 2004 montou seu invasor espacial com nove cubos e chamou o estilo de Rubikcubism. Sua "Mona Lisa" de 330 cubos foi arrematada em leilão em 2020 por 480.200 euros, e em 2022 e 2023 o museu MIMA, em Bruxelas, exibiu mais de cem de suas obras cúbicas.
O que mais gostei foi a descrição do processo: primeiro um esquema de pixels com seis cores e, nas peças mais complexas, o Photoshop para conferir as cores. É o mesmo caminho de qualquer pixel artista, só que aqui os "pixels" são cubos de plástico. Para quem trabalha com uma paleta limitada, é uma boa oportunidade de olhar técnicas conhecidas por outro ângulo.
Recentemente, li um guia detalhado sobre o Aseprite que descreve o fluxo de trabalho para jogos de pixel art. Anotei as partes que me pareceram mais úteis, especialmente a configuração padrão que "minimiza os erros".
Tela: Os personagens começam com 32x32 pixels, os inimigos, itens e ícones começam com 16x16 pixels, e o personagem principal pode ser ampliado para 64x64 pixels quando necessário. Durante a edição, a ampliação padrão pode ser definida como 800%, mas no jogo, é importante manter a renderização em 1:1. Não se deixe enganar pela ampliação da tela no editor.
Paleta de cores: Comece com a paleta DB32 do Lospec, defina os tons principais e, em seguida, expanda para 48-64 cores conforme necessário. No entanto, tente limitar o número de cores usadas em cada quadro a 16. A paleta de cores é apenas um conjunto de "cores opcionais", não um conjunto de "cores que devem ser usadas". É melhor usar um conjunto principal de cores para todo o projeto e evitar trocas completas durante o desenvolvimento, pois isso pode fazer com que os ativos antigos não correspondam ao estilo.
Animação: A taxa de quadros para o estado ocioso é de 8 FPS, para ataques é de 12 FPS e para habilidades especiais é de 24 FPS. É possível definir durações diferentes para cada quadro dentro do mesmo arquivo usando a opção "Frame Duration".
Exportação: As planilhas de sprites são organizadas em linhas, acompanhadas de dados JSON. Os nomes dos arquivos são combinados como "nome_do_personagem_nome_da_ação" em pares PNG + JSON.
Um dos erros mais comuns ao importar para a engine é a forma de filtragem: use sempre o modo "Point" e evite o "Bilinear". As imagens de pixel também não precisam de compressão de textura. No Unity, é possível usar o Aseprite Importer oficial para importar diretamente os arquivos .aseprite, eliminando a necessidade de exportação manual.
Outra sugestão que considero muito valiosa: identifique as tarefas que você repete mais de dez vezes por dia e crie pequenos scripts em Lua com cerca de 20 a 30 linhas de código para automatizá-las. Faça um desses scripts por semana. Ao longo de alguns meses, o tempo economizado será muito maior do que você imagina.
Um dos tutoriais do Pixelblog de Raymond Schlitter desta primavera trata de algo que sempre achei complicado: um jogo de mechas por turnos no estilo de Front Mission, desenhado numa grade isométrica. É um conceito com fins educativos, não um projeto de verdade, e ele faz referência a posts anteriores sobre projeção isométrica.
Os mechas são desenhados em cerca de 32x32 pixels, menores do que os 64x64 ou mais que ele costuma usar, então os detalhes precisam ser abstraídos em muito poucos pixels. O método dele é começar com formas geométricas simples para cada parte e construir primeiro o corpo. O tronco deve projetar-se para a frente, como a frente de um tanque, os ombros são robustos e ficam acima da cabeça, e a cabeça permanece baixa e esguia, com apenas um ou dois pixels brilhantes para os ópticos. Os pés são pensados para estabilidade, inspirados em garras, pinças e cascos, já que pés humanoides comuns ficam estranhos nesse estilo. As listras de destaque vêm por último, e só onde reforçam as formas.
Ele esboça três tipos de unidade: infantaria com formas arredondadas, artilharia com um canhão gigante fundido à cabeça e caças com triângulos afiados e pernas de articulação invertida, cada um com uma breve nota tática.
A parte do ambiente é igualmente útil. O tile base é um cubo de 32x32 cujo losango superior tem cantos de 2 px, e os tiles adjacentes devem ser sobrepostos numa ordem consistente para que as texturas encaixem. Os tiles naturais começam com um tile de terra com texturas de grama variadas por cima. A água fica com cerca de metade da altura de um cubo normal, e sua animação faz um loop de 16 quadros deslocando uma textura de linhas 1 px para baixo a cada quadro, enquanto os realces alternam.
Minha frase favorita é o lembrete de que tiles repetidos precisam ficar bons quando repetidos por um mapa inteiro, então vale a pena testar a sobreposição por conta própria.
O mais recente Pixelblog de Raymond Schlitter no SLYNYRD é um estudo sobre plataformas ninja de 8 bits, e uma boa leitura para quem gosta de ver um conjunto inteiro de recursos de jogo construído em torno de uma única ideia. Ele se inspira abertamente em Ninja Gaiden e trabalha com a paleta do NES do início ao fim, embora não siga estritamente os limites do hardware.
O personagem do jogador vem primeiro. Ele parte de um modelo simples de boneco para que as animações fiquem prontas antes de qualquer detalhe de design, e o traje vermelho vivo foi escolhido pelo impacto visual, mesmo que não seja muito discreto. O conjunto de movimentos é inspirado em Ryu Hayabusa: corrida ágil, escalada de paredes, pendurar-se em tetos, um salto mortal e um ataque aéreo. O que eu mais gostei foi o raciocínio de que o personagem fica parado ao atacar no chão, o que exige precisão nos confrontos em vez de deixar você apertar o golpe enquanto corre.
Em seguida vêm os inimigos: uma torre-helicóptero que varre o canhão em 180 graus em cinco direções, um tanque-aranha que se agarra a paredes e tetos, e um gorila ciborgue lento que funciona como esponja de dano. Para o gorila, ele partiu de referências de caminhada com os nós dos dedos, desenhou formas corporais simples para acertar o movimento e só depois acrescentou detalhes robóticos. Juntar cabeça e corpo em uma só peça dá a ele uma rigidez deliberada.
A parte do ambiente foi a mais útil para mim. Ele usa blocos de 16x16 em seis camadas, cada uma rolando na própria velocidade para criar o parallax, e uma projeção de gabinete em que as linhas de profundidade ficam em cerca de 67,5 graus, subindo dois pixels para cada um na horizontal, o que deixa os degraus limpos. O resultado aparece em um mockup de 320x180.
Uma coisa a mais: este é o primeiro Pixelblog em que um dos minitutoriais, a decomposição completa de quadros do ninja, fica atrás de um paywall do Patreon, enquanto a lição principal continua gratuita. Os recursos e os arquivos-fonte são vendidos em um pacote separado. Eu adoraria ver alguém colocar esses sprites em um controlador de jogador de verdade.
A Habr publicou a tradução de um longo artigo de Karl Svensson sobre como os tubos de raios catódicos (CRT) afetaram o pixel art. O tema é controverso, e gostei de o autor discordar da explicação simples de que «os CRTs borravam tudo».
Ele começa com um vídeo popular do TikTok que afirma que os artistas antigos levavam em conta o desfoque dos CRTs, que suavizava as bordas grosseiras dos pixels. Svensson admite que isso é parcialmente verdade e concorda que o pixel art moderno em blocos muitas vezes vira uma nostalgia imprecisa. Mas ele aponta que o hardware antigo tem muitos outros aspectos a considerar. Ele ainda usa CRTs antigos com regularidade, por isso desliga os filtros de CRT por software dos emuladores, já que, segundo ele, nenhum reproduz fielmente uma tela real. Uma foto de um Commodore 64 num monitor Commodore 1084S mostra que as bordas irregulares dos pixels também são visíveis num CRT.
Em seguida, ele compara dois jogos de C64. Maniac Mansion (1987) roda em 160×200 e parece anguloso, enquanto Mayhem in Monsterland (1993) usa dithering e suavização na mesma paleta fixa de 16 cores para imitar uma resolução e profundidade de cor maiores. Essas técnicas dependem de características do CRT: um leve desfoque, as linhas de varredura e um pouco de vazamento de cor.
O autor considera a era de 16 bits a época de ouro do pixel art: Amiga 500, SNES, Atari ST e Mega Drive. O Amiga mostrava 32 cores de uma paleta de 4096, e os gráficos de jogos como Silkworm ou Ruff'n'Tumble foram melhorando aos poucos. Ele também aborda os truques de cor do CGA e explica que, em telas VGA de passo de ponto fino, os pixels individuais aparecem bem melhor.
Para mim, o artigo foi um bom lembrete: antes de acrescentar um «desfoque retrô», vale entender para qual tela o original foi desenhado.
No Pixelblog 63, Raymond Schlitter se volta para o shoot 'em up horizontal e monta um conjunto de recursos em torno de aviões da Segunda Guerra Mundial que combatem sobre uma paisagem natural. Depois de artigos anteriores sobre shmups verticais, esta é sua primeira abordagem do gênero horizontal, em que os padrões de tiro atravessam a tela em vez de descer.
Ele começa pelo avião do jogador, porque ele define o tom e a resolução de todo o resto. Com cerca de 48x32 pixels há espaço para detalhes sem que a animação fique cara. A aeronave é inspirada no P-51 Mustang. Um ponto que achei interessante é que ele anima o rolamento (roll) em vez da arfagem (pitch) no movimento vertical. O nariz permanece nivelado para que os tiros sempre saiam em linha reta, e a rotação em uma resolução tão baixa costuma deixar aglomerados de pixels barulhentos. Em resumo, o rolamento mantém o sprite limpo e fica bom.
A animação usa cinco orientações: um quadro neutro, duas posições de rolamento para cima e duas para baixo, além de uma hélice girando constantemente. Ele também dá uma regra de design para a sensação de jogo: um toque mostra só o primeiro grau de rolamento, segurar mostra a inclinação total, e soltar volta pela pose rasa até o neutro. Ele desaconselha colocar inércia no movimento em um gênero baseado em reações precisas.
As opções, pequenas cápsulas que orbitam a nave, também são abordadas. Além do uso no jogo, ele defende que elas dão presença na tela, o que ajuda a sentir onde está a nave enquanto os olhos acompanham as trajetórias dos tiros.
Os inimigos são aviões alemães e um veículo de artilharia Hummel. O fluxo de trabalho começa com um modelo de poucas cores de bloco, depois as cores reais e detalhes básicos, em seguida iluminação e detalhes finos, e o contorno por último. Uma troca de paleta permite reaproveitar a animação da hélice em vários aviões, e ele sugere gastar quadros extras só onde o comportamento justificar. É uma lição prática de economia.
A equipe do Aseprite anunciou em 22 de julho de 2026 que a v1.3.18 é a nova versão estável. Ela inclui correções de bugs e travamentos, além dos novos recursos introduzidos desde a v1.3.18-beta1, e pode ser baixada pela sua conta em aseprite.org.
As principais mudanças da versão principal são uma nova separação de tags dentro de grupos na linha do tempo e uma nova opção de “tamanho de sheet em potência de dois” para exportar sprite sheets. Também há correções para copiar dados de usuário (cor e texto) de tags e slices ao duplicar um sprite, e para vários travamentos, como ao excluir uma seleção colada ou ao ocultar uma camada enquanto move pixels.
As versões pontuais que vieram depois importam para quem trabalha com tiles. A v1.3.18.4 corrigiu o alinhamento do Snap to Grid para pincéis maiores que um pixel e melhorou copiar e colar tiles entre camadas de tilemap. Builds posteriores corrigiram um travamento ao colar tilemaps e outro depois de exportar um sprite sheet quando o sprite tinha uma seleção. As exportações de GIF animado agora usam o cabeçalho 89a correto, e arquivos PNG em tons de cinza são carregados com uma paleta de cinza.
Quem faz scripts também tem novidades: a versão da API Lua passou para 41, com Dialog:samerow{} e novos eventos de sprite para salvar (save e beforesave).
Gosto de notas de versão assim porque elas mostram onde está o atrito do dia a dia: grades, tilemaps e exportações. Se você vinha adiando uma atualização por causa de um bug ao copiar tiles, esta versão parece ser a que vale testar.
Ao desenhar personagens em pixel art, mais cedo ou mais tarde você esbarra no termo "sprite sheet". Compartilho uma explicação para iniciantes que Keitaro escreveu no note, porque ela percorre o funcionamento passo a passo e me pareceu muito útil.
Um sprite é uma imagem 2D exibida na tela do jogo. Personagens, inimigos, itens, projéteis e efeitos entram nessa categoria, e uma sprite sheet é o que se obtém ao reunir tudo isso em uma imagem grande. Numa animação de caminhada, mostram-se em sequência um quadro com o pé direito à frente, um com os dois pés juntos e outro com o pé esquerdo à frente, trocando rapidamente para parecer que a figura anda. Em outras palavras, o movimento vem da troca de imagens paradas, não de um vídeo.
O jogo não exibe a imagem grande inteira. Ele recorta, por coordenadas, apenas o quadro necessário. Por exemplo, se cada quadro tem 128×128 px e há oito lado a lado, a área exibida passa por 0–127 px, depois 128–255 px, e assim por diante. O artigo também dá um exemplo em que o eixo horizontal são 8 direções e o vertical são ações (andar, atacar, levar dano, defender), ou seja, 8 direções × 7 estados, totalizando 56 quadros.
No uso prático, o texto ressalta que o mais importante é alinhar a posição de referência em cada quadro. Se os pés escorregam alguns pixels de um quadro para o outro, o personagem parece tremer para cima e para baixo durante a animação. Manter o fundo transparente também é indispensável.
Por fim, o texto distingue sprite sheet, que é apenas um conjunto de imagens relacionadas, de sprite atlas, que empacota várias imagens em uma única textura para ganhar eficiência na renderização. O que mais me marcou foi o resumo de que fazer as imagens é menos difícil do que dar a elas uma forma que o jogo consiga usar corretamente. Acho que isso também ajuda quem faz pixel art, sobretudo na etapa de exportação.
Nos fundos de pixel art, as pedras são um elemento discretamente trabalhoso. O autor おかか容疑者 do note apresentou, nas notícias de pixel art de sexta-feira, a extensão do Aseprite «Rock Generator for Aseprite».
A extensão é publicada no itch.io e é uma ferramenta de produção exclusiva para pedras: ela importa pedras como malhas 3D e permite usá-las como pixel art. Só pela página de download já se veem muitos parâmetros, e o artigo diz que é justamente por focar em pedras que é possível ajustar com tanto detalhe.
Segundo o texto, há 10 formas prontas, 21 estruturas prontas e 72 looks (aparências). Dá para criar pedras cobertas de musgo e pedras com neve, o que parece prático para montar fundos. A interface suporta 27 idiomas, incluindo o japonês.
É uma ferramenta paga, a partir de US$ 4,99 (cerca de 800 ienes) em outubro de 2026. Há uma versão de teste no fim da página, mas, segundo o artigo, ela só traz imagens de exemplo do resultado. Se quiser conferir antes de comprar, vale lembrar disso.
Já era possível modelar pedras no Blender ou em outro programa e importá-las para o Aseprite. Ainda assim, fazer um esboço rápido de pedras dentro do próprio Aseprite parece muito eficiente e pode ajudar quando é preciso produzir muitos fundos de pixel art. Eu sempre tenho dúvidas sobre como pintar as diferentes texturas de pedra, então notícias sobre ferramentas de apoio como esta são muito bem-vindas.
O festival de pixel art “Pixel Art Park 9 (PAP9)” acontece no domingo, 11 de outubro de 2026, no Pacifico Yokohama. As atrações deste ano foram apresentadas em um artigo no note, escrito pelo Sr. Morita, da empresa de desenvolvimento de jogos Ixeal, de Nerima.
A Ixeal participa como empresa patrocinadora. Ela vai apresentar dois jogos originais inéditos, desenvolvidos para o PAP9, e o artigo apresenta um deles: 『Magical Soup』.
A ideia é capturar “sabores escondidos” para fazer uma sopa. Existem três tipos de sabores escondidos, “normal”, “perigoso” e “mágico”, e a combinação muda quais sopas podem ser feitas. Quem joga também ganha um adesivo do mesmo tipo da sopa que preparou. O jogo é da equipe que criou 『JUST Onigiri』, exibido no PAP8 anterior.
O segundo jogo e os novos produtos de pixel art serão apresentados em artigos futuros.
Parece um evento divertido para quem ama pixel art, com coisas para jogar e pegar na mão. Ver como o pixel art se mexe dentro de um jogo e poder conversar diretamente com os criadores parece uma oportunidade rara. Se você mora por perto, vale a pena dar uma passada.
