Niedawno wpadł mi w ręce poradnik pixel artu od Juniper Dev, a oto najważniejsze wnioski z niego, od wyboru programu po zaawansowane kolorowanie, zebrane w notatkach. Dzielę się nimi ze wszystkimi, którzy też chcą zacząć.
Jeśli chodzi o program, polecam Aseprite: interfejs jest przyjazny, a animacje i tilesety zaprojektowano z myślą o tworzeniu gier. Jeśli nie chcesz płacić, darmową alternatywą będzie otwartoźródłowy LibreSprite albo przeglądarkowy Piskel. Co do kolorów, na początku nie warto przejmować się teorią barw: mnie wystarczały gotowe palety z Lospec, a w teorię można wgryzać się stopniowo, gdy nabierze się wprawy. Dla każdego materiału przygotuj co najmniej trzy kolory (bazowy, cień i światło), a uzyskasz podstawowe wrażenie bryły.
Rysując linie, pamiętaj o usuwaniu zbędnych pikseli; włączenie Pixel Perfect w Aseprite sprawia, że wszystko jest dużo czystsze. Przy krzywych utrzymuj symetryczne długości segmentów pikseli (np. 1-2-3-2-1), a linie będą znacznie płynniejsze. Przy kolorowaniu używaj do cieni lub świateł kolorów sąsiadujących na kole barw, a obraz będzie żywszy; unikaj też „cieniowania poduszkowego”: najpierw ustal kierunek źródła światła, a potem oświetlaj wszystko spójnie. Dithering i antyaliasing to dwie bardzo przydatne sztuczki: pierwsza tworzy fakturę przejść, druga wygładza krawędzie.
Kontur nie musi być czysto czarny; spróbuj ciemniejszej wersji koloru samego obiektu. Na koniec rada dla twórców gier: nie mnóż kolorów, bo więcej niż trzy na jeden materiał łatwo robią bałagan; często pomniejszaj podgląd, żeby upewnić się, że po zmniejszeniu wszystko nadal jest czytelne. Najważniejsze to czerpać radość z procesu, bo to ważniejsze niż obsesja na punkcie „idealnego efektu końcowego”.
Pixelblog 62 dotyczy teł krajobrazowych i stawia tezę, z którą się zgadzam: tła nie powinny znajdować się na końcu listy priorytetów produkcji. Ustalają klimat i wciągają gracza w świat, ale muszą też służyć rozgrywce. W platformówkach i shmupach trzeba je czasem przygasić, żeby sprite'y były czytelne, a w turowych RPG mogą być bogate i immersyjne.
W tej lekcji Raymond Schlitter skupia się na scenach walki wymyślonego turowego JRPG, inspirowanego Dragon Quest i Phantasy Star 4, z miejscem na dole dla bohaterów widzianych od tyłu. Wyzwaniem jest przekonujące poczucie głębi przy użyciu 16 kolorów lub mniej.
Wybiera płótno 192x144. Ma proporcje 4:3, mieści się w typowych rozdzielczościach konsol 8- i 16-bitowych i dobrze się dzieli, jeśli później chcemy paralaksę z przewijaniem co do piksela. Proces zaczyna się od pełnych poziomych pasów koloru, które określają horyzont, a potem ziemia i niebo są dzielone na kolejne pasy. Jego kluczowa uwaga: głębia bierze się głównie z wyboru kolorów, zgodnie z perspektywą powietrzną. Najbliższy plan jest najbardziej nasycony i ma najmocniejszy kontrast, a każdy oddalający się plan traci nasycenie, jaśnieje i przesuwa odcień w stronę koloru nieba. Pod czystym błękitnym niebem najbliższa trawa jest najcieplejsza, a dalsze plany dryfują ku błękitowi.
Po planach kolorów dodaje dwie warstwy gór, używając kolorów z pasów nieba, i dopiero potem przechodzi do detali. Trawa składa się z wielu krótkich pionowych kresek o szerokości jednego piksela, a kluczem jest spójność grupowania i skali. Każdy etap pokazuje jako osobny obraz, więc można śledzić w swoim tempie. Pomocna lektura, jeśli palety wychodzą płasko.
Na Habr trafiłem na długi artykuł o tym, jak kostka Rubika stała się materiałem artystycznym, i jest w nim sporo ciekawych rzeczy dla miłośników pixel artu. Autor od kilku lat tworzy mozaiki z kostek i wyjaśnia, dlaczego ten gatunek jest tak bliski grafice cyfrowej.
Główna myśl jest prosta: kolorowy kafelek na ściance kostki to w istocie piksel. Na jednej ściance są dziewięć kwadratów, a paleta ma sześć kolorów, więc kilka kostek razem daje obraz o niskiej rozdzielczości, przypominający ekran starego komputera lub automatu do gier. Zgadza się też chronologia: złoty wiek gier 8-bitowych, takich jak Space Invaders, Pac-Man czy Donkey Kong, przypadł na ten sam czas co moda na kostkę Rubika na początku lat 80. Według autora termin „pixel art” po raz pierwszy użyli w 1982 roku Adele Goldberg i Robert Flegal z Xeroxa.
Dalej artykuł przedstawia historię gatunku. Najwcześniejsze próby przypisuje się brytyjskiemu artyście Fredowi Hollyemu z połowy lat 80. W latach 90. programista Jacob Devenport udokumentował mozaiki z kilkudziesięciu kostek, w tym pierwszą dwustronną. Prawdziwym przełomem był francuski artysta uliczny Invader, który w 2004 roku zbudował swojego kosmicznego najeźdźcę z dziewięciu kostek i nazwał ten styl Rubikcubism. Jego „Mona Lisa” z 330 kostek sprzedała się na aukcji w 2020 roku za 480 200 euro, a w latach 2022–2023 muzeum MIMA w Brukseli pokazało ponad sto jego prac z kostek.
Najbardziej spodobało mi się, jak autor opisuje proces: najpierw schemat pikseli w sześciu kolorach, a przy bardziej złożonych pracach Photoshop do kontroli barw. To ta sama droga, którą idzie każdy twórca pixel artu, tyle że „piksele” są tu plastikowymi kostkami. Dla kogoś, kto pracuje z ograniczoną paletą, to dobra okazja, by spojrzeć na znane techniki pod innym kątem.
Ostatnio przeczytałem obszerny przewodnik na temat programu Aseprite, który szczegółowo opisuje proces tworzenia gier w stylu pixel art. Zanotowałem fragmenty, które okazały się dla mnie najbardziej przydatne, zwłaszcza domyślne ustawienia, które "zmniejszają ryzyko popełnienia błędów".
Płótno: Postacie zaczynają od rozdzielczości 32x32 pikseli, wrogowie, przedmioty i ikony od 16x16 pikseli, a głównego bohatera można powiększyć do 64x64 pikseli w razie potrzeby. Domyślne powiększenie podczas edycji można ustawić na 800%, ale w grze należy zachować renderowanie w proporcji 1:1. Nie daj się zwieść powiększonemu płótnu w edytorze.
Paleta kolorów: Zacznij od palety DB32 dostępnej na stronie Lospec. Po ustaleniu podstawowych kolorów, można ją rozszerzyć do 48-64 kolorów w zależności od potrzeb, ale staraj się ograniczyć liczbę używanych kolorów do 16 w pojedynczej klatce. Paleta kolorów to "opcje", a nie "obowiązkowe kolory", które muszą być użyte. Najlepiej używać jednej, spójnej palety kolorów w całym projekcie i unikać jej zmiany w trakcie rozwoju, ponieważ może to powodować rozbieżności w stylu elementów.
Animacja: Częstotliwość klatek dla stanu spoczynkowego: 8 FPS, dla ataku: 12 FPS, dla specjalnych umiejętności: 24 FPS. W jednym pliku można ustawić różne czasy trwania klatek za pomocą opcji "Frame Duration".
Eksport: Arkusz sprite'ów (sprite sheet) powinien być układany w wiersze, wraz z danymi JSON. Nazwy plików powinny być tworzone przez połączenie nazwy postaci i nazwy akcji, np. "nazwa_bohatera_atak.png" + "nazwa_bohatera_atak.json".
Najczęstszym problemem po zaimportowaniu do silnika jest sposób filtrowania: "Filter Mode" musi być ustawiony na "Point", a nie na "Bilinear". Grafika pikselowa nie wymaga kompresji tekstur. Unity umożliwia bezpośredni import plików .aseprite za pomocą oficjalnego importera Aseprite, co eliminuje konieczność ręcznego eksportu.
Kolejna rada, z którą się zgadzam: Zidentyfikuj czynności, które wykonujesz codziennie więcej niż dziesięć razy i napisz mały skrypt w Lua (około 20-30 linii kodu), aby je zautomatyzować. Dodawaj taki skrypt raz w tygodniu. Z czasem oszczędzisz znacznie więcej czasu, niż mogłoby się wydawać.
Jeden z wiosennych tutoriali Pixelbloga Raymonda Schlittera dotyczy czegoś, co zawsze uważałem za trudne: turowej gry o mechach w stylu Front Mission, rysowanej na siatce izometrycznej. To koncepcja o charakterze edukacyjnym, a nie prawdziwy projekt, i odnosi się do wcześniejszych wpisów o projekcji izometrycznej.
Mechy rysuje się mniej więcej w rozmiarze 32x32 px, czyli mniejszym niż zwykłe 64x64 i większe, więc detale trzeba uprościć do bardzo niewielkiej liczby pikseli. Jego metoda polega na tym, że każda część zaczyna się od prostych figur geometrycznych, a najpierw buduje się korpus. Tułów powinien wysuwać się do przodu jak przednia część czołgu, barki są masywne i ustawione wyżej niż głowa, a głowa pozostaje niska i smukła, z jednym lub dwoma jasnymi pikselami na optykę. Stopy projektuje się pod kątem stabilności, czerpiąc inspirację z pazurów, szczypiec i kopyt, bo zwykłe ludzkie stopy w tym stylu wyglądają niezgrabnie. Paski akcentujące dodaje się na końcu i tylko tam, gdzie wzmacniają kształty.
Szkicuje trzy typy jednostek: piechotę o zaokrąglonych kształtach, artylerię z gigantycznym działem zrośniętym z głową oraz myśliwce z ostrymi trójkątami i nogami o odwróconym zgięciu, każdą z krótką notką taktyczną.
Część dotycząca otoczenia jest równie przydatna. Podstawowy kafelek to sześcian 32x32, którego górny romb ma narożniki po 2 px, a sąsiednie kafelki trzeba nakładać w spójnej kolejności, by tekstury przylegały równo. Kafelki naturalne zaczynają się od kafelka ziemi z różnymi teksturami trawy na wierzchu. Woda ma mniej więcej połowę wysokości zwykłego sześcianu, a jej animacja zapętla się w 16 klatkach: tekstura linii przesuwa się o 1 px w dół w każdej klatce, a refleksy na przemian zmieniają się.
Moja ulubiona myśl to przypomnienie, że powtarzane kafelki muszą dobrze wyglądać, gdy są powtórzone na całej mapie, dlatego warto samemu przetestować nakładanie warstw.
Najnowszy Pixelblog Raymonda Schlittera na SLYNYRD to studium 8-bitowych platformówek ninja i dobra lektura dla każdego, kto lubi zobaczyć, jak cały zestaw zasobów gry powstaje wokół jednego pomysłu. Otwarcie czerpie inspirację z Ninja Gaiden i przez cały czas pracuje z paletą NES, choć nie trzyma się ściśle ograniczeń sprzętu.
Na początku jest postać gracza. Zaczyna od prostego manekina, żeby animacje były ustalone, zanim pojawi się jakikolwiek detal projektowy. Jaskrawoczerwony kostium wybrano dla efektu, nawet jeśli nie jest zbyt dyskretny. Zestaw ruchów wzoruje się na Ryu Hayabusie: szybki bieg, wspinanie się po ścianach, zwisanie z sufitu, skok z przewrotem i cięcie w powietrzu. Podobało mi się rozumowanie, że postać zatrzymuje się, gdy atakuje na ziemi. To wymusza precyzję w starciach, zamiast pozwalać wciskać cios w biegu.
Potem wrogowie: helikopterowa wieżyczka, która przesuwa działo o 180 stopni w pięciu kierunkach, pajęczy czołg przyklejający się do ścian i sufitów oraz powolna cyber-goryl, która pełni rolę gąbki na obrażenia. Przy goryli korzystał z materiałów o chodzeniu na kostkach, najpierw szkicował proste kształty ciała, żeby dobrze złapać ruch, i dopiero potem dodawał elementy robotyczne. Połączenie głowy i tułowia w jeden element daje celowo sztywny efekt.
Najbardziej przydatna była dla mnie część o otoczeniu. Używa kafelków 16x16 w sześciu warstwach, z których każda przewija się z własną prędkością, co daje parallax, oraz rzutu szafkowego, w którym linie głębi mają około 67,5 stopnia: dwa piksele w górę na każdy piksel w bok, dzięki czemu schodki wychodzą czysto. Wynik pokazano na makiecie 320x180.
Jeszcze jedna rzecz: to pierwszy Pixelblog, w którym jeden z mini-poradników, pełny rozkład klatek ninja, znajduje się za płatnym dostępem na Patreonie, podczas gdy główna lekcja pozostaje darmowa. Zasoby i pliki źródłowe sprzedawane są jako osobny pakiet. Chciałbym zobaczyć, jak ktoś wrzuca te sprite'y do prawdziwego kontrolera gracza.
Habr opublikował tłumaczenie długiego artykułu Karla Svenssona o tym, jak lampy kineskopowe (CRT) wpłynęły na pixel art. Temat budzi spory, a mnie spodobało się, że autor nie zgadza się z prostym wyjaśnieniem, że „kineskopy wszystko rozmywały”.
Zaczyna od popularnego filmu na TikToku, w którym twierdzi się, że dawni artyści uwzględniali rozmycie kineskopów, dzięki któremu surowe krawędzie pikseli wydawały się łagodniejsze. Svensson przyznaje, że jest to częściowo prawda, i zgadza się, że nowoczesny pixel art w blokowym stylu często przeradza się w nieprecyzyjną nostalgię. Zwraca jednak uwagę, że stary sprzęt ma znacznie więcej aspektów do rozważenia. Sam regularnie korzysta z dawnych kineskopów, dlatego wyłącza programowe filtry CRT w emulatorach, uważając, że żaden z nich nie oddaje wiernie prawdziwego ekranu. Zdjęcie Commodore 64 na monitorze Commodore 1084S pokazuje, że nierówne krawędzie pikseli są widoczne także na kineskopie.
Następnie porównuje dwie gry na C64. Maniac Mansion (1987) działa w rozdzielczości 160×200 i wygląda kanciasto, natomiast Mayhem in Monsterland (1993) przy tej samej stałej palecie 16 kolorów stosuje dithering i wygładzanie, by naśladować wyższą rozdzielczość i głębię kolorów. Te techniki opierają się na właściwościach kineskopu: lekkim rozmyciu, liniach skanowania i niewielkim przenikaniu kolorów.
Złotą erą pixel artu autor uważa epokę 16-bitową: Amigę 500, SNES, Atari ST i Mega Drive. Amiga potrafiła wyświetlić 32 kolory z palety 4096, a grafika w grach takich jak Silkworm czy Ruff'n'Tumble stopniowo się poprawiała. Omawia też sztuczki z kolorami CGA i wyjaśnia, że na ekranach VGA o drobnym skoku punktów pojedyncze piksele są znacznie lepiej widoczne.
Dla mnie artykuł był dobrym przypomnieniem: zanim doda się „retro rozmycie”, warto zrozumieć, pod jaki ekran oryginał był rysowany.
W Pixelblogu 63 Raymond Schlitter przechodzi do poziomej strzelanki i buduje zestaw zasobów wokół samolotów z II wojny światowej walczących nad naturalnym krajobrazem. Po wcześniejszych tekstach o pionowych shmupach to jego pierwsze podejście do gatunku poziomego, w którym wzory pocisków przecinają ekran zamiast spadać z góry.
Zaczyna od samolotu gracza, bo ten wyznacza ton i rozdzielczość dla wszystkiego innego. Przy około 48x32 pikselach jest miejsce na detale, a animacja nie staje się zbyt kosztowna. Maszyna wzorowana jest na P-51 Mustang. Ciekawe jest to, że przy ruchu w pionie animuje przechył (roll), a nie pochylenie (pitch). Dziób pozostaje w poziomie, więc pociski zawsze lecą prosto, a obrót przy tak niskiej rozdzielczości zwykle daje zaszumione skupiska pikseli. Krótko mówiąc, przechył utrzymuje sprite'a w czystości i dobrze wygląda.
Animacja ma pięć orientacji: jedną klatkę neutralną, po dwie pozycje przechyłu w górę i w dół oraz nieustannie kręcące się śmigło. Podaje też zasadę projektową dotyczącą odczucia z gry: krótkie dotknięcie pokazuje tylko pierwszy stopień przechyłu, przytrzymanie pełne przechylenie, a puszczenie przechodzi przez płytką pozę z powrotem do neutralnej. W gatunku opartym na precyzyjnych reakcjach odradza dodawanie bezwładności do ruchu.
Omówione są też opcje, czyli małe moduły krążące wokół statku. Poza funkcją w grze, jak twierdzi, dodają obecności na ekranie i pomagają poczuć, gdzie jest twój statek, gdy oczy śledzą tory pocisków.
Wrogami są niemieckie samoloty i działo samobieżne Hummel. Jego proces zaczyna się od szablonu z kilkoma kolorami blokowymi, potem prawdziwe kolory i podstawowe detale, następnie światło i drobne detale, a na końcu obrys. Zamiana palety pozwala użyć tej samej animacji śmigła w wielu samolotach, a on radzi wydawać dodatkowe klatki tylko tam, gdzie zachowanie je uzasadnia. Praktyczna lekcja oszczędności.
Zespół Aseprite ogłosił 22 lipca 2026 roku, że v1.3.18 to nowa stabilna wersja. Zawiera poprawki błędów i awarii oraz nowe funkcje wprowadzone od v1.3.18-beta1; można ją pobrać z konta na aseprite.org.
Najważniejsze zmiany w wydaniu podstawowym to nowe oddzielanie tagów w grupach na osi czasu oraz nowa opcja „rozmiar arkusza będący potęgą dwójki” przy eksporcie arkuszy sprite'ów. Są też poprawki kopiowania danych użytkownika (kolor i tekst) tagów i slice'ów przy duplikowaniu sprite'a oraz kilku awarii, na przykład przy usuwaniu wklejonego zaznaczenia lub ukrywaniu warstwy podczas przesuwania pikseli.
Kolejne wydania punktowe są ważne dla osób pracujących z kafelkami. v1.3.18.4 naprawił wyrównanie funkcji Przyciągaj do siatki dla pędzli większych niż jeden piksel i ulepszył kopiowanie oraz wklejanie kafelków między warstwami tilemap. Późniejsze buildy naprawiły awarię przy wklejaniu tilemap oraz awarię po eksporcie arkusza sprite'ów, gdy sprite miał zaznaczenie. Eksporty animowanych GIF-ów używają teraz poprawnego nagłówka 89a, a pliki PNG w skali szarości wczytują się z szarą paletą.
Nowości są też dla twórców skryptów: wersja API Lua wzrosła do 41, dodano Dialog:samerow{} oraz nowe zdarzenia zapisu sprite'a (save i beforesave).
Lubię takie informacje o wydaniu, bo pokazują, gdzie w codziennej pracy pojawiają się tarcia: siatki, tilemapy i eksporty. Jeśli odkładałeś aktualizację przez błąd kopiowania kafelków, ta wersja wygląda na tę, którą warto wypróbować.
Kiedy zaczynasz rysować postacie w pixel arcie, prędzej czy później trafiasz na pojęcie „arkusz sprite'ów” (sprite sheet). Dzielę się wprowadzeniem dla początkujących napisanym przez Keitaro na note: krok po kroku tłumaczy, jak to działa, i uznałem je za bardzo pomocne.
Sprite to dwuwymiarowy obraz wyświetlany na ekranie gry. Postacie, wrogowie, przedmioty, pociski i efekty należą do tej kategorii, a arkusz sprite'ów to zbiór tych obrazów w jednym dużym pliku. Przy animacji chodzenia pokazuje się kolejno klatkę z prawą nogą z przodu, klatkę z nogami złączonymi i klatkę z lewą nogą z przodu, szybko je przełączając, żeby wyglądało to jak chód. Ruch powstaje więc z przełączania nieruchomych obrazów, a nie z wideo.
Gra nie wyświetla całego dużego obrazu. Wycina za pomocą współrzędnych tylko potrzebną klatkę. Na przykład jeśli każda klatka ma 128×128 px i stoi ich osiem obok siebie, obszar wyświetlania przesuwa się od 0–127 px do 128–255 px itd. Artykuł podaje też przykład, w którym oś pozioma to 8 kierunków, a pionowa to czynności (chodzenie, atak, otrzymanie obrażeń, obrona), czyli 8 kierunków × 7 stanów, łącznie 56 klatek.
Przy praktycznym użyciu, jak zaznaczono w artykule, najważniejsze jest wyrównanie punktu odniesienia w każdej klatce. Jeśli stopy przesuwają się o kilka pikseli między klatkami, postać podczas animacji wydaje się drgać w górę i w dół. Przezroczyste tło jest również konieczne.
Na koniec wyjaśniono różnicę między arkuszem sprite'ów, czyli po prostu zbiorem powiązanych obrazów, a atlasem sprite'ów, który pakuje kilka obrazów w jedną teksturę dla wydajniejszego renderowania. Najbardziej zapadło mi w pamięć podsumowanie, że tworzenie obrazów jest mniej trudne niż nadanie im formy, którą gra może poprawnie wykorzystać. Myślę, że to pomoże również twórcom pixel artu, zwłaszcza na etapie eksportu.
W tłach pixel artu skały są drobnym, ale zaskakująco czasochłonnym elementem. W piątkowym przeglądzie wiadomości o pixel arcie autor note おかか容疑者 przedstawił rozszerzenie do Aseprite „Rock Generator for Aseprite”.
Rozszerzenie jest opublikowane na itch.io. To narzędzie produkcyjne przeznaczone wyłącznie do skał: wczytuje skały jako siatki 3D i pozwala używać ich jako pixel artu. Już sama strona pobierania pokazuje mnóstwo parametrów, a autor artykułu uważa, że właśnie ograniczenie się do skał pozwala na tak precyzyjne dostrajanie.
Jak podaje artykuł, w zestawie jest 10 gotowych kształtów, 21 gotowych struktur i 72 looki (wyglądy). Można nimi tworzyć także skały pokryte mchem i ośnieżone, więc wydaje się to wygodne przy budowaniu teł. Interfejs obsługuje 27 języków, w tym japoński.
Jest to narzędzie płatne, od 4,99 dolarów amerykańskich (około 800 jenów) według stanu z października 2026 roku. Na dole strony jest wersja próbna, ale według artykułu zawiera ona tylko przykładowe obrazy wyników. Jeśli chcesz to sprawdzić przed zakupem, warto o tym pamiętać.
Modele skał można było już wcześniej przygotować w Blenderze lub innym programie i zaimportować do Aseprite. Mimo to możliwość szybkiego naszkicowania skał bezpośrednio w Aseprite wydaje się bardzo wydajna i może się przydać, gdy trzeba przygotować wiele teł w pixel arcie. Zawsze mam kłopot z tym, jak malować różne faktury kamienia, więc wiadomości o takich pomocniczych narzędziach naprawdę mnie cieszą.
Festiwal pixel artu „Pixel Art Park 9 (PAP9)” odbędzie się w niedzielę 11 października 2026 roku w Pacifico Yokohama. Wystawy tegorocznej edycji zostały przedstawione w artykule na note autorstwa pana Mority z firmy tworzącej gry Ixeal z dzielnicy Nerima.
Ixeal bierze udział jako firma sponsorująca. Zaprezentuje dwie zupełnie nowe, autorskie gry stworzone z myślą o PAP9. Artykuł przedstawia jedną z nich: „Magical Soup”.
Chodzi o łapanie „ukrytych smaków”, żeby ugotować zupę. Są trzy rodzaje ukrytych smaków: „normalny”, „niebezpieczny” i „magiczny”, a ich kombinacja decyduje o tym, jaką zupę można przygotować. Gracz dostaje też naklejkę tego samego typu co ugotowana zupa. Grę stworzyła ekipa, która przygotowała „JUST Onigiri”, wystawiane na poprzednim PAP8.
Drugą grę i nowe gadżety z pixel artem zaprezentujemy w kolejnych artykułach.
Brzmi jak fajne wydarzenie dla miłośników pixel artu, z grami do ograna i rzeczami do potrzymania w ręku. Zobaczyć, jak pixel art porusza się w grze, i porozmawiać bezpośrednio z twórcami to rzadka okazja. Jeśli mieszkasz w pobliżu, warto wpaść.
