← Back to Blog Game Jam

How I Prepped 40 Sprites for a Game Jam in One Weekend

July 2026  ·  By ORH Studio  ·  5 min read

The jam theme dropped Friday at 8 PM: "Something is always watching." By 8:15, I had a game concept. By 8:20, I realized I had zero assets that matched it.

I needed roughly 40 sprites — a protagonist, three enemy types, environment tiles, a handful of UI elements. I had the weekend. This is what actually happened.

Friday night, 9 PM. I started on OpenGameArt, which is my default first stop. Found a decent stealth-character sprite sheet — 128×48 pixels, four rows, twelve frames each. The readme said "16×16 per frame." I trusted it, started importing into Godot, and immediately got garbage. Turns out whoever uploaded it had measured wrong; it was actually 16×12 with two pixels of padding on the bottom of each row. An hour of confusion because I didn't verify the actual pixel dimensions before starting.

That's mistake number one, and I make it every time I work with assets I didn't create myself: don't trust the readme for frame dimensions, trust a ruler. Open the sheet in any image viewer, count the frames yourself, divide. Twenty seconds of arithmetic that would have saved me that hour.

Saturday morning, 9 AM. After sleeping on it, I switched workflows. Instead of importing directly, I started previewing everything first. Upload the sprite sheet, get individual frames out, sanity check them visually before touching the engine. Slower in theory, faster in practice — I caught three more assets with incorrect frame counts before they became Godot problems.

The environment tiles were a different kind of issue. I'd sourced a cave tile set that came as 47 individual PNGs with chaotic naming: tile_v2_FINAL_fixed.png, tile_wall_USE_THIS.png, that kind of thing. Re-packing them into a proper atlas by hand would have been tedious. I used Sprite Sheet Packer to drag them all in at once, set a column width, and get a clean atlas out in about three minutes. Not glamorous, but it was the difference between "done" and "still fiddling with file names at midnight."

Saturday afternoon, around 2 PM, I got stuck for two solid hours. One of the enemy animations — a floating eye creature — looked fine as individual frames. Loaded them into Godot, ran the animation, and it strobed. Not a frame rate issue; the frames were out of order in a way that wasn't obvious from the filenames. They were numbered sequentially but the sequence itself was wrong: the artist had organized them by row in the sprite sheet rather than by animation phase.

I spent those two hours trying to fix it inside Godot, dragging frames around in the SpriteFrames editor. Eventually I went back to basics, relaid the frames in the correct order outside the engine first, then reimported. Five minutes of prep work at the start would have replaced two hours of debugging. I keep relearning this lesson.

The frames that look fine individually are the ones that bite you. It's always the "obviously correct" asset that has the subtle ordering problem.

Sunday morning, the unexpected good part. I found a GIF on a free asset site — an old animated torch sprite, exactly the vibe I needed, but animated GIF format from what looked like 2011. I nearly skipped it because dealing with GIFs felt annoying. Extracted the frames, got eight clean PNGs out. The loop was perfect. That torch ended up being one of the better-looking things in the finished game, and it came from an asset I almost passed over because of the file format.

There's something worth noting about older free assets: the pre-2015 stuff on OpenGameArt is often higher quality than it looks at first glance, precisely because it's been around long enough for the bad uploads to get filtered out by community ratings. Don't dismiss something because it's a GIF or because the preview thumbnail is small.

What I'd do differently. Verify frame dimensions before importing anything — every time, no exceptions. Preview animations outside the engine before they touch the project. And build a 30-minute "asset sanity buffer" into my jam schedule rather than assuming everything will slot in cleanly on the first try. It never does, and it's better to plan for that than to eat into actual game development time.

The game shipped Sunday at 9 PM with all 40 sprites in place. It was not a great game. The sprites were fine.