Ich habe vor Kurzem den Pixel-Art-Guide von Juniper Dev gelesen und die wichtigsten Punkte – von der Softwarewahl bis zur fortgeschrittenen Kolorierung – in Notizen zusammengefasst, die ich mit allen teilen möchte, die ebenfalls einsteigen wollen.
Als Software empfehle ich Aseprite: Die Oberfläche ist einsteigerfreundlich, und die Animations- und Tileset-Funktionen sind auf Spieleentwicklung ausgelegt. Wer nichts bezahlen möchte, kann das Open-Source-Programm LibreSprite oder die Browserversion Piskel als kostenlose Alternative nutzen. Bei den Farben habe ich mich anfangs nicht mit Farbtheorie aufgehalten, sondern direkt fertige Paletten von Lospec verwendet und mich erst nach und nach, als ich mehr gezeichnet hatte, damit beschäftigt. Wenn man für jedes Material mindestens drei Farben bereithält – Grundfarbe, Schatten und Glanzlicht –, erzielt man schon eine grundlegende Räumlichkeit.
Denk beim Zeichnen von Linien daran, überflüssige Pixel zu entfernen; mit aktiviertem Pixel Perfect in Aseprite wird es viel sauberer. Bei Kurven sollten die Längen der Pixelsegmente symmetrisch sein (z. B. 1-2-3-2-1), dann wirken die Linien deutlich flüssiger. Beim Kolorieren lassen benachbarte Farben auf dem Farbkreis Schatten und Glanzlichter lebendiger wirken; vermeide außerdem „Pillow Shading“, indem du zuerst die Richtung der Lichtquelle festlegst und dann einheitlich beleuchtest. Dithering und Anti-Aliasing sind zwei sehr praktische kleine Techniken: Das eine erzeugt weiche Übergänge, das andere glättet die Kanten.
Konturlinien müssen nicht reines Schwarz sein – probier eine dunklere Version der Objektfarbe aus. Zum Schluss ein Tipp für Entwickler: Häufe nicht zu viele Farben an, mehr als drei pro Material wirken schnell unruhig; zoome oft heraus, um zu prüfen, ob alles auch verkleinert noch klar erkennbar ist. Am wichtigsten ist, den Prozess zu genießen – das zählt viel mehr, als sich über ein „perfektes Endergebnis“ den Kopf zu zerbrechen.
Pixelblog 62 befasst sich mit Landschaftshintergründen und vertritt einen Punkt, dem ich zustimme: Hintergründe sollten in der Produktionsreihenfolge nicht ganz hinten stehen. Sie schaffen das Setting und ziehen die Spieler in die Welt, müssen aber auch das Gameplay unterstützen. In Plattformern und Shmups müssen sie oft zurückgenommen werden, damit die Sprites gut lesbar bleiben, während sie in rundenbasierten RPGs reich und immersiv sein können.
Für diese Lektion konzentriert sich Raymond Schlitter auf die Kampfszenen eines fiktiven rundenbasierten JRPGs, inspiriert von Dragon Quest und Phantasy Star 4, mit Platz unten für Helden von hinten. Die Aufgabe lautet, mit 16 Farben oder weniger einen überzeugenden Tiefeneindruck zu erzeugen.
Er wählt eine Leinwand von 192x144. Sie hat ein 4:3-Format, passt in gängige 8- und 16-Bit-Konsolenauflösungen und lässt sich gut teilen, falls später pixelgenaues Parallax-Scrolling dazukommt. Der Prozess beginnt mit massiven waagerechten Farbbändern, die den Horizont festlegen, danach werden Boden und Himmel in weitere Bänder unterteilt. Sein zentraler Punkt: Tiefe entsteht vor allem durch die Farbwahl und folgt der Luftperspektive. Die nächste Ebene ist am gesättigtesten und hat den stärksten Kontrast, jede zurückweichende Ebene verliert Sättigung, wird heller und verschiebt ihren Farbton in Richtung Himmelsfarbe. Unter klarem blauen Himmel ist das nächste Gras am wärmsten, die fernen Ebenen wandern ins Blaue.
Nach den Farbebenen fügt er zwei Bergschichten hinzu, die Farben aus den Himmelsbändern wiederverwenden, und geht dann ins Detail. Das Gras besteht aus vielen kurzen, einpixeligen senkrechten Strichen, entscheidend ist die Konsistenz in Gruppierung und Maßstab. Jeden Schritt zeigt er als eigenes Bild, sodass man in seinem Tempo folgen kann. Ein hilfreicher Text, wenn Paletten flach wirken.
Auf Habr bin ich auf einen langen Artikel gestoßen, der beschreibt, wie der Zauberwürfel zum künstlerischen Material wurde. Für alle, die Pixel-Art mögen, steckt darin viel Interessantes. Der Autor baut seit einigen Jahren Mosaike aus Würfeln und erklärt, warum dieses Genre der digitalen Grafik so nahesteht.
Der Kerngedanke ist einfach: Eine farbige Kachel auf der Seite eines Würfels ist im Grunde ein Pixel. Jede Seite hat neun Felder, die Palette umfasst sechs Farben, und mehrere Würfel ergeben zusammen ein Bild in niedriger Auflösung, das an den Bildschirm eines alten Computers oder Spielautomaten erinnert. Auch der Zeitpunkt passt: Die goldene Ära der 8-Bit-Spiele wie Space Invaders, Pac-Man oder Donkey Kong fiel mit dem Zauberwürfel-Boom Anfang der 1980er Jahre zusammen. Laut dem Autor wurde der Begriff »Pixel-Art« 1982 erstmals von Adele Goldberg und Robert Flegal bei Xerox verwendet.
Der Artikel zeichnet dann die Geschichte des Genres nach. Die frühesten Versuche gehen auf den britischen Künstler Fred Holly Mitte der 1980er Jahre zurück. In den 1990ern dokumentierte der Programmierer Jacob Devenport Mosaike aus einigen Dutzend Würfeln, darunter das erste zweiseitige. Den eigentlichen Durchbruch brachte der französische Streetart-Künstler Invader, der 2004 seine Weltraum-Invasoren aus neun Würfeln baute und den Stil Rubikcubism nannte. Seine »Mona Lisa« aus 330 Würfeln wurde 2020 bei einer Auktion für 480.200 Euro verkauft, und 2022 bis 2023 zeigte das Brüsseler MIMA-Museum über hundert seiner Würfelarbeiten.
Besonders gefallen hat mir, wie der Autor den Prozess beschreibt: zuerst eine Pixelskizze mit sechs Farben, bei komplexeren Arbeiten dann Photoshop zur Farbkontrolle. Das ist derselbe Weg, den jeder Pixel-Künstler geht, nur dass die »Pixel« hier Plastikwürfel sind. Für alle, die mit einer begrenzten Palette arbeiten, ist das ein guter Anlass, vertraute Techniken aus einem neuen Blickwinkel zu betrachten.
Ich habe kürzlich einen sehr ausführlichen Leitfaden zu Aseprite gelesen, der den Arbeitsablauf für pixelbasierte Spiele sehr detailliert beschreibt. Ich habe die Teile notiert, die für mich am nützlichsten waren, insbesondere die "Standardkonfiguration", die dazu dient, Fehler zu vermeiden.
Leinwand: Charaktere beginnen mit 32x32 Pixeln, Feinde, Gegenstände und Icons mit 16x16 Pixeln. Der Hauptcharakter kann bei Bedarf auf 64x64 Pixel vergrößert werden. Beim Bearbeiten kann die Standard-Zoomstufe auf 800 % eingestellt werden, aber im Spiel sollte die Darstellung 1:1 sein. Lassen Sie sich nicht von der vergrößerten Leinwand im Editor täuschen.
Farbpalette: Beginnen Sie mit der DB32-Palette von Lospec. Legen Sie die Hauptfarben fest und erweitern Sie die Palette bei Bedarf auf 48–64 Farben. Versuchen Sie jedoch, die Anzahl der tatsächlich verwendeten Farben pro Frame auf maximal 16 zu beschränken. Die Farbpalette ist eine "Auswahl von Farben", keine "Liste von Farben, die unbedingt verwendet werden müssen". Es ist am besten, für das gesamte Projekt eine einzige Hauptfarbpalette zu verwenden und diese während der Entwicklung nicht grundlegend zu ändern, da dies zu Stilunterschieden bei älteren Assets führen kann.
Animation: Leerlaufanimation: 8 Bilder pro Sekunde (FPS), Angriff: 12 FPS, Spezialfähigkeiten: 24 FPS. Innerhalb derselben Datei können Sie mit der "Frame Duration" unterschiedliche Zeitspannen für einzelne Frames festlegen.
Export: Sprite Sheets werden zeilenweise angeordnet und mit JSON-Hash-Daten versehen. Die Dateinamen werden als "Charaktername_Aktion" verwendet und mit PNG- und JSON-Dateien gepaart.
Das häufigste Problem beim Import in die Spiel-Engine ist die Filterung: Verwenden Sie unbedingt den "Point"-Filter und nicht den "Bilinear"-Filter. Pixelgrafiken benötigen auch keine Texturkomprimierung. Unity kann die .aseprite-Datei direkt mit dem offiziellen Aseprite Importer importieren, wodurch der manuelle Exportschritt entfällt.
Ein weiterer Ratschlag, dem ich zustimme: Identifizieren Sie Aufgaben, die Sie täglich mehr als zehn Mal ausführen, und schreiben Sie ein kleines Skript mit etwa 20–30 Zeilen Lua, um diese zu automatisieren. Fügen Sie jede Woche ein solches Skript hinzu. Im Laufe von Monaten sparen Sie viel mehr Zeit, als Sie vielleicht denken.
Eines von Raymond Schlitters Pixelblog-Tutorials aus diesem Frühjahr behandelt etwas, das ich immer schwierig fand: ein rundenbasiertes Mech-Spiel im Stil von Front Mission, gezeichnet auf einem isometrischen Raster. Es handelt sich um ein Lernkonzept, nicht um ein echtes Projekt, und es verweist auf seine früheren Beiträge zur isometrischen Projektion.
Die Mechs werden etwa 32x32 Pixel groß gezeichnet, kleiner als seine üblichen 64x64 und mehr, weshalb Details auf sehr wenige Pixel reduziert werden müssen. Seine Methode: Jeder Teil beginnt als einfache geometrische Form, und zuerst wird der Körper aufgebaut. Der Torso sollte nach vorne ragen wie die Front eines Panzers, die Schultern sind wuchtig und sitzen höher als der Kopf, und der Kopf bleibt niedrig und schlank, mit nur ein oder zwei hellen Pixeln für die Optik. Die Füße werden auf Stabilität ausgelegt und orientieren sich an Krallen, Scheren und Hufen, denn normale menschenähnliche Füße wirken in diesem Stil unbeholfen. Akzentstreifen kommen zuletzt und nur dort, wo sie die Formen stärken.
Er skizziert drei Einheitentypen: Infanterie mit runden Formen, Artillerie mit einer riesigen Kanone, die mit dem Kopf verschmolzen ist, und Jäger mit scharfen Dreiecken und rückwärts gelenkten Beinen, jeweils mit einer kurzen taktischen Notiz.
Auch der Umgebungsteil ist sehr nützlich. Die Basiskachel ist ein 32x32-Würfel, dessen obere Raute 2 px lange Ecken hat, und benachbarte Kacheln müssen in einer konsistenten Reihenfolge überlagert werden, damit die Texturen bündig sitzen. Naturkacheln beginnen mit einer Erdkachel, auf die verschiedene Grastexturen kommen. Wasser liegt bei etwa der halben Höhe eines normalen Würfels, und seine Animation läuft in 16 Frames, indem eine Linientextur pro Frame um 1 px nach unten verschoben und die Glanzlichter abwechselnd gesetzt werden.
Mein Lieblingssatz ist die Erinnerung, dass sich wiederholende Kacheln auch über eine ganze Karte gut aussehen müssen. Es lohnt sich also, die Schichtung selbst auszuprobieren.
Raymond Schlitters neuester Pixelblog auf SLYNYRD ist eine Studie über 8-Bit-Ninja-Plattformer und eine gute Lektüre für alle, die gerne sehen, wie ein ganzes Set an Spielassets um eine einzige Idee herum entsteht. Er nimmt sich offen Ninja Gaiden zum Vorbild und arbeitet durchgehend mit der NES-Palette, hält sich dabei aber nicht streng an die Hardware-Grenzen.
Zuerst kommt der Spielercharakter. Er beginnt mit einer einfachen Dummy-Vorlage, damit die Animationen stehen, bevor irgendein Designdetail hinzukommt. Der knallrote Anzug wurde wegen des Aha-Effekts gewählt, auch wenn er nicht gerade unauffällig ist. Das Bewegungsrepertoire orientiert sich an Ryu Hayabusa: schnelles Laufen, Wandklettern, Hängen an Decken, ein Flip-Sprung und ein Luftschlag. Mir hat die Begründung gefallen, dass die Figur beim Angriff am Boden stehen bleibt. Dadurch sind Begegnungen präziser, statt dass man im Laufen wild auf den Schlagknopf drückt.
Dann folgen die Gegner: ein Heli-Geschütz, dessen Kanone in fünf Richtungen über 180 Grad schwenkt, ein Spinnenpanzer, der an Wänden und Decken klebt, und ein langsamer Cyber-Gorilla, der als Schadensschwamm dient. Für den Gorilla arbeitete er mit Referenzen zum Knöchelgang, skizzierte einfache Körperformen, um die Bewegung richtig zu treffen, und fügte erst danach die robotischen Details hinzu. Kopf und Körper als ein Teil zu verschmelzen, verleiht ihm eine bewusste Steifheit.
Der Umgebungsteil war für mich der nützlichste. Er verwendet 16x16-Kacheln in sechs Ebenen, die sich jeweils mit eigener Geschwindigkeit verschieben, um den Parallax-Effekt zu erzeugen. Dazu kommt eine Kabinettprojektion, bei der die Tiefenlinien etwa 67,5 Grad betragen und für jeden Pixel nach rechts zwei nach oben laufen, sodass die Stufen sauber aufgehen. Das Ergebnis zeigt er in einem 320x180-Mockup.
Noch etwas Wissenswertes: Dies ist der erste Pixelblog, bei dem eines der Mini-Tutorials, die komplette Frame-Aufschlüsselung des Ninjas, hinter einer Patreon-Bezahlschranke liegt, während die Hauptlektion kostenlos bleibt. Die Assets und Quelldateien werden als separates Paket verkauft. Ich würde gern sehen, wie jemand diese Sprites in einen echten Spielercontroller einbaut.
Auf Habr ist eine Übersetzung eines langen Artikels von Karl Svensson erschienen, in dem es darum geht, wie Kathodenstrahlröhren (CRT) die Pixelkunst beeinflusst haben. Das Thema ist umstritten, und mir gefällt, dass der Autor der einfachen Erklärung widerspricht, CRTs hätten „alles verwischt“.
Er beginnt mit einem beliebten TikTok-Video, in dem behauptet wird, frühere Künstler hätten die Unschärfe der CRTs einkalkuliert, die grobe Pixelkanten weicher wirken ließ. Svensson gibt zu, dass das teilweise stimmt, und stimmt auch zu, dass moderne Blockpixelkunst oft zu ungenauer Nostalgie wird. Er weist aber darauf hin, dass alte Hardware viel mehr Aspekte hat. Er benutzt selbst regelmäßig alte CRTs und schaltet deshalb die Software-CRT-Filter in Emulatoren ab, weil keiner davon ein echtes Bildschirmbild zuverlässig nachbildet. Ein Foto eines Commodore 64 auf einem Commodore-1084S-Monitor zeigt, dass ungleichmäßige Pixelkanten auch auf einem CRT sichtbar sind.
Anschließend vergleicht er zwei C64-Spiele. Maniac Mansion (1987) läuft mit 160×200 und wirkt eckig, während Mayhem in Monsterland (1993) mit derselben festen 16-Farben-Palette Dithering und Glättung einsetzt, um eine höhere Auflösung und Farbtiefe zu imitieren. Diese Techniken beruhen auf Eigenschaften des CRT: leichter Unschärfe, Zeilenstrukturen und einem geringen Farbübersprechen.
Das goldene Zeitalter der Pixelkunst sieht der Autor in der 16-Bit-Ära: Amiga 500, SNES, Atari ST und Mega Drive. Der Amiga konnte 32 Farben aus 4096 darstellen, und die Grafik in Spielen wie Silkworm oder Ruff'n'Tumble wurde nach und nach besser. Außerdem behandelt er Farbtricks des CGA und erklärt, dass einzelne Pixel auf VGA-Bildschirmen mit feinem Punktabstand deutlich besser zu sehen sind.
Für mich war der Artikel eine gute Erinnerung: Bevor man einen „Retro-Unschärfe“-Effekt hinzufügt, lohnt es sich zu verstehen, für welchen Bildschirm das Original gezeichnet wurde.
In Pixelblog 63 wendet sich Raymond Schlitter dem horizontalen Shoot 'em up zu und baut ein Set an Assets rund um Flugzeuge des Zweiten Weltkriegs, die über einer natürlichen Landschaft kämpfen. Nach früheren Beiträgen zu vertikalen Shmups ist dies sein erster Zugriff auf die horizontale Variante, bei der Projektilmuster quer über den Bildschirm laufen statt nach unten.
Er beginnt mit dem Spielerflugzeug, weil es Stil und Auflösung für alles Weitere vorgibt. Bei etwa 48x32 Pixeln bleibt Raum für Details, ohne dass die Animation zu aufwendig wird. Das Flugzeug ist dem P-51 Mustang nachempfunden. Interessant fand ich, dass er bei vertikaler Bewegung die Rollbewegung statt der Nickbewegung animiert. Die Nase bleibt waagerecht, damit die Schüsse immer geradeaus fliegen, und eine Drehung bei so niedriger Auflösung führt ohnehin oft zu verrauschten Pixelhaufen. Kurz gesagt: Rollen hält den Sprite sauber und sieht gut aus.
Die Animation umfasst fünf Ausrichtungen: ein neutraler Frame, je zwei Rollstufen nach oben und unten sowie ein ständig drehender Propeller. Außerdem gibt er eine Designregel für das Spielgefühl vor: Ein kurzer Tipp zeigt nur die erste Rollstufe, Halten zeigt die volle Schräglage, und beim Loslassen geht es über die flache Haltung zurück in die Neutralposition. In einem Genre, das auf präzise Reaktionen setzt, rät er davon ab, der Bewegung Trägheit zu geben.
Auch die Optionen werden behandelt, die kleinen Module, die um das Schiff kreisen. Abgesehen von ihrer Spielfunktion, so argumentiert er, schaffen sie Präsenz auf dem Bildschirm und helfen dabei, die eigene Position zu spüren, während das Auge den Geschossbahnen folgt.
Die Gegner sind deutsche Flugzeuge und ein Artilleriefahrzeug Hummel. Sein Ablauf: zuerst eine Vorlage aus wenigen Blockfarben, dann echte Farben und Grunddetails, danach Licht und Feindetails und zum Schluss die Umrandung. Durch einen Palettenwechsel lässt sich die Propelleranimation über mehrere Flugzeuge hinweg wiederverwenden, und er rät, zusätzliche Frames nur dort einzusetzen, wo das Verhalten es rechtfertigt. Eine praktische Lektion in Sparsamkeit.
Das Aseprite-Team hat am 22. Juli 2026 angekündigt, dass v1.3.18 die neue stabile Version ist. Sie enthält Fehler- und Absturzkorrekturen sowie die neuen Funktionen, die seit v1.3.18-beta1 hinzugekommen sind, und kann über das Konto auf aseprite.org heruntergeladen werden.
Die wichtigsten Änderungen der Hauptversion sind eine neue Trennung von Tags innerhalb von Gruppen in der Zeitleiste und eine neue Option „Sheet-Größe als Zweierpotenz“ für den Export von Sprite-Sheets. Außerdem wurden Fehler beim Kopieren von Benutzerdaten (Farbe und Text) von Tags und Slices beim Duplizieren eines Sprites behoben, ebenso mehrere Abstürze, etwa beim Löschen einer eingefügten Auswahl oder beim Ausblenden einer Ebene während des Verschiebens von Pixeln.
Die anschließenden Point-Releases sind für alle wichtig, die mit Tiles arbeiten. v1.3.18.4 korrigierte das Einrasten am Raster (Snap to Grid) für Pinsel, die größer als ein Pixel sind, und verbesserte das Kopieren und Einfügen von Tiles zwischen Tilemap-Ebenen. Spätere Builds beheben einen Absturz beim Einfügen von Tilemaps und einen Absturz nach dem Export eines Sprite-Sheets, wenn das Sprite eine Auswahl hatte. Animierte GIF-Exporte verwenden jetzt den korrekten 89a-Header, und Graustufen-PNGs werden mit einer Graustufenpalette geladen.
Auch für Scripting gibt es Neuigkeiten: Die Lua-API-Version ist auf 41 gestiegen, mit Dialog:samerow{} sowie neuen Sprite-Ereignissen zum Speichern (save und beforesave).
Solche Release-Notes mag ich, weil sie zeigen, wo im Alltag die Reibungspunkte liegen: Raster, Tilemaps und Exporte. Wer wegen eines Tile-Kopierfehlers mit dem Update gezögert hat, sollte diese Version wohl ausprobieren.
Wer Figuren im Pixelstil zeichnet, stößt früher oder später auf den Begriff „Spritesheet“. Ich stelle eine Einsteiger-Erklärung von Keitaro auf note vor, die die Funktionsweise Schritt für Schritt aufschlüsselt und mir sehr hilfreich erschien.
Ein Sprite ist ein 2D-Bild, das auf dem Spielbildschirm angezeigt wird. Figuren, Gegner, Gegenstände, Geschosse und Effekte gehören dazu, und ein Spritesheet entsteht, wenn man sie in einem großen Bild zusammenfasst. Bei einer Laufanimation zeigt man nacheinander ein Bild mit dem rechten Fuß vorn, eines mit beiden Füßen nebeneinander und eines mit dem linken Fuß vorn, und wechselt schnell, damit es wie Gehen aussieht. Die Bewegung entsteht also durch den Wechsel von Standbildern, nicht durch ein Video.
Das Spiel zeigt das große Bild nicht als Ganzes an. Es schneidet über Koordinaten nur den benötigten Ausschnitt heraus. Ist ein Frame etwa 128×128 px groß und stehen acht nebeneinander, wandert der Anzeigebereich über 0–127 px, dann 128–255 px usw. Der Artikel nennt außerdem ein Beispiel, bei dem die Waagerechte 8 Richtungen und die Senkrechte Aktionen (Gehen, Angriff, Treffer, Verteidigung) darstellt, also 8 Richtungen × 7 Zustände, insgesamt 56 Frames.
Beim praktischen Einsatz kommt es laut Artikel vor allem darauf an, die Bezugsposition in jedem Frame gleich zu halten. Wandern die Füße von Bild zu Bild um einige Pixel, wirkt die Figur während der Animation wie ein Zittern auf und ab. Ein transparenter Hintergrund ist ebenfalls unverzichtbar.
Zuletzt wird der Unterschied zwischen einem Spritesheet, also einfach einer Sammlung zusammengehöriger Bilder, und einem Sprite-Atlas erklärt, der mehrere Bilder für eine effizientere Darstellung in eine einzige Textur packt. Besonders hängen geblieben ist mir die Zusammenfassung: Die Bilder zu malen ist weniger schwierig, als sie in eine Form zu bringen, die das Spiel richtig verwenden kann. Ich denke, das hilft auch Pixelartisten, gerade beim Export.
Im Pixelart-Hintergrund sind Felsen eine unscheinbare, aber ziemlich aufwendige Sache. Der note-Autor おかか容疑者 hat in seinen Pixelnews am Freitag die Aseprite-Erweiterung „Rock Generator for Aseprite“ vorgestellt.
Die Erweiterung wird auf itch.io angeboten. Es ist ein Werkzeug, das sich ausschließlich auf Felsen konzentriert: Es lädt Felsen als 3D-Mesh und macht sie als Pixelart verwendbar. Schon auf der Downloadseite fallen viele Parameter auf, und der Artikel meint, dass gerade die Beschränkung auf Felsen die feine Einstellbarkeit ermöglicht.
Laut Artikel gibt es 10 vorgefertigte Formen, 21 vorgefertigte Strukturen und 72 Looks (Erscheinungsbilder). Damit lassen sich auch moosbedeckte und verschneite Felsen erstellen, was sich gut für Hintergründe eignet. Die Oberfläche unterstützt 27 Sprachen, darunter Japanisch.
Es handelt sich um ein kostenpflichtiges Tool, Stand Oktober 2026 ab 4,99 US-Dollar (etwa 800 Yen). Am Ende der Seite gibt es eine Testversion, laut Artikel enthält sie aber nur Beispielbilder der Ausgabe. Wer das vor dem Kauf prüfen möchte, sollte das im Hinterkopf behalten.
Felsen in Blender oder einem anderen Programm zu modellieren und dann in Aseprite zu importieren, war schon vorher möglich. Trotzdem scheint es effizient, Felsen direkt in Aseprite grob zu erstellen, und das könnte nützlich sein, wenn man viele Hintergrund-Pixelbilder braucht. Ich grüble immer, wie ich die verschiedenen Gesteinstexturen male, deshalb freut mich so ein Hilfswerkzeug.
Das Pixel-Art-Fest „Pixel Art Park 9 (PAP9)“ findet am Sonntag, dem 11. Oktober 2026, in der Pacifico Yokohama statt. Die diesjährigen Aussteller werden in einem note-Artikel von Herrn Morita vorgestellt, der bei der Spieleentwicklungsfirma Ixeal aus Nerima arbeitet.
Ixeal nimmt als Sponsorfirma teil. Das Unternehmen zeigt zwei komplett neue Originalspiele, die für das PAP9 entwickelt wurden. Der Artikel stellt davon eines vor: 『Magical Soup』.
Das Spielprinzip: Man fängt „versteckte Aromen“, um Suppe zu kochen. Es gibt drei Arten davon, „Normal“, „Gefährlich“ und „Magisch“, und je nach Kombination ändert sich, welche Suppe man zubereiten kann. Wer spielt, erhält außerdem einen Sticker in der Art der selbst gekochten Suppe. Das Spiel stammt vom Team hinter 『JUST Onigiri』, das beim letzten PAP8 ausgestellt war.
Das zweite Spiel und neue Pixel-Art-Merchandise sollen in späteren Artikeln vorgestellt werden.
Das klingt nach einer schönen Veranstaltung für alle, die Pixel-Art lieben, mit Spielen zum Ausprobieren und Dingen zum Anfassen. Zu sehen, wie sich Pixel-Art im Spiel bewegt, und direkt mit den Machern sprechen zu können, ist sicher eine seltene Gelegenheit. Wer in der Nähe wohnt, sollte vielleicht vorbeischauen.
