Hace poco leí la guía de pixel art de Juniper Dev y resumí en unos apuntes los puntos clave, desde la elección del software hasta el coloreado avanzado, para compartirlos con quienes también quieran empezar.
En cuanto a software, recomiendo Aseprite: la interfaz es amigable y sus funciones de animación y tilesets están pensadas para el desarrollo de videojuegos. Si no quieres pagar, puedes usar el LibreSprite de código abierto o la versión web Piskel como alternativas gratuitas. Con el color, al principio no me obsesioné con la teoría y usé directamente paletas ya hechas de Lospec; después, a medida que dibujaba más, fui estudiándola poco a poco. Con preparar al menos tres colores por material —base, sombra y luz— ya se consigue una sensación básica de volumen.
Al trazar líneas, recuerda eliminar los píxeles sobrantes; activar Pixel Perfect en Aseprite deja todo mucho más limpio. En las curvas, haz que la longitud de los segmentos de píxeles sea simétrica (por ejemplo, 1-2-3-2-1) y las líneas fluirán mucho mejor. Al colorear, usa colores adyacentes en el círculo cromático para las sombras o las luces y la imagen ganará viveza; además, evita el «sombreado almohada»: decide primero la dirección de la fuente de luz y luego ilumina todo de forma coherente. El tramado (dithering) y el antialiasing son dos trucos muy útiles: uno crea una textura de transición y el otro suaviza los bordes.
El contorno no tiene por qué ser negro puro; prueba con una versión oscura del color del propio objeto. Por último, un consejo para desarrolladores: no acumules demasiados colores, porque más de tres en un mismo material suele quedar confuso; reduce a menudo la vista previa para asegurarte de que se sigue leyendo con claridad en tamaño pequeño. Lo más importante es disfrutar del proceso, mucho más que obsesionarse con un «resultado perfecto».
El Pixelblog 62 trata sobre fondos de paisaje y defiende un punto con el que coincido: los fondos no deberían quedar al final de tus prioridades de producción. Establecen el escenario y atraen al jugador al mundo, pero también tienen que servir al juego. En plataformas y shmups puede que haya que atenuarlos para que los sprites se lean bien, mientras que en los RPG por turnos pueden ser ricos e inmersivos.
Para esta lección, Raymond Schlitter se centra en las escenas de batalla de un JRPG por turnos imaginario, inspirado en Dragon Quest y Phantasy Star 4, con espacio en la parte inferior para héroes vistos desde atrás. El reto que se plantea es lograr una sensación convincente de profundidad usando 16 colores o menos.
Elige un lienzo de 192x144. Tiene proporción 4:3, encaja dentro de las resoluciones habituales de consolas de 8 y 16 bits y se divide bien si después quieres un parallax de scroll perfecto al píxel. El proceso empieza con bandas horizontales de color sólido que definen el horizonte, y luego el suelo y el cielo se dividen en más bandas. Su punto clave es que la profundidad viene sobre todo de la elección del color, siguiendo la perspectiva atmosférica: el plano más cercano es el más saturado y con mayor contraste, y cada plano que se aleja pierde saturación, se aclara y desplaza su tono hacia el color del cielo. En un cielo azul despejado, la hierba más cercana es la más cálida y los planos lejanos derivan hacia el azul.
Tras los planos de color añade dos capas de montañas reutilizando colores de las bandas del cielo, y luego entra en detalles. La hierba se compone de muchas líneas verticales cortas de un solo píxel, y la clave es la consistencia en la agrupación y la escala. Incluye cada paso como una imagen separada para que puedas seguirlo a tu ritmo. Es una lectura útil si tus paletas te resultan planas.
Encontré en Habr un artículo largo sobre cómo el cubo de Rubik se convirtió en material artístico, y tiene mucho interés para quienes aman el pixel art. El autor lleva varios años creando mosaicos con cubos y explica por qué este género está tan cerca de los gráficos digitales.
La idea principal es sencilla: una baldosa de color en la cara de un cubo es, en esencia, un píxel. Cada cara tiene nueve cuadrados y la paleta tiene seis colores, así que varios cubos juntos forman una imagen de baja resolución, parecida a la pantalla de un viejo ordenador o de una máquina recreativa. Las fechas también encajan: la época dorada de los juegos de 8 bits como Space Invaders, Pac-Man o Donkey Kong coincidió con la fiebre del cubo de Rubik de comienzos de los 80. Según el autor, el término «pixel art» lo usaron por primera vez en 1982 Adele Goldberg y Robert Flegal, de Xerox.
Después, el artículo repasa la historia del género. Los primeros experimentos se atribuyen al artista británico Fred Holly a mediados de los 80. En los 90, el programador Jacob Devenport documentó mosaicos de varias decenas de cubos, entre ellos el primero de dos caras. El verdadero salto llegó con el artista callejero francés Invader, que en 2004 construyó su personaje de Space Invaders con nueve cubos y bautizó el estilo como Rubikcubism. Su «Mona Lisa» de 330 cubos se vendió en subasta en 2020 por 480 200 euros, y en 2022-2023 el museo MIMA de Bruselas acogió una exposición de más de cien de sus obras con cubos.
Lo que más me gustó fue cómo el autor describe el proceso: primero un diagrama de píxeles con seis colores y, en las piezas más complejas, Photoshop para controlar los colores. Es el mismo camino que sigue cualquier artista de pixel art, solo que aquí los «píxeles» son cubos de plástico. Para quien trabaja con una paleta limitada, es una buena razón para mirar técnicas conocidas desde otro ángulo.
Recientemente, leí una guía muy completa sobre Aseprite que desglosa el flujo de trabajo para juegos de pixel art. He anotado las partes que me resultaron más útiles, especialmente la configuración predeterminada que "es difícil de usar incorrectamente".
Lienzo: Los personajes comienzan con un tamaño de 32x32 píxeles, los enemigos, los objetos y los iconos comienzan con 16x16 píxeles, y el personaje principal se puede ampliar a 64x64 píxeles cuando sea necesario. La escala predeterminada para la edición se puede establecer en 800%, pero en el juego, es importante mantener una relación de aspecto de 1:1. No te dejes engañar por la escala ampliada del lienzo en el editor.
Paleta de colores: Comienza con la paleta DB32 disponible en Lospec, luego amplíala a 48-64 colores según sea necesario, pero trata de limitar el número de colores utilizados en cada cuadro a 16. La paleta de colores son simplemente "colores opcionales", no "colores que deben usarse". Es mejor utilizar un conjunto de paletas de colores principales para todo el proyecto y evitar cambiar la paleta por completo durante el desarrollo, ya que esto puede hacer que los activos antiguos tengan un estilo inconsistente.
Animación: La velocidad de fotogramas de espera es de 8 FPS, la de ataque es de 12 FPS y la de habilidades especiales es de 24 FPS. Se pueden establecer diferentes duraciones para cada cuadro dentro del mismo archivo utilizando la opción "Frame Duration".
Exportación: Las láminas de sprites se organizan por filas y se acompañan de datos JSON. Los nombres de los archivos se combinan con extensiones PNG y JSON utilizando el formato "nombre del personaje_nombre de la acción".
El problema más común al importar a un motor de juegos es el modo de filtrado: siempre utiliza el modo "Point" y no el modo "Bilinear". Las imágenes de píxeles tampoco necesitan compresión de texturas. Unity puede importar directamente archivos .aseprite utilizando el importador oficial de Aseprite, lo que elimina la necesidad de exportar manualmente.
También hay un consejo que me parece muy valioso: identifica las tareas que realizas más de diez veces al día y utiliza un pequeño script de Lua de unas veinte o treinta líneas para automatizarlas, una por semana. Con el tiempo, el tiempo ahorrado es mucho mayor de lo que se imagina.
Uno de los tutoriales de Pixelblog de Raymond Schlitter de esta primavera aborda algo que siempre me ha resultado complicado: un juego de mechas por turnos al estilo de Front Mission, dibujado sobre una cuadrícula isométrica. Es un concepto con fines educativos, no un proyecto real, y remite a sus publicaciones anteriores sobre la proyección isométrica.
Los mechas se dibujan a unos 32x32 píxeles, más pequeños que los 64x64 o más que suele usar, así que los detalles tienen que simplificarse en muy pocos píxeles. Su método consiste en empezar por formas geométricas sencillas para cada parte y construir primero el cuerpo. El torso debe proyectarse hacia delante como el frontal de un tanque, los hombros son voluminosos y van más altos que la cabeza, y la cabeza se mantiene baja y estilizada, con uno o dos píxeles brillantes para los ópticos. Los pies se diseñan para dar estabilidad, tomando como referencia garras, pinzas y pezuñas, porque los pies humanoides normales se ven torpes en este estilo. Las franjas de acento se añaden al final y solo donde refuerzan las formas.
Bosqueja tres tipos de unidad: infantería con formas redondeadas, artillería con un enorme cañón fusionado con la cabeza y cazas con triángulos afilados y piernas con articulación invertida, y añade a cada una una breve nota táctica.
La parte del entorno es igual de útil. La casilla base es un cubo de 32x32 cuyo rombo superior tiene esquinas de 2 px, y las casillas adyacentes deben superponerse en un orden coherente para que las texturas encajen. Las casillas naturales parten de una casilla de tierra con texturas de hierba variadas encima. El agua queda a unos la mitad de la altura de un cubo normal, y su animación se repite en 16 fotogramas desplazando una textura de línea 1 px hacia abajo en cada uno, mientras los brillos alternan.
Mi frase favorita es el recordatorio de que las casillas que se repiten deben verse bien al repetirse en todo un mapa, así que merece la pena probar la superposición por cuenta propia.
El último Pixelblog de Raymond Schlitter en SLYNYRD es un estudio sobre plataformas ninja de 8 bits, y es una buena lectura para cualquiera a quien le guste ver un conjunto completo de recursos de juego construido alrededor de una sola idea. Él toma abiertamente como referencia Ninja Gaiden y trabaja con la paleta de la NES en todo momento, aunque no se ciñe estrictamente a los límites del hardware.
El personaje del jugador va primero. Parte de una plantilla de maniquí sencilla para que las animaciones queden resueltas antes de añadir cualquier detalle de diseño, y el traje rojo intenso se eligió por su impacto aunque no sea muy sigiloso. El repertorio de movimientos está inspirado en Ryu Hayabusa: una carrera ágil, escalar paredes, colgarse de los techos, un salto mortal y un tajo en el aire. Lo que más me gustó es el razonamiento de que el personaje se queda quieto al atacar en el suelo, porque eso obliga a la precisión en los enfrentamientos en lugar de dejar pulsar el tajo mientras corres.
Después vienen los enemigos: una torreta-helicóptero que barre su cañón 180 grados en cinco direcciones, un tanque araña que se agarra a paredes y techos, y un gorila cibernético lento que actúa como esponja de daño. Para el gorila partió de referencias de caminar con los nudillos, trazó formas corporales sencillas para acertar el movimiento y solo después añadió detalles robóticos. Fundir cabeza y cuerpo en una sola pieza le da una rigidez deliberada.
La parte del entorno es la que me pareció más útil. Usa mosaicos de 16x16 en seis capas, cada una con su propia velocidad de desplazamiento para lograr el parallax, y una proyección tipo gabinete donde las líneas de profundidad siguen aproximadamente 67,5 grados, subiendo dos píxeles por cada uno de avance para que los escalones queden limpios. El resultado se muestra en una maqueta de 320x180.
Un detalle más: es el primer Pixelblog en el que uno de los minitutoriales, el desglose completo de fotogramas del ninja, queda tras un muro de pago de Patreon, mientras que la lección principal sigue siendo gratuita. Los recursos y los archivos fuente se venden como un paquete aparte. Me encantaría ver a alguien llevar estos sprites a un controlador de jugador real.
En Habr se ha publicado una traducción de un extenso artículo de Karl Svensson sobre cómo los tubos de rayos catódicos (CRT) influyeron en el pixel art. El tema es discutible, y me gustó que el autor no esté de acuerdo con la explicación simple de que «los CRT lo difuminaban todo».
El artículo empieza con un vídeo popular de TikTok que afirma que los artistas antiguos tenían en cuenta el desenfoque de los CRT, que suavizaba los bordes toscos de los píxeles. Svensson reconoce que esto es en parte cierto y coincide en que el pixel art de bloques modernos a menudo se convierte en una nostalgia imprecisa. Pero señala que el hardware antiguo tiene muchos más aspectos que considerar. Él sigue usando CRT antiguos con regularidad, por eso desactiva los filtros CRT de software de los emuladores, ya que, según dice, ninguno reproduce fielmente una pantalla real. Una foto de un Commodore 64 en un monitor Commodore 1084S muestra que los bordes irregulares de los píxeles también se ven en un CRT.
A continuación compara dos juegos de C64. Maniac Mansion (1987) funciona a 160×200 y se ve anguloso, mientras que Mayhem in Monsterland (1993) usa dithering y suavizado con la misma paleta fija de 16 colores para imitar una mayor resolución y profundidad de color. Estas técnicas dependen de las propiedades del CRT: un leve desenfoque, las líneas de barrido y una ligera filtración de color.
El autor considera que la edad dorada del pixel art es la era de 16 bits: Amiga 500, SNES, Atari ST y Mega Drive. La Amiga mostraba 32 colores de una paleta de 4096, y los gráficos de juegos como Silkworm o Ruff'n'Tumble mejoraron poco a poco. También analiza los trucos de color de CGA y explica que, en pantallas VGA de paso de punto fino, los píxeles individuales se ven mucho mejor.
Para mí, el artículo fue un buen recordatorio: antes de añadir un «desenfoque retro», conviene entender para qué pantalla se dibujó el original.
En el Pixelblog 63, Raymond Schlitter se pasa al shoot 'em up horizontal y construye un conjunto de recursos alrededor de aviones de la Segunda Guerra Mundial que combaten sobre un paisaje natural. Tras los artículos anteriores sobre shmups verticales, este es su primer acercamiento al género horizontal, donde las ráfagas de balas cruzan la pantalla en lugar de bajar por ella.
Empieza por el avión del jugador, porque marca el tono y la resolución para todo lo demás. Con unos 48x32 píxeles hay espacio para el detalle sin que la animación se encarezca. El avión está inspirado en el P-51 Mustang. Lo que me pareció interesante es que anima el balanceo (roll) en lugar del cabeceo (pitch) para el movimiento vertical. El morro se mantiene nivelado para que las balas salgan siempre de frente, y la rotación a una resolución tan baja suele dejar grupos de píxeles ruidosos. En resumen, el balanceo mantiene el sprite limpio y se ve bien.
La animación usa cinco orientaciones: un fotograma neutro, dos posiciones de balanceo para arriba y dos para abajo, además de una hélice que gira sin parar. También da una regla de diseño sobre cómo debe sentirse en juego: un toque muestra solo el primer grado de balanceo, mantener pulsado muestra la inclinación completa y soltar vuelve pasando por la postura suave hasta el neutro. Desaconseja añadir inercia al movimiento en un género basado en reacciones precisas.
También trata las opciones, las pequeñas cápsulas que orbitan la nave. Más allá de su uso en la jugabilidad, sostiene que aportan presencia en pantalla, lo que ayuda a sentir dónde está tu nave mientras tus ojos siguen las trayectorias de las balas.
Los enemigos son aviones alemanes y un vehículo de artillería Hummel. Su flujo de trabajo consiste en una plantilla de unos pocos colores de bloque, después colores reales y detalle básico, luego iluminación y detalle fino, y el contorno al final. Un cambio de paleta permite reutilizar la animación de la hélice entre aviones, y sugiere gastar fotogramas extra solo donde el comportamiento lo justifique. Es una lección práctica de economía.
El equipo de Aseprite anunció el 22 de julio de 2026 que la v1.3.18 es la nueva versión estable. Incluye correcciones de errores y fallos, además de las nuevas funciones introducidas desde la v1.3.18-beta1, y se puede descargar desde tu cuenta en aseprite.org.
Los cambios principales de la versión base son una nueva separación de etiquetas dentro de los grupos de la línea de tiempo y una nueva opción de «tamaño de hoja en potencia de dos» para exportar hojas de sprites. También hay correcciones para copiar datos de usuario (color y texto) de etiquetas y cortes al duplicar un sprite, y para varios fallos, como al eliminar una selección pegada o al ocultar una capa mientras se mueven píxeles.
Las versiones puntuales posteriores son importantes para quienes trabajan con tiles. La v1.3.18.4 corrigió la alineación de Ajustar a la cuadrícula para pinceles de más de un píxel y mejoró copiar y pegar tiles entre capas de tilemap. Compilaciones posteriores corrigieron un fallo al pegar tilemaps y otro al exportar una hoja de sprites cuando el sprite tenía una selección. Las exportaciones de GIF animado ahora usan la cabecera 89a correcta, y los archivos PNG en escala de grises se cargan con una paleta de grises.
Quienes escriben scripts también tienen novedades: la versión de la API de Lua pasó a la 41, con Dialog:samerow{} y nuevos eventos de sprite para guardar (save y beforesave).
Me gustan notas de versión como esta porque muestran dónde están las fricciones del día a día: cuadrículas, tilemaps y exportaciones. Si has estado posponiendo una actualización por un error al copiar tiles, esta versión parece la indicada para probar.
Cuando empiezas a dibujar personajes en pixel art, tarde o temprano te topas con el término "hoja de sprites" (sprite sheet). Comparto una explicación pensada para principiantes que Keitaro escribió en note, porque recorre paso a paso cómo funciona el sistema y me pareció muy útil.
Un sprite es una imagen 2D que se muestra en la pantalla del juego. Personajes, enemigos, objetos, balas y efectos entran en esta categoría, y una hoja de sprites es el resultado de agruparlos en una sola imagen grande. En una animación de caminar, se muestra un fotograma con el pie derecho adelante, luego otro con los dos pies juntos y después otro con el pie izquierdo adelante, cambiando rápido para que parezca que camina. Dicho de otro modo, el movimiento surge de cambiar imágenes fijas, no de un vídeo.
El juego no muestra la imagen grande completa. Recorta solo el fotograma que necesita dividiendo la imagen en coordenadas. Por ejemplo, si cada fotograma mide 128×128 px y hay ocho en fila, el área visible pasa de 0–127 px a 128–255 px, y así sucesivamente. El artículo también pone un ejemplo en el que el eje horizontal son 8 direcciones y el vertical son acciones (caminar, atacar, recibir daño, defender), de modo que se gestionan 8 direcciones × 7 estados, es decir, 56 fotogramas.
Al usarlas en la práctica, el artículo insiste en que lo importante es alinear la posición de referencia de cada fotograma. Si los pies se desplazan unos píxeles de un cuadro a otro, el personaje parece temblar arriba y abajo durante la animación. Mantener el fondo transparente también es imprescindible.
Por último, aclara la diferencia entre una hoja de sprites, que es simplemente un conjunto de imágenes relacionadas, y un atlas de sprites, que empaqueta varias imágenes en una sola textura para mejorar la eficiencia del dibujado. Lo que más me quedó es su resumen: hacer las imágenes es menos difícil que darles una forma que el juego pueda usar correctamente. Creo que también será útil para quienes dibujan pixel art, sobre todo en la fase de exportación.
En los fondos de pixel art, las rocas son un trabajo pequeño pero sorprendentemente laborioso. En su sección de noticias de pixel art del viernes, el autor de note おかか容疑者 presentó la extensión de Aseprite «Rock Generator for Aseprite».
La extensión se publica en itch.io. Es una herramienta de producción exclusiva para rocas: permite importar rocas como mallas 3D y usarlas como pixel art. Solo con ver la página de descarga ya se aprecian muchos parámetros, y el artículo explica que precisamente por centrarse en las rocas se puede ajustar con tanto detalle.
Según el artículo, incluye 10 formas predefinidas, 21 estructuras predefinidas y 72 looks (aspectos visuales). También se pueden crear rocas cubiertas de musgo o con nieve, así que parece fácil de usar para construir fondos. La interfaz admite 27 idiomas, incluido el japonés.
Es una herramienta de pago, desde 4,99 dólares estadounidenses (unos 800 yenes) a octubre de 2026. Al final de la página hay una versión de prueba, pero según el artículo solo contiene imágenes de ejemplo del resultado. Si quieres comprobarla antes de comprar, tenlo en cuenta.
Ya era posible modelar rocas en Blender u otro programa e importarlas a Aseprite. Aun así, poder esbozar rocas rápidamente dentro de Aseprite parece muy eficiente y puede ser útil cuando hay que producir muchos fondos de pixel art. Siempre me cuesta decidir cómo pintar las distintas texturas de roca, así que las noticias sobre herramientas de apoyo como esta me alegran de verdad.
El festival de arte pixel “Pixel Art Park 9 (PAP9)” se celebrará el domingo 11 de octubre de 2026 en Pacifico Yokohama. Las propuestas de este año se presentan en un artículo de note de Morita, de la empresa de desarrollo de videojuegos Ixeal, de Nerima.
Ixeal participa como empresa patrocinadora. Presentará dos juegos originales totalmente nuevos desarrollados para PAP9, y el artículo presenta uno de ellos, 『Magical Soup』.
El juego consiste en atrapar “sabores ocultos” para preparar una sopa. Hay tres tipos de sabores ocultos, “normal”, “peligroso” y “mágico”, y según la combinación cambia la sopa que se puede hacer. Además, quien juega recibe una pegatina del mismo tipo que la sopa que ha preparado. El juego es obra del equipo que hizo 『JUST Onigiri』, expuesto en el PAP8 anterior.
El segundo juego y los nuevos productos de arte pixel se presentarán en artículos posteriores.
Parece un evento divertido para quienes aman el arte pixel, con cosas que se pueden jugar y tocar. Ver cómo se mueve el arte pixel dentro de un juego y poder hablar directamente con quienes lo crean parece una gran oportunidad. Si vives cerca, quizá valga la pena pasarse.