Guest Post: By Nicolas Mayoraz

I have always been fascinated by puzzles of all kinds. I love that moment when “this seems impossible” transition into “Wow! I think I got it”.

Very young, I remember cherishing a sliding tile game of 31 white and red tiles with golden engraved numbers locked in a 4 by 8 black frame. I was playing it so much that the plastic tiles were getting harder to move around, until my father had the great idea to grease the toy. It surely did a marvel to the gliding of the tiles, but to this day, I cannot dissociate the memory of my dear game with the smell of the drops of motor oil it had swallowed. |

On the back of the frame was depicted a series of configurations to be reached. One of them was appropriately named “impossible”. This first mesmerized me, and I surely deployed some vain tenacity to prove it wrong, until I realized that actually half of all configurations are possible and the other half are impossible. I convinced myself of that fact by breaking open the game, and observed that I could put back all the tiles in any arbitrary order, until the last two tiles, the order of which will determine which half of the configurations are possible.

In 2006, I first got the idea of the iQube by playing mindlessly with poker dice on a table.

**What if we had a game like the tile game, but replacing the sliding tiles by rolling cubes?** While the Rubik’s cube is a great object that once in hands calls for being operated, I distinctly envisioned how the iQube would be ideal for an electronic device where its cubes would be spinned smoothly by a finger gliding on the surface of a touch sensitive display. Each cube would be numbered and have protuberant colored facets so that one can simultaneously see the colors of several facets. |

Before embarking in the venture of programming it, I needed to convince myself that the puzzle had some potential of being interesting, which in my book is synonym of hard to crack. I’ll describe in a separate blog the different considerations and back of the envelope estimations I did to gather evidence of the potential of the game. I initially tried to get a sense of the intricacies of the puzzle by rolling dice on a table. But this approach did not go very far and I needed the real deal to play with in order to find out the true depth of its secrets.

At that time, I was teaching my teenager sons Hadrien and Calixte the basics of programming using flash and actionscript from Macromedia. That was a perfect medium to develop a prototype for the iQube. As I was eager to get a glimpse on the difficulty of the puzzle, my first draft was graphically minimal, primary colored cubes were jumping abruptly from one state to the next. However, this prototype was good enough to deliver a first finding about the iQube which considerably raised my enthusiasm about the game. He who has ever played with the Sliding Tiles knows that the puzzle can be constructed iteratively, row by row, tile by tile. The only tricky part is that the last two tiles of a row or a column have to be placed simultaneously. Once we figured out how to do that, the Sliding Tiles had no more secret. Given the similarity between the iQube and the Sliding Tiles, I was half fearing that this property would hold for the iQube. I finished coding the first draft in flash one night at 2 am and started playing with an instance of five numbered cubes on a two rows and three columns grid. Starting from a well organized configuration (as in the left illustration), and shuffling the pieces around, I then tried to recover the original organization.

I noticed that placing correctly the two cubes in the first column (cube 1 and cube 4, as in the right illustration), which was itself a non-trivial task, did not lead to a configuration where the other three cubes (2, 3, and 5), when confined in the last two columns, where a few movements away from being correctly placed as well. Woohoo! At that point I knew that the iQube was challenging.

In the next few months I improved the flash version of the game, adding different challenges, simulating a continuous motion of the cubes (done the hard way, before the advent of actionscript 3D). Hadrien eventually polished the game and gave it its present look-and-feel.

Along the way, I played with it and explored its various enigmas. I needed to find out whether there was a way to go from a given configuration, say all cubes in the same orientation and in order, to another given configuration, like all cubes in the opposite orientation and in the same order. At first, I was playing with 8 cubes in a 3x3 grid with the initial empty position in the center of the grid. My colleague Hai Dang Thai I had shown that game to found an elegant solution exploiting the symmetry of this configuration. This solution does not apply once the initial empty position is moved in a corner. For 8 cubes in a 3x3 grid, my first solution required several hundred moves, which I suspect is far from optimal. Soon, my original excitement fueled by the complexity of the puzzle got replaced by a concern that game might be actually too hard for being truly appealing. To convince myself of the contrary, I needed other persons to crack it. Both Hadrien and Calixte eventually did it, and Calixte even improved my own solution, resolving the Grand Master challenge in 246 moves.

