"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
- 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
- You can always place rocks out in the boonies without affecting
any of the intermediate tiles in an ice puzzle.
- 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
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