Introducing Twizzle (alpha)

[Christopher Mowla]

Hmm, I'd say that's more up to @pjk. But I can certainly write different embeddings for players to be used on different pages, if you have a good idea of how to make that easy to use.


Yeah. The solutions is probably to use https://colorjs.io/, but that's 35KB gzipped. I haven't yet tested how much that would get reduced with tree shaking, but for comparison a fresh visit to alpha.twizzle.net/edit/?puzzle=clock uses only ≈100KiB of code over the network. So I've set aside all the color details until I have time to combine them with a full pass for accessibility.

Wow, yeah, in your previous post, it sounded like you are currently importing a package of which much of it you don't use.

Not sure if this is exactly what you're trying to accomplish (mimic real-life mixture of pigment colors) ... or this dependency's size (I'm not at all familiar with github), but I just found out about this new "revolutionary" method (published in Dec. 2021). https://scrtwpns.com/mixbox/docs/

(Just scroll down that page to see the usage in JS.)

 

[THE_V01DL0RD]

Any updates on twizzle?

 

[Christopher Mowla]

I found another cause of parsing error. When there is no space between a repeated sequence (that is in parenthesis) and a parenthesis of another part of the algorithm.

For example, (r B' z')(2R' F U2 F')4 2R' (z B r') will not parse, but (r B' z') (2R' F U2 F')4 2R' (z B r') will.

I added the needed space between the handful of algorithms on the 4^3 parity wiki pg, but I wanted to report it here as another FYI.

 

[xyzzy]

Twizzle currently aims for compatibility with WCA notation, but I don't think FCN is a good skewb notation outside of scrambling.

FCN by itself can only denote moves that keep one corner fixed, as its name ("fixed corner notation") suggests. This happens to work okay for scrambling (which is not to say some other set of four corners won't work better—I have not looked into this (because I don't care about skewb), but I assume at least some skewbers have, over the 10 whole years since FCN became the standard skewb scrambling notation), but for writing out algs, FCN is underpowered. Even the extremely commonplace sledgehammer cannot always be written in FCN!

Twizzle's current notation extends FCN by adding "UL", "UR", "D" and "F" for the four remaining corner turns. This preserves compatibility with FCN, but is now unintuitive. Granted, assuming you had no prior knowledge of any skewb notation, if I gave you a cube and told you that you had to label the eight corners with "U", "L", "R", "F", "B", "UL", "UR" and "D" in some order, then Twizzle's labelling will be the only one that makes sense; however, this would only be via a convoluted series of eliminations.

