Claude Sonnet 5.5 vs. Opus 5.5 vs. GPT 6.1: Building a 3D Dungeon Game with Pure Code

Three models were given the same challenge: build a playable dungeon game entirely through code — no texture images allowed — using Python scripts to model environments and animations in Blender, then assembling everything in the Godot engine. The flagship Opus 5.5 was expected to dominate easily, but the mid-tier Sonnet 5.5 kept pace surprisingly well, while the budget-friendly GPT 6.1 exposed some serious weaknesses. The real-world results turned out far more interesting than any benchmark leaderboard.

Phase 1: Stylized Dungeon Environment

The reference style was clear — rough stone blocks, deep shadows, and a visual contrast between cool water pools and warm firelight. All three models operated without the Blender MCP plugin, writing Python scripts to drive Blender in headless command-line mode. The setup included a builder agent and a reviewer agent: the reviewer would examine rendered outputs and feed back revision notes, while the model had full autonomy to decide whether to keep iterating or submit the final result.

In terms of output quality, Opus 5.5 produced the scene closest to the reference — heavy shadows, rough stone textures, and an overall lighting quality that felt remarkably refined. Sonnet 5.5 was equally impressive, handling rough stonework, water pools, and warm rim lighting with strong stylistic fidelity. GPT 6.1, by contrast, delivered something noticeably flatter — the layout was readable but the walls and floors were too uniform, with weak stylization and little of the gloomy dungeon atmosphere.

The technical approaches were fascinating to compare. Looking at the stone walls in isolation — with no external textures at all — Opus 5.5 relied on actual geometry: stone block protrusions were real mesh geometry, with darker base bands achieved through vertex color shading. GPT 6.1 took a completely different approach: it scripted the creation of 12 distinct stone materials and assigned them to different geometric surfaces. The two strategies reflect meaningfully different interpretations of the task.

The Surprising Bill

The visual results might suggest a clear ranking between flagship and mid-tier, but the estimated API-equivalent costs from Phase 1 were completely unexpected. GPT 6.1 finished in 1 hour 20 minutes with 137 API calls, for an equivalent cost of roughly $3.77. Sonnet 5.5 ran for 4 hours 50 minutes with 1,670 calls — cache reads alone came to $114 — bringing the equivalent bill to $164.79. Opus 5.5 took 4 hours 44 minutes with 1,492 calls, for an equivalent cost of $205.49.

The root cause: Sonnet 5.5's per-token price is only half that of Opus, but it made significantly more calls and consumed far more tokens overall, driving the final bill sharply upward.

---

What is Headless Mode? It refers to driving Blender via the command line — without any graphical interface — to execute Python scripts that handle modeling, materials, rendering, and all other operations. This approach is commonly used for server-side batch rendering and automated pipelines. For AI models, it means bypassing the GUI entirely and describing every detail of a 3D scene through pure code: vertex coordinates, material node connections, light positions and intensities are all written as scripts and interpreted by the Blender engine. This requires deep familiarity with Blender's Python API (bpy) — a single incorrect API call can crash an entire script or produce broken geometry. The rendered screenshots returned by the reviewer agent serve as the model's only "eyes," making iterative visual feedback the sole correction mechanism.

---

Phase 2: Character Modeling and Animation Rigging

Phase 2 raised the difficulty considerably — all four characters (knight, skeleton warrior, slime, and bat) had to be built from scratch in Blender through pure code, including full skeletal rigging and motion animations.

Sonnet 5.5 delivered a genuine surprise here: the skeleton warrior's bones scattered realistically on defeat, and the bat's wing-flapping motion looked genuinely natural. Comparing animations side by side across all three models, Sonnet 5.5 and Opus 5.5 were nearly neck and neck on the knight's running, sword-swing, and death animations, as well as skeleton movement.

GPT 6.1's knight death animation was extremely crude, and the skeleton moved with the stiffness of a tin toy. All three models performed relatively similarly on the slime's movement and bat flight — suggesting that simple motion has a lower difficulty floor, and that the real differentiator is complex, physically expressive animation.

---

