Case study

«Tower Bloxx» Study

A mobile design study where I rebuilt a classic one-tap tower-stacking loop, then expanded it into a city-building prototype with construction quality, resource production and district progression.

Playable prototype Mobile game design Systems design Game loop study Godot 4 / GDScript
Hero gameplay captureCity → plot → Tower Run → Perfect → building reveal.
StatusPlayable vertical slice
PeriodPrototype in active development
TeamSolo prototype
RoleGame Designer, Systems Designer, Godot Prototyper
ToolsGodot 4, GDScript, Android toolchain, Kenney City Kit
Reference frameClassic one-tap tower-building mobile games
Key challengesRebuilding the tower loop, one-tap game feel, portrait readability, city economy, arcade-to-meta-loop integration

Overview

A classic mobile loop rebuilt, tested and expanded.

This prototype began as a design study. I took a familiar tower-stacking formula, reduced it to its functional parts and rebuilt the core interaction in Godot: moving crane, suspended block, one tap, landing result, visible tower growth.

Once the tower run felt readable on its own, I connected it to a city layer. Precision now affects combo, instability, building quality, population, Factory production and the next construction decision.

Study frame diagramReference → rebuild → validate → expand.

Production story

From classic tower-stacking loop to city-building prototype.

The work moved through seven stages: reference, reconstruction, motion, camera validation, precision rules, city progression and visible city feedback.

01 / Choose the reference

Start from a classic one-tap construction fantasy.

I began with a recognizable mobile idea: crane, release, landing, tower growth. The point was to study the structure behind it, not copy the visual surface.

02 / Rebuild the core

Make the basic tower run work before adding meta systems.

The first milestone was a playable release-and-stack loop. The player had to read the swing, tap at the right moment and understand the landing result.

03 / Add skill to motion

Keep the input simple, but make the motion learnable.

Depth comes from crane trajectory, suspended load, inertia, release velocity and a target that changes after placement.

04 / Validate portrait readability

Use the camera as a gameplay rule.

The final camera keeps the center, distance and FOV stable, moves vertically and freezes while the block is in flight.

05 / Systemize precision

Turn good timing into more than feedback.

Perfect landings center the block, continue combo, reduce instability and raise final building quality.

06 / Add the meta loop

Turn each tower run into a construction decision.

The player chooses a plot and building type before the run. The result returns as population, production, adjacency value or Town Hall progress.

07 / Show the city systems

Replace a flat score chase with a district that reacts.

Physical plots, traffic, trees, Factory conveyors, Parks and completed models make the economy visible without extra text.

Systems Design Breakdown

Expanding a classic one-tap tower loop into a city economy.

The starting point was a proven mobile structure: one input, short attempts, readable failure and a clear mastery target. My first task was to rebuild that foundation cleanly.

The expansion came after validation. Building choice changes run length and purpose; performance determines construction quality; quality changes population or production; those resources open the next build.

Main Design Challenge

How can a classic one-tap loop support a modern progression system?

The core action had to stay understandable in seconds: wait, tap, release, land, continue. At the same time, the prototype needed more long-term value than a score chase.

I kept short-term mastery in the crane trajectory, pendulum motion, landing overlap, combo and instability. The city layer gives each run a consequence: the same building can return different value depending on how well it was constructed.

Design question

Release timing → Landing overlap → Perfect / Miss → Combo & Instability → Building quality → Population / Production → Next build

Core loop

Choose the build, execute the run, update the city.

Parks deliberately break the rhythm. A Park is placed immediately and works as a spatial decision, not another arcade run.

Choose a Plot

Select a physical plot with placement context, height limit and neighboring buildings.

Choose a Building

Residential buildings, towers, Factories, Parks and the Town Hall create different goals.

Spend Blocks

Construction consumes blocks. Factories produce more and support the next build.

Complete the Tower Run

Release blocks, avoid misses and try to keep a Perfect combo.

Convert Performance

Perfect ratio, misses and completion become Poor, Normal, Good or Excellent quality.

Update the City

The finished building changes population, production, adjacency value or district progress.

Systems designed

