Cliffhold

Under attack
Advanced defences
Attack
Cannon towers
Attack
Birds eye view on the island
Upgrade tree zoom in
Upgrade tree
## Inspiration

Cliffhold started with the idea of a modern Rampart. I wanted to build an island fortress and watch a siege test its walls, weapons, and layout. Physics was part of that idea from the beginning: rolling logs, collapsing structures, and ships crashing into one another. Box3D turned out to be a perfect fit.

The building mechanics came first, but I was still searching for the right gameplay loop. Sir, We Have an Orc Problem inspired the incremental progression. Fighting, earning upgrades, and returning with a stronger defense gave the construction a purpose. Failure became a way to unlock new possibilities and improve the next attempt.

## What it does

Cliffhold is an incremental tower defense game about building defensive automations. You place walls, aim cannons, configure log tripwires, and draw patrol routes for Coast Guard ships. Then you start the raid and see how your decisions hold up.

The prototype contains one island and a three-wave assault. You begin by throwing stones at enemies and gradually unlock weapons, traps, and stronger fortifications. Permanent upgrades let you build on the progress of previous attempts.

Physics makes placement matter. Logs collide with one another, harpoons pull ships into other vessels, and destroyed walls open routes for attackers. Your defenses can also damage friendly targets, including your keep, so more firepower needs a better plan.

## How we built it

I built Cliffhold with OpenAI Codex, using Three.js for rendering, Box3D for physics, and Manifold for geometry used in destruction. The models are generated procedurally in code.

I set the direction, played the results, and corrected what did not work. AI handled much of the implementation, debugging, and automated verification. The build log records the process, including rejected approaches, changes in direction, and checks run after fixes.

AI also helped me build development tools as I needed them. A browser-based balance workbook lets me edit damage, health, reload times, and upgrade costs directly. An audio workbook lets me browse, preview, and assign sounds to game actions, then package only the selected clips.

For procedural models, I built an Asset Workshop with staged generation, revision history, screenshot review, and refinement passes.

## Challenges we ran into

The first challenge was finding a satisfying game around the construction mechanics. The incremental progression connected the pieces: each siege gives the player feedback and resources for a stronger attempt.

Getting the models to look good was another challenge. I was developing an increasingly elaborate process to refine them through multiple stages. GPT-6 Astra saved the day by producing better models more directly, reducing how much that process had to compensate for.

Touch controls needed repeated revision. Large handles and extra buttons often got in the way. Drawing walls, adjusting firing cones, and moving tripwires had to feel manageable on a phone.

Performance required investigation too. I recorded a session on my Pixel phone and used the trace to identify raid-start stalls and expensive work during combat. That led to changes in enemy navigation, wall rendering, and interface updates.

## Accomplishments that we're proud of

I’m proud that the defenses interact in ways that make the fortress layout matter. A rolling log or a harpooned ship can affect more than its intended target. A breach changes how enemies reach the keep. Those consequences give the player something concrete to learn from.

I also like how the harpoon battery communicates through its mechanism. The loaded spear, moving bow limbs, rope, and turning winch show the weapon firing and reloading. The animation follows its actual cooldown.

The development tools became a useful part of the project. When an effect sounded too harsh, I could audition alternatives. When an upgrade felt too expensive, I could change its cost in the workbook and test it again.

The game also packages into a self-contained browser build with local libraries, sounds, and assets, so it can run without an internet connection.

## What we learned

AI was useful for much more than generating game code. It helped me create the tools needed to inspect, tune, and test the game.

Playing the results remained essential. A control could work correctly and still feel awkward. A detailed model could be hard to read. A sound could pass playback tests and still be unpleasant.

Specific feedback produced the most useful changes. A phone recording helped locate performance problems. Screenshots made visual issues easier to discuss. Describing exactly how a gesture should behave was more effective than asking for “better controls.”

I also learned to reconsider the workflow itself. The model refinement pipeline solved a real problem, but when Astra produced better results directly, some of that complexity became unnecessary.

## What's next for Cliffhold

I want to expand Cliffhold across more islands and distinct biomes, with terrain offering different defensive opportunities. That could mean configuring an avalanche trap or sabotaging a bridge over a river before enemies cross it.

A deeper technology tree and more powerful tools of mass destruction would give players more ways to experiment. I also want to keep improving touch controls, combat feedback, and sustained phone performance as the game grows.

The core would remain the same: build a plan, watch the siege test it, and return with a better fortress.