# 生成拼出單詞的冰滑拼圖

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)

## 最佳答案

### 三個想法

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.