一千萬個為什麽

搜索

生成拼出單詞的冰滑拼圖

假設我有這樣的謎題:

Ice puzzle

這個想法是,既然你在冰上,一旦你開始移動,你就不能停下來,直到你遇到一塊石頭。如果你將紅色/藍色色塊視為在移動時留下痕跡的油漆,那麽嘗試以最少的移動次數收集所有硬幣拼出一個單詞。

但是,正如您所看到的,這個難題嚴重限制了您可以執行的動作,使其變得非常容易。我想構建一個提供更多自由的拼圖,並且可能涉及多次越過相同的油漆補丁,但是我擔心由此產生的拼圖可能有多個解決方案,或者如果你做的事情,繪制的單詞可能無法識別不同的順序。

所以我的問題是:有沒有一種好的方法:1)產生一個更開放的謎題仍然保證一個獨特的解決方案或2)修改謎題機制,以便1)更容易做?


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.

轉載註明原文: 生成拼出單詞的冰滑拼圖