最近看了 Juniper Dev 的像素画指南，把从软件选择到进阶上色的要点整理成一份笔记，分享给同样想入门的朋友。
软件上我推荐 Aseprite，界面友好，动画和图块集都是为游戏开发设计的；不想付费的话，可以用开源的 LibreSprite 或网页版 Piskel 作为免费替代。配色方面我一开始不纠结色彩理论，直接用 Lospec 上现成的调色盘，画多了再慢慢研究。每种材质至少准备底色、阴影、高光三种颜色，就能做出基本的体积感。
画线时记得去掉多余的像素，在 Aseprite 里开启 Pixel Perfect 会干净很多；画曲线时让像素段长度对称（比如 1-2-3-2-1），线条会顺很多。上色时用色轮上相邻的颜色做阴影或高光，画面会更鲜艳；还要避免「枕头式阴影」，先想好光源方向再统一打光。抖色和抗锯齿是两个很实用的小技巧，一个营造过渡质感，一个让边缘更平滑。
轮廓线不一定用纯黑，可以试试物体本身的深色版本。最后给开发者的建议：颜色别堆太多，同一材质超过三种容易乱；经常缩小看预览，确保缩小后依然清晰。最重要的是享受过程，比纠结「完美成品」更重要。
来源：32comic
Pixelblog 62 присвячено пейзажним фонам, і в ньому є думка, з якою я згоден: фони не повинні стояти в кінці списку виробничих пріоритетів. Вони задають атмосферу й затягують гравця у світ, але водночас мають працювати на геймплей. У платформерах і шмапах їх часто доводиться приглушувати, щоб спрайти читалися, а в покрокових RPG фон може бути багатим і занурювальним.
У цьому уроці Раймонд Шлиттер зосереджується на бойових сценах вигаданої покрокової JRPG, натхненної Dragon Quest і Phantasy Star 4, із місцем унизу для героїв, яких видно зі спини. Завдання — створити переконливу глибину, використовуючи 16 кольорів або менше.
Он обирає полотно 192x144. Пропорції 4:3, розмір вкладається в поширені роздільні здатності 8- і 16-бітних консолей і добре ділиться, якщо згодом знадобиться паралакс із прокручуванням з точністю до пікселя. Робота починається з суцільних горизонтальних смуг, що задають лінію горизонту, потім земля й небо діляться на більше смуг. Його ключова думка: глибина здебільшого створюється вибором кольору за законами повітряної перспективи. Найближчий план найнасиченіший і найконтрастніший, а кожен план, що віддаляється, втрачає насиченість, світлішає і зсуває відтінок до кольору неба. Під ясним блакитним небом найближча трава найтепліша, а дальні плани йдуть у синяву.
Після кольорових планів він додає два шари гір, використовуючи кольори з небесних смуг, і переходить до деталей. Трава складається з багатьох коротких однопіксельних вертикальних штрихів, і ключ — сталість у групуванні та масштабі. Кожен крок він показує окремим зображенням, тож можна йти у власному темпі. Корисна стаття, якщо палітри здаються плоскими.
Джерело: SLYNYRD
На Habr я натрапив на довгу статтю про те, як кубик Рубіка став художнім матеріалом, і в ній багато цікавого для тих, хто любить піксель-арт. Автор кілька років створює мозаїки з кубиків і пояснює, чому цей жанр так близький до цифрової графіки.
Головна думка проста: кольорова плитка на грані кубика — по суті піксель. На одній грані дев'ять квадратів, у палітрі шість кольорів, тож кілька кубиків разом утворюють зображення з низькою роздільною здатністю, схоже на екран старого комп'ютера чи ігрового автомата. Збігаються й часові рамки: розквіт 8-бітних ігор на кшталт Space Invaders, Pac-Man і Donkey Kong припав на ту саму «рубікоманію» початку 1980-х. Термін pixel art, за словами автора, вперше вжили 1982 року Адель Голдберг і Роберт Флегал з Xerox.
Далі йде історія жанру. Найранніші експерименти приписують британцю Фреду Холлі середини 1980-х. У 1990-х програміст Джейкоб Девенпорт задокументував мозаїки з кількох десятків кубиків, зокрема першу двосторонню. Справжнім проривом став французький стрит-арт-художник Invader, який 2004 року склав свого космічного загарбника з дев'яти кубиків і назвав напрям Rubikcubism. Його «Мона Ліза» з 330 кубиків 2020 року пішла з аукціону за 480 200 євро, а у 2022–2023 роках брюссельський музей MIMA показав понад сотню його кубічних робіт.
Найбільше мені сподобався опис процесу: спочатку макет-піксельна схема з шести кольорів, а в складніших роботах — Photoshop для контролю кольорів. Це той самий шлях, що й у будь-якого піксель-артиста, лише «пікселі» тут — пластикові кубики. Для тих, хто працює з обмеженою палітрою, це привід поглянути на звичні прийоми під іншим кутом.
Джерело: Habr
Останнім часом я прочитав детальне керівництво з використання програми Aseprite, в якому детально описано процес створення піксельних ігор. Я записав ті частини, які були для мене найбільш корисними, особливо набір "налаштувань за замовчуванням, які важко застосувати неправильно".
Полотно: Розмір спрайтів для персонажів починається з 32x32 пікселів, для ворогів, предметів та іконок – з 16x16 пікселів. Головного героя можна збільшити до 64x64 пікселів, якщо це необхідно. Під час редагування можна встановити масштаб відображення за замовчуванням на 800%, але в самій грі важливо відображати спрайти в масштабі 1:1, не дозволяйте збільшеному полотну в редакторі вас обдурити.
Палітра кольорів: Почніть з палітри DB32, доступної на сайті Lospec. Після визначення основних кольорів, розширте палітру до 48-64 кольорів, але намагайтеся використовувати не більше 16 кольорів в одному кадрі. Палітра – це "набір доступних кольорів", а не "набір кольорів, які потрібно використовувати". Для всього проєкту найкраще використовувати один основний набір кольорів, і не змінюйте його в процесі розробки, інакше стиль старих ресурсів може не відповідати новому.
Анімація: Швидкість кадрів для анімації: 8 FPS для нейтрального стану, 12 FPS для атаки, 24 FPS для спеціальних навичок. У одному файлі можна задати різну тривалість для різних кадрів за допомогою параметра "Frame Duration".
Експорт: Спрайти експортуються у вигляді "sprite sheet", розташованих по рядках, разом з файлом JSON, що містить дані. Назви файлів повинні бути у форматі "назва_персонажа_назва_дії" і складатися з файлів PNG та JSON.
Найбільш поширеною помилкою після імпорту в ігровий рушій є неправильний вибір фільтра: використовуйте режим "Point", а не "Bilinear". Піксельні зображення не потребують стиснення текстур. У Unity можна використовувати офіційний імпортер Aseprite для прямого імпорту файлів .aseprite, що дозволяє уникнути ручного експорту.
Ще одна порада, з якою я повністю згоден: визначте дії, які ви повторюєте більше десяти разів на день, і напишіть невеликий скрипт на Lua (близько 20-30 рядків коду), щоб автоматизувати їх. Робіть це щотижня. За кілька місяців ви заощажите набагато більше часу, ніж можете собі уявити.
Ви можете почати вибір палітри кольорів звідси:
https://lospec.com/palette-list
Джерело: Xmohe, "Коробка чарів для незалежних ігор".
Один із весняних туторіалів Pixelblog Раймонда Шліттера присвячений темі, яка завжди здавалася мені складною: покрокова гра про мехів у стилі Front Mission, намальована на ізометричній сітці. Це навчальна концепція, а не реальний проєкт, і автор посилається на свої попередні дописи про ізометричну проєкцію.
Мехи малюються приблизно у 32x32 пікселі, менше за звичні 64x64 і більше, тож деталі треба звести до дуже небагатьох пікселів. Його метод: кожну частину починати з простих геометричних фігур і спершу будувати корпус. Тулуб має виступати вперед, як лоб танка, плечі масивні й стоять вище за голову, а голова лишається низькою й обтічною, з одним-двома яскравими пікселями для оптики. Ступні проєктують для стійкості, запозичуючи форму в кігтів, клешень і копит, бо звичайні людиноподібні стопи в цьому стилі виглядають незграбно. Акцентні смуги додаються наприкінці й лише там, де підсилюють форму.
Він накидає три типи юнітів: піхоту з округлими формами, артилерію з гігантською гарматою, злитою з головою, та винищувачі з гострими трикутниками й ногами зі зворотним згином, кожен із коротким тактичним коментарем.
Частина про середовище не менш корисна. Базовий тайл — куб 32x32, у верхнього ромба кути по 2 px, а сусідні тайли треба накладати в одному й тому самому порядку, щоб текстури стикувалися без швів. Природні тайли починаються з земляного тайла, поверх якого кладуться різні текстури трави. Вода приблизно вдвічі нижча за звичайний куб, а її анімація зациклюється на 16 кадрах: лінійна текстура зсувається вниз на 1 px за кадр, а блики чергуються.
Мені найбільше подобається нагадування, що тайли, які повторюються, мають добре виглядати, коли їх повторюють по всій карті, тож варто самому перевірити накладання шарів.
Джерело: SLYNYRD Pixelblog
Найновіший Pixelblog Раймонда Шлітера на SLYNYRD присвячено 8-бітним платформерам про ніндзя. Це цікаве читання для тих, кому подобається бачити, як ціла низка ігрових ассетів будується навколо однієї ідеї. Він відверто бере за взірець Ninja Gaiden і весь час працює з палітрою NES, хоча й не дотримується обмежень заліза суворо.
Спочатку йде персонаж гравця. Він починає з простої болванки, щоб анімація була готова до того, як з'являться будь-які дизайнерські деталі. Яскраво-червоний костюм обрано для помітності, навіть якщо він не надто непомітний. Набір рухів спирається на Рю Хаябусу: швидкий біг, лазіння по стінах, висіння на стелі, перекидний стрибок і повітряний удар. Мені сподобалася логіка, за якою персонаж зупиняється, коли атакує на землі. Це вимагає точності в сутичках, а не дозволяє натискати удар, поки біжиш.
Далі вороги: вертолітна турель, яка водить гарматою на 180 градусів у п'яти напрямках, павуча танкетка, що чіпляється за стіни й стелі, та повільна кібергорила, яка слугує губкою для пошкоджень. Для горили він спирався на референси ходьби на кісточках пальців, спочатку накидав прості форми тіла, щоб ловити рух, і лише потім додав роботизовані деталі. Об'єднання голови й тулуба в одну деталь надає їй навмисної скутості.
Найкорисніше для мене була частина про оточення. Використовуються тайли 16x16 у шести шарах, кожен із яких прокручується з власною швидкістю для ефекту паралаксу, і шафова проєкція, де лінії глибини йдуть приблизно під 67,5 градуса: на кожен піксель убік припадає два пікселі вгору, тож сходинки виглядають чисто. Результат показано на макеті 320x180.
Ще одне: це перший Pixelblog, де один із міні-уроків, повний покадровий розбір ніндзя, закритий платною підпискою Patreon, тоді як основний урок лишається безкоштовним. Ассети та вихідні файли продаються окремим пакетом. Я б хотів побачити, як хтось вставить ці спрайти в справжній контролер гравця.
Джерело: SLYNYRD
На Habr вийшов переклад великої статті Карла Свенссона про те, як електронно-променеві трубки (ЕПТ) вплинули на піксель-арт. Тема спірна, і мені сподобалося, що автор не погоджується з простим поясненням «ЕПТ усе розмивали».
Його текст починається з популярного відео в TikTok, у якому стверджується, що старі художники враховували розмиття ЕПТ, через яке грубі краї пікселів здавалися м'якшими. Свенссон визнає, що це почасти правда, і погоджується, що сучасний блоковий піксель-арт часто перетворюється на неточну ностальгію. Але він нагадує, що в старого заліза аспектів набагато більше. Сам він регулярно користується старими ЕПТ, тому вимикає програмні ЕПТ-фільтри в емуляторах: за його словами, жоден із них не передає справжній екран правильно. Фото Commodore 64 на моніторі Commodore 1084S показує, що нерівні краї пікселів видно й на ЕПТ.
Далі йде порівняння двох ігор для C64. Maniac Mansion (1987) працює в роздільній здатності 160×200 і виглядає кутасто, а Mayhem in Monsterland (1993) при тій самій фіксованій палітрі з 16 кольорів використовує дизеринг і згладжування, щоб імітувати більшу роздільну здатність і глибину кольору. Ці прийоми спираються на властивості ЕПТ: легку розмитість, растрові рядки і невелике просочування кольорів.
Золотою добою піксель-арту автор вважає 16-бітну еру: Amiga 500, SNES, Atari ST і Mega Drive. Amiga показувала 32 кольори з 4096, а графіка в іграх на кшталт Silkworm чи Ruff'n'Tumble поступово покращувалася. Він також розбирає трюки з кольором CGA і пояснює, що на екранах VGA з дрібним кроком точок окремі пікселі видно значно краще.
Для мене ця стаття стала добрим нагадуванням: перш ніж додавати «ретро-розмиття», варто зрозуміти, для якого екрана малювали оригінал.
Джерело: Habr
У Pixelblog 63 Раймонд Шлиттер береться за горизонтальний шутер і будує набір ассетів навколо літаків Другої світової, що б'ються над природним ландшафтом. Після попередніх матеріалів про вертикальні шмапи це його перша спроба в горизонтальному жанрі, де візерунки куль перетинають екран, а не падають згори вниз.
Починає він із літака гравця, бо саме він задає стиль і роздільну здатність для всього іншого. Близько 48x32 пікселів лишають місце для деталей, але анімація не стає надто дорогою. Літак змодельовано за P-51 Mustang. Цікаво, що для вертикального руху він анімує крен, а не тангаж. Ніс лишається рівним, тож кулі завжди летять прямо, а поворот на такій низькій роздільній здатності зазвичай дає шумні скупчення пікселів. Словом, крен тримає спрайт чистим і добре виглядає.
Анімація має п'ять орієнтацій: нейтральний кадр, по два положення крену вгору й униз та гвинт, що постійно обертається. Він також подає дизайнерське правило щодо відчуття гри: короткий дотик показує лише перший градус крену, утримання дає повний нахил, а відпускання повертає через неглибоку позу до нейтрального положення. В жанрі, що тримається на точних реакціях, він радить не додавати руху інерції.
Розглянуто й опції, маленькі модулі, що обертаються навколо корабля. Окрім ігрової ролі, на його думку, вони додають присутності на екрані й допомагають відчувати, де твій корабель, поки очі стежать за траєкторіями куль.
Вороги — німецькі літаки та артилерійська установка Hummel. Його процес починається з шаблону з кількох блокових кольорів, далі йдуть справжні кольори та базові деталі, потім світло й дрібні деталі, а контур додається наостанок. Заміна палітри дозволяє використовувати анімацію гвинта на різних літаках, а додаткові кадри він радить витрачати лише там, де поведінка на це заслуговує. Практичний урок ощадливості.
Джерело: SLYNYRD
Команда Aseprite оголосила 22 липня 2026 року, що v1.3.18 стала новою стабільною версією. Вона містить виправлення помилок і збоїв, а також нові можливості, додані після v1.3.18-beta1; завантажити її можна з вашого облікового запису на aseprite.org.
Головні зміни основного релізу — новий спосіб розділення тегів у групах на таймлайні та нова опція «розмір аркуша — степінь двійки» для експорту спрайт-аркушів. Також виправлено копіювання користувацьких даних (колір і текст) тегів та слайсів під час дублювання спрайта та кілька збоїв, наприклад під час видалення вставленого виділення або приховування шару під час переміщення пікселів.
Наступні проміжні релізи важливі для тих, хто працює з тайлами. v1.3.18.4 виправив вирівнювання «Прив'язки до сітки» для пензлів більших за один піксель і покращив копіювання та вставку тайлів між шарами тайлмапа. У пізніших збірках виправлено збій під час вставки тайлмапів і збій після експорту спрайт-аркуша, якщо в спрайта було виділення. Експорт анімованих GIF тепер використовує правильний заголовок 89a, а PNG у відтінках сірого завантажуються із сірою палітрою.
Для скриптерів також є новини: версію Lua API піднято до 41, додано Dialog:samerow{} та нові події збереження спрайта (save і beforesave).
Мені подобаються такі описи змін, бо вони показують, де в щоденній роботі виникають труднощі: сітка, тайлмапи, експорт. Якщо ви відкладали оновлення через помилку копіювання тайлів, ця версія виглядає тією, яку варто спробувати.
Коли починаєш малювати персонажів у піксель-арті, рано чи пізно натрапляєш на термін «спрайтшит» (sprite sheet). Ділюся вступним поясненням Keitaro з note: воно крок за кроком розбирає, як це працює, і мені воно видалося корисним.
Спрайт — це двовимірне зображення, яке виводиться на екран гри. Персонажі, вороги, предмети, кулі та ефекти належать до спрайтів, а спрайтшит — це набір таких зображень, зібраних в одну велику картинку. Для анімації ходи показують кадр із правою ногою попереду, потім кадр із ногами разом, потім кадр з лівою ногою попереду, швидко їх змінюючи, щоб виник ефект руху. Тобто рух створюється зміною нерухомих картинок, а не відео.
Гра не виводить велике зображення цілком. За координатами вона вирізає лише потрібний кадр. Наприклад, якщо кожен кадр має 128×128 пікселів і вісім стоять поряд, область виведення зсувається з 0–127 px на 128–255 px і так далі. У статті також наведено приклад, де по горизонталі — 8 напрямків, а по вертикалі — дії (ходьба, атака, отримання удару, захист), тобто 8 напрямків × 7 станів, разом 56 кадрів.
Під час практичного використання, як зазначено в статті, найважливіше — вирівняти опорну точку в кожному кадрі. Якщо ноги зсуваються на кілька пікселів від кадру до кадру, персонаж під час анімації ніби тремтить угору й униз. Прозорий фон теж обов'язковий.
Нарешті розведено різницю між спрайтшитом, тобто просто набором пов'язаних зображень, і атласом спрайтів, який пакує кілька зображень в одну текстуру для ефективнішого малювання. Найбільше мені запам'ятався висновок, що створити зображення простіше, ніж привести їх до форми, яку гра може правильно використати. Думаю, це стане в пригоді й піксель-артистам, особливо на етапі експорту.
Джерело: note (Keitaro)
У фонах піксель-арту каміння — дрібниця, але на його створення несподівано багато часу. У п'ятничному огляді піксель-новин автор note おかか容疑者 розповів про розширення для Aseprite «Rock Generator for Aseprite».
Розширення опубліковано на itch.io. Це інструмент виключно для каменів: він імпортує їх як 3D-меші, і їх можна використовувати як піксель-арт. Уже на сторінці завантаження видно багато параметрів, і автор статті вважає, що саме обмеження лише каменями дає змогу так детально їх налаштовувати.
За словами статті, у комплекті є 10 готових форм, 21 готова структура та 72 «looks» (зовнішніх вигляди). Можна створювати і камені, вкриті мохом, і засніжені, тож для побудови фонів це виглядає зручно. Інтерфейс підтримує 27 мов, зокрема японську.
Інструмент платний: станом на жовтень 2026 року ціна починається від 4,99 долара США (близько 800 єн). Унизу сторінки є пробна версія, але, як пишеться в статті, вона містить лише зразки зображень результату. Якщо хочете перевірити її перед покупкою, варто це пам'ятати.
Моделі каменів і раніше можна було створити в Blender чи іншій програмі, а потім імпортувати в Aseprite. Проте можливість швидко накидати каміння прямо в Aseprite виглядає дуже ефективно і може стати в пригоді, коли потрібно створити багато фонів у піксель-арті. Мені завжди важко вирішити, як малювати різні текстури каміння, тож новини про такі допоміжні інструменти справді приємні.
Джерело: note (おかか容疑者)
Фестиваль піксель-арту «Pixel Art Park 9 (PAP9)» відбудеться в неділю, 11 жовтня 2026 року, у Pacifico Yokohama. Про учасників цього року розповіли у статті на note, яку написав пан Моріта з ігрової студії Ixeal з району Нерима.
Ixeal бере участь як компанія-спонсор. Вона представить дві абсолютно нові авторські гри, розроблені спеціально для PAP9. У статті описано одну з них, «Magical Soup».
Суть гри — ловити «приховані смаки», щоб зварити суп. Є три види прихованих смаків: «звичайний», «небезпечний» і «магічний», і їхнє поєднання визначає, який суп вийде. Гравець також отримує наліпку того самого типу, що й зварений суп. Гру створила команда, яка зробила «JUST Onigiri», що експонувалася на минулому PAP8.
Друга гра та нові товари з піксель-артом будуть представлені в наступних статтях.
Це схоже на приємну подію для любителів піксель-арту: тут можна пограти й потримати речі в руках. Побачити, як піксель-арт рухається всередині гри, і поспілкуватися з авторами напряму — рідкісна можливість. Якщо живете поруч, варто завітати.
