Throttle Tower Defense

Build a machine of ridiculous power, then deliberately push the Rift harder. SURGE future waves into the present for greater rewards. How greedy do you dare get? What dangers wait deeper in the Rift?

Comment

Inspiration

Throttle Tower Defense began with a simple question:

What if becoming more powerful made you want the game to become more dangerous?

The earliest concept was a familiar tower-defense battlefield with one unusual interaction: a throttle that controlled how aggressively enemy pressure entered the fight. Instead of simply surviving whatever waves the game decided to send, the player could push the system harder and decide when their defenses were ready for more.

But there was an obvious danger: if the throttle only made the game run faster, then this would just be tower defense with a speed button.

That became the central design challenge.

The idea evolved into something more distinctive:

Build a machine of ridiculous power, then deliberately weaponize the game’s own difficulty against yourself.

The stronger the machine becomes, the more confident the player becomes. Confidence becomes ambition. Ambition becomes greed.

Eventually the question changes from:

“Can I survive?”

to:

“How hard dare I push it?”

And behind that sits another question:

What might be waiting deeper in the Rift if I become powerful enough to keep going?

That tension between power, confidence, greed, self-imposed danger, and discovery shaped everything that followed.

What it does

Throttle Tower Defense is a portrait tower-defense game about exploiting an unstable Rift for POWER and deciding how aggressively you dare provoke it.

Players build and upgrade an automated defensive machine around a Power Core. Once the machine is ready, they choose how aggressively to operate it:

IDLE → G1 → G2 → G3 → G4 → REDLINE

Higher gears do more than make the battle animate faster. They dramatically increase how quickly new waves are committed to the battlefield, causing threats to overlap and forcing the machine to process increasingly intense pressure.

At REDLINE, the game can operate beyond what a player could reasonably manage manually.

That creates the intended fantasy:

Do I trust the machine enough to make the problem worse on purpose?

Then there is SURGE.

SURGE lets the player pull actual future waves into the present for greater rewards. The 10, 20, and 40 WAVES options are not temporary difficulty modifiers. Those future waves are consumed and committed to the fight now.

SURGE is stackable. The player can keep calling more future danger into the present.

There is no cooldown, charge meter, secondary currency, or artificial punishment.

The danger itself is the cost.

As the run progresses, additional routes open, new enemy behaviors expose weaknesses in the defense, and different tower roles create placement, damage, and support decisions.

Push far enough, and the Rift begins sending threats that challenge assumptions the player has learned from ordinary route defense.

The result is a loop built around growing confidence and self-inflicted escalation:

BUILD → PUSH → DOMINATE → GET GREEDY → OVERCOMMIT → RECONFIGURE → GROW STRONGER → PUSH DEEPER

When the Core is drained, the run ends. Reaching a stronger Best Wave increases Starting POWER on the next attempt, letting the player build a larger machine earlier and challenge the Rift more aggressively.

The intended long-term fantasy is not simply surviving endless waves.

It is becoming powerful enough to manufacture increasingly dangerous problems for yourself—because greater danger is how you find out what your machine can really do and what lies deeper in the Rift.

How we built it

Throttle Tower Defense was built as a portrait-first mobile web game using HTML5 and Three.js.

Development was deliberately iterative and AI-assisted.

Before implementation, the concept went through a tournament against several other tower-defense ideas. They were compared against mobile usability, immediate comprehension, originality, replay potential, prototype speed, execution risk, and the competition criteria. Throttle Tower Defense advanced because its signature interaction was simple enough to prototype while creating a much larger design space around player-controlled pressure.

From there, development used:

  • a detailed design interview to expose assumptions before coding;
  • a living Game Development Document as the design source of truth;
  • game-designer and game-producer red-team reviews;
  • a coding-agent handoff defining technical and competition constraints;
  • small playable implementation increments;
  • deterministic technical validation;
  • repeated human playtesting for feel, pacing, comprehension, and balance;
  • a living Build Log recording decisions, failures, pivots, and lessons as they happened.

Human judgment remained authoritative for whether the game was actually fun, whether it created the intended feelings of power, temptation, greed, and consequence, and whether each iteration stayed true to the original human-authored design vision. AI could propose, analyze, implement, test, and challenge ideas, but a technically correct system did not automatically earn its place in the game.

External playtesting was especially useful because it exposed a distinction between mechanical problems and communication problems. Players could discover the intended fun in SURGE and self-imposed pressure, but they did not always understand those systems quickly enough.

That led to a final comprehension-focused polish pass rather than a broad rebalance: clearer Throttle and SURGE language, explicit stackability, visible committed-wave feedback, stronger Relay feedback, clearer POWER and progression messaging, Core repair and Safety Governor feedback, and a short first-run title/purpose screen.

The final competition build uses readable source, locally packaged Three.js, and no runtime network dependencies. The exact submission package was rebuilt, extracted, regression tested, and validated on real phones.

Challenges we ran into

Making the Throttle more than a speed control

This was the biggest design risk from the beginning.

Simply speeding everything up made the same battle happen faster. That was not enough.

We separated battlefield speed from wave-delivery pressure so higher gears could create genuinely more simultaneous threat. Once waves are committed, lowering the Throttle does not magically erase them.

