markforster / cubits Goto Github PK

Cube state is currently an array of Vectors and the information stored in the vectors are used to both perform rotations and transformations and to determine the location and orientation of layers and faces as well as to determine which cubits and faces are center pieces, edges and corners which in turn is an important part of determining which faces / layers are solved.

A niave attempt at protecting cubestate is currently implemented by marking the cubestate property of a Cube as readonly however, this isn't really useful. First of all a cube instance will simply operates on the instance of the cubestate it has a reference to. Transformations and checking solved state are all based on the emergent properties of this state which means in practice the cubestate for a Cube could be switch out with another cubestate and the Cube could still functional perfectly fine with that new state.

Transformation and Solve state could break if the values stored in the Vectors are changed for example: If the position vertex of a vector contains values other than 0 or 1 then the implementation will struggle to determine which cubits are aligned and so on the same layer; If the direction vertex of a vector is NOT aligned to face outwards from the position vertex relative to its starting position then the implementation will also have a hard time determining what faces of the cube are solved.

The implementation needs to protect the Vector and Vertex information so that the cubestate can not be directly modified outside of the Cube instance.

Is your feature request related to a problem? Please describe.
We have the following implementations of comparing arrays:
src/lib/compareArray.ts
src/lib/arrayEquals.ts

Both implementations look almost similar. One throwing an exception!! but almost identical

I figure in my haste to get this all working I didn't stop to check if i'd already written it

Describe the solution you'd like
Remove all but 1 implementation and refactor the code where the others are used to use the final chosen implementation.

My recommendation is to remove src/lib/compareArray.ts as this throws an exception if the array lengths are different! It would be better to simply return false as the arrays are clearly not the same if they are different lengths. An exception seems aggressive!

Describe alternatives you've considered
No alternatives. There should not exist 3 implementations of the same feature

Additional context
More haste, less speed.

I have observed the following (using the example files as a base and substituting the colour to test each face):

import { ICube } from '../src/cube/ICube';
import { CubeRotationDirection } from '../src/cube/lib';
import { COLOURS } from '../src/lib/colours';
import { cubeExample, showCubeDetails } from './lib';

const color = COLOURS.WHITE;

cubeExample(`Rotating ${COLOURS[color]} side clockwise once`, (cube: ICube) => {
  showCubeDetails(cube, 'Starting Cube');

  cube.rotateLayerForColour(color, CubeRotationDirection.ClockWise);

  showCubeDetails(
    cube,
    `Cube rotation: <Side ${COLOURS[color]}, Direction ClockWise>`,
  );
});

White, Green and Red rotates clockwise and anticlockwise as expected however Orange, Blue and Yellow rotate counter to the rotation direction specified.

The common property of all faces that rotate correctly is that the vector direction of the cubits of each face are all a positive value. For those that do not rotate correctly the vector direction of the cubits of those faces have a negative value.

The obvious fix is to check if the vector direction for the face (via the centre cubit) is negative and if it is reverse the rotation direction of that which is being specified

Currently cube layers and faces can be rotated clockwise and anticlockwise specified via a colour through its interface.

Orientation is assumed to always be white on top with green to the front and orange to the left (Yello, blue, red respectively).

In order to provide better support for visualising and operating the cube orientation needs to be implemented. Orientation should support an [X, Y] format or some permutation of allowing the operator to orientate and visualise the cube. This will become important once the operator wishes to execute cube notation on the cube and the orientation can no simply be implied!

Right now the ICube interface provides features to rotate a cube, rotate a layer by colour and check if a colour layer OR the cube as a whole is solved however the only way to know what changes have been made to the cubes state is to a) pass a CubeState to the Cubes constructor on instantiation then b) query the cubestate to determine what configuration it is on. In addition to this from the outside looking in there is no meaningful way t derive data beyond position and direction of the vectors in the cubestate without understanding more about the inner workings of how the Vectors stored within the cubestate relate to the specific colours of each Vector.

Internally the 54 vectors that make up the Cubes individual cubits are arranged in such a way that their indices determine their colour. Although through rotation the Vertex information is changed to represent the position and orientation of each cubit the index of each cubit in the cubestate never changes which allows the current implementation to use a simple algorithm to derive a cubits colour based on its index position (via modulus of 9) see src/lib/colourForIndex.ts.

Rather than expect another developer to have to figure this out and implement their own methods to derive this information the following changes should be made:

1. Expose any library methods that will expose information about layers and their colours so meaning can be extracted from the cubes state
2. Possible provide convenience methods to simplify extracting this information for example: A method to get the colours of all cubits for a given face or layer either by a Vertex specifying the axis / direction or by a colour. This way the code can be useful to any script that intends to render the cube.

Implement a cube operator as either a stand alone class or as a decorator. The operator should initially provide convenience and QOL methods to better manage the cube state ideally via its base ICube interface.

Additionally the cube operator could take list of rubiks cube notation, interpret it and perform operations on the cube. The notation may need extending a little in order to provide support for orientation of the cube

The initial unpacked size of the NPM module ended up at about 69kb. I reduced this down in a previous commit by configuring tsc to remove comments bringing it down to about 38.9kb

I want to go through the code and look for opportunities to reduce this further by reducing characters.

for example: converting 'function' declarations into 'const ?? = () =>' etc

In the short term this could reduce the file size marginally. I may look to build with webpack using a configuration I have from another project however this would mean i'd need to better structure my module exports!

Low hanging fruit for now!