I saw Bigmode Game Jam 2026 shared on Discord right after the new year. I hadn’t touched game dev in a while. Holidays, burnout, the usual. The jam felt like a good reason to get back into it.
The theme was “Slick.”
I brainstormed around ten ideas. Some didn’t hit the judging criteria. Some felt like things everyone would build. I wanted something with a mechanical hook that actually matched the theme, not just a loose interpretation.
I landed on the ice tile mechanic from Pokemon. Press a direction, slide until you hit a wall, stop. That’s slick. Literally. And it was a mechanic I’d always found interesting to think about in terms of puzzle design.
To keep it from reading as a Pokemon clone, I leaned into a visual style I’d been developing over the past year of game jams: retro neon arcade. Minimalist geometry, a deliberate color palette, particle effects, post processing. It’s become something of a signature at this point. Slick visuals to go with a slick mechanic.
I Missed the Deadline
Two days in, I had a solid prototype. Movement felt good. The core loop was there. I was genuinely excited about where it was going.
Then I got sick.
Not “a little under the weather” sick. Flu first. Then that turned into pneumonia. Then some pre-existing immune issues decided to join the party. It was a rough month. I missed the deadline entirely.
After things cleared up, I still felt like the idea was worth finishing. I’d put real thought into the mechanic. The prototype was solid. And honestly, I just needed to make something again. So I finished it anyway.
What the Game Actually Is
The core loop is simple:
- Press a direction. Slide until you hit something. Stop.
- A laser sits on the left side of the screen.
- Obstacles spawn on the right and scroll toward you.
- Survive as long as you can.
It’s an endless runner crossed with Flappy Bird, built around a single sliding mechanic. Movement, collisions, obstacles, death. That’s the whole game.
What Worked
Small Scope
This is something I’ve been actively working on in recent jams. Pick one mechanic. Make it feel as good as it can. Extend it instead of adding new systems.
The results have been noticeably stronger. Less stress during development, too.
Four systems: movement, collisions, obstacles, death. I stayed inside those walls and the game is tighter for it.
Tight Controls
If a player repeats the same action hundreds of times, that action needs to feel correct every time.
I spent the first two days on this alone:
- Movement directions had to be pixel-perfect and aligned to the gameplay grid.
- Collisions had to start and stop at the right point.
- Input buffers made the controls feel fair, not frustrating.
- Speed easing (accelerate to top speed, decelerate just before collision) made movement feel physical instead of mechanical.
Getting this right before building anything else kept the rest of development clean.
Retro Neon Arcade Style
I developed this visual style for a jam about a year ago, kind of by accident. It clicked, I got positive feedback on it, and it’s stuck around since. At this point it’s become something of a signature in the jams I participate in.
The formula:
- Minimalist geometry (no complex sprites needed)
- Deliberate color palette
- Particle effects at key moments
- Light post processing pass
Art is not my strongest skill. I don’t currently have a dedicated artist to work with. This style lets me ship something that looks considered without needing to illustrate anything. It scales well to short timelines. And for this game specifically, the neon-on-dark palette reinforced the “slick” theme without me having to force it.
What Didn’t Work
Obstacle Generation
I wanted obstacles and movement to align to a grid. Everything snapping cleanly to the same spatial logic.
The first approach was simple: randomly place obstacles across each column as it spawned. That broke quickly. Adjacent columns could combine to create scenarios with no valid path through. The game felt unfair because it was unfair.
The fix required thinking about it differently. I built a decision maker that generates a full maze layout first, guarantees there are no invalid paths, and then strips out the walls entirely. What’s left are only the blocks a player would actually collide with while navigating that maze. No walls. Just the collision points. It’s a roundabout way to get there, but it means the obstacle layout is always solvable by construction, not by luck.
It works. It’s not the optimal solution. For a prototype, it’s good enough.
Shipping on a Time Budget
I set a time budget for the maze generation problem. When I hit it, I shipped what I had.
That was the right call. The controls are tight. The generation is fair. The game feels complete even if the underlying system has room to grow.
Chasing the perfect solution would have killed the scope.
What I’d Do Differently
Not much on the production side. For roughly a week of actual development time, this is a tight little arcade game. But there are things I missed.
The biggest knowledge gap was going into the maze generation problem cold. I built what made sense to me, got it working, and moved on. After the fact, I found there are well-documented approaches to this kind of problem (flood fill, cellular automata, Wave Function Collapse). Knowing those tools exist before sitting down would have saved real time.
Beyond that, there’s a list of small things I didn’t catch or didn’t get to:
- Obstacle particles are too large when they collide with the laser.
- Default Unity fonts made it to the final build. I just forgot to swap them.
- The wall color is an ugly default grey that doesn’t fit the aesthetic.
- Background particles are slightly misaligned with the camera. You can see the loop point.
- There’s a 1-unit gap on the far right of the grid where a player can technically clip outside the obstacle spawner.
- The game-over restart flow was an afterthought. It works, but it’s barebones and looks it.
- No sound effect on the level-up flash.
None of these are critical. In isolation they’re minor. I may circle back and fix them one at a time if the mood strikes, but for a prototype I’m comfortable leaving it here for now.
Play the Demo
Slick Slider is free to play in your browser over on Itch.io. No installs or downloads needed. Drop a comment there when you’ve played it. I always love to hear what others think about my games.
I’m also working on getting games and prototypes embedded directly on this site. More on that soon.
0 Comments