by Nicolò Chioato

Twenty Days, a Couch, and a Rubik’s Cube
It was the autumn of 2022, and I had just undergone surgery for two herniated discs in my back.
My recovery came with some fairly strict instructions: I couldn’t stay on my feet for too long, but more importantly, I couldn’t sit down. That meant no board games, no computer, and not much television either. For about twenty days, I could essentially do only two things: walk or lie down.
A tragedy.
Fortunately, at the time I was learning how to solve a Rubik’s Cube. So I spent a lot of those days lying on the couch with the cube in my hands, turning it over and over, studying it, and trying to memorize the algorithms needed to solve it. After staring at it for long enough, one day a rather strange thought occurred to me:

“What if the creator had chosen these particular colors for a reason?”

What if yellow meant loot? Blue meant the sea? Red meant danger? Green meant open plains?
What if, all these years, we had been solving the cube as a simple puzzle without realizing that behind those colors there could have been a story of journeys, monsters, treasures, and adventures?

Of course, I didn’t actually believe Ernő Rubik had hidden a fantasy game inside his cube. But the idea was there now.

One Face, One Tiny Adventure

There was one property of the cube that particularly fascinated me: the six center pieces always remain in the same position relative to one another. Everything else moves, rotates, and gets scrambled, but the centers do not. So I started imagining that each center could represent a hero, while the eight squares surrounding it formed a sort of micro-map. Suddenly, when I looked at one face of the cube, I could see a scene.

The yellow hero, for example, became a thief, specialized in recovering as much treasure as possible. There was a monster to his right. Another was approaching from the opposite corner, skirting the orange desert in front of him. Behind him, the sea blocked his escape, but to his left there was treasure waiting to be claimed.

All he had to do was defeat the monster beside him, and the loot would be his. Nine colored squares had become a tiny adventure.

One of the first scenes I imagined while looking at a face of the cube: the yellow hero surrounded by monsters, terrain, and treasure.
The First, Gloriously Useless Prototype

At that point, I wanted to see the idea physically in front of me. I happened to own a LEGO cube onto which pieces could be attached on every side. I could even place a LEGO minifigure in the center of a face, which seemed perfect for representing the hero. It felt almost made for the job. So I built the first prototype of Dungeon Cube.

It didn’t work.

The first Dungeon Cube prototype. Much more useful for discovering what not to do than for actually playing the game.
The problem was that I needed to communicate far more information than those tiny LEGO pieces could convey. A monster, a chest, a trap, a coin, a mountain — on such a small space, each element needed to be recognizable immediately. LEGO pieces were either too abstract, or, when I tried to make them more descriptive, simply too large. I needed symbols.

From LEGO Pieces to Stickers

The second prototype kept the LEGO hero in the center of the face, but the other squares were replaced with stickers. Monsters, treasures, and obstacles could finally have a clear visual identity.

The second prototype. Visually, it was getting much closer to the final idea — but the actual game was still missing.
Now I had a hero, and I had a vocabulary of symbols. The important question remained: What was the player actually supposed to do with them? My first idea was to connect the symbols physically to the hero. If a mission required the hero to equip a sword, the sword symbol should end up next to the minifigure’s arm. If the hero had to confront a monster, that monster should be directly in front of him. And that was when the core mechanism of the entire game began to emerge:

Manipulate the cube to bring the right symbol into the right position.

The missions would give narrative meaning to those configurations. You were not simply moving symbol X into position Y: that symbol might be a sword the hero needed to wield, a monster they had to face, or a treasure they needed to reach. A configuration of nine squares could tell a story.

Giving the Colors a Meaning

At this point I returned to the question that had started the whole project: “What if these colors really did mean something?” I decided that each color should have its own thematic identity.

Red would contain monsters, dangers, and threats to fight or avoid.

Yellow would contain treasures, coins, gems, and other rewards.

Blue would represent the sea, water, and similar elements.

White would contain allies, help, and generally positive elements.

Green would represent travel and open spaces.

Orange would represent mountains, difficult terrain, and challenging routes.

These associations changed and evolved during development, but one thing I still find amusing is that the final version of Dungeon Cube remains surprisingly faithful to them. I now had the heroes, the symbols, the colors, and the missions.

It was time to actually play the game.

A Puzzle Wasn’t Enough

The first tests were disappointing. Simply using a symbol’s position relative to the minifigure wasn’t precise enough. It wasn’t always clear which square counted as being “in front” of the hero, when a monster was supposed to attack, when it could be defeated, or exactly what consequences it should have. I could have written everything explicitly on the mission card: “Move this symbol to exactly this square.”
But then the game would have become: “I managed to get symbol X into position Y in three moves instead of four.”

That wasn’t what I wanted. I wanted the player to have a specific objective, but I also wanted things to happen while they were trying to accomplish it.
Perhaps while trying to reach a treasure, they would encounter a monster. Perhaps they would be forced across a mountain and suffer fatigue. Or perhaps they would unexpectedly discover something useful. The cube couldn’t just be the puzzle. It also had to generate the consequences of solving that puzzle.
That was when I came up with what I called the connection points.

Connection Points

Every symbol on a movable square would have one or more small connection points. The hero’s center square would have corresponding points of its own.
Whenever a connection point on an outer square lined up with a matching point on the hero, that symbol became active.

That was all I needed. Now you could look at your face of the cube and immediately understand what was happening.

– If the activated symbol was the one required by the mission, great.

– If it was a monster, you fought the monster.

– If it was an obstacle, you suffered its effect.

– If it was a bonus, even better.

