Hypercubing Leaderboard Submission Rules¶

These rules are not written in legalese. Please don’t try to exploit them. Ask in the Hypercubers Discord if you have any questions, comments, or concerns about these rules.

These rules may be flexible, especially for new categories. For example, if you’re speedsolving a really big puzzle that no one’s done before, it might be reasonable to allow macros for it.

General rules¶

These programs are recommended for speedsolving. If using a program not listed here, you should ask on the Discord first.
The puzzle must be solved from a full scramble.
Spectators may commentate, but must not help the solver.
Algorithm reference sheets are strongly discouraged.¹
Reversing the scramble is not allowed; the solution must be novel.

Speedsolving rules¶

These rules apply generally to speedsolving submissions unless the category has specific rules.

Macros are not allowed.
Piece filters are allowed.
All speedsolves require video evidence, such as a screen recording.
- A timer with precision of 0.01 seconds or better must be visible on the screen during the solve. Timers built into the puzzle software are preferred.
- Inspection time must not exceed 60 seconds. In other words, the solve timer must be started within 60 seconds of the puzzle being completely scrambled.
If using keyboard controls:
- If possible, a keybinds reference must be visible during the solve.²
- The keybinds should not be hyperoptimized for specific algorithms.³
Log file is not required, but you should still save your PBs!
Using software to compute a solution to the puzzle state is not allowed.

Blindsolving rules¶

Macros are allowed during solving.
Piece filters are allowed during memorization but not during solving.
All blindsolves require video evidence of the solver that clearly shows the screen and that they are not cheating by using some external reference.
The solver does not need to be blindfolded, but the colors on the puzzle must be invisible during the solve.
Using software to compute a solution to the puzzle state is not allowed.
Besides those rules, typical blindsolving rules apply:
- Final time = memorization time + solving time.
- Writing anything down isn’t allowed.

Real-life puzzle rules¶

All real-life puzzle solves video evidence that shows the puzzle fully in frame throughout the solve and shows the entire scrambling and solving process as well as the timer.
Scrambles must be generated by a computer program that produces a random state or at least this many random moves:
- Physical 2⁴: see below
- Hemimegaminx: 30 moves

Physical 2⁴ rules¶

See Canonical Moves for more details.

All rules for real-life puzzles apply.
Allowed moves for physical 2x2x2x2 events are limited to 2 categories, the canonical moveset originally made by the hypercubing mailing list as well as a few additional moves:
- Canonical moves:
  - All R and L cell rotations
  - U/D y2
  - F/B z2
  - I/O x* (a.k.a. axial twist)
  - Any of many equivalent gyro algorithms
- Additional moves:
  - U/D x2/z2
  - F/B x2/y2
  - I y2/z2
For 2⁴, scrambles must be generated by this page or any equivalent scramble generator.
- Hand scrambles are no longer allowed, as they have an increased chance to have an easier solution than random state scrambles.
- It’s ok if you mess up the scramble a little bit. It should still be way more random than any hand scramble.
- For random-move scrambles:
Any full puzzle rotation that doesn’t change the state (including the Gyro) may be applied to the puzzle during inspection; other moves may not.

Fewest-moves solving rules¶

Log files are required for submission.
Video evidence is not required.
Collaboration is allowed; each collaborator must be given the option to be credited for the solve, and should be credited if their contributions were significant.
Moves are counted using STM.
Use of computer software to generate a partial or full solution is allowed, but must be noted in the submission.

Principles when writing new speedsolving software¶

If you’re thinking of writing a new program for speedsolving or suggesting a new feature for Hyperspeedcube, here are some principles we try to follow:

No more than one move per keypress.
If your program has keybinds (especially customizable ones), add some reference that shows what keys are being pressed and what they’re doing.
New features should hopefully make solving strategy more interesting. Some examples:
- Macros on the 3⁴ encourage commutator spam, which is very boring compared to layer-by-layer or F2L methods, so they are not allowed for speedsolves.
- Piece filters reduce time spent looking for pieces, which is boring to do and boring to watch. There’s a trade-off there: piece filters encourage a stricter solving order, which is less interesting in a way, but this also enables 3-Block, a very interesting method.
New features should ideally have some justification based on 3D speedsolving. For example, multiple keybind sets is analogous to different grips on a 3D puzzle.⁴

We can’t stop you from using an algorithm reference, but it’s not in the spirit of the competition and it’ll probably slow you down. ↩
If the program doesn’t have a built-in keybinds reference (such as akkei’s physical 3⁴ simulator) then you probably don’t need one. ↩
In particular, you should not be able to execute a meaningful algorithm by pressing a sequence of keys in a line on the keyboard. Keybinds should be laid out in a way that makes sense moreso than a way that is useful for an algorithm. A keybind set optimized for general RKT is fine. If you have a question about this, ask on the Discord. ↩
You might hold a 3³ differently to execute <M,U> moves more efficiently compared to <R,U,F> moves. Similarly, a 4D creature might have a specialized grip on the 3⁴ for RKT compared to general moves. ↩