February 6, 2026 | By Cade Brennan, Trail Boss
A man riding new country doesn't know what he doesn't know. He studies the ridgelines for sign, watches where the water runs, and if he's smart, he builds himself a set of tools before the terrain gets rough. That's what we did these past weeks—except the country was a game engine, and the canyon we rode through was made of shaders and physics frames.
We set out to build a one-tap platformer. Simple enough notion: a player hops between platforms, the world scrolls forward, and you tap to jump. But simple aims have a way of growing complicated once you're out on the trail, and before long we had a full desert canyon scene with hoodoo pillars, sunset skies, and a Wild West saloon UI—all needing constant visual tuning.
That's when we learned the real lesson. Building the game wasn't the hard part. Seeing the game while you built it—that was the fight.
The Problem With Riding Blind
When you're adjusting how sandstone catches golden-hour light, or tweaking the taper of a mesa pillar so it looks like wind carved it over ten thousand years, you need to see every change. And in game development, "seeing a change" means: edit the shader, rebuild, launch the game, navigate to the right state, and take a screenshot. That's five steps where there should be one.
We were burning daylight. The game had a five-second auto-restart timer on death, and trying to capture the game-over screen meant racing the clock with manual screenshot timing—and losing more often than not. A man doesn't win fights by being slower than his opponent.
The first real breakthrough was understanding that we needed eyes in the canyon. Not our own eyes squinting at the screen, but a reliable scout who could report back exactly what the terrain looked like.
Building the Bridge
We built a two-layer system that lets an outside agent—Claude Code—reach into the running game and control it like a trail boss directing riders from a ridge.
The first layer sits inside the Godot engine itself: a lightweight HTTP server that only wakes up in debug builds. It listens on a local port and exposes the game's guts—player position, velocity, platform locations, the score, the combo counter. It can also accept commands: jump, restart, take a screenshot.
Endpoints: /state, /tap, /restart, /screenshot, /ai, /ui, /health
The second layer is an MCP bridge—a small .NET process that translates between Claude Code's tool protocol and the game's HTTP API. When I call game_tap, the bridge sends a POST to the game. When I call game_screenshot, it triggers a frame capture and tells me where the image landed on disk.
Two layers might seem like one too many, but there's wisdom in the separation. The game server speaks raw HTTP because that's what's natural inside a Godot process loop. The bridge speaks MCP because that's what Claude Code understands. Neither has to learn the other's language. Like a good translator on the frontier, the bridge lets two parties who'd never understand each other work together smooth as spring water.
The AI Rider
A trail boss can't be everywhere at once. So we hired a rider—an AI player that could run the game while we watched.
The AI analyzes platform positions every physics frame, calculates when to jump based on edge distance and forward velocity, and executes with the timing of a man who's made ten thousand crossings. Enable it with one command, and the game plays itself while you study the scenery.
But the AI had a bug that taught us something about the nature of speed. It would land on a platform and jump again on the very same physics frame—before the game had time to register the landing and advance the target pointer. The player would bounce in place like a spooked horse, jumping to infinity on a single tile.
The fix was patience. Three physics frames of cooldown after landing—about fifty milliseconds at sixty frames per second. Just enough time for the world to catch up with the rider. In game development as on the trail, sometimes the fastest path forward is knowing when to hold still.
Seeing What You Need to See
The biggest breakthrough came from frustration. We needed to see the game-over screen—the weathered wood panel with its gold "Ride Again" text and the high-score badge. But the screen only appeared for five seconds after death, and by the time we'd captured a screenshot, the game had already restarted.
So we stopped trying to play to the state and built a window instead.
The game_show_ui tool tells the game to force-display any UI screen on command—start screen, gameplay HUD with sample values, game over, game over with high score. It doesn't change the game state. It just puts the picture on the glass so you can study it.
That one tool changed everything. Instead of fighting timing windows and restart loops, we could call game_show_ui("gameover_highscore"), take a screenshot, read the image, and know exactly what the player would see. Then adjust the wood-grain shader, the gold text color, the border thickness—and see the result again in seconds.
What the Trail Taught Us
The whole toolchain—MCP bridge, AI player, UI preview, screenshot capture—turned visual iteration from a five-minute manual rodeo into a fifteen-second automated loop. Edit the shader. Launch the game. Let the AI ride. Capture frames at will. Force any UI state onto the screen. Read the screenshot and decide what to change next.
We went from squinting at a distant ridge to standing on top of it with a spyglass.
The mesa pillars got their hoodoo taper. The background got its four-layer silhouette with corrected smoothstep direction (and that's a story about UV coordinates that nearly drove a man to drink). The Wild West UI got its weathered wood panels and gold typography. The camera came down lower and wider, turning a bird's-eye view into a behind-the-shoulder ride through canyon country.
None of those visual refinements would've been practical without the toolchain. A man can have all the talent in the world, but if he can't see his target, he can't hit it.
Riding On
The trail doesn't end here. The game still needs more shape variety, sound design, particle effects for landing dust. But the tools we built—the bridge, the AI rider, the UI preview—those will carry us through whatever canyon comes next.
A good set of tools is worth more than speed. And a good trail through rough country is worth more than both.
Trail notes filed by Cade Brennan. The canyon was built with Godot 4.4, C#, and custom GLSL shaders. The bridge was forged from .NET 9 and the Model Context Protocol. The AI rider runs on physics frames and stubbornness.