Connection points solved one of the fundamental problems of the design: they made it immediately clear which elements on the face were interacting with the hero.
For the first time, you could actually read a face of the cube. The system seemed to work. Then I ran into a much bigger problem.

Too Many Moves, Too Many Monsters, Too Much of Everything

I started writing more complicated missions. A mission might require, for example, two different symbols to be present on the same face at the same time. To create that kind of configuration, the player inevitably needed to make several moves. Initially, I resolved the hero’s face after every single move.

It was a disaster.

Getting two symbols into the right positions could require a long sequence of rotations. Every rotation meant checking the face again, activating new symbols, fighting more monsters, and resolving more bonuses and penalties. A simple mission turned into an endless chain of effects. It was clumsy, slow, and almost impossible to control. This problem stopped development for weeks. I had the object. I had the concept. I had even found a way to turn the squares of the cube into a little story. But I couldn’t turn it into a game that was actually enjoyable to play. I seriously considered abandoning the project.

The Solution Was Already Inside the Cube

Then, one day, I was back on the couch. I was studying algorithms for solving the Rubik’s Cube when I noticed something that, of course, anyone familiar with the cube already knows: some algorithms allow you to rotate the lower layer — or even the two lower layers — without changing the upper face.
And suddenly I saw the solution. Not every move needed to have the same cost.

A player could freely make any number of moves that did not disturb their own face, while having only a limited number of moves that were allowed to change it.
In the version I was developing, this meant having two moves that could disturb your own face, plus unlimited moves that did not, before resolving it.

That one rule changed the entire game.

Complex missions could now be solved in a reasonable number of steps. Players could focus on the objective and manipulate the rest of the cube to prepare their position, but unexpected consequences still happened. I had finally found the balance I was looking for: enough control to make plans, but not enough control to prevent every surprise. That was probably the moment when Dungeon Cube actually started working as a game.

Six Faces, Six Heroes

I began writing missions and testing them.
But while working on them, another detail of the Rubik’s Cube kept returning to my mind. There are six center pieces. And in my game, each center represented a hero. Until then, I had mostly thought of the game as an individual experience, but why not use all six faces? What if several players played on the same cube?

I loved the idea of the cube representing a single shared world viewed from different perspectives. Each player could have their own hero, their own face, and potentially their own asymmetric abilities. Starting from the mission system, the most natural multiplayer structure was a race. Everyone would try to complete the same mission, but each player would work from their own face of the cube. At the end of their turn, they would physically pass the cube to the next player. The first player to complete the objective would be the one who had managed to do it using fewer turns — and therefore fewer meaningful moves — than the others.

This was not a dexterity race. Nobody had to perform cube algorithms faster than anybody else. It was a race of efficiency. And during the first multiplayer tests, something appeared that I hadn’t fully planned.

When you improve your own face of a Rubik’s Cube, you inevitably change the others as well. In other words, while trying to help yourself, you are potentially making life more difficult for your opponents. With the rule allowing unlimited moves that did not disturb your own face, this could even become intentional. A player could use those “free” moves to leave as many problems as possible on the next player’s face, forcing them to spend their precious moves clearing the obstacles. The interaction came directly from the physical structure of the cube. And once players became comfortable with the system, it was a lot of fun.

IDEAG

By this point, the prototype had almost reached its final mechanical form. I tested it with friends, collected feedback, and continued making changes. Eventually I brought it to IDEAG, the Italian gathering where board game designers bring prototypes to playtest and exchange feedback. That was when I noticed something I hadn’t really been able to judge while testing mostly with people I already knew.

The prototype attracted people.

A Rubik’s Cube turned into a board game was immediately curious. People would stop, look at it, and want to understand what it was and how it worked.
I received a lot of feedback there, and several of those suggestions found their way into later versions. The game worked. But there was still one thing that didn’t feel right. Failing a mission was too frustrating.

Failing, but Becoming Stronger

That problem found its solution after the game was signed by Red Glove. Development was handled by Federico Dumas, who introduced an idea that completed the structure of the game: a roguelite-style progression system. If a player failed a mission, they would not simply start over from scratch. The failed attempt still earned them a reward that could be spent on bonuses and upgrades. On the next attempt, they would therefore be slightly stronger. If they failed again, they would gain even more tools to work with.

Failure was no longer just a punishment. It had become part of the progression. This also meant that a particularly difficult mission could no longer become an impassable wall. You might not beat it on your first attempt, but by continuing to play you would gradually accumulate enough advantages to find a way through. That was the missing piece.

Six Heroes, One Story

At that point, the main mechanisms were finally in place. But the game still needed something I had not been able to give it myself: a real story capable of connecting all those missions. This was where Simona Lombardo joined the project. She wrote six stories, one for each of the game’s heroes. Those six adventures were not separate stories. They intertwined into one larger epic narrative, with meetings, twists, and different endings. That narrative structure finally gave the missions something they had previously possessed only in embryonic form:

A context.

A reason to face them.

A world to be part of.

Dungeon Cube

Then came the illustrations, the final graphic design, and the components. And the little prototype born during a forced recovery — after passing through a LEGO cube, stickers, minifigures, connection points, countless tests, and more than a few moments when I thought the whole thing would never work — finally became:

Dungeon Cube: La Furia dei Drahakor

Dungeon Cube: La Furia dei Drahakor in its final form.
Looking back, I find it amusing that so much of the final game was already hidden, although I couldn’t possibly have known it at the time, inside the very first question I asked myself while lying on the couch with a Rubik’s Cube in my hands:

“What if those colors really meant something?”