Back

A 3D Boss Fight with Claude, Tripo & Godot

2026.10.2110 MIN READWorkflows

01 / OVERVIEW

Overview

I started with a boy in a red scarf and a deserted 1980s American town. A faceless statue tears the buildings into the sky. The idea became a playable third-person action demo in Godot.

Claude helped plan, script, and test; Tripo supplied concept images, models, rigging, and animation. I directed the project and reviewed the assembled game in Godot.

This hands-on approach follows a vibe-gaming workflow that connects ideas, AI-assisted development, and playable testing.

Project setup:

  • Engine: Godot 4.7.2, Forward+
  • AI coding assistant: Claude Code
  • Image generation: Tripo image generation
  • 3D generation: Tripo P and H series models
  • Project: The Red Scarf, a short third-person Boss-fight demo
The Red Scarf: the playable Boss fight.
The Red Scarf: the playable Boss fight.
Play The Red Scarf in your browserVibe gaming tutorial

02 / OVERVIEW

What the Finished Demo Plays Like

The boy enters town along Main Street. At the plaza, a faceless statue releases a shockwave and pulls the buildings into a spiral around it.

The player climbs the floating shops by jumping, hovering, and scarf leaping. Parrying a glowing projectile briefly breaks the statue’s shield; throwing nearby objects damages it. After three rounds, the boy can reach and seal the statue.

The Red Scarf gameplay showreel.

03 / OVERVIEW

Set Up the Tools and Project

Give Claude a project memory

I kept the Godot project, design documents, concepts, Tripo models, and scripts together. At the root, CLAUDE.md recorded the rules Claude should follow across sessions.

It covered the essentials:

  • Describe the game, tone, and visual direction.
  • List asset rules, such as consistent style and no unwanted symbols or text.
  • Require a plan before large changes.
  • Keep a prompt history.
  • Record recurring pitfalls and project conventions as they are discovered.

I added recurring fixes to the same file: mesh winding, model orientation, animation names, and scarf-leap target rules. Later sessions could reuse them.

Install the Tripo CLI

To connect Claude to Tripo, I asked it to install the Tripo CLI:

Project Prompt
Help me install and configure Tripo CLI: npm install -g tripo-cli
Tripo CLI docs

Connect Godot and Claude

Claude could edit text-based Godot scenes and GDScript directly. A Godot MCP connection let it run the game, capture screenshots, inspect logs, and simulate input.

I verified the connection by asking Claude to report the open scene and node tree, then checking the MCP port and project against my configuration.

Project Prompt
Compare the Godot MCP servers that are available right now and pick the one that fits this project best (Godot 4.7, Claude Code, editor control plus running and inspecting the game).
Explain your choice, then install it into the_red_scarf/ and configure it at project scope (.mcp.json in the project root). Turn telemetry off.

04 / OVERVIEW

Reduce the Idea to a Testable Game

Write the design, then cut it down

Claude’s first design covered the town, movement, boss attacks, and level flow, but had too many phases and scarf abilities for a short demo.

Project Prompt
I'm making a game demo with Claude, Tripo and Godot. Here's the idea:

The player is a boy in a bright red scarf, a gray hoodie, blue denim shorts and bright yellow basketball sneakers. The scarf is a supernatural object: he can hover with it, move quickly between platforms, grab objects and throw them, and use it as a whip.
The game starts on the main street of a mid-1980s American small town: one main road, houses and shops on both sides (post office, gym, diner and so on). In the central plaza stands a statue of a man in a suit whose face has been erased. It is a hostile supernatural object. When the boy arrives, it releases a shockwave and slowly rises into the sky. The houses around it are torn out of the ground and end up as floating platforms at different heights. The player jumps between them, blocks the objects the statue hurls with telekinesis, fights back, and finally reaches the statue and seals it with the scarf.

Write a short design doc in design/game_design.md: building types, the boss's attacks in two phases, the boy's attacks, defense and movement moves, and the level flow.
Show me your plan first. Ask me if anything is unclear.

I cut it back to the smallest loop that still felt like this game:

Project Prompt
Simplify the combat:
1. The boss has only one phase.
2. Remove the scarf shield and the scarf whip.
3. New loop: the player moves across floating buildings and can only break the statue's shield by parrying its attacks (right click / RT, like a fighting-game parry). Once the shield is down, the player throws objects at it to deal damage.

I cut combat to one boss phase: parry to break the shield, throw objects during the exposed window, and use the floating town as the movement challenge. Every remaining move had to serve that loop.

Build the town from data

