Roundup
Game development is one of the hardest domains to give a clean "best model" answer for, because a single gameplay feature can mix three things a benchmark never tests together: engine-specific API knowledge (Unity, Unreal, or Godot), real math (vectors, quaternions, physics), and performance discipline (this runs every frame, 60 times a second). A model can nail the API and get the math wrong, or nail both and write something that tanks the frame rate. No benchmark measures any of this, so this ranking leans on general reasoning and real-world reports, then hands the deciding vote to your engine. The live board is at /benchmarks (VCI = SWE 40 / TB 30 / LCB 30).
The honest caveat: there is no canonical game-dev benchmark with the authority SWE-bench Verified has for Python, and SWE-bench is Python repo surgery — it touches none of C#, C++, or GDScript. Read what follows as informed guidance, then test the shortlist in your actual project.
Why the Python benchmark still tells you something
General coding ability transfers. A model that reasons well about algorithms and structure carries that into gameplay logic and systems code. And the LiveCodeBench component of our index (the LCB in the VCI) is especially relevant here, because a lot of game code is exactly the self-contained algorithmic problem-solving LCB measures — pathfinding, collision, state machines. So SWE-bench and LCB together make a reasonable shortlist signal. The numbers below are general, not game-specific — that caveat is the point.
| Model | SWE-bench Verified (general proxy) | Why it matters for game dev |
|---|---|---|
| 95.0 | Top ceiling for complex systems and math (LCB 89.8) | |
| 88.6 | The safe default across Unity, Unreal, Godot | |
| 85.2 | High-volume gameplay scripting | |
| 80.6 | Strong all-rounder, good math reasoning (LCB 85.3) | |
| 79.3 | 167 tok/s — fast gameplay iteration (LCB 87.6) | |
| 77.6 | $0.435 / $0.87 per M — cheap high-volume scripting | |
| 77.3 | 204 tok/s — fastest here, great for rapid edits | |
| 75.6 | Strong self-contained problem-solving (LCB 88.5) |
The three things that have to line up
- Engine API. Unity's C# and MonoBehaviour lifecycle, Unreal's C++ and Blueprint interplay, Godot's GDScript and node tree — each is its own idiom. A model strong in general C# can still misuse Unity's coroutines or lifecycle callbacks. Godot, being less represented in training data, shows more variance. This is what your own-project test surfaces.
- Math. Vectors, quaternions, dot and cross products, interpolation, physics. Here the reasoning ceiling matters — and the LiveCodeBench numbers are a real signal, since math-heavy game code resembles LCB problems. Fable 5 (LCB 89.8), Gemini 3.5 Flash (87.6), and GPT-5.5 (85.3) all reason well about this kind of self-contained logic.
- Performance. Game code runs in a hot loop. Allocating in
Update, an O(n²) check across all entities, a shader that stalls the GPU — correct code that murders your frame rate. A careful model flags these; you still profile. The simulator lies here too: measure on target hardware.
Speed versus ceiling
A lot of gameplay work is fast iteration — tweak the behavior, play, tweak again. Fast models like Gemini 3.5 Flash (167 tok/s, and strong on LCB) and Qwen3.7 Max (204 tok/s) make that loop pleasant, and for routine scripting their capability is plenty. Step up to Opus 4.8 or Fable 5 for the hard parts: a physics system, a netcode layer, a performance-critical algorithm where the math and the frame budget both have to be right.
Picks by engine and task
- Unity (C#). Opus 4.8 as the default — it knows current Unity idioms well. Fable 5 for complex systems. Fast models for routine gameplay scripts.
- Unreal (C++ / Blueprint). The reasoning ceiling matters most here given C++'s complexity — Opus 4.8 or Fable 5. Verify Blueprint-to-C++ reasoning explicitly.
- Godot (GDScript). More model variance; test candidates directly on your node tree. Opus 4.8 is the safe starting point.
- Math-heavy systems. Weight LiveCodeBench — Fable 5, Gemini 3.5 Flash, and Gemini 3.1 Pro all score high.
How to actually test on your stack
- Pick one representative task — a real gameplay feature, a real math bug, a real performance issue. Not a toy.
- Give the same decision-complete task to two or three candidates. See prompt engineering for coding agents for how to make it fair.
- Judge on your criteria: correct engine API, correct math, and — profiled on target hardware — no frame-rate hit.
- Repeat on a second task. One is a data point; two is a signal.
Bringing your own API keys makes this cheap — swap the model, rerun the task, compare. The Vibe Father runs different models against the same job for exactly this reason.
Our honest bottom line for game dev
Want one model across engines? Opus 4.8 — the most consistent across Unity, Unreal, and Godot. For hard systems and math, Fable 5, and lean on the LiveCodeBench numbers for math-heavy work. For fast gameplay iteration, Gemini 3.5 Flash or Qwen3.7 Max. But game dev is uniquely resistant to a single answer — engine, math, and performance rarely all align in one model for one task, so test in your project and profile on real hardware. Trust the board as a shortlist. Understand the puzzle metric in the LiveCodeBench explainer, and see the whole field in the best coding model roundup. Live numbers at /benchmarks.