Building a 3D conveyor puzzle: a Depot Dash devlog

Most routing puzzles freeze the world while you think. Depot Dash does the opposite: the belts never stop. That one decision is the whole game, and it’s what this devlog is about.

A puzzle with a heartbeat

When you pause time, a routing puzzle becomes a question of “what is the solution.” Fine, but a little cold. In Depot Dash parcels are always moving, so the question changes to “can I set the junctions in the right order before the next box arrives.” That shift, from a static board to a moving one, turns a logic puzzle into something with a pulse. You’re not solving; you’re keeping up.

It also changes what failure feels like. Because everything is visible and in motion, when you misroute a parcel you can usually see exactly which junction you flipped too late. That “I know what I did wrong” feeling is the hook. It’s the difference between a puzzle that frustrates you and one that makes you say “again.”

Keeping the depot readable

Real-time only works if the player can trust their eyes, so I spent most of the polish budget on readability:

• A parcel’s destination is written right on the box, no hidden information.
• Junctions flip with a single click or tap, so switching is never fiddly.
• The camera sits high enough to see the whole floor, so planning ahead is always possible.

Everything hard about a level comes from the timing and ordering of your switches, never from something the game hid from you. That’s a rule I held to across all 62 levels.

Scaling difficulty by layering

The campaign is 62 levels across 6 chapters, Chapter 1 is the free twelve you can play in the browser, and Chapters 2–6 are the fifty in the Depot Mastery Bundle on Android. The trap I wanted to avoid was making later levels harder by making them busier, more clutter, more noise, more luck. Instead, difficulty grows by layering new decisions on the same simple controls:

• Early chapters teach one junction and one parcel type.
• Later chapters add more destinations and tighter queues.
• Then fragile parcels arrive, they can’t survive the fast express lanes, so you have to route them the safe way while still hitting your goals.
• Mistake limits drop, so precision starts to matter as much as speed.

Same two-button game, harder and harder decisions. That’s the pattern I trust.

The rule I made and then had to enforce

Early on I wrote down a rule for myself: no luck-based puzzles. The queue is visible, the layout is fixed, and every level must be solvable. If a run fails, a different ordering of switches would have worked.

Writing that rule took ten seconds. Enforcing it took a lot longer, because it turns out there is a whole category of level that looks fair and is not.

The failure mode is a level where the solution exists but requires you to have already known something you could not have known on a first attempt. A parcel arrives whose destination only becomes visible once it is past the junction that needed setting. Technically solvable, on the retry. Practically, it is a level that charges you one failure as an entry fee, and it feels indistinguishable from randomness even though nothing random happened.

I cut several levels that had this shape, and the test I ended up using is: could a player who reads the queue carefully, with no prior knowledge of this level, clear it first time? Not three-star it, clearing and three-starring were always meant to be different puzzles, but clear it. If the answer is no, the level is hiding information, and the “I know what I did wrong” feeling that makes the retry loop work collapses into “I guess I’ll find out.”

That distinction between hard and hidden is the thing I would most want another puzzle designer to take from this project. They feel similar from the outside and they produce completely different relationships with failure.

Every level is verified

The corollary to a no-luck rule is that “I think this is solvable” is not good enough. Every level in the campaign passes an automated solvability check, which is the kind of unglamorous infrastructure that does not show up anywhere in the game and without which the design rule is just a hope.

This mattered most in the later chapters, where fragile parcels, express and rusty lanes, and multi-way junctions stack on top of each other. Once a level has four interacting constraints, human intuition about whether a valid route exists is genuinely unreliable, I have been confident a level was fine and been wrong, and confident a level was impossible and been wrong in the other direction.

It also changes what a player bug report means. When someone tells me a level is impossible, I can say with confidence that it is not, and then the interesting question becomes why it looks impossible, which is usually a readability problem, and usually fixable.

Three stars, three skills

The star system is really a second, optional game layered on top of “just clear it.” One star for finishing, more for accuracy and efficiency, fewer mistakes and fewer switches. Chasing three stars means planning the route that needs the fewest flips overall, sometimes accepting a longer path for one parcel so you never touch a busy junction twice. It’s where Depot Dash stops being reactive and becomes genuinely strategic.

The thing I only understood properly when I sat down to write the three-star guide is that the speed star is barely a star. You cannot make a belt run faster or skip the queue, so shift duration is dominated by mistakes and wasted flips, which the other two stars already measure. Speed is a consequence of playing well, not a separate skill, and players who chase it directly flip junctions early and often “just in case”, which is precisely what the efficiency star punishes.

I am not sure whether that is elegant or a design flaw. It means three stars is really two skills with a third that comes free, which is tidier than it sounds but also less than the interface promises. It stays as it is for now.

If you want to feel the belts not-stopping for yourself, Depot Dash is here, Chapter 1, free, in the browser.