What is Rigging? It's the core workflow for 3D character animation: an armature made of bones is created inside the character mesh, and weight painting defines how much each bone influences the surrounding vertices, allowing the mesh to deform as the skeleton moves. Implementing this entirely through code is extremely challenging, because weight distribution is normally painted manually by artists in a 3D viewport. Converting that process to a script means mathematically describing distance falloff relationships between each vertex and its influencing bones. The skeleton collapse effect further requires triggering constraint releases or rigid body simulation at specific frames — an even deeper test of the model's command of Blender's physics system API. This is precisely the technical barrier that Sonnet 5.5 cleared in this phase.

---

Phase 3: Importing into Godot and Assembling the Game

The final phase required importing all scenes and characters into the open-source Godot engine, wiring up interaction logic, and assembling everything into an actually playable dungeon game.

Opus 5.5 delivered solid combat gameplay: the knight's movement was smooth, monster interactions felt natural, sword strikes produced spark effects, and the hit feedback was genuinely satisfying. Its one weakness was that the water surface effect lost some of its Blender-rendered quality after importing into the engine.

Sonnet 5.5 was one of the real highlights of the test. It shared the same water-surface degradation after engine import, but its combat and monster interactions were consistently strong — its completion level stayed tight on Opus's heels. GPT 6.1, however, fell apart in the live gameplay phase: characters looked too blocky, movement felt wrong, and more egregiously, the knight's special attack triggered a clipping bug — the character sank through the floor and emerged somewhere else entirely, performing a spectacular disappearing act.

The Secret Behind Game Feel

Why did Opus 5.5's game feel noticeably better? The key was layered hit feedback. Strip all the feedback away, and a sword strike feels like swinging through air. Add back the animation, sound effect, particle effect, hit flash, hit stop, screen shake, and knockback one layer at a time, and the same strike transforms from weightless to viscerally satisfying. That sense of impact is built entirely from this stack of carefully layered feedback.

---

Game designers call this "Game Feel" or "Juice" — a framework systematically articulated by Martin Jonasson and Petri Purho in their 2012 GDC talk. The core idea: the more immediate and varied the perceptible feedback triggered by a single action, the more players feel that their input "has weight." Hit Stop simulates physical impact transfer through momentary frame-freeze; Camera Shake activates the player's vestibular perception; Knockback provides visual confirmation of spatial displacement; Hit Flash uses visual contrast to emphasize the moment of contact. Opus 5.5's ability to autonomously generate and combine these mechanisms at the code level suggests a systematic understanding of game feel engineering — not merely "writing logic that runs."

---

Final Tally: Value vs. Cost

Putting the equivalent API costs and total time for all three models side by side surfaces a central question.

Sonnet 5.5 ran for 13 hours 46 minutes with an equivalent bill of $318. Opus 5.5 ran for 12 hours 58 minutes at $376.30. GPT 6.1 finished in just 7 hours 5 minutes for only $29.17.

These two sets of numbers reveal something important: although Sonnet 5.5's per-million-token price is half that of Opus, its higher call count and much greater token consumption on complex tasks mean the total bill across all three phases isn't dramatically different from the flagship. And while GPT 6.1's output was rough and bug-ridden, its total cost was less than one-tenth of the other two, in roughly half the time.

Conclusion: Half the Price ≠ Half the Bill

Across this three-phase dungeon development test, mid-tier Sonnet 5.5's output quality came impressively close to flagship Opus 5.5. But paying half the per-token price didn't translate to half the total bill — because complex, long-chain tasks amplify call counts and token consumption, eroding the unit-price advantage.

This points to a very practical decision problem: are you willing to tolerate GPT 6.1-level roughness and bugs to save 90% of the budget, or is it worth spending an extra ~$300 for a genuinely usable result? In high-quality, long-chain task scenarios, flagship-tier models still offer irreplaceable value. A lower unit price is appealing, but what truly determines total cost is a model's ability to get things right the first time.

---

This phenomenon is known in AI engineering as "token bloat": in long-chain, multi-iteration agentic tasks, models repeatedly read and write large amounts of conversation history for self-verification, error recovery, and context maintenance — causing each call to consume far more tokens than a simple single-turn query. Sonnet 5.5's 1,670 calls versus Opus's 1,492 suggests it tends toward more frequent small-step iteration rather than fewer large-step reasoning passes, which offsets its unit-price advantage. This is a critical warning for API cost estimation: when evaluating the real cost of autonomous agents, don't just look at model pricing — you also need to estimate the call-count multiplier introduced by task complexity.