1. The Cube Is Not a Mobile Port — It’s a Separate Platform

• “When you move a classic PC mechanic onto a phone, it never really sticks — you have to reinvent the game. The same applies to the cube.”
• Example: Arkanoid — a great classic, but on the cube the mechanic “just doesn’t fit,” despite several attempts.
• Example: 2048 — the mechanic was redesigned from scratch; the only thing left from the original is number-doubling. The result feels natural on the cube, because the core experience—momentum, motion across faces—comes through intuitively.
👉 Rule: If the game feels like a port, it’s almost certainly dead on arrival.

2. Game-First Means Starting With the Core Mechanic

A crucial principle: you build a WOWCube game not from story, levels, or content, but from a central mechanic that:
• naturally fits the cube,
• feels tactually pleasant,
• creates a desire to repeat the action (the “fidgeting effect”).
Tips:
• A game should be built around an awesome mechanic, rather than visuals or lore.
• The core mechanic must be intuitive, pleasant, and natural.
• If the mechanic is weak, no amount of graphics or story will save the game.
Example: 2048 — the basic loop is: rotation → inertia → merge. Everything else (score, timer, goals) is built on top. A side example of a native-feeling mechanic: inertia in the iPhone contacts list. The list “flies” the way the human brain expects it to, even though there’s no real inertia. That natural feel is what you aim for.
Bad starting point: “Let’s make a dungeon crawler; we’ll figure out the controls later.”
Good starting point: “Rotating the cube launches objects with momentum — can that become a compelling gameplay loop?”
Ask yourself:
• What is the one action the player performs most often?
• Why is that action enjoyable specifically on the cube?
• Will the player instinctively want to do it again?
If the mechanic doesn’t spark a “I want to turn it again” feeling, keep searching.

3. Natural WOWCube Mechanics Are Not Taps and Cursors

This is straightforward: twist and tilt are the core mechanics. Taps and cursors are a necessary compromise and should be used sparingly.
Natural mechanics:

• Twist — rotating the cube to create changes in the game world
• Tilt — gravity-based movement or control
• Inertia — objects continue moving after the cube rotates
• Face recombination — treating the cube as a unified 3D structure, not a single screen
Non-natural mechanics:

• Taps — sensing is unreliable; acceptable for simple menu selection but not gameplay
• Cursor/selector — a poor fit, used only in menus when absolutely necessary
👉 Rule: If the game is mainly controlled through twists and tilts, it’s cube-native.

The Game Must Work Across All Faces and Use the Cube’s Form

Another foundational idea:
• “The cube inherits the logic of the Rubik’s Cube — the entire surface is active.”
• A WOWCube game should exist across all sides, not behave like a single flat screen.
This implies:
• The world can transition across faces.
• States can depend on orientation.
• The cube’s shape itself can be part of the puzzle.
👉 Rule: If the game looks like something that could run on a phone, that’s a red flag.

5. The Mechanic Should Not Just Be Possible — It Should Be Pleasant

The key criterion: it must produce the feeling of :“I want to turn it again.”
Fidgeting is a core part of WOWCube’s UX: The player performs an action → immediately sees the effect → enjoys it → repeats.
Example: A musical fidget toy — even without full gameplay, the simple act of placing different instruments on the top face is already fun. (The app with 24 instruments where only the four on the upper face play.)

6. Prototyping: Begin With a ‘Dirty’ Alpha Without Beauty

Strict requirements for the first prototype:

• no splash screens,
• no pretty graphics,
• minimal color, squares, pixels, text,
• a single level or even part of one,
• unfinished physics, unfinished bugs — fine.
Purpose of the alpha: Show that the mechanic plays. If it doesn’t — stop.
Example: 2048’s alpha was just squares with numbers.
Counterexample: A month spent on visuals wrapped around a dead mechanic.

7. Not Everything Can Be Tested in the Emulator — Real Cubes Matter

Most successful cube games rely on:

• physics,
• inertia,
• sound,
• weight,
• natural motion,
• fidgeting (the desire to twist and manipulate the device).
The emulator ≠ the cube. “Using the emulator is like smelling flowers through a gas mask.”
Therefore:

• Puzzles or puzzle-like games: emulator is fine
• Tilt/inertia/fidget-based games: must be tested on the physical device

8. The Marker of a Potential Hit — Tactility + Novelty

1. demonstrate that the cube is a unique platform,
2. be instantly understandable,
3. produce enjoyable, repeatable interaction (“fidgeting”).

Example of good thinking:
Reimagining Space Invaders for the cube:

• monsters crawl across faces,
• the player anchors themselves by orientation and aims by tilting,
• monsters shift with twists,
• shooting auto-fires when directions align.

This is how you reinvent a mechanic for the cube from scratch.

9. Development Priorities Must Be Set Correctly

Early in development, the focus should not be story. Instead, ask:

• How does the core mechanic work specifically on the cube?
• Why is it natural for twist/tilt?
• How does the game use all faces?
• What makes it cube-native?

This shift in questions is what changes the developer’s mindset.

10. The Main Test: Have You “Caught the Spirit of the Cube”?

Developers fall into two categories:

✔ Those Who Understand the Cube

• propose mechanics born from the device,
• use the cube’s shape,
• design from physical interaction.

✖ Those Who Don’t

• propose a story that doesn’t map to the hardware,
• drag over mobile patterns,
• rely on taps/cursors,
• think about graphics and levels instead of mechanics.

The Short Formula for a WOWCube Hit

A WOWCube game is built from a core mechanic that:

• naturally fits the cube’s physics (twist, tilt, inertia, multi-face structure),
• is pleasurable to repeat,
• operates across all sides,
• avoids mobile-style input,
• and is fun even in a raw prototype.

When defining your idea, ask yourself:

“What makes this game more enjoyable, more natural, or more interesting on the cube than on a phone or a computer?”

Excellent answer:
“The mechanic is genuinely pleasant and emerges from the cube’s shape, control, or face combinations.”

So-so answer:
“It will probably play about as well as it would on a phone/PC.”

Bad answer:
“On phone/PC it’s good; on the cube we’ll adapt it somehow — difficult but possible.”