Building Structle: A Daily Bridge Puzzle with Custom Physics

Structl logo

You're staring at a canyon. A vehicle sits on one side. The other side is nothing but empty space. You've got a limited budget of beams and joints, and exactly one job: build a bridge that holds. You start placing steel girders, watch them sag under imaginary weight, and when you think you've got it, you hit go. The vehicle crawls across, the beams glow yellow then amber then red as physics screams through them, and if you didn't overthink it, you'll get a star. That's Structle. That's what I built, and I'm genuinely obsessed with it.

Live gameplay, creating a bridge to support the vehicle

The Core Loop

Structle is a bridge-building puzzle game. After completing one game, it unlocks the next challenge in a different handcrafted puzzle with a unique terrain type, budget constraints, and environmental chaos trying its best to wreck your bridges. You place joints and beams in a 2D plane, watch a physics engine simulate stress in real time, send a vehicle across, and the system scores you on how much beam you didn't waste. One star for holding. Two for under budget. Three for elegance.

Multiple challenges to play

Twenty-five puzzles. Ten different terrain types. Canyon, Wind (crosswinds and rain collapsing your structure), Ice (low friction, everything slides), River (water current pushing laterally), Earthquake (ground tremors), Lava (rising lava destroys beams), Sandstorm, Night (brutal beam budgets because you can't see), Snow, Decay (beams rot over time). Each one teaches you something different about structural stress, physics constraints, and problem-solving under pressure.

Snow terrain challenge

The visuals sell it. Your beams are construction-grade steel with yellow and black hazard stripes and rivet details. They glow. As stress climbs, they shift from cool yellow to hot orange to furious red with emissive highlights. When they snap, debris tumbles with physics. The terrain extrudes into a 3D cliff face with rock materials. Water shimmers with shader-based liquid surfaces. Rain streaks across the screen. Lightning cracks the sky. The collapse feedback isn't just satisfying; it makes you want to break things again just to see what happens.

That was the design principle that drove everything: "The sandbox milestone is the make-or-break. Once building and collapsing feels fun in freeform mode, everything else is wrapping a game around that core. If the collapse doesn't make you say 'whoa,' keep iterating." I spent months iterating on that physics feel alone because everything downstream of that moment is secondary.

The Technical Foundation

Structle runs on Next.js 16 with React 19 and TypeScript throughout. The rendering layer is Three.js via React Three Fiber, v9. Styling is Tailwind CSS v4. And the whole thing lives on Vercel.

But the real technical story isn't the stack. It's the physics engine.

I built a custom 2D Verlet integration physics engine that runs at 120Hz with a fixed timestep. That's decoupled from rendering. The engine lives in pure logic files: `physics.ts`, `simulation.ts`, `camera.ts`, `terrain.ts`, `materials.ts`. No React. No framework dependencies. Just math and state mutations. It's elegant because it has to be.

Here's how the pipeline flows: Physics updates at 120Hz independent of the frame rate. Rendering reads from that physics state each frame via `useFrame`. Input gets raycasted to an invisible ground plane, converted to game coordinates. Game state gets dirty-checked every frame and synced to React state for the HUD. It's a one-way data flow from physics to rendering. The 3D components (BeamMeshes, TerrainMesh, DebrisMeshes, LiquidSurface, RainEffect, WindEffect, SkyBackground) all read, never write.

The constraint solver runs four iterations per physics tick. That's aggressive enough to keep your bridges stable but loose enough to feel organic when they fail. The debris system runs with damping, max fall distance checks, and rest detection so your broken beams don't bounce forever.

There's a `WORLD_SCALE` constant set to 0.1 with a Y-flip because the physics engine operates in pure 2D math space while rendering happens in 3D. This decoupling seems like overhead until you realize it means I can iterate on physics without touching the rendering pipeline, and I can swap visual styles without touching the solver. That separation of concerns paid for itself a hundred times over during development.

The puzzles themselves are static JSON configs. No backend. No runtime puzzle generation. Just 25 handcrafted scenarios stored locally and synced via local storage for player stats and streaks. The daily rotation is deterministic based on the date, so everyone gets the same puzzle every day and can compare scores.

Why This Matters

I've spent my career as a Lead Design Engineer focused on design systems, React architecture, and TypeScript patterns. That work is important. But there's something about building a game that scratches a different itch. It forces you to care about physics feel, visual feedback, moment-to-moment interaction, and the emotional arc of a moment in time. It's not about scaling to a thousand users or building a reusable component library. It's about whether someone feels joy or frustration in a specific instant.

Structle is the culmination of that tension. It's a serious technical project: a distributed rendering and physics pipeline, custom constraint solvers, optimization for mobile, real-time 3D graphics. But it's also a love letter to game development. I've been building interactive experiences since my computer graphics days at Syracuse. Solar system simulators, planet builders, educational gravity games. This game feels like a natural evolution of that trajectory.

The code is clean. The architecture is sound. The performance is good. But more than that, the puzzle design is intentional. Every terrain type creates a specific problem space. Night mode with its brutal beam budget teaches constraint thinking. Wind and River teach lateral thinking. Earthquake and Decay teach dynamic failure modes. The difficulty curve is intentional. The visual language is consistent.

What's Next

Structle is live right now. The core game is still a work in progress and running on Vercel. But this is the beginning of something bigger. I want to expand the puzzle library beyond twenty-five. I want to explore seasonal themes. I want to build a leaderboard system where people can compete on puzzle scores. I want to experiment with user-generated puzzles, which would require a backend architecture to validate and serve dynamic configurations.

There's also the question of platforms. Mobile-first is the current reality, but a desktop version would be interesting. And if the game gets traction, I want to explore what a game with this foundation can become when you add progression systems, narrative threads, or community features.

But right now, what matters is that I've proven to myself that I can build a game, ship it, and have it feel complete and intentional. The technical foundation is solid. The design is clear. The physics feel right. Everything beyond that is iteration and growth. And after years of building design systems and component libraries, iteration and growth in service of pure fun feels like the right move.