How to Create an Algorithm for Solving a Rubik’s Cube

Creating a Rubik’s Cube algorithm usually means writing a program that finds a solution from many possible starting states. That is different from writing a move sequence that solves one particular scramble. This article explains how to represent the cube and choose a practical solving strategy.

A full optimal solver is a substantial project. A basic solver can still be useful: it can find a solution, verify move sequences, or solve the cube in stages without always finding the fewest possible moves.

Decide what the algorithm should do

If you know the exact scramble and it was produced by a sequence of moves, reversing that sequence gives a solution. Reverse the move order and invert every move. For example, the inverse of R U R' U' is U R U' R'.

That shortcut does not solve an arbitrary cube state. A general solver must work out a path from the current state to the solved state, so it needs a state representation, a list of legal moves, and a solving method.

Represent the cube’s state

For a standard 3×3×3 cube with fixed centers, model the movable pieces rather than all 54 stickers:

• Eight corners, each with a position and an orientation.
• Twelve edges, each with a position and an orientation.

A common representation stores a corner permutation array cp, corner orientations co, edge permutation ep, and edge orientations eo. A permutation records which piece occupies each position. An orientation records how that piece is twisted or flipped there.

Define each face turn as a transformation of these arrays. For example, an R turn cycles four corner positions and four edge positions, while also changing the orientations of the affected corners. You can precompute the transformation for every move and apply it to a state. This is much faster and less error-prone than rotating sticker colors directly during every search step.

Use a consistent move notation. In standard Singmaster notation, R means a clockwise quarter-turn of the right face as viewed directly from that face; R' is the inverse turn and R2 is a half-turn. Define all six faces the same way in your code.

Not every arbitrary set of arrays describes a reachable cube. For a legal state, the corner twists sum to zero modulo 3, the edge flips sum to zero modulo 2, and the corner and edge permutations have matching parity. Checking these invariants helps catch bugs in state parsing and move tables.

Choose a solving strategy

For a first project, a staged solver is often easiest to understand. It solves features in sequence—for example, one layer, then the middle layer, then the last layer—using algorithms that preserve progress already made. This can produce a working solver, but it requires carefully designed cases and may produce long solutions.

For a more general search-based solver, Kociemba’s two-phase method is a common practical choice. In phase one, it brings the cube into a subgroup where all edges and corners are oriented and the four designated middle-slice edges are in that slice. Phase two solves the remaining state using a restricted set of turns: any turn of the U or D face, and half-turns of the other four faces. Phase one does not solve the cube by itself; it makes the remaining search much smaller.

Another general approach is IDA*, or iterative-deepening A*. It searches paths up to an increasing cost bound. A heuristic estimates how many moves remain. A pattern database can provide a useful lower bound by precomputing distances for selected groups of pieces. Taking the maximum of admissible lower bounds remains admissible; adding them is safe only when the costs are partitioned appropriately.

Build an IDA* search

The outline below assumes face-turn metric: each quarter-turn, inverse turn, or half-turn has cost one. If you want to optimize a different metric, such as counting a half-turn as two quarter-turns, adjust move costs and heuristic distances consistently.

solve(start):
    bound = heuristic(start)
    repeat:
        result = search(start, cost=0, bound, previous_face=none)
        if result is a solution:
            return result
        if result is infinity:
            report no solution
        bound = result

search(state, cost, bound, previous_face):
    estimate = cost + heuristic(state)
    if estimate > bound:
        return estimate
    if state is solved:
        return the path so far

    smallest_excess = infinity
    for move in legal_moves:
        if move uses the previous_face:
            continue
        next_state = apply(move, state)
        result = search(next_state, cost + 1, bound, move.face)
        if result is a solution:
            return result
        smallest_excess = min(smallest_excess, result)
    return smallest_excess

The same-face restriction is a search optimization when your move set includes all three nontrivial turns of each face: two consecutive turns of one face can be combined into a single turn. For a correct optimal search, the heuristic must never overestimate the remaining cost, and pruning rules must not remove every representation of a valid solution. An admissible heuristic lets IDA* find a shortest solution in the chosen metric, though the search may still be expensive.

Test the implementation

Test move tables before building a large search. Apply a face turn four times and check that the cube returns to its starting state. Apply a move and then its inverse and check the same. Also test that every move preserves the corner-twist, edge-flip, and permutation-parity invariants.

Then generate short scrambles, ask the solver to solve them, and apply the returned moves to the scrambled state. The final state must be solved. For a known scramble, compare the result with the reversed, inverted sequence as an independent check. Longer scrambles and random legal states are useful later, once the state model and tests are reliable.