Stack Tower, Before It Had a Theme

No theme, no arctic setting, no story — just a platform, a block sliding back and forth above it, and a button to drop it. That's the entire game right now, and I want to be clear that this is the intended first version, not a placeholder waiting for art. I wanted to prove out the actual stacking mechanic in complete visual isolation before spending any time deciding what the tower should look like or be set against.

Precision drop, not physics simulation

There's a version of this genre built on full rigid-body physics, where a poorly aligned block can visibly wobble, tip, and crash off the stack in a satisfying, chaotic way. I went a simpler route: each dropped block is checked against the block below it, and how much it overlaps determines whether it counts as a clean placement, a partial one that narrows the tower, or a miss that ends the run. It's a much cheaper system to build and reason about than real physics, and it means the entire skill test is purely about timing your drop against a moving target, with no physics engine variance making an identical-looking drop behave differently between runs. I think that's the right trade for this version — deterministic feedback matters more here than physical realism does.

Why the platform narrows instead of just ending the run

A slightly misaligned drop doesn't end the game outright — it clips the overlapping portion of the new block, narrowing your effective platform for every drop after it. That was an important call against the more punishing alternative of ending the run on any imperfect placement. Purely binary success-or-death drops sound clean on paper but feel miserable in practice for a game with this much repetition — nobody wants forty seconds of careful stacking undone by one slightly early tap. Narrowing the platform keeps the tension climbing (a narrower base makes every subsequent drop harder) without a single mistimed tap being an instant, unforgiving loss.

Speed has to increase, but not linearly

The sliding block moves faster the higher the tower gets, and getting the actual acceleration curve right took more attempts than I expected. A linear speed increase either starts too slow to feel like escalating tension early on, or gets unplayably fast too soon once the multiplier compounds. I ended up with a curve that ramps gently for the first several successful drops, then accelerates more aggressively past a certain height — mirroring the same instinct behind 60 Sec Survival's named phases, even though this game doesn't call them out with a label. The escalation should be felt through the controls tightening, not announced with text on screen.

Overlap tolerance needed its own tuning pass

How forgiving the overlap check is turned out to be the single number most responsible for how the whole game feels. Too strict, and even a visually close-looking drop reads as a near-miss, which feels unfair because the player's own eyes told them it looked fine. Too lenient, and the platform barely narrows even after several sloppy drops in a row, which removes the tension the narrowing mechanic exists to create in the first place. I ended up erring slightly toward generous rather than strict, on the theory that a game this repetitive needs to feel responsive to genuine effort even when that effort isn't pixel-perfect — strict precision games work when there's a whole scoring system built around rewarding precision specifically, and this one isn't that, it's about sustained rhythm over many drops.

Height as the only score, on purpose

There's no separate points system layered on top of height — how high you got is the score, full stop. I considered awarding bonus points for perfectly centered drops as a secondary metric, and cut it because it would have created a confusing situation where two different numbers could disagree about who actually played better: someone chasing a high perfect-drop bonus at the cost of a slightly more conservative, lower final height versus someone who stacked recklessly but higher overall. Height alone is unambiguous. It's the thing the whole game is visually about, so it's the thing that should be the score.

What's deliberately not here yet

There's no visual theme, no combo system for consecutive perfect drops, and no sense of progression beyond a plain height counter. All of that is intentional for this version — I wanted the core drop-and-stack loop validated entirely on its own mechanical merits before deciding what to wrap around it. If the block-overlap system and the speed curve hold up under real play, dressing the whole thing in an actual setting is a much smaller and more enjoyable problem to solve next than trying to fix a boring core loop that's already buried under art.

The audio right now is similarly bare — a single neutral tone on a clean drop, a different one on a clipped drop, nothing on a miss beyond the run simply ending. I thought about building out a fuller sound palette before launch and decided against it for the same reason the visuals stayed plain: I want to hear which parts of the drop-feedback loop actually need audio reinforcement once real people are playing it, rather than guessing up front and potentially building the wrong cues for a game that might end up looking and sounding completely different once it has an actual setting.

It's a small, quiet game right now, and that's fine. Not everything needs a hook on day one. Some things just need the underlying loop to be genuinely sound, and everything else — the setting, the sound design, the combo system — can arrive later once that foundation has actually earned it. A tall, dressed-up tower built on a shaky drop mechanic would be a worse outcome than a plain one built on a mechanic that actually holds up. I've made that mistake before, chasing presentation ahead of a loop that wasn't ready for it, and I'd rather write this one down as the plain version on record than pretend it launched more finished than it actually is.