Generating ice-sliding puzzles which spell out words

Let's say I have a puzzle like this:

The idea is that since you're on ice, once you start moving you can't stop until you hit a rock. If you treat the red/blue patches as paint that leaves trails when you move, then trying to collect all the coins in the fewest number of moves spells out a word.

However, as you can see, this puzzle heavily restricts what moves you can perform, making it very easy. I'd like to construct a puzzle which gives more freedom and possibly involves crossing over the same paint patches multiple times, but I'm afraid that the resulting puzzle might have multiple solutions or the painted word might be unrecognisable if you do things in a different order.

So my question is this: Is there a good way of either 1) generating a more open puzzle which still guarantees a unique solution or 2) modifying the puzzle mechanics so that 1) is easier to do?.

Edit: To clarify I'm not asking about generating these sorts of puzzles in general. Instead, given a target word, how can we generate a unique-solution puzzle which spells out that word? (via paint/any other mechanic)

• I think the main problem is that this type of puzzle depends on there being multiple routes to achieve "difficulty". In most hard ones I've seen, there are normally one or two choke points (hopefully hard to spot) that have only one way in, and the rest is designed so that there are many red herrings and loopbacks, in an effort to get you confused/frustrated. So basically you'd be painting over the same spots many times. I can't see a good way to make it paintable while keeping it hard if you want the end result to be recognizable. – Set Big O Nov 19 '14 at 2:41
• Geobits' comment is spot on. If you want to make the puzzle harder, you'll have to introduce new dynamics such as patches visited an even number of times "erasing" existing paint. And if you want there to be a unique paint pattern for collecting all the coins, you'll necessarily have to outlaw any moves that could disturb this unique pattern, which is basically the only factor that makes the puzzle difficult. – COTO Nov 19 '14 at 2:47
• @COTO New dynamics are welcome :) What I was thinking was that if the least-moves solution is unique (sorry for leaving that out earlier), then that'll enforce the pattern. So in my example you could go URDLUL to collect the first coin, but URDUL is shorter — you have a bit of freedom, but there's only one solution. – Sp3000 Nov 19 '14 at 2:56
• A lot of these comments could be answers. Come on, don't be shy! I want to upvote. – xnor Nov 19 '14 at 4:01
• I hope you don't mind but I will use the solution to develop a mobile app game. – Kenshin Nov 19 '14 at 4:23

Three Ideas

1. It seems a bit unimaginative, but why not eliminate the paint blotches and replace them with "glow" tiles that change state from glowing to non-glowing and back (or perhaps switch to glowing and remain glowing) when the puck passes over them? Divide the puzzle into a series of "rooms", with one letter per room or a few letters per room, and engineer bottlenecks so that while it's a minor nightmare to get the puck out of one room into the next one, any solution that does get you out has automatically lit up all the right tiles by running over them the right number of times.

2. As a second thought, you could take advantage of having multiple pushable blocks that leave colour trails behind them. And while it might seem obvious what direction a block is supposed to be pushed in, such pushes obviously don't always commute. The real challenge then comes in figuring out the order and direction of block pushes to complete the letter in a room and get the puck through to the next room. Non-commutivity obviously isn't an exploitable tool if you're only ever moving one object around.

3. "Under the hood", puzzles of this type are just directed graphs, or (my preference of abstraction) automata. You have a set of states (position of the puck, position of any other movable objects), and a set of edges or transitions between them. You also have the states of any tiles that get painted, light up, etc. The more complex the topology of states and transitions in the automaton (vertexes, edges in the graph), the more complex the puzzle will be. Ensuring tiles are properly lit up, etc. is accomplished by imposing a guaranteed set of states that must be visited (and potentially, a guaranteed order of visitation) leading up to a new "room" or the end of the puzzle.

There are some wonderful tools out there for doing this using automata and formal languages, but you can also do it by hand. My recommendation would be to start with a state diagram with specific "rooms" as described above. Ignore any correspondence between states and positions for now. For each room, start adding states and transitions to make a room as topologically complex as desired. Add in loops and one-ways and blocking states (i.e. dead ends) and whatever else your heart desires.