The iQube Grand Master is challenging, but not enough to intimidate motivated teenagers, which puts it in the same league as the Rubik’s Cube.

In 2008, Philip Dhingra, an IOS app developer, wrote the first version of the iQube for the iPhone, using OpenGL for rendering the cubes in 3D. My wife Mita, fully aware of the longer lasting appeal of games over pure puzzles, insisted that a more casual mode of play be added to the challenges. Together we designed the scramble mode, where a series of quizzes are generated by shuffling few random moves from an organized configuration, the aim being to unscramble it in the same number of moves. This addition allowed for gentle progression in the intricacies of the iQube, and turned the single brain basher puzzle into a game with thousands of little brain teasers, proving hours of fun.

When my daughter Anjeli was 7 years old, she was well versed in many puzzle-like games such as Cut-the-Rope, Where-is-My-Water, and later Bad-Piggies. She suggested to add a reward system to the iQube Scramble, and pretty much designed the current points system, with points being accumulated with the resolution of each puzzle, the better the solution the more points, which points are then needed to unlock higher levels in the game.

In summary, the Genesis of the iQube puzzle has been very much our family enterprise over several years, and I hope that the fun and enjoyment it provided us while slowly shaping it into the app you find today on the AppStore or on our website will be transpire to you, the player, and you will find hours of gratification deciphering its many facets.

Along the way, I played with it and explored its various enigmas. I needed to find out whether there was a way to go from a given configuration, say all cubes in the same orientation and in order, to another given configuration, like all cubes in the opposite orientation and in the same order. At first, I was playing with 8 cubes in a 3x3 grid with the initial empty position in the center of the grid. My colleague Hai Dang Thai I had shown that game to found an elegant solution exploiting the symmetry of this configuration. This solution does not apply once the initial empty position is moved in a corner. For 8 cubes in a 3x3 grid, my first solution required several hundred moves, which I suspect is far from optimal. Soon, my original excitement fueled by the complexity of the puzzle got replaced by a concern that game might be actually too hard for being truly appealing. To convince myself of the contrary, I needed other persons to crack it. Both Hadrien and Calixte eventually did it, and Calixte even improved my own solution, resolving the Grand Master challenge in 246 moves.

The iQube Grand Master is challenging, but not enough to intimidate motivated teenagers, which puts it in the same league as the Rubik’s Cube.

In 2008, Philip Dhingra, an IOS app developer, wrote the first version of the iQube for the iPhone, using OpenGL for rendering the cubes in 3D. My wife Mita, fully aware of the longer lasting appeal of games over pure puzzles, insisted that a more casual mode of play be added to the challenges. Together we designed the scramble mode, where a series of quizzes are generated by shuffling few random moves from an organized configuration, the aim being to unscramble it in the same number of moves. This addition allowed for gentle progression in the intricacies of the iQube, and turned the single brain basher puzzle into a game with thousands of little brain teasers, proving hours of fun.

When my daughter Anjeli was 7 years old, she was well versed in many puzzle-like games such as Cut-the-Rope, Where-is-My-Water, and later Bad-Piggies. She suggested to add a reward system to the iQube Scramble, and pretty much designed the current points system, with points being accumulated with the resolution of each puzzle, the better the solution the more points, which points are then needed to unlock higher levels in the game.

In summary, the Genesis of the iQube puzzle has been very much our family enterprise over several years, and I hope that the fun and enjoyment it provided us while slowly shaping it into the app you find today on the AppStore or on our website will be transpire to you, the player, and you will find hours of gratification deciphering its many facets.