Making Rubik's Cube Simulator, can't figure out why move procedure isn't working

[andrew.jaynes]

Hi, I'm making a rubik's cube simulator, and I'm having an issue.

This is what you need to know about my code:

The cube is represented as a list of 6 3x3 matrices as shown.

A "Link" is what I call a list of 3 colors.

A "Location Code" (LocCode) is a list that refers to a place on the cube where a Link can be found.
It looks like this:

The string in the LocCode will be "r" if the LocCode represents a row, and "c" if the LocCode represents a column
The first integer in the LocCode represents the face where the LocCode can be found (Front:1 Right:2 Back:3 Left:4 Top:5 Bottom:6)
And the second integer represents which Link the LocCode is describing on that face. For columns, the top is 1, middle is 2, bottom is 3, and for rows it goes 1-3 left-to-right.

These two methods, which I have tested and which work as far as I know, are meant to "read" from and "write" on different LocCodes. My question doesn't involve these methods, and you don't have to look at them, but here they are just in case.

thank you for reading - stay with me here

Then, I have a dictionary which defines the sequences of LocCodes that are associated with each Rubik's cube "move"

Here are the moves if you don't know:

And here is the dictionary

So, just to make sure you understand this,
Take specifically the "U" move
This represents the "U" move (rotating the top row on the cube clockwise)
The four LocCodes represent the order of the transfer of Links that happens when you make the U move. [r,1,1] goes to [r,4,1] which goes to [r,3,1] etc.

I understand that my code doesn't account for the fact that the 9 squares on the face itself also rotate. I will code that later.

Ok, finally, here is the procedure that isn't working.

The parameter "text," is the standard Rubik's cube move notation.
See the picture above^ if you don't know what those are.

The variable "wise" is true if the move is normal, false if it's reversed, and 2 if it's a double.
I haven't coded or tested reverse or double moves. The standard moves aren't even working

When I run this code (which I have tested and looked over about a million times) with the parameter "U", and with the starting cube that I showed above^^, the Links move around in ways I wouldn't expect.

[Pictured are the front, top, and left sides of the cube]

I cannot for the life of my figure out why this would be happening.

You can also try the entire code yourself, here it is:
rubiks.aia (22.3 KB)

I know this is a big and hard-to-understand post, but I know there are smart people out there who can help. I'm submitting this for my computer science final project which is due Friday please help.

[ABG]

Do you have a link to an online explanation of your link coding system, or is this original with you?

[andrew.jaynes]

No, sorry but it's original with me.

A "Link" is a list of three colors that are in either a row or a column somewhere on the cube.

this represents a transfer of links that would happen in the move F

The link in red would be represented by the LocCode ["c", 4, 3] (third column on the fourth face), and it would be moving to the new LocCode ["r", 5, 3] (third row on the fifth face).

I hope this makes sense please LMK if there's anything else I can clarify

[ABG]

I think I need to sleep on this.

The identification of the 54 (6 * 9 ) squares can be thought of as a three digit (or letter) string for each square, embodying face (a letter), row 1-3, column 1-3, but I have not yet grasped how to assign those rows and columns to the squares on each face, what with all the faces facing in different directions.

Once such an assignment is laid out, a move then would map 8 + (4 * 3) = 20 identifiers' colors through cycles 8 and 12 units long.

Off to think (sleep) on this more...

[andrew.jaynes]

Each of the squares on the cube is referred to as a color literal in a 3-dimensional list.
6 faces, 3 rows per face, 3 colors per row

The Links are just helpful ways of shuffling around the squares by grouping them into lists of three.

The "push/grab Links" methods allow you to read or write any Link of 3 colors in a row, whether that's a horizontal row or a vertical column. If the Link grabs from a row, it can just copy that preexisting row from the cube database. But, if the Link grabs from a column, it has to traverse three rows and grab one from each.

The LocCodes are used to tell you the different locations where Links can go.

The rows and columns are numbered like so-- this might make things easier to understand:

Grouping them as such allows for them to move as four blocks in one cycle that's four units long. Don't worry about rotating the 8 cubes on the face right now, I will code that in later- just need help no this specific problem.

Thanks for agreeing to help with this! It is due Friday and I really need the support!

[Kevinkun]

My work until now, but I need To leave my computer for several days, maybe explain my idea later.

EDIT:
the U move procedure has a bug, the for each number should be from length of list to 2 step -1. i will edit the image later.

[andrew.jaynes]

Ok I think I understand. I will have to rearrange the data structure, scrapping all the Link stuff, and reformat my code to accommodate, but I suppose it is worth it.

Can you make the procedure general, so it can be used for any move, take the name of the move as the parameter to the method, and then make a dictionary of all the different CSV files that you can reference?

[Kevinkun]

if you understand the idea of how it works, then you can make the other move like U', F, F'...
and adopt it to with parameters.

[andrew.jaynes]

Yes. I think I can.

For the Prime moves, I think I will just systematically copy and then reverse each of the CSV rows in the code- and then for the double moves can I think I'll just run the code twice

[ABG]

The idea of assigning each tile a unique name as key is important.

It simplifies things considerably.

Also, a temporary variable is needed for reassignments into however you store your tile colors, just as in a bubble sort you need a temporary variable to do a swap.
The temporary variable could even be a copy of the entire setup, to avoid rewriting your inputs during a loop over the structure.

Whatever ID system you choose, you will need either to store (or generate) your display polygons by ID, or map your IDs into how you feed your display code.

It may be helpful to keep for each face two lists of tile addresses:

• an inner ring of tiles on that face, to support rotation of the face, and
• an outer ring of tiles on adjoining faces, to support rotation of the border colors.

[andrew.jaynes]

I think I'm going to have the list of 6 3x3 matrices I showed earlier for display purposes, and then i can transfer the data to and from the One Big List you had in your code, useful for moving purposes

Thanks for all your help!

[dyjkim]

Just got to say, what an interesting APP!

[ABG]

@andrew.jaynes

For the Prime moves, I think I will just systematically copy and then reverse each of the CSV rows in the code

Or you could run a non-prime move three times, to get the same result.

[ABG]

For what it's worth, here is a version using a list and dictionary based rotation scheme, using your front end.

rubiks_ABG.aia (17.9 KB)

[andrew.jaynes]

Thanks! I think I'm going to organize the rendering code a little differently (I'm still going to use the 3x3 matrices for rendering purposes, and have ways to transfer in between that and raw data). But, this is still useful to see

[ABG]

I thought this was due last Friday.

Did you get an extension?

There is still room for improvement in my code, where I have multiple sections of the same code fed by different CSV tables. Those could be calls to a common routine with an extra parameter or two.