# How to construct a cubie representation of a rubik's cube, given an array

Just to get this out of the way, I have seen this, and it is not what I'm looking for.

So, let's say you are programming a Rubik's Cube. (I know, very unoriginal, but bored programmers have to do something..) This Rubik's Cube is defined by an array of six 2-D arrays (one for each face,) and these 2-D arrays' sizes vary, based on the size of the cube. For instance, if I had a 3x3x3 cube, the array would be 6x3x3. That is, it would have 6 3x3 arrays.

Now, let's say I wanted to get an array of the cubies which make up this cube. Each cubie is defined by two things (I think..): the colors of it and its location on the cube. For example, if you had a solved cube, one of the cubies would be the red, green, and yellow cubie, and, assuming yours is sitting in the same orientation as mine, that cubie would be the front, right, up cubie.

However, none of this answers my question: how do I go about defining a set of these cubies, given an array of variable sizes. I know, for instance, that the cubie previously mentioned could be defined as cube[0][0][dimension-1], cube[2][0][0], cube[4][dimension-1][dimension-1]. (For a bit of reference, the order in which I define my faces is front, back, right, left, up, down. Hence the 0, 2, and 4, making front, right, and up.)

Anyway, with that said, I'd rather not hard-code all of this and was wondering if there was a simpler way. So, what's the best way to do something like what I was just describing?

Edit: For clarification, I am trying to get the separate, individual, smaller cubes which make up the Rubik's Cube as a whole. For instance, the piece with the red, green, and white stickers on it.

-
Just to be sure I understand, the previous question dealt with just the colors of the stickers on the faces of the cubies, but you also want to be able to easily identify the solid hunks of plastic to which those stickers are attached, for example to know that the cubie that originally was top left front has returned to the top left front location even if its faces are not oriented the same way? – David K May 22 '14 at 12:14
@DavidK Yes, that is correct. – Steven Fontaine May 23 '14 at 16:40

There are a few ways to do this.

In addition to the six 3x3 arrays containing the colors of the stickers, you could have a 3x3x3 array representing the solid cubies. (The interior cell of this array can be ignored.) The cells of the 3x3x3 array could then contain integers (or pointers to more detailed objects) describing the original location of each cubie. You just have to make sure you do the appropriate "rotation" of the 3x3x3 array each time you "rotate" the stickers.

Or you could just put everything in one 5x5x5 array. The central 3x3x3 array could represent the solid parts of the cube and the central 3x3 array of cells on each face of the 5x5x5 array could represent the stickers.

Another alternative: just a 3x3x3 array, in which each cell contains a pointer to a structure. The structure identifies the original location of the cubie and the colors and locations of the stickers on its faces. The structure also contains a modifiable integer that describes the orientation of the cubie: a particular value (say, 0) for the orientation the cubie "should" have in a fully-solved cube, and 23 other values representing the other possible orientations of the cubie after a sequence of rotations. You also need a function (which could be a simple table lookup) that says which orientation results from each possible quarter-turn applied to each possible orientation. You will also probably find use for a function that says, for each orientation, what face of the original (orientation 0) cubie is on the top, bottom, left, and so forth. To rotate a slice of the cube, you have to permute the contents of the moving cells, of course, but you also have to correctly modify the orientation of every cubie in the rotated slice (including the cubie in the center of the face for a face rotation, even though the location of the cubie does not move).

-

It sounds like you might like my answer here: http://programmers.stackexchange.com/a/262847/156217

The basic idea is:

1. Address the cube in an x-y-z coordinate system, with a center at (0, 0, 0).
2. A Piece class stores a position (x, y, z) and colors (cx, cy, cz). The Piece knows which sticker colors are on which axis (x, y, or z) but doesn't know which direction the sticker is facing.
3. The Cube stores an unordered list of Pieces.
4. Rotations are done by updating the position and colors of the relevant Pieces.

This is nice because all rotation logic is confined to the Piece class. A Piece doesn't know its orientation, but it doesn't need to. The orientation of a Piece is strictly dependent on its position: the corner at (-1, -1, -1) is the LEFT-UP-BACK corner.

-