Claude wrote a Node script to generate a parameterized SVG of the oval town: Main Street, twelve shops, residential roads, parks, parking lots, and a plaza.

The same script exported JSON for Godot’s blockout, buildings, roads, lamps, and trees. Concept art and the playable level therefore shared one layout.

I revised one parameter at a time, such as parking-lot size, backyard depth, or shop entrances, so each change was easy to review.

Project Prompt
Here's the town I have in mind. The street grid is a grid inside an oval outline:
- The long axis of the oval is the widest street, Main St, lined with functional buildings like the post office and the gym.
- The other streets run perpendicular to Main St on both sides, lined with houses.
- The center of the oval is a round plaza; the statue stands on a concrete pedestal in the middle.
- Asphalt streets with lane markings. Raised concrete sidewalks in front of the shops, with American red ash street trees at regular intervals.

Design the town structure, fill in the details I didn't mention and improve the design.
Draw it as a top-down plan with a Node script (tools/townplan/gen_town_svg.mjs) that generates an SVG from parameters kept at the top of the file.
The parameterized town plan used as the layout source.
The parameterized town plan used as the layout source.

Establish a visual direction

I used the layout as a strict reference for a top-down illustration, preserving roads, lots, footprints, trees, and the town outline.

The first 45-degree view looked like a tilted map. Rotating the reference locally before regenerating gave it a convincing angle.

Project Prompt
Strict layout reference: image[1]. Keep every road, block, building footprint, lot, park, parking lot, tree and the oval outline exactly as in image[1]. North up. Add, remove, move or resize nothing. Only restyle it as a finished top-down orthographic illustration of a quiet mid-1980s American small town in autumn.

[...town contents: main street, roundabout and statue, twelve shops seen as flat roofs only, all facing the main street, houses, parks, parking lots, red ash trees, a water tower...]

Style: stylized non-photorealistic game environment, simple hard-edged geometry, flat slightly exaggerated colors, light weathering, no grime. Warm late-afternoon sun from the west.

No vehicles, people, text, lettering, flags, or national or religious symbols. The statue has no face.

From the final plan and bird’s-eye image, Claude listed the assets, separating Tripo models from objects built in Godot. Face-count tiers kept roughly thirty concepts and thirty models within budget.

Project Prompt
The town concept art is done. Using the final plan (v6), list every asset we need, split into "generate with Tripo" and "build in the engine". Then write a concept-image prompt for each Tripo asset in design/asset_prompts.md.
- Shops on Main St should vary more, with clearly different heights, so the opening walk has an interesting skyline.
- Split scene assets into tiers (S / A / B / C) by importance and size, give each tier a model and a triangle budget (hard cap 10,000 per asset), and estimate the total for the scene.
The bird’s-eye style reference for the town.
The bird’s-eye style reference for the town.

05 / OVERVIEW

Prototype an Asset Before Making the Rest

Test one representative building

I tested the pipeline on one supermarket first, checking its visual style, suitability as a modeling reference, and the right Tripo model family.

  • Does the concept image match the town's visual direction?
  • Does the image provide a clean modeling reference?
  • Which Tripo model family produces the right geometry?

The first image had visible shelves, baked-in warm light, a brand-like vending machine, and an oversized foundation.

I updated the shared rules: board up windows, switch off lights, use neutral white reference lighting, and keep foundations flush with the walls.

Project Prompt
Use image[1] only as a reference for color palette, materials and rendering style. Do not copy its content or camera.

A single isolated one-story small-town supermarket from the mid-1980s: a wide, low box about 16 meters wide, 14 meters deep and 5 meters tall. The front is a long row of large plate-glass windows with a pair of glass doors in the middle, under a flat red-and-white striped metal awning. Above the awning, a tall flat sign panel runs the full width of the roofline, painted with bold color bands and a simple shopping-cart pictogram, no letters. Pale yellow painted brick walls, a flat roof with two boxy rooftop AC units. A plain red vending machine stands beside the doors. All windows and glass doors are boarded up with weathered wooden planks, so no interior is visible. All lights, signs and neon tubes are switched off. The building sits on a thin flat concrete slab exactly the size of its footprint, flush with the walls on every side.

Three-quarter front view from slightly above, the whole building in frame, centered on a plain light gray background, neutral white daylight with soft even lighting and no warm tint, no cast shadows, no ground beyond the slab.

Style: simplified realism with hard-edged, clean forms, mid-1980s American, slightly saturated comic-book colors, light weathering, no grime.

No text, no letters, no logos, no flags, no national or religious symbols, no people, no vehicles
First MART conceptFirst MART concept
Revised MART conceptRevised MART concept

