Message #830

From: Roice Nelson <>
Subject: Re: [MC4D] Introducing "MagicTile"
Date: Sun, 31 Jan 2010 15:26:39 -0600

Thanks Matt!

I agree with your thoughts about inverting the outermost face, and have
added it to "the scary list". The same issue comes up in the 4D puzzles (at
least in my implementation of Magic120Cell since I allow showing cells
mirrored by the projection). I had originally reversed the twisting of
those faces, but ended up reverting that when I discovered some bug entropy
related to it. Also, I worried it could lead to confusion, like "hey,
that’s not counterclockwise!". On the other hand, it makes the projection
effects explicit. It might actually be nice to have an option for this,
which I think I’ll do when I get to it.

The two layer puzzles are an interesting topic for sure. I put them in the
list even though they don’t currently do anything (except in the Megaminx
family), because they look pretty. I was on the fence about enabling the
Megaminx behavior as is, but did so solely because of the Impossiball. It
is the only puzzle in the list right now which overlaps material when
twisting. I actually feel there is a better length-2 analogy for the
Megaminx than the Impossiball, which is twisting a slicing circle that is a
"great circle" (cuts the unprojected puzzle sphere in half). The order of
this twist is 2 instead of 5 and swaps opposite faces. It also twists
without overlapping any material, which is why I prefer it. The reason I
didn’t include this as the length-2 version is that this twist is
edge-centered rather than face-centered, and I had made the (arbitrary)
decision to restrict to the latter in the first version. I have to keep
myself sane somehow :)

The situation is similar in other puzzles. Check out the length-2 digonal
and trigonal puzzles and note that the nicest twists there (which don’t
overlap material) are vertex-centered. To answer your question about
supporting all even length puzzles vs. just length-2, absolutely. The guts
are capable, I just didn’t expose those as menu options until the behavior
is better worked out. And I welcome further discussion of the specification
of these puzzles! In particular, what would be a good way to specify
edge/vertex twists?

When you get to the infinite tilings, thinking about even-layers becomes
even stranger, and there is analogizing work to be done :) In the hexagonal
case, I think the right twist of the length-2 puzzle would be a translation
of half of the puzzle! (do you agree?) Again, the reason I favor this is
because no material overlaps. The problem I ran into was how to specify
such twists elegantly. Try thinking about it and backing yourself into some
corners :) One thing I can say is that a { clicked cell + direction }
simply isn’t enough information to specify it. The same is true in the
hyperbolic cases.

Related to the last paragraph, it is interesting that outer twists for the
infinite tilings don’t make sense regardless of whether the puzzle is even
or odd. What would a slice-2 twist on a length-3 hexagonal puzzle do? The
topology restricts the movement, which (I think) makes sense to me if I
picture the hexagonal puzzle on a torus instead of unrolled as in MagicTile.
Anyway, I’m perhaps getting a little off topic, but the reason to mention
this is that we won’t be able to specify reorientations for the infinite
tilings as a twist "with all slices down". However, I’d love to see
reorientations (both view rotations and panning) done some other way in both
the spherical/hyperbolic cases. To see a really nice example of panning
hyperbolic space, check out Don’s hyperbolic tessellation
The are some big challenges to get this working in MagicTile, and
performance is one of the largest, since so much needs to be drawn.

In regards to your question about the tiling patterns, there is a simple
procedure I used to get the current list, and it involved specifying two
numbers. First was the number of reflections from a "fundamental" cell to
an "orbit" cell (I actually called them masters/slaves in the code). Second
was which polygon segment to do this reflection across. So for example,
take a look at the 6-colored octagonal puzzle. This would be 2,4
(equivalently 4,2). The white center cell is reflected twice across the 4th
segment of each adjacent cell, and recursively thereafter. I wish I
understood this all better, as I actually just had the program run through a
loop to see which of the configurations "converged". Some end up fitting
together and some don’t. Math Magic! Hope this helped clarify. has some papers with lists that would probably help expose the
magic more. Btw, the patterns that work in the hexagonal case end up
producing puzzles where the number of colors are perfect squares, go figure!
And I wasn’t able to find working patterns for polygons with 11 and 13
sides, though I wonder if they exist and I wasn’t recursing deeply enough.

So there is plenty more discussion that could happen, but I don’t want to
overload it right off the bat. One last thing though related to your final
comment. I put a feature in the program just for you Matt! Under "Options
-> Edit Settings…", play with the "Slicing Circles Expansion Factor".
This is analogous to "deepening the cuts" on the original puzzles, which I
know you’ve wanted in the 4D puzzles. It is a fully experimental setting
and I know cases where it doesn’t work well, but often it does. Try 1.4 on
a Megaminx for a more difficult puzzle!

Also, if anyone feels some of this discussion shouldn’t be on the
hypercubing mailing list, let me know. I’m a little worried some might feel
the hyperpuzzling connection a little too tenuous.

All the best,

On Sun, Jan 31, 2010 at 3:37 AM, Matthew Galla <> wrote:

> Very nice, Roice.
> Although the options are clearly limited, this program is a work of art.
> The hyperbolic face patterns combined with the scrambled colors are
> absolutely beautiful.
> I played around with some puzzles I already understood, and it takes a
> while to get used to the little quirks in your program, but well worth it! I
> did notice that the outermost face for the cube and megaminx series is
> controlled opposite to my intuition. If I am thinking in terms of macros and
> try to apply a macro I know works near the center of the puzzle on the
> outermost face, I find that I must invert every move on the outermost face.
> A closer look reveals that this is because the outermost face is inverted.
> Now this is just an idea, but have you considered inverting the movement for
> just the outermost face? Although it my confuse some things visually, I
> think it may be an overall improvement solving-wise.
> Also, most of your 2-layer puzzles are currently not working (which I’m
> sure you already know). Are you looking into correcting this function of the
> program? If so, can we expect puzzles with an even number of layers >2? For
> puzzles with even layers (excluding cube) the visual pieces will have to
> pass under/over/through each other. This is an inevitable behavior if you
> restrict the exterior shape of a puzzle (which your program does because it
> forces it to be drawn on a hyperplane). However, as you demonstrated with
> the two-layered megaminx (impossiball) this is clearly do-able.
> I am also looking forward to an updatewhere we can reorient some of these
> puzzles! This is allowable on the cubical and dodecahedral puzzles by
> holding down every layer number, but I would love to watch some these
> hyperplane tesselations shift!
> My favorite thing about your program, however, is the identical puzzles
> with different sticker patterns. I am very interested to know how you came
> up with the different patterns of colors on say, {6,3}, as well as the other
> puzzles with multiple color-pattern options.
> All in all, an excellent program that opens up a world of puzzles I had
> never considered before! Although, I should say that none of the puzzles in
> your program are very hard ;)
> Thank you for once again expanding the limits on twisty puzzles!
> Matt Galla
> PS How many moves counts as an official scramble so I can start submitting
> my solves? :)
> On Sat, Jan 30, 2010 at 9:04 PM, Roice Nelson <> wrote:
>> Thanks to everyone for the thoughtful feedback on my question this week.
>> I appreciate it, and it was good to get your perspectives.
>> I think I’m ready enough to share a first pass of the new Rubik analogue I
>> started playing with before the MC4D 4.0 fun, which I mentioned the
>> possibility of here<>some time ago. While you might observe it doesn’t quite fall into the
>> category of hyperpuzzles, it does in at least once sense mentioned below :D
>> Here is the page with the download, pictures, and a video<>.
>> To describe the analogue idea, I’ll just quote the beginning of the
>> explanation on that page:
>>> This program aims to support twisty puzzles based on regular polygonal
>>> tilings <> having Schlafli
>>> symbols <> of the form {p,3}
>>> for any p>=2. That is, all regular tilings of polygons with two or more
>>> sides, where three tiles (puzzle faces) meet at a vertex. The Rubik’s cube
>>> is the special case where faces are squares (p=4). The other familiar
>>> special cases are the Megaminx (p=5) and the Pyraminx (p=3), although you’ll
>>> discover the last takes a slightly different form under this abstraction
>>> (akin to Jing’s Pyraminx <>).
>>> All the other puzzles are new as far as I know, and some may be surprising,
>>> e.g. the puzzles based on digons <>
>>> (p=2).
>>> Each 2D tiling admits a particular constant curvature (homogenous)
>>> geometry. The geometry is Spherical for p=2 to p=5, Euclidean (flat) for
>>> p=6, and Hyperbolic for p>=7. Since you can’t "isometrically embed" the
>>> entire hyperbolic plane in 3-space<>,
>>> I have a connection to hyperpuzzling<> even
>>> though I’m talking about 2D tilings!
>> …
>> I’ve actually only solved the 3x3x3 on it so far, and I wonder if it may
>> be more fun to watch than play! I’ve been calling it MagicTile, though
>> perhaps there could be something better? As with everything, it is a known
>> work in progress (the length of the task list has grown to scary
>> proportions). I have no plans for further development at the moment, though
>> I’ll happily fix any glaring bugs.
>> Enjoy!
>> Roice
>> P.S. This is the only "twisty puzzle" group I’m active in, so if any of
>> you are also members of other groups and think they would be interested to
>> hear about these new puzzles, I’ll appreciate the exposure :)