Choose how the player changes the belt
Pick one action for the first build: rotate a belt tile, toggle its direction, or place a junction. Do not let a single tap perform different edits depending on an unclear context. Mark each destination and state whether items may wait on a tile, pass through, or collide with another item.
Paste-ready concept prompt
Original concept prompt: “Create a single-player conveyor-routing puzzle on a small square grid. One crate enters from the left and must reach a matching dock on the right. Tap a belt tile to rotate its arrow clockwise; press Run to move the crate one tile per beat. Complete the level when the crate reaches its dock. The attempt fails if the crate reaches the wrong dock or enters a blocked cell. Show the full route for one beat before starting, and include Restart to stop movement and restore the original belt directions. Begin with a straight belt and one corner; introduce a junction only in a later level.” This is a proposed design recipe that needs a working generated build and playtest.
Test route and timing together
Test a correct route and a wrong-dock route using the same crate. Confirm that the displayed arrows agree with movement at every step and that the player cannot edit a belt while a crate is crossing it unless that is an intentional rule. Try Restart during movement and after a failed route; the crate, beat counter, and tile directions should all return to their starting values.
If the crate moves faster than a tester can read the path, lengthen the beat or keep movement step-based. Add a second crate only after the first route is predictable, then decide explicitly how the puzzle handles simultaneous occupancy.
Questions about conveyor belt game prompt
Should belts move continuously or one cell at a time?
Cell-by-cell movement makes routing easier to inspect and test. Continuous motion can be added later if it preserves the same route rules and does not hide a junction decision.
What should happen if two crates meet?
Choose and explain one rule, such as stopping before overlap or ending the attempt. Test the meeting directly so a collision does not resolve differently depending on update order.