From a C++ Experiment to Spheriz: Rethinking the Falling-Block Puzzle

More than two years ago, Spheriz did not have accounts, levels, achievements, skins, ads, or purchases. It did not even have a proper mobile interface.

It was a C++ window with some circles, some dots, and a falling piece. And that was enough.

I was experimenting with game ideas at the time and kept coming back to falling-block games. The underlying idea behind Tetris and everything it inspired is genuinely strong: a tiny ruleset, an increasingly constrained space, simple pieces, and unexpectedly deep decisions. Tetris is brilliant. That's not the part I had a problem with.

The problem was scrolling through the App Store and seeing how much of it was the same rectangular grid wearing a different outfit. "Block Game." "Block Puzzle." "Block" something. Plenty of these changed the colors, the name, the UI, whether pieces drag or fall, but a lot of them still lived on the exact same rectangular board underneath. I did not want to make another one of those. I wanted to know whether there was unexplored territory inside the mechanic itself.

What If the Board Was Circular?

The question I kept asking myself was simple: what happens if the blocks still fall, but there is no bottom? What if they move toward a center instead? And if there are no horizontal rows to clear, what should the player clear instead?

The answer I landed on was rings.

The original model was a circular board divided into concentric layers and radial sectors. Pieces enter from the outside and travel inward. Complete a full ring around the center, and it clears. It kept everything that makes falling-block games work: pieces arrive, you rotate them, you place them, you complete a structure, the structure clears, and eventually you run out of room if you're not careful. What changed was the player's spatial reasoning. You stop thinking left and right. You start thinking in sectors, layers, and gaps around a center.

The Original C++ Prototype

The first version of this looked about as far from a finished product as you can get. A grey circle in the middle, a ring of dots radiating outward, and a tiny black tetromino-like piece sitting above it, waiting to fall.

It wasn't a product. It wasn't trying to be. It was a proof of concept with exactly one job: answer the question "can this mechanic actually work?" And it did. Placing a piece into a radial sector and watching a ring complete felt like a real game loop, even wrapped in placeholder grey dots.

The 2D / 3D Drawing

Once the board was circular, extending it into a sphere felt like the obvious next question. I sketched it out by hand: a 2D radial grid next to a 3D globe grid, side by side, both labeled Spheriz.

2D asks "what if falling-block placement happened around a circle?" 3D asks "what if it happened around an entire object?" That distinction is where Spheriz started to feel like it had its own identity instead of being a reskinned grid. A circle is still fundamentally flat. A sphere is a different kind of problem entirely.

And Then I Left It Alone

I want to be honest about the part that doesn't fit neatly into a highlight reel: proving a mechanic works and shipping a product are two completely different amounts of effort, and I did not close that gap quickly.

How should pieces behave? How large should the board be? How should scoring work? How should the player actually control a sphere with their thumb? How do you make depth readable on a small, flat phone screen? What should progression look like? Why would someone open this again tomorrow? What's the business model? None of those questions had answers yet, and for a while, Spheriz just sat there as an interesting experiment I'd occasionally poke at.

But I kept coming back to it. Not out of obligation, just because the core idea still felt worth finishing.

Coming Back With a Different Goal

When I picked it up seriously again, the goal had changed. It was no longer "make the prototype look better." It became "make something I could actually publish."

That meant a real rebuild, this time on a mobile stack: React Native, Expo, and TypeScript, with Skia handling the 2D rendering so the radial board could stay smooth and responsive on an actual phone instead of a desktop window.

The modern 2D version kept everything the original prototype got right: a center, radial sectors, concentric rings, pieces moving inward, rings clearing when completed. The player still ends up thinking in sectors and layers instead of conventional rows, just now with actual colors, actual physics, and an actual score counter instead of a debug window.

Making It Work in 3D

"Just turn the circle into a sphere" sounds simple on paper. In practice, it changes the interaction almost completely.

A phone screen is flat. Half of a sphere is, by definition, facing away from the player at any given moment. You can't just drop a piece and hope it lands somewhere sensible, because the player needs to actually understand where it's going to land, including on the side of the globe they can't currently see. So the globe itself had to become part of the controls: drag to aim, rotate the piece, drop it, and rotate the whole thing again when you need to check the far side before committing.

I originally thought of 3D as a visual extension of the 2D mode, basically the same rules with better lighting. It turned out to be a genuinely different spatial interpretation of those rules, and building it that way, rather than as a camera trick bolted onto the 2D board, is the only reason it actually feels like its own mode.

A Game Needed More Than an Endless Score

Endless scoring is fine for replayability, but it doesn't ask the player to solve specific problems. It just asks them to survive longer. Levels let the game pose actual questions: score this much, survive this long, clear this many rings, do it with this few pieces, hit this clear streak, fit this exact piece into this exact gap, clear the entire board.

Classic 2D and Classic Globe each got their own 100-level campaign built around these constraints. By level 91 through 99, that's things like surviving 142 seconds, clearing 8 rings, or reaching a 5x clear streak. Level 100 is where it stops being a normal level and becomes a boss fight of sorts.

Level 100: Singularity

Singularity's objective is a perfect clear, a 4x clear streak, and a score of 25,000, all in the same run, all rated Impossible in-app for a reason.

By that point the level isn't really an endless run with a harder skin on it. It plays more like a puzzle scenario: you're planning several conditions at once instead of reacting piece by piece, because progress toward one objective often has to double as progress toward another.

Everything That Isn't "The Game"

Here's the part that took longer than the gameplay itself: a working renderer and a fun mechanic were nowhere near enough to actually ship this. A real mobile product needed accounts, cloud-backed progression, achievements, leaderboards, daily challenges, sensible offline behavior for players without a connection, purchase restoration, advertising, reward validation, account deletion, a store, a virtual currency, a Premium tier, cross-device state, and a plan for what happens when any one of those things fails.

The prototype only had to answer "is this mechanic interesting?" The product had to answer "can this survive real users?" Those are very different bars to clear, and the second one is where most of the actual engineering time went.

Orbs, Cosmetics, and Monetization

I didn't want Spheriz to be pay-to-win. It's a competitive, score-based puzzle game, and letting someone buy gameplay advantages would undermine the entire point of a leaderboard. But a real mobile game still needs a business model that isn't "hope people feel generous."

The answer was cosmetics: spheres, block styles, backgrounds, trails, drop effects, clear effects, spawn effects, and combo effects, funded by Orbs, a one-time Premium purchase, optional purchases, and ads for players who'd rather not pay anything. None of it changes how the game plays. It changed how it looks and felt like yours. The categories grew organically, starting with simple block color variants and eventually expanding into full curated collections that coordinate material, motion, and interface styling across everything you've unlocked.

When the Economy Became Real

This is the part that quietly changes everything about how you're allowed to write the code. Once a virtual currency can be purchased with real money, client-only state stops being good enough.

Before money is involved, "the player has some number of Orbs" can just be local data sitting on the device. The moment real money enters the picture, that same number becomes a security boundary, and treating it like ordinary local state is how games end up with duplicated currency and drained economies.

The architecture that resulted from that realization: the app handles UI, gameplay, and local presentation, a Cloudflare Worker handles trusted operations, PlayFab stores authoritative economy and account state, and RevenueCat verifies purchases and entitlements. I'm intentionally not going into endpoint-level detail here, this is a portfolio story, not a backend manual, but the short version is that anything involving real money or account state is treated as untrusted on the client and confirmed server-side. That's one of the clearest lines between a prototype and production software: a prototype trusts itself, a product doesn't.

Premium Without a Subscription

I didn't think a puzzle game needed another monthly subscription competing for someone's attention. Spheriz Premium is a one-time, lifetime purchase. Free players can play the full core game. Premium expands content and removes forced advertising. Orb packs exist separately as their own optional purchase.

The principle underneath all of it stayed simple: paying should never let someone buy their way to a higher competitive score. It can buy convenience and appearance. It can't buy the leaderboard.

More Than Two Years Later

Some apps go from idea to release in a matter of weeks. Spheriz didn't, and it grew across a stretch of time where I was learning and improving at a lot of things at once: geometry and rendering, mobile interaction design, backend architecture, security boundaries that actually matter once money is involved, monetization that doesn't feel exploitative, App Store compliance, and just generally finishing things instead of leaving them at 80%.

Writing the algorithm that moves a piece toward the center is the easy part. Finishing the product around it, the part nobody screenshots for a portfolio, is the hard part.

Shipaton 2026

RevenueCat's Shipaton 2026 became a deadline, and I mean that in the most useful way possible. Spheriz was not invented for it. It existed more than two years earlier as a prototype gathering dust between other projects. What Shipaton gave me was a reason to stop treating it as an experiment I'd get back to eventually.

I'd already spent enough time thinking about Spheriz. I didn't need another redesign pass. I needed a deadline that would actually stick, and Shipaton provided one.

Do I expect it to win? Honestly, I don't know. There will be strong projects in that competition, and I have no illusions about being the only person who's spent years on something. But the competition already did something valuable regardless of the outcome: it turned "I'll finish this one day" into a shipped product on the App Store.

What Spheriz Taught Me

Two things, mainly.

Originality doesn't necessarily mean inventing a new genre from nothing. Sometimes it means questioning one basic assumption a whole category of software has quietly agreed on. Falling-block games use rectangular grids. Why? Pull on that thread and you get circles, rings, spheres, new controls, and level designs that wouldn't exist otherwise.

And finishing takes much longer than inventing. The idea can happen in an evening. The production work around it, the part that turns an idea into something someone else can actually pick up and use, is what takes years. Ideas give a project a reason to exist. Execution is what gives other people a way to experience it.

What's Next

Shipping isn't the end of this one. There's room to keep improving the 3D experience, expand the competitive systems, add more level variety, grow the cosmetics further, and get Android out once it clears Google Play review.

For the first time in more than two years, Spheriz is no longer a prototype waiting for me to come back to it. It's a game. And that's a much better place to continue from.

Where to Get It

• App Store
• Read more on the Spheriz project page.
• Privacy Policy
• Support