With this done, now choose a small, specific set of states that the system "should" pass through in order to reach the "end of room" state. Again, don't worry about the correspondence of these states with the physical reality of the ice puzzle for now. If you find that there are other ways of getting to the end of room state that don't require you to pass through the necessary states (possibly in sequence), you then either have the option of editing the automaton to eliminate erroneous solutions, changing the correct solution, accepting multiple solutions, or, if you're feeling bold, syncing the automaton with a higher order automaton that dictates a broader order of operations. For this last option, think of a dungeon in a Zelda game. You have to run through a maze (a low-level automaton) to get the dungeon item, then run through the same maze again to get the master key using the dungeon item, then run through the same @#\$% maze a third time to get to the boss using the big key. The high-level automaton in this case is the enforced sequence "enter → item → big key → boss". Your high level automaton doesn't necessarily have to be this explicit. It could be based on pushing blocks, running over switches, basically anything that causes a state change.

However complex you ultimately wind up making your room's automaton, at the end you have a certain guaranteed complexity, and an assurance that a specific set of states must be visited (possibly in order) to reach the end-of-room state. Now comes the part where you turn your automaton into an ice rink. You do this by laying out rocks in ways that limit the puck's movement to paths that correspond to state transitions in the automaton.

I admit this second phase can be challenging, especially since the layout phase would have to be built around your "special sequence" of states corresponding to very specific physical transitions (to paint out a letter, light up a letter, etc.) but you have three saving graces:

1. You can always add as many intermediate conveyor states as needed to connect two states. Just make sure each conveyor state leading to state A can only exit to A (or another conveyor leading to A).
2. You can always place rocks out in the boonies without affecting any of the intermediate tiles in an ice puzzle.
3. The sky's the limit on how puck movement can potentially affect the state of the rink tiles. Not only do you have your original idea and the few alternatives I've suggested, there's nothing stopping you from making a puck that passes over tile X paint all the tiles in X's row up until it hits rocks, or paint X and its 4-connected neighbours, or do whatever, so long as the user can establish a consistent pattern between action and consequence.

Both of these processes (automaton design, rock layout) can be automated with a good deal of work, but they can just as easily be done by hand. My preference is always to do a smaller scale example by hand first, get a feel for how easy the process is when done manually and how painful the various steps would be if scaled up, and then assess whether programming an automated solution is worth the effort.

• I really like this graph/automaton idea you mention because it's certainly a lot easier to come up with a unique solution that way. Conversion would be interesting, but of course there's nothing that says I can't have, say, a hexagonal grid or any other mechanic to make it easier. – Sp3000 Nov 19 '14 at 4:36
• @Sp3000: You can always do it in reverse too. Generate a million random block layouts a second, generate the state graph for each case, and stop when you hit on one that has a unique solution of sufficient complexity. I just don't think you'll get "rich" solutions this way, and of course you'd still have to contrive some means of getting the tiles to change state in predictable ways. The advantage of working with the abstraction and then laying it out is that you can lay out the most position-critical states first, while your freedom is greatest, then fit everything non-critical around them. – COTO Nov 19 '14 at 4:43

The simple solution to more freedom is just that, give them more freedom. Add intersections, and forks.

Wanna make it harder? That's possible too. Add special blocks if that give way when used # times. Make each paint color have a special effect when you cross them, like Blue turns you around, Yellow spins you 90° clockwise.

Wanna make it more interesting? Throw in some enemies that move back and forth, pacing, that way they have to time their movements when their making them so they don't die!

Wanna give the player a better feel of their character? Make it a penguin that slides on it's belly :D

Don't forget to build up on difficulty, don't start out with something too hard or the player will get frustrated to quickly. Don't keep it too simple or they'll get bored. A good idea is to introduce new features of gameplay slowly, and each time give them a tutorial level, only then do you start merging features.

• I think I see why you mentioned game dev - I wasn't thinking of making this into a game specifically, but rather just how to make this sort of puzzle give a word via through its solution and not be too easy. Special blocks sound interesting, but would probably make construction (and uniqueness checking) even harder... – Sp3000 Nov 19 '14 at 9:53
• @Sp3000 Small price to pay if it results in a really cool puzzle game. I'd totally buy this on the App Store. – warspyking Nov 19 '14 at 9:56