That changed the Throttle from a convenience feature into a risk decision.

Making extreme pressure technically believable

The fantasy calls for enormous pressure, especially at REDLINE and after repeated SURGE use. Simulating and rendering every logical enemy independently would eventually undermine the mobile experience.

The solution was to separate logical threat from physical presentation.

Compatible enemies can be represented through bounded groups while preserving the information that matters to gameplay: health, enemy count, origin wave, route, rewards, and leaks. Gatling combat uses mathematical damage rather than requiring hundreds of simulated physical projectiles, while visual effects remain deliberately bounded.

That lets the perceived scale grow dramatically without requiring technical complexity to grow at the same rate.

Removing tower-defense dead time

Another challenge appeared once the player’s machine became powerful.

Winning easily is satisfying.

Waiting through dozens of waves that no longer threaten you is not.

SURGE became the answer.

Instead of forcing the player to wait for the game to catch up with their power, SURGE lets them reach into the future and bring the challenge to themselves.

That created one of the most important emotional moments in the game:

“Did I call too much?”

Playtesting confirmed that once players understood they could repeatedly SURGE, they deliberately overcommitted and experienced exactly that reaction.

Communicating an unusual mechanic

The final external playtests revealed another challenge: players could understand ordinary tower-defense interactions quickly, but Throttle and SURGE were unusual enough that some of their meaning had to be communicated more explicitly.

That was important evidence.

Rather than changing the pressure systems themselves, the final pass focused on helping players understand the decisions they were already making: higher gear means more than fast-forward; SURGE means real future waves; SURGE can be stacked; POWER is the spendable resource; Relay boosts nearby damage; and a stronger Best Wave is what makes the next run start stronger.

Keeping scope under control

There were many opportunities to add more towers, enemy types, currencies, boss abilities, progression trees, routes, and other systems.

We repeatedly chose not to.

The question became:

Does this make the experience of building overwhelming power and daring to push harder meaningfully better?

If not, it stayed out of the competition prototype.

That focus was intentional. The prototype is meant to prove the pressure engine first.

Accomplishments that we're proud of

The biggest accomplishment is that the final game still expresses the fantasy that originally made the concept worth building.

We are especially proud that:

  • Throttle creates actual committed battlefield pressure rather than merely accelerating animation.
  • SURGE turns future danger into a player-controlled risk/reward decision.
  • Repeated SURGE lets players deliberately create a scale of creeping doom that they themselves asked for.
  • A strong machine feels genuinely powerful, encouraging the player to become greedier rather than simply waiting for the game to get harder.
  • Three routes and focused-fire, group-damage, and support roles create meaningful machine-design decisions without requiring a huge prototype content roster.
  • Rift threats can challenge assumptions the player learned from ordinary route defense.
  • The game can represent extreme logical pressure while keeping simulation and presentation bounded.
  • A stronger Best Wave feeds directly into the next attempt through increased Starting POWER.
  • The final build passed regression, exact-package validation, and repeated real-device testing.

Most importantly, playtesting validated the central wager behind the design:

Building power makes players want permission to create a worse problem for themselves.

And once SURGE was understood, players used that permission.

What we learned

The biggest lesson was that more features do not necessarily create a stronger prototype.

A clear player experience was more valuable than a large system list.

We also learned that a mechanic’s implementation and its fantasy have to reinforce each other. The Throttle became interesting only when higher settings created real pressure. SURGE became interesting because pressing it makes an irreversible commitment rather than simply changing a number.

Another major lesson was the value of separating technical validation from human validation.

Automated tests could prove that future waves were consumed exactly once, rewards were correct, logical enemy counts remained intact, and the submission package worked offline.

They could not prove that REDLINE felt exciting, that an unexpected Rift threat felt dangerous, that SURGE created temptation, that the power fantasy felt right, or that the experience remained true to the original design intent.

Those questions required human judgment and playtesting.

The tests also clarified an important future-design lesson: players naturally asked for more towers, enemies, and progression once they understood the basic game. That feedback is valuable, but it does not mean the future should simply become “more tower defense.”

The deeper opportunity is to use future content to keep renewing the same central fantasy:

become more powerful, use that power to provoke greater danger, and discover what happens when you push farther than before.

What's next for Throttle Tower Defense

The competition build deliberately focuses on proving the core pressure engine rather than trying to simulate the content breadth of a finished game.

A full version would expand that engine into an open-ended pursuit of escalating POWER and Rift discovery.

Players would build increasingly absurd automated machines, then deliberately weaponize the game’s own difficulty against themselves—using growing strength to summon greater pressure and push deeper into the Rift.

Additional towers, enemy behaviors, machine synergies, progression systems, Rift events, and special threats would not be the destination by themselves. They would be the means of continually renewing three things:

POWER. PRESSURE. DISCOVERY.

The deeper the player pushes, the more the Rift could reveal: new threats, new behaviors, new machine possibilities, and things that challenge what the player thought they understood about the game.

The Rift Titan in the prototype is an early glimpse of that design space: a threat that stops obeying an assumption the player has learned to depend on.

A full game could keep asking the player two questions for a very long time:

How powerful can I become?

And what is waiting deeper in the Rift?

Built With

Share this project:

Updates

Submission history