Generating ice-sliding puzzles which spell out words

Question

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)

Answer 1

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.

Answer 2

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.