Compare model families before scaling up

With the same supermarket image and controlled face limits, P-series produced cleaner hard edges; H-series had more even triangles and softer surfaces.

For this game, I chose:

  • Use P1.0 for buildings, vehicles, and props that benefit from clean hard surfaces.
  • Use H3.1 for organic forms such as the statue and floating ground pieces.
  • Use P2.0 for the boy because the character needed clean topology for rigging.

This was a choice for this game, not a universal model ranking.

Comparing H-series and P-series MART models in Godot.
Comparing H-series and P-series MART models in Godot.
Project Prompt
The current models are all clean and fairly flat. For performance, would P1.0 suit the buildings better than H3.1? Run a comparison: generate MART with P1.0 at 4000 faces and with H3.1 at 6000 faces, import both into a test folder, and render them side by side from the storefront, front, corner and top views (shaded and wireframe). Then tell me which one to use and why.

Generate the remaining scene assets

After the prototype passed review, I generated the remaining assets. Each had a category, folder, model preset, and face budget.

The batch had three checks:

Project Prompt
Generate concept images for all remaining scene assets the same way as MART, using the prompts in design/asset_prompts.md and cpt/town_birdseye.png as the style reference.
Check balance first. Save each image under cpt/assets/<category>/.
Check every image against the checklist in asset_prompts.md (single object, clean background, no text or symbols, matches the bird's-eye style, no thin fragile parts).
Retry failed tasks individually; never rerun the whole batch.
Record progress in design/batch_checkpoint.md so we can resume if we stop halfway.
When done, list what succeeded, what failed and what needs my review.
  • Check every image for a single object, clean background, no accidental text, and no fragile parts.
  • Retry failed tasks individually.
  • Record progress in a checkpoint file.

I regenerated individual failures: a gas station with a hole in its back wall, a missing water tower, and loose supermarket geometry.

Concept images for the scene assets.
Concept images for the scene assets.

Build the character separately

The boy needed concept art, modeling, a rig check, rigging, and animation retargeting. I kept the scarf separate to avoid unwanted skin weights and preserve its complex actions.

Project Prompt
A full-body cartoon-style boy in a standard T-pose, arms extended horizontally, legs straight. He wears a gray hoodie with the hood up. His face is shrouded in shadow, eyes hidden, with only his mouth and grayish-brown bangs visible. He has a long red scarf wrapped around his neck, with both hanging ends draped down behind his back, not in front. He wears dark blue denim shorts ending above the knee so his knees are exposed, with buttoned flap pockets on both the left and right sides. He wears oversized yellow sneakers and has relatively thin legs. Cartoon character design, clean 3D model.

I ran the free rig check first. The animation list covered idle, walk, run, jump, fall, throw, parry, scarf leap, hit, defeat, seal, and victory. Retargeting more than five at once failed, so I used three smaller jobs and combined them in Godot.

Project Prompt
The boy model is ready at models/boy/boy_body.glb. Rig it and add the animations the demo needs. Run the free rig check first. List the animations you plan to use, mapped to Tripo presets, before generating anything.

I checked character views manually for mirrored hands and hair mistaken for sunglasses before using them in the batch.

The boy’s character concept before modeling and rigging.
The boy’s character concept before modeling and rigging.

Standardize imports and quality checks

An import step added weighted normals and hard edges to walls that looked too soft. Texture limits varied by asset, with exceptions for the boy, scarf, statue, and trees.

I checked scale, orientation, walls, roofs, and stray polygons before moving models from the test directory into the playable scene. Production assets needed zero reported issues.

Project Prompt
When I inspect the models, the normals are smoothed across every edge, so flat walls look soft and cheap. I want something like Blender's Weighted Normal modifier.
Write a Godot import hook that recomputes weighted normals on import (area-weighted, edges sharper than 30 degrees become hard edges, keep the normal map), plus a setup script that attaches the hook to a list of GLBs and limits texture size (4K, or 2K for small assets) with VRAM compression. Don't apply it to the boy, the scarf, the statue or trees.
Render before/after comparisons so I can judge the result.

06 / OVERVIEW

Build the Demo in Layers

Start with a gameplay blockout

A Godot tool script read the town JSON to build a playable blockout with colored collision boxes, ground, spawn point, and floating layout. Inspector controls and a command-line script rebuilt it after data changes.

Swap In Models then replaced the boxes with Tripo assets at the same positions. Both versions used the same layout data.

Shops formed the climbable spiral; houses stayed in the background. A report checked overlaps, headroom, roof spacing, and platform reachability.

Gameplay blockoutGameplay blockout
The same layout with Tripo modelsThe same layout with Tripo models
Project Prompt
Build a gameplay-only blockout:
- Export the town plan as JSON (gen_town_svg.mjs --json) and write an @tool script (Scripts/town/town_builder.gd) that reads it and generates the ground, a colored box with collision for every shop and house (heights from the design doc), and the player spawn at the west entrance.
- Add inspector buttons: Build Town, Preview Tree, Reset To Ground, Swap In Models.
- Also add a command-line build script so you can rebuild the scene headless.
- Swap In Models replaces each box with res://Assets/Models/<model>.glb, scaled to the lot and rotated to face the street, keeping the position.
Show me screenshots from the street and from above.

Add movement and the procedural scarf

The controller had ground, air, hover, and scarf-leap states. Exposed settings and a smoke test helped tune and check each move.

Project Prompt
Start the player controller in the blockout scene. Use the rigged boy model directly, no capsule placeholder.
- CharacterBody3D with states: ground, air, hover (hold jump midair, drains scarf energy), scarf leap.
- Third-person over-the-shoulder camera, keyboard + mouse and gamepad input maps.
- AnimationTree state machine built by a generator script (Scripts/tools/build_player_scene.gd), not by hand in the editor.
- All feel parameters exported so I can tune them in the inspector.
- An automated smoke test that spawns the player, runs, jumps, hovers and scarf leap, and saves screenshots.

A modeled neck wrap looked too stiff, so code generated both the wrap and tail. The same tail could hang, reach, grab, wrap the statue, and release without separate models or animations.

The first wrap looked inside out because of triangle winding and flipped normals. Claude fixed the mesh and recorded the cause in CLAUDE.md.

Project Prompt
The neck scarf looks too stiff. Try generating it procedurally instead of using the Tripo model:
- ScarfWrap: three thick, soft knitted loops around the neck, rebuilt every frame from the neck, head and spine bones, pushed out by capsules on the head, neck, chest and upper arms, fuller at the back so it fills the gap between the hood and the shoulders, with a little spring lag.
- ScarfTail: a Verlet chain hanging from the knot at the back, with thickness, stiff enough not to stretch, colliding with body capsules. Reaching out to grab props, hanging from anchors and wrapping the statue all use the same tail (reach(point) / release()).
- Both share one wool material with the red knit texture and a soft sheen at grazing angles.
Keep the per-frame cost low and tell me the measured time.
Procedural scarf wrap checks in Godot.
Procedural scarf wrap checks in Godot.

Make scarf leap feel intentional

The first scarf leap swung like a grappling hook. I changed it to accelerate toward a chosen landing point, with a red aura, dust, trail, and landing pulse to make the motion readable.

Early targets on awnings could send the boy through a building or trap him. I added landing and flight-path checks. A valid target had to:

  • sit on a real roof edge;
  • have enough clearance above it;
  • provide room for the character to stand;
  • avoid a flight path through the destination building.

A report checked every building from twelve directions and required zero invalid leap points.

Project Prompt
Change how the scarf leap feels. Right now it swings like Spider-Man. Instead, the boy knows where he's going and moves straight to the target. While moving, rotate his model so his feet point at the target, as if his feet were pulling his whole body toward it.
Drop the scarf from the scarf leap and sell the power with effects: a red aura when the scarf leap starts, a puff of dust and a small energy pulse at the start point, a trail along a small arc, then the aura fades on landing with a small shockwave at the contact point.
The speed is not constant: a little slow at first, then accelerating hard, never slowing down until it arrives.
The final scarf leap toward a rooftop edge.
The final scarf leap toward a rooftop edge.

Connect the boss fight

The route included the main menu, introduction, rising town, checkpoint, three-segment boss fight, and ending.

The statue threw objects, including a parryable glowing one. A parry opened its shield for about seven seconds. Later attacks added a fan volley and a meteor-like car, while visibility checks blocked throws through buildings.

Project Prompt
Finish all playable content for a first complete version:
- A basic main menu, pause menu and ending screen with buttons.
- The intro: "The Oval Town" title card; when the player enters the plaza, the statue shakes, lifts off its pedestal, a "The Statue" title card, then a shockwave pushes the boy back along the ground. Buildings fly up into the spiral tree. One checkpoint at the end of this sequence.
- The boss fight: shield, parry window about 0.25 s, about 7 s exposed window, damage only from throws while exposed, 3 health segments, attacks unlocked by remaining health: single throw, fan volley (only the glowing one can be parried), car meteor shower.
- Sealing: when its health reaches 0, a scarf leap point appears on the statue; scarf leap to it and press the seal button repeatedly.
- A full-flow automated test that plays the whole game with a real parry, three rounds of throws, a death and restart, the seal and the ending, saving screenshots at each stage.
Show me the plan first, then build it.

At zero health, a scarf-leap target appeared on the statue. The player repeatedly pressed seal to fill a ring; stopping let it fall.

The statue’s shield is activeThe statue’s shield is active
A successful parry opens the damage windowA successful parry opens the damage window

07 / OVERVIEW

Polish, Test, and Export

Add the scene treatment

After combat worked, I added ground detail, grass, trees, lighting, post-processing, and effects. One soft additive shader gave the aura, rings, projectiles, and trails a consistent look.

Project Prompt
Polish: add the final details to the rest of the town based on the concept art (streets, parks, lane markings and so on). If details are missing or unclear, generate reference images of parts of the town first.
Street layout and lane markings should be as plausible as possible; use Tripo to generate textures if needed. The road surfaces must never flicker.
Add NPR style procedural grass on the lawns.

I checked changes from the player’s camera for flickering roads, blocked doors, and misplaced lamps.

Project Prompt
Render with ACES tone mapping. Add post-processing: bloom, ambient occlusion, SSIL, depth of field, film grain, motion blur, chromatic aberration, FXAA, and an FSR 2 option, all in an Options menu. Bloom, AO, SSIL and DOF have Off / Low / Medium / High; FSR 2 has Off / Native AA / Quality / Balanced / Performance; motion blur, chromatic aberration and film grain are toggles.
Also add VSync and resolution.
The film grain should closely emulate Super 8 film. Godot has no built-in film grain or motion blur, so implement them as Compositor effects.
Main Street before polishMain Street before polish
Main Street after polishMain Street after polish

Add audio and interface feedback

I began with synthesized audio, then replaced most of it with credited CC0 music and effects. Synthesized sounds stayed where no suitable clip fit.

Project Prompt
Find CC0 music and sound effects to replace the synthesized ones. Music should be synthwave / analog synth. Prefer less popular sources so the game feels unique. Where nothing fits, keep the synthesized sound. Verify the license on every page and generate a credits file.

The HUD showed context-specific controls until the player used each move. The first glowing throw briefly slowed time to teach the parry.

Project Prompt
Add interactive hints the first time each move is needed (move, jump, hover, dash, rush, Scarf Leap, grab, throw, parry), for a more explicit and intuitive guide to the controls. Each hint stays until the player actually does the move, then it is ticked off.
First-use control hints for keyboard and gamepad.
First-use control hints for keyboard and gamepad.

Run the full regression pass

Before export, Claude rebuilt the scenes, ran reports, and played from menu to ending, including a real parry, death and restart, sealing, and screenshots.

Project Prompt
Before we export, do a full pass:
1. Rerun every generator in order (build_blockout --float --swap, build_player_scene, build_game) and make sure the main scene is the main menu.
2. Run every report (tree_report, grapple_point_report, street_report, lamp_probe, audio_probe, skin_gap_report) and both automated tests. Everything must pass.
3. Play the game through MCP from the main menu to the ending, take screenshots at each stage and read the game log for errors and warnings.
Report: what passed, what failed, and anything I should check by hand.

The full playthrough caught orientation errors, missing effects, and checkpoint resets after movement or timing changes.

Project Prompt
Export a Windows build of the game. Set up a Windows Desktop export preset for the_red_scarf (embed the PCK, the game icon, product name "The Red Scarf"). Check that the export templates for Godot 4.7.2 are installed; if not, tell me how to install them instead of guessing.
Exclude test scenes, test scripts and Assets/Models/_test/. Write a script that sets the build number and exports, run the exported exe once, and report the build size and any errors.

The first Windows export was 1.15 GB, mostly textures. Removing unused assets and old models and using smaller normal-map compression brought it to 755.5 MB.

A playthrough of the final game

08 / OVERVIEW

What I Would Carry into the Next Project

The workflow I would repeat is:

  • Describe the intended result.
  • Make one small prototype.
  • Inspect it in the real runtime.
  • Turn each repeated problem into a rule or report.
  • Only then scale up.

I would reuse the same pattern: one source for the town layout, checkpoints for asset batches, geometry rules for scarf leap, and a full boss-fight test.

For a similar demo, start with one character, one route, and one enemy. Test a representative asset before batching, and turn recurring problems into checks you can rerun.