(Contrast the colloquial megaminx notation, where the top hemisphere's faces are "U", "L", "F", "R", "BR", "BL" (possibly with varying capitalisation on BL/BR), and the bottom hemisphere's faces are often "D-something". The faces that are easier to access don't get a "U" prefix (except the topmost face itself), while the faces that are harder to access get a "D" prefix. Note also that Twizzle's megaminx notation doesn't follow this convention!)

The same labelling is also used for Twizzle's Redi Cube notation, but as the Redi Cube is a much more shallow-cut corner-turning cubic puzzle than skewb is, FCN doesn't make sense to use on it, and neither does Twizzle's current extended FCN.

Anyway tl;dr I think Rubikskewb notation is better for both skewb and Redi Cube outside of scrambling. (For scrambling, I don't have any qualms about FCN for skewb.)

I don't know what a good way of implementing multiple conflicting notations is. There are also conflicts between community-preferred notation and Twizzle/acn-supported notation for other puzzles, notably big cubes: bigblders prefer Singmaster/Singmaster-like notations, but that conflicts with SiGN, which is more generally useful.

 

[Lucas Garron]

Twizzle currently aims for compatibility with WCA notation, but I don't think FCN is a good skewb notation outside of scrambling.

Indeed, this is something I would love to address.

One important design decision is that the same notation for the same puzzle always means the same thing. For example, it should always be possible to copy a 3x3x3 alg from one web app to another without changing its meaning. It also means that scramble notation must be compatible with solving notation. This rules out any sort of contextual heuristic, or any toggle to switch between contradicting notations.

One reason Twizzle launched as alpha.twizzle.net (rather than beta) is that it gives us two obvious chances to make breaking changes (which can be smoothed over with redirects) without supporting inconsistent notation in the same version of the app. Alpha is very experimental, beta should be as thoroughly revised as possible, and once we're out of beta things should be pretty much permanent.

Once we're further along in the process of replacing TNoodle with `twsearch`, I'd really like to take a serious look at community-vetted notation changes that remain balanced with WCA priorities. For example, one simple choice to avoid the WCA notation conflict with rubikskewb would be to switch the WCA to something very clear like UF/UR/UB/UL/DF/DR/DB/DL. Given how short Skewb scrambles are, the extra letters are probably not much of an issue. But it's very impactful to change official notation, and if we're going to overhaul things I would also really like to see as much consistency as possible across puzzles:

• Skewb and FTO use the same 8 radial axes (4 axes in 2 directions each), but rubikskewb is inconsistent with conventional FTO notation. If we settled on something consistent, this would help make it obvious what notation to pick for a variety of other puzzles.
• Lowercase letters refer to wide moves in SiGN. I would like to avoid lowercase letters referring to single-layer outer turns like in rubikskewb, because this conflicts with wide notation for higher-order Skewb and similar puzzles. But I'm also open to the idea of deprecating `r` in favor of `Rw` (SiGNw) so that `r` can be used in puzzle-specific ways, assuming this doesn't alienate a significant fraction of the community.

 

[SpeakCuba]

4x4 mode has an issue where the scramble inputted won't be recognized. A scramble such as
Uw2 2L2 Uw2 2L2 U2 3Rw' Rw2 R' U2 M2 U2 M' U M2 U M2 or
M2 U M2 U M' U2 M2 U2 M' U 2L2 U2 2L2 Uw2 2L2 Uw2

Will not work. The algorithm box turns red and no reconstruction is shown. Why is this? Those 2 examples are both parity algorithms, so I do not understand why they are not allowed.

 

[Lucas Garron]

4x4 mode has an issue where the scramble inputted won't be recognized. A scramble such as
Uw2 2L2 Uw2 2L2 U2 3Rw' Rw2 R' U2 M2 U2 M' U M2 U M2 or
M2 U M2 U M' U2 M2 U2 M' U 2L2 U2 2L2 Uw2 2L2 Uw2

Will not work. The algorithm box turns red and no reconstruction is shown. Why is this? Those 2 examples are both parity algorithms, so I do not understand why they are not allowed.

alg.cubing.net and Twizzle use the convention that M2 refers to only a single middle slice, which 4x4x4 does not have. So this notation is not supported on 4x4x4. You can use m for wide middle moves:

 Twizzle link 

Uw2 2L2 Uw2 2L2 U2 3Rw' Rw2 R' U2 m2 U2 m' U m2 U m2

At some point, we should hopefully have better explanations in-app instead of just a red highlight.

 

[SpeakCuba]

alg.cubing.net and Twizzle use the convention that M2 refers to only a single middle slice, which 4x4x4 does not have. So this notation is not supported on 4x4x4. You can use m for wide middle moves:

 Twizzle link 

Uw2 2L2 Uw2 2L2 U2 3Rw' Rw2 R' U2 m2 U2 m' U m2 U m2

At some point, we should hopefully have better explanations in-app instead of just a red highlight.

Thank you!

 

[THE_V01DL0RD]

Uw2 2L2 Uw2 2L2 U2 3Rw' Rw2 R' U2 M2 U2 M' U M2 U M2 or
M2 U M2 U M' U2 M2 U2 M' U 2L2 U2 2L2 Uw2 2L2 Uw2

Oa perm real?

 

[marioshouse2010]

Hi, I would like to ask about the usage of the "picture" and "invisible" cube types. I am trying to make it easier to visualize a picture cube's center rotation, and I found the "picture" option exists. Am I supposed to upload an image to make it work? because right now I only have a black cube. And what is the use of the invisible cube? I can't find an option to give the picture cube a pattern, is it still under development?

 

[Renslay]

I wanted to write a reconstruction of my physical 2x2x2x2 solve for educational purposes, and I realized that while Twizzle supports the puzzle, gyro is not possible to perform (unless I'm missing something). Also, it's strange to me that it uses M notations for what is officially(?) called the I cell.

If needed, I can offer my help expanding the move set, though I'll need a little help to understand the current implementation.

 

[abunickabhi]

How do we write the notation for slice moves for FTO in twizzle?

Edit: 2R or 2F works fine to execute slice moves!

Also how do FTO rotations work in twizzle?

 

[acrystal]

How do we write the notation for slice moves for FTO in twizzle?

Edit: 2R or 2F works fine to execute slice moves!

Also how do FTO rotations work in twizzle?

For non-cubic puzzle like pyra, FTO, and mega, we use Uv, Rv, Lv, DRv, like that.

 

[Renslay]

FTO also has a special puzzle turn: T.
Otherwise you couldn't reach all possible orientations!
(Sadly, T doesn't have variations, unlike Rv or Uv or the other v-s).

 

[Pyjam]

It would be a fantastic improvement if Twizzle supported the {x, y} notation for rotations. Currently, it can sometimes be a struggle to find the command that produces the desired rotation, whereas {x, y} would make it immediately clear.
Of course, this would also mean supporting the Edge In Front representation.