Talk:Rubik's Cube

Rubik's Cube Primer

For the uninitiated a Rubik's Cube is composed of 20 moving pieces which rotate around the 6 fixed center sub-faces of each face.

Physical Design

For Discussing the outward appearance of the Rubik's Cube.

Size

Full cube has been suggested to be 64 meters to a side. Beyond that no details have been decided, that's the point of this page.

Face Design

Instead of the normal solid color decoration should be something MC related. Suggestions include:

Diamond Item
Pickaxe
McO Icon
Torch
Golden Apple
Slime Ball
Cookie
Mobs (Chicken, Wolf, Sheep, Pig, etc.)

- How about something thematically linked of which there are six? We have the six staple elements of minecraft... wood, stone, iron, gold, diamond, obsidian... each of which could go with a different face colour, and they link with the current donor kits too. So perhaps a wood spade, a stone axe, an iron hoe, a gold sword and a diamond pickaxe... but what would we have for obsidian? Riot 17:48, 31 July 2011 (UTC)

Display Guts

The current design uses Craftbook areas to toggle the images of the cube sub-faces.

The Brains

IGNORE THIS ATTEMPT TO MAKE MVC DESIGN PATTERN IN REDSTONE >_> --Rtkwe 17:05, 31 July 2011 (UTC)

Three Principle Components:

State Storage
Display Decoder & UI
Logic - Controls transitions between states and updating the in memory model

State Storage

Conatins the model of the cube. Stores a ccode representing the edge or corner piece which is a given edge/corner location. Total memory requirements are 16 cells of 4 bits apiece (2 types (edge/corner), 8 locations, & 8 different pieces for each location). Using this memory model should greatly simplify manipulating the state when a movement occurs. For construction of the cells themselves, D FLip-flops with reciever for new/old state output to/from Controller. Update signal is sent from central controller.

Display Decoder

Takes state from memory and sends signals to CB [Area] signs.

UI

Allow the player to select CW & CCW for each face. Deatails as yet undetermined.

Design

(Ideas throw them at me)

Control & Logic

There are 12 different transitions, CW & CCW for each face of the cube. Each transition, cube movement, there are a series of steps:

Load current state into D FLip Flops (simplest way to prevent a race condtion during the update step)
The buffer then uses transmitters to send the new state to the memory unit.
Trigger the update transmitter to load the new state into memory.
Wait for next transition input from user.

There are two crutial subsystems to the controller:

Reset

Simply loads the default solved state into the memory.

Randomizer

Scrambles the cube for new solve.

New Cube Control Design

Premises

The central 6 sub-panels are fixed and do not change
There are 6 different states (colours)
Each of the other sub-panels can be in any of the 6 states
There are 12 possible moves the cube can perform
Each individual sub-panel is only affected by 4 (edge panel) or 6 (corner panel) of those moves, the other moves do not change it
Each sub-panel thus has it's current state (colour) and 4 or 6 possible "next states" that it will change to, depending on what move is selected
When a move is performed, the correct "next state" for each affected sub-panel needs to be selected

Control

The control is based on matching the correct next state to the move that is performed. Each sub-panel is controlled by a control cell. The cells receive input/information about which state the surrounding 6 sub-panels mentioned above are in, thus information about all possible "next states". The input is received through wireless transmitters/receivers. This input is then fed into one half of an AND Gate. The other half of the AND Gate receives information about which move is selected. Each possible move and each possible state (colour) combination has it's own AND Gate. Thus, only the AND Gate that matches the move that is performed to the correct "next state" will become active. This, in turn, sets a RS NOR latch which feeds to the appropriate Craftbook Area sign of the affected sub-panel. Simultaneously, all other previously active RS NOR latches feeding into incorrect area sign of the affected sub-panel are reset so as to allow the to be set again with further cube moves. The correct RS NOR latch is unaffected by this reset.

Auto-solve and Scrambler

An auto solve that also acts as a reset is included, scrambler is a possible option.

UI

12 buttons corresponding to the individual move options. Transmisson for buttons is blocked as long as one is already active to prevent jamming. Transmission block can be done through Redstone means or by simply blocking the buttons with pistons (has the added benefit of allowing players to know when they can press a new button).

Shintyx 20:10, 31 July 2011 (UTC)

- I really like this idea - interactive interfaces like this are always the best. Riot 19:17, 1 August 2011 (UTC)

Terminology

To avoid confusion when talking about the planned project, some general terminology:

Face - One entire side of the cube. There are 6 faces, named by which direction they are facing: North, South, East, West, Top, Bottom. Each Face consists of 9 panels.
Panel - Sub-division of each face. Panels show the colours/pictures that can be moved around the cube. Each face has three different kids of panels: 1 Center panel (never moves), 4 Edge panels and 4 Corner panels.
Colour/State - The individual colours (can also be pictures) that the panels currently show. Named 'State' for redstone purposes. There are 6 different colours. Moving the cube so that all panels on one face show the same colour solves the cube.
Move - The individual moves that can be performed. Each face can make a clockwise (CW) or counter-clockwise (CCW) move, resulting in a total of 12 possible moves. Performing a move moves the colours on the panels in the direction that was selected.
Cell - One cell is the control unit for one panel. Every time a move is performed, it checks whether the panel needs to change its colour and selects the correct colour to show.

Shintyx 13:02, 3 July 2011 (UTC)