Classic Tower Run Reconstruction

One-tap tower stacking rebuilt around crane movement, release timing, landing, misses and tower growth.

Crane & Release Timing

A smooth ellipse, readable suspended-load behavior and retained velocity after release.

Landing & Perfect

Miss, ordinary placement and Perfect placement with exact centering.

City Economy & Adjacency

Population opens builds, Factories produce blocks, Parks improve neighbors and the Town Hall gives the district a goal.

Loop Reconstruction

The first task was to make the old loop work again.

I reduced the reference to its working structure: one input, moving crane, suspended block, timing decision, landing result, tower growth, repeated attempts and rising tension when mistakes accumulate.

If this part did not feel readable, the city layer would only hide a weak core mechanic. The validation target was simple: can the player understand the action without explanation, fail for clear reasons and improve through timing?

Tower-only prototypeEarly release mechanic, tower growth and landing comparison.

One-Tap Game Feel

The input is simple. The motion carries the difficulty.

The design goal was not to add more controls. The ellipse keeps crane motion continuous, the hook acceleration drives the block as a suspended load, and momentum survives the release.

The player learns a consistent system instead of guessing an animation. The tap stays simple, but timing has room for mastery.

Landing & Quality

Perfect placement changes the system, not only the score.

Below 35% overlap is a miss. From 35% to 90.999% is acceptable and keeps its offset. At 91% and above, the landing is Perfect and the block centers exactly.

The player gets a forgiving success floor and a clear mastery target. Precision still feels good immediately, but it also changes the economic value of the finished building.

Miss / Attached / PerfectOverlap scale and consequences for each result.

Mobile Camera Design

The camera defines the playable field.

A camera that followed the hook and tower offset removed the player’s stable point of reference. The final camera keeps horizontal center, distance and FOV fixed, rises by one block after the opening floors and freezes during flight.

Offset stays visible as a consequence of earlier placements instead of being hidden by framing. That matters because instant readability is the whole appeal of the one-tap format.

Meta Loop Design

The classic score loop became a construction economy.

The selected building sets cost and run length. Residential buildings turn height and quality into population; Factories turn quality into production speed; Parks create adjacency decisions; the Town Hall gives the district a finish line.

Failure does not erase the run. The city receives a partial building and returns part of the cost, so even a bad run becomes part of the city state.

The city does not replace the classic tower loop. It gives that loop a reason to continue beyond score.

Full city loopPlot selection, building choice, Tower Run result and model reveal.

Technical Challenge

Adding a city layer without breaking the rebuilt tower loop.

Problem
City economy, UI and saving could easily become tangled with hook motion, camera behavior and landing physics.

Decision
Keep the layers independent. The city sends a BuildRequest into the Tower Run. The Tower Run returns a BuildResult. Neither side reads the other side’s internal state.

Result
The rebuilt tower mechanic stays playable on its own, while the city can change costs, rewards, building types and progression separately.

CityState → BuildRequest → Tower Run → BuildResult → CityState

Layer boundary diagramCityState → BuildRequest → Tower Run → BuildResult.

Product Design Test

Reward hooks stayed local until the loop earned them.

I tested extra-chance and Factory reward moments with local five-second placeholders only. No live ads, analytics or networking were added before checking whether those moments felt voluntary and useful.

Project takeaways

What this prototype demonstrates through the work itself.

The case is strongest when treated as a design study: analyze the old loop, rebuild the interaction, validate it in portrait and expand it into progression.

Game Loop Analysis

I analyzed a classic one-tap formula, reduced it to its functional structure and rebuilt it as a playable prototype.

Systems Design

I connected the rebuilt arcade loop, construction quality, resources, spatial bonuses and a district goal.

Mobile Interaction Design

I kept the mechanic to one tap and used camera, motion and feedback to preserve readability.

Validation

I tested the tower loop first, then checked physics, city balance, saving and layer transitions separately.

Next step

Want the full breakdown?

If your team needs a designer who can analyze an existing game loop, rebuild it as a playable prototype and expand it into a deeper progression system, I can bring the same approach to your project.