How to make a pixel art game — the practical roadmap

The gap nobody warns you about

Everyone wants to make a pixel art game. The idea feels so close you can taste it -- a little platformer, maybe a roguelike, something with crunchy sprites and tight controls. You've played Celeste and thought "that can't be that hard." You've watched Stardew Valley interviews where one guy built the whole thing alone and figured hey, if he can do it, so can I.

And you're right. You can.

But there's a canyon between "I want to make a game" and actually shipping one, and most people fall into it within the first two weeks. Not because the work is impossibly hard. Because they start wrong. They pick a scope that would take a studio three years, spend a month drawing tiles before writing a line of code, and burn out before they have anything playable.

This is the practical version. How to make a pixel art game and actually finish it -- not the fantasy roadmap, the real one.

Step 1: Pick a scope that's almost embarrassingly small

Your first game shouldn't be an RPG. It shouldn't be a Metroidvania. It shouldn't have a crafting system, skill trees, dialogue branches, or 47 enemy types.

It should fit on one screen.

Celeste started as a PICO-8 game jam project -- a single room platformer that Maddy Thorson and Noel Berry built in four days. Four days. The commercial version that sold millions came later, but the core mechanic? Proved in a weekend. Undertale's battle system prototype was a simple bullet-hell box. Hollow Knight's first demo was three rooms and one boss.

Look, I know "start small" is advice you've heard a thousand times. But here's what people actually mean: pick one mechanic and make it fun. Not two mechanics. Not three. One. A jump. A dash. A sword swing. A single spell. Make that feel good, build a few rooms around it, and call that your game.

You can always expand later. You can't un-burn out.

Good first projects:

• A single-screen platformer (think the original PICO-8 Celeste)
• A wave-based survival game (one arena, enemies approach, you fight)
• A puzzle game (one mechanic, 10 levels)
• A Flappy Bird clone with your own art style

Projects that kill beginners:

• An open-world RPG
• A Stardew Valley-style farming sim
• Anything with "procedural generation" in the pitch
• Any game that needs more than 50 unique sprites

Pick the embarrassingly small one. Ship it. Then go bigger.

Step 2: Choose an engine and stop second-guessing

Engine debates are a trap. People spend months researching engines instead of making games. Here's the honest breakdown.

My honest take? Godot for most people. It's free, it's lightweight (100MB editor versus Unity's 2+ GB), and 2D is a first-class citizen -- not a layer bolted onto a 3D engine. Pixel-perfect rendering works out of the box. Set your texture filter to "Nearest" in project settings and you're done. No fighting with import settings, no custom shaders, no mysterious half-pixel blurring.

Unity's fine if you already know C# or want the largest ecosystem of tutorials and assets. But for a pixel art game, you'll spend your first hour just configuring things that Godot handles by default.

GameMaker is the fastest path from zero to playable. Undertale, Hyper Light Drifter, and Hotline Miami were all GameMaker. If you want to be running around a room with a character within 30 minutes of opening the engine, this is it.

Phaser is JavaScript-based and runs in the browser. Great if you're already a web developer. Less great if you want to ship on Steam.

Here's what matters more than any of this: pick one and commit. The engine you know will always beat the engine that's technically superior. You can read a longer breakdown in our best game engines for pixel art comparison.

Step 3: Define your art style before you draw a single pixel

This step gets skipped constantly, and it's why so many indie games have art that looks like five different people made it (even when one person did).

Three decisions. Make them now, stick with them forever.

Resolution

Your sprite resolution affects everything downstream -- animation complexity, detail level, how much art you need to produce. Bigger isn't better. Bigger means more pixels to draw per frame, more frames per animation, more time per asset.

16x16 is the sweet spot for most first games. It's detailed enough to be readable, small enough to produce quickly. Celeste's player character is effectively 16x16-ish. Most NES-era games ran at similar sizes. There's a reason the resolution stuck around. Check our 16x16 pixel art tutorial if you want a deep dive on working at that scale.

32x32 gives you more room for expression but roughly triples production time per sprite. Only go here if your game really needs it -- close-up characters, detailed animations, RPG portraits.

Color palette

Don't pick colors freehand. Just don't.

Go to Lospec and pick a pre-made palette. Restricting yourself to 8-16 colors forces visual consistency and makes your game look intentional instead of random. Every great pixel art game uses a limited palette. It's not a limitation, it's a superpower.

Some solid starting palettes:

• PICO-8 (16 colors) -- the classic. Perfect for retro-style games.
• Endesga 32 (32 colors) -- versatile, great color range, popular with indie devs.
• Sweetie 16 (16 colors) -- softer, modern pixel art feel.
• Resurrect 64 (64 colors) -- if you need more range but still want constraint.

Pick one. Commit. Don't deviate. Your future self will thank you when every sprite, tile, and UI element looks like it belongs in the same game. We've got a full breakdown in our pixel art color palettes guide.

Style consistency

Decide on a few rules and follow them everywhere: Do outlines use black or dark versions of the fill color? Is lighting top-left or top-right? Are characters drawn at 3/4 view or side view? Do you use dithering or flat fills?

Write these down. Seriously. Three bullet points. Tape them next to your monitor. The goal is that any sprite you make at hour 50 matches what you made at hour 1.

Step 4: Create your sprites

This is where most people either get stuck for months or rush through with terrible results. Neither is necessary. Here's what actually works in 2026.

The manual approach

If you want full control and don't mind spending the time:

Aseprite ($20) is the industry standard. Onion skinning, animation timeline, palette management, tilemap support. Every serious pixel artist uses it. The learning curve is maybe a weekend. Worth every penny if you're planning to do a lot of pixel art.

Piskel (free, browser-based) is perfectly fine for simpler projects. Less powerful than Aseprite, but you can be productive in ten minutes. Good enough for a game jam or a first project.

Our own pixel editor works if you need quick edits without installing anything.

The AI-assisted approach

Here's the honest reality: if you're learning how to make a pixel art game and you aren't already a skilled pixel artist, spending three months learning to draw before you start coding is backwards. You'll burn out before your game exists.

Sprite AI and similar tools let you describe what you want -- "pixel art knight, sword raised, 32x32, side view" -- and get a usable sprite in seconds. Not perfect. Usable. The kind of quality that gets your game playable while you improve your manual skills on the side.

Full disclosure: that's our tool. But the broader point stands regardless of which generator you use. AI sprites get you to "playable prototype" fast.

The hybrid workflow (what actually ships games)

The developers who finish games in 2026 aren't choosing between manual and AI. They're using both.

1. Generate base sprites with Sprite AI for speed
2. Edit them in Aseprite or Piskel to match your style
3. Create key art manually -- the stuff players stare at (title screen, main character, bosses)
4. Generate bulk assets -- background objects, items, enemies that appear for two seconds

This isn't lazy. It's production strategy. Professional studios have concept art → modeler → texture artist → rigger pipelines because splitting creative work is efficient. You're a solo dev -- AI is your pipeline.

For a deeper dive on generation techniques, check our AI sprite generator guide and the sprite sheet workflow.

Step 5: Build with placeholders first

Counterintuitive advice: don't wait until your art is perfect to start building.

The single best thing you can do for your game is get something playable with colored rectangles within the first week. Seriously. Rectangles. A red square for the player, blue squares for enemies, green squares for pickups. Wire up movement, collision, and one core mechanic.

Why? Because you'll discover design problems immediately. Maybe the jump height feels wrong. Maybe the room is too big. Maybe the core mechanic isn't fun. You want to find that out with rectangles, not after spending 40 hours on beautiful sprites for a game that doesn't feel right.

The workflow:

1. Week 1: Colored rectangles, core mechanic playable
2. Week 2-3: Replace with real sprites (generated or hand-drawn), iterate on feel
3. Week 4+: Polish, add juice (screen shake, particles, sound), playtest

Eric Barone spent years on Stardew Valley's art, yes. But he also had a functioning game prototype long before the art was final. Prototype first. Pretty second.

Step 6: Polish is what makes it feel real

Here's where pixel art games go from "student project" to "thing people actually want to play."

Screen shake. Add 2-3 pixels of screen shake on impacts. Takes five minutes to implement. Makes combat feel 10x better.

Particles. Dust when you land, sparks when you hit metal, little puffs when enemies die. Tiny sprites -- 4x4, 8x8 -- animated over a few frames. This is where AI generation pays for itself. You can produce 20 particle variations in five minutes.

Sound. This one isn't art, but it matters as much as art. BFXR generates retro sound effects for free. Spend an afternoon. Your game will feel completely different.

Juice. Squash-and-stretch on characters. Brief hitpause when attacks connect. Flash white on damage. Smooth camera follow instead of locked camera. None of this is hard to implement. All of it is the difference between "feels amateurish" and "feels polished."

The talk "Juice it or lose it" by Martin Jonasson and Petri Purho is 15 minutes long and will change how you think about game feel. Watch it before you start polishing.

The mistakes that kill pixel art game projects

I've seen these kill projects over and over. Including my own.

Scope creep

"What if I also added..." is the most dangerous phrase in game development. You started making a platformer and now you're designing an inventory system, a crafting tree, and a dialogue engine. None of which existed in your original plan.

Every feature you add multiplies development time. Not adds -- multiplies. A platformer with a shop takes twice as long as a platformer without one. A platformer with a shop, crafting, AND dialogue takes eight times as long. The math is brutal.

Cut features. Then cut more. Ship what's left.

Art perfectionism

You redraw the player character for the fifth time. The walk cycle still isn't quite right. You've spent two weeks on art and haven't opened your engine since the prototype.

Stop. The art is good enough. You're making a game, not a portfolio piece. Stardew Valley's art isn't technically impressive -- it's charming. Undertale's art is deliberately rough. Neither game suffered for it. Players care about feel and fun, not whether your idle animation has 6 frames or 8.

Never shipping

The hardest part of game development isn't coding, art, or design. It's saying "this is done" and releasing it. There's always one more thing to fix, one more feature to add, one more sprite to redraw.

Set a deadline. A hard one. "I will post this on itch.io by [date]." Tell someone. Accountability matters. A finished game with rough edges teaches you more than an unfinished masterpiece sitting on your hard drive.

Resources to keep moving

Art fundamentals: Start with pixel art fundamentals for the core principles -- readability, color theory, form at small scales.

Sprite creation: Sprite AI for fast generation, pixel editor for quick edits, Aseprite for serious manual work.

Engine guides: Our best game engines for pixel art comparison goes deep on each option.

Palettes: Lospec palette list is the definitive resource. Bookmark it.

Game feel: "Juice it or lose it" (YouTube), "The Art of Screenshake" by Jan Willem Nijman, and Celeste's GDC postmortem.

Communities: r/gamedev, r/pixelart, the Godot Discord, game jam communities on itch.io. Showing up with a playable prototype -- even a tiny one -- gets you feedback that reading articles never will.

Just start

The best way to learn how to make a pixel art game is to make a bad one. Not read about making one. Not watch tutorials about making one. Not spend three months picking the right engine and drawing practice sprites.

Open Godot. Create a scene. Add a colored rectangle. Make it move with arrow keys.

That's your game. Everything else -- sprites, levels, enemies, polish -- is iteration on top of that rectangle. Generate some sprites with Sprite AI when you need art. Edit them in Aseprite when they aren't quite right. Playtest constantly. Ship when your deadline hits.

Celeste started as a rectangle that could jump and dash. So can yours.

Start generating sprites for your game →

Related posts

Guide

Easy pixel art for beginners: Create your first sprite

Start creating pixel art today. Learn the fundamentals, create your first sprite, and discover tips that make pixel art easier than you think.

Guide

Isometric pixel art for games — grids, sprites, and tilesets

The isometric grid trips everyone up at first. Here's how to actually draw isometric sprites and tilesets that tile correctly in Unity, Godot, and GameMaker.

Guide

10 pixel art color palettes you can steal for your game

Copy-paste hex codes for 10 proven pixel art palettes. Each one includes use cases and examples so you stop wasting time picking colors.