One Prompt, Four Models - Which AI Is the Better Game Developer?

Model launches inevitably spawn new evals measuring how they stack up against prior releases. With a significant share of revenue now coming from agentic engineering via coding harnesses, Terminal-Bench and SWE-bench are what the AI labs themselves tout in their press releases. While these assessments do measure coding, they are ripe for benchmaxxing (essentially including the answers in the model by training on the exam questions) and fail to answer the most important question: can it draw a pelican on a bike? In all seriousness, I think it’s important to keep the frontier model companies on their toes by asking novel questions that they’ve never seen in pre-training so that you can get an honest evaluation of how they work in the real world. So - continuing from my deep dive on the Kimi K3 launch earlier this week - I’ve decided to come up with a simple game prototype prompt for my test.

Why a game #

I’ve been having fun using AI to prototype simple game ideas recently. Despite what you might have heard, LLMs are not able to just make a game out of thin air. This is true for clones of existing games, and doubly true when there’s no reference material to clone. Games are complex works of art, whether made by a few people or hundreds; too many factors and design decisions go into the process for anything of measurable quality to come out the other end. However, they’re great tools for standing up a quick prototype to see how the gameplay feels. In this case, I’m not trying to develop an idea - I just want to see how each model responds to being asked to create something that (likely) doesn’t already exist in the model.

The setup #

To challenge the models with an unfamiliar design, I picked a popular game that released earlier this year and likely wouldn’t have been omnipresent in the training data. I also had to specify that the models must not use trademarked assets or content in their finished product. Here is what I came up with:

Build a complete, playable **Godot 4.x** game: a cozy sandbox life-sim where you play as a shapeshifting blob creature that has taken human form, and you terraform a wild island into a thriving habitat that attracts creatures to come live with you.

Create a **complete Godot 4 project** in the current working directory — `project.godot`, every `.tscn` scene, and every `.gd` script — that runs immediately when I open the folder with the Godot editor. Since you cannot produce binary assets, **do not reference any image, audio, or font asset files**: all visuals must be produced in code (drawn with `_draw()`, `Polygon2D`, `ColorRect`, procedurally generated `ImageTexture`s, or `TileMapLayer` tiles built from generated atlas images) and any audio must be synthesized at runtime with `AudioStreamGenerator`. Write idiomatic GDScript with typed variables. Do not use placeholder comments like `# add more here` — every feature you list must actually work, and every scene you reference must be included.

## Core fantasy

You are a shapeshifter in human form. You cannot fight — instead, you **copy abilities from creatures you befriend** and use those abilities to reshape the world. Do not use actual game names, designs, or trademarks: invent your own original creatures and ability names that fill the same roles.

## World

- Procedurally generated 2D top-down tile-based island, at least 96x96 tiles, with distinct biomes: meadow, forest, rocky hills, pond/lake, and beach edging into ocean. Use `FastNoiseLite` for generation and a `TileMapLayer` (or equivalent) for rendering.
- A `Camera2D` follows the player smoothly; the world is larger than the screen.
- Full day/night cycle (~3 minutes per day) with smooth lighting/tint transitions (e.g. a `CanvasModulate` driven by the clock), plus occasional rain weather that waters crops automatically.
- Tiles are editable at runtime: the terrain the player sees can be changed by abilities (see below).

## Player

- WASD/arrow movement using a `CharacterBody2D` with smooth (not grid-snapped) motion and collision against water, trees, rocks, and placed objects.
- A simple but charming animated character (drawn in code — walk cycle, facing direction, a subtle idle bounce).
- Interact with the tile in front of you via mouse click or an interact key (E or Space).

## Abilities (the heart of the game)

The player starts with no abilities. Each wild creature species grants one ability when befriended. Implement at least these five, each with a visible effect and `GPUParticles2D`/`CPUParticles2D` feedback:

1. **Water jet** — waters tilled crops, fills dug holes to create ponds, douses things.
2. **Vine lash** — cuts tall grass and harvests plants in a small arc, drops seeds/fibers.
3. **Flame burst** — burns trees into wood + clears stumps; cooks harvested food into better food.
4. **Dig** — tills grass into farmland soil, digs holes, can lower terrain to shape ponds.
5. **Rock throw / boulder smash** — breaks rocks into stone for building.

Abilities are selected via a hotbar (keys 1–5) with icons and cooldowns.

## Farming loop

- Till soil (Dig) → plant seeds → water (Water jet or rain) → visible multi-stage growth over time → harvest (Vine lash).
- At least 3 crop types with different growth times and values.
- Harvested goods go into an inventory (I key opens it) with stack counts.

## Building

- A build menu (B key) lets the player place objects using gathered resources: wooden fence, stone path, flower bed, small pond, berry bush, lamp post (a `PointLight2D` that lights up at night), and a cozy house.
- Placement shows a valid/invalid ghost preview; resources are deducted; objects can be removed for a partial refund.

## Creatures & the habitat system

- At least 6 original creature species wander the wild, each with distinct code-drawn looks, movement personalities (skittish, curious, lazy...), and simple needs.
- Each species has **habitat preferences** (e.g., "wants 5+ flowers and a pond nearby", "wants stone paths and lamp posts"). When you build an area meeting a species' preferences, wild ones visit, a heart meter fills as their needs stay met, and they **move in permanently** — unlocking their ability for you and appearing in a journal.
- A journal (J key) lists every species: silhouette if unseen, full entry with their habitat requirements and befriend status once encountered — this is how the player learns what to build.
- Resident creatures roam your village, sleep at night, and occasionally leave gifts.

## UI & polish

- HUD (built with Godot `Control` nodes): clock/day counter, weather icon, hotbar, current resources.
- A gentle onboarding: the first creature you meet walks up to you, grants Water jet, and a short tooltip-style quest chain teaches till → plant → water → harvest → build → befriend.
- Particles for every ability, footsteps, and harvesting; floating "+2 wood"-style pickup text.
- Ambient synthesized audio: soft day/night ambience and small sound effects for actions via `AudioStreamGenerator` (with a mute toggle, M).
- Save/load the full world, inventory, and creature state to `user://save.json`, autosaving each in-game day, with a "New Game" option.
- Target smooth 60 fps; avoid per-frame allocations and per-frame full-map scans.

## Deliverable

Before writing any code, state a brief architecture plan (under 200 words) listing every file you will create. Then create all files in the current working directory. Define all input actions in `project.godot` so no manual Input Map setup is needed. Before finishing, re-check your work: every script path, scene path, and node path referenced anywhere must actually exist in the project. It must open and run with zero edits.

Now that I had my one-shot prompt, I needed to decide how to run the tests and on which models: a four-way competition across two harnesses. Kimi K3 and GPT-5.6 Sol would run through Codex (partially because it was easy to patch in routing to OpenRouter) and Claude Fable 5 and Claude Sonnet 5 would run via Claude Code. They would all use the same prompt verbatim, running on the same machine, under the same rules. In order to increase the difficulty of the challenge, I decided to have them deliver their game using Godot instead of the more common Three.js web demos that they were likely heavily trained on. I also disallowed them from having a local copy of Godot in their test environment - I wanted this to accurately measure what they first produced, not what they could brute force their way into delivering (which is also a very valid test). My plan was to measure them across the quality of work, token usage, cost, and wall-clock time to deliver - one run each, native harness included, so weigh the numbers accordingly.

The scoreboard #

Many of my evaluation criteria were straightforward metrics with a clear ranking:

My takeaways:

• Sol did not mess around! It saw the task and moved straight to delivering it, finishing in under 6 minutes.
• Sonnet used 25M tokens - nearly 4x the nearest competitor and staggeringly more than Sol’s meager ~700k.
• Fable and Sonnet budgeted a similar share of their output on reasoning (roughly three-quarters of it, by my estimate²), with K3 coming in second and Sol a distant third.
• K3 took forever to actually do anything. It eventually delivered after a staggering 1 hour 38 minutes, an eternity relative to Sol and the modest Claude contenders.³ With no output after 20 minutes, I worried that nothing was happening, but tracing the network traffic confirmed that it was just reasoning a ton before taking its first turn (a consequence of the way Codex operates).
• Fable (unsurprisingly) cost significantly more than the other models at $19.14.⁴ What did shock me was that Sol was by far the least expensive.

Judging the actual quality of the games was more complicated. That meant playing each of them (as much as possible) to see how they felt, and weighing the intangibles - an inherently subjective process.

However, before I get to that I should note that only two of the games loaded without compiler errors (Sonnet and Fable). The Sonnet game had its own issues (the UX was parked in the top-left corner of the screen, rendering it basically unplayable), but it did load. Only Fable ran with zero modifications to what was delivered. I decided to allow Fable to fix the other models’ work (small surgical changes only) to get the games running. Each set of changes was 30 LOC or fewer - and somewhat ironically, having Fable fix them all cost more than producing their code did in the first place.

Only Fable ran with zero modifications to what was delivered.

Judging the games #

Main Menu #

Now that each game was runnable, I decided to load them up and see what we got. This is also where we got our first look at the naming taste each model had - however, that deserves its own section so I’ll defer commenting for now. Most of the models produced an actual menu screen for starting a new game or continuing from a save. At first I thought Sol had ignored this entirely, but I eventually discovered a menu overlay on the Esc key (included here for your comparison):

Creatures & UI #

We had a game! Things were going reasonably well up to this point - the next thing to judge was the interfaces for the game systems. I started with the journal - the most important of these, since it set up the guidelines for progression:

I’m going to have to score this a tie between K3 and Fable. K3 has the clearly better layout for the overlay and some genuinely interesting creature design, while Fable delivers cute creatures and helpful information about each creature’s state. Sol and Sonnet get the job done as well. Honestly, none of these were bad - I was starting to get my hopes up for the game itself. Next up was the inventory:

K3 slightly edges out Sonnet on this one. However, you’ll notice I could only show you one item type in the Kimi build - more on that soon. Fable underwhelmed here from a style standpoint, but the ability to see what you had selected should not be understated. Sol had an inventory, so I guess that counts. Onto the final UX component, the build interface:

Gameplay #

Now that the basic interfaces had been tested, it was time to move onto the actual gameplay - and this is where things started to take a turn. My goal was to genuinely play each game to completion where I could. The game’s objective was to recruit every creature type, acquire their abilities, and build out a cozy little world. Only one of the games actually played like a real game, with progression and working mechanics.

Fable

I realize there probably wasn’t much suspense on which entry pulled it off - Fable was the only game of the group that felt like a real (albeit short) game. The day/night cycle and weather effects worked (with a funny snoring animation that played when the creatures slept at night). The actions gave clear feedback when used - both visually and with text when necessary. There were visual indicators on what tile you were selecting and whether an object was placeable. There was a sense of z-scale - the player was occluded when walking behind a tree. The game economy worked and you could meet the requirements to progress through all the creature types. There was different attract/repel logic for the creatures, and the Fluffnib actively avoided my character until I met the right conditions (also providing an entirely Fable-invented 25% speed boost when I hearted them). While it clearly cost the most, this was starting to be the basis for what could be an actual game. I actually - somewhat - enjoyed my playthrough.

K3

Kimi, Kimi, Kimi - we started off so well, why did it have to go so wrong! Unfortunately, this is where the veneer of the game started to crack apart. I could not for the life of me get any gameplay elements to work. Across multiple reloads, sometimes I’d get the water jet ability (seemingly by pure luck) and sometimes I wouldn’t. I finally decided to pull Fable in to see what was going on (because I surely wasn’t going to actually logic my way through its code), asking “why can’t I learn skills from the creatures?” - and it found that the game’s core progression is not just buggy, but provably unwinnable. There were three independent hard locks - here is the Fable response, verbatim:

1. **The seed ability is never granted.** The only ability sources are the tutorial meeting (Water Jet) and creature move-ins. But `creature_met()` is only ever called from the WANDER-state encounter check (`creature.gd:165-175`), and the tutorial Dripple spawns directly into APPROACH (`world.gd:291`), then FOLLOW — a terminal state that never returns to WANDER. No wild Dripples spawn as a backstop (`world.gd:263` spawns zero of the tutorial species). Fresh game: zero abilities, ever. (Only a save/reload works around it — `from_save` resets FOLLOW to WANDER.)
2. **Dig is circularly locked.** Moleto teaches Dig; Moleto's habitat requires 4 soil tiles; soil is created only by the Dig ability (`world.gd:441-442`). Dripple's habitat is Dig-locked too (needs wet soil), and doubly so: the buildable "Small Pond" places an `Obj.POND` object (`world.gd:595`) while the habitat scan counts only water *tiles* (`world.gd:751`), so the pond you can build satisfies nothing.
3. **The material economy is circularly locked.** Wood, stone, and fiber require Flame Burst, Boulder Smash, and Vine Lash — taught by creatures whose habitats cost wood, stone, and fiber to build. Starting inventory is 4 turnip seeds; barehand interaction only picks up gifts, which come only from already-resident creatures.

Even ignoring all of the above, move-ins are near-unreachable in practice: creatures only start homing within 9 tiles of the village center (`creature.gd:192`), spawn deliberately >8 tiles away (`world.gd:268-273`), and random-walk a 112×112 map with no pathfinding; the one species that approaches the player locks itself into the terminal FOLLOW state by doing so.

This wasn’t just a quick fix to get us back on track - the entire set of interconnected gameplay systems would need rebalancing to make the game playable. However, I was still able to have some fun (for like a minute) - there was a very funny gameplay element that did seem to work. When you walked above a creature, you could sit on top of it - being carried around the map as if you were riding it. Because the creatures seemed to get locked into a follow state, you would collect a little creature army as you were shuttled around the game world. I genuinely don’t know how or why this behavior manifested, but it was sort of fun to watch.

Sonnet

After being dejected with my K3 run, I was ready for a palate cleanse on the Sonnet build, and it delivered. The game played quite well - appropriate collision on trees, water, and ponds (even Fable didn’t prevent walking on water). It was very difficult to see at night, but I guess you can argue that’s what the lamps are there to solve. There also seemed to be an intermittent progression bug - sometimes I’d get the fire ability (for collecting wood), sometimes not. I couldn’t get the sixth creature type to spawn; maybe there was a condition I wasn’t meeting. That said, I played until I had collected all the core abilities and built everything. I would score this as a functional, working game.

Sol

Now I was ready to try good ole five-minute Sol - let’s see what you made us for a buck-fifty. It started off a little shaky - there was a persistent frame-rate stutter (perhaps some uncaught exception), but it was definitely still playable. To my surprise, everything seemed to work. I was shocked that with such little effort, it had built out the spec (for the most part) at the bare minimum quality level. There were gaps though: you could select any tile on the map regardless of player proximity, there was no way to unselect a building (which meant every click fired both the ability and the building placement), and there were circular dependencies on progression (you need vine lash to collect berries, but you can’t acquire vine lash without collecting berries). That said, I was able to play through the game and do most of the mechanics. I hearted creatures, grew crops, harvested terrain, and built a base.

Audio #

In a decision that I quickly learned to regret, I had asked the models to generate audio for the gameplay. It was almost universally awful. Thankfully there was a mute command that I rapidly employed for most of my gameplay. I waited until my screenshots and notes were done before going back for a thorough audio evaluation of each:

• Fable: the ambient music was soft wave sounds. There were footsteps, water splash is a whooshing noise, lash is a slapping sound, and dig is a crash. Planting seeds is a water-droplet-like noise. There is a “can’t take action” sound that is what you imagine a failure noise to be. When it’s raining, it seems to escalate the ocean wave noise in volume (which sort of works).
• Kimi: the always-on music is annoying white noise (very mild wave in and out). There are some interesting chirping noises occasionally. For abilities, the only one I could test is water splash, which sounds like an annoying blast noise. The rain effect is an unbearable television static noise. These sound effects were far and away the worst.
• Sonnet: there is no ambient sound or rain sound. The “can’t take action” is this gentle bloop noise that is fantastic - in general, this had the best sounds of all the games. The action sounds felt Nintendo-esque with gentle tom drum sounds, pitched correctly. There is a sound that plays at the start of a new day. Learning a new ability plays a piccolo-like sound. Sometimes I would hear a weird, very low volume siren noise (not necessarily unpleasant).
• Sol: no sound. A blessing in disguise.

Naming #

With the visuals, gameplay, audio, and progression testing complete, I was ready to judge one of the more nuanced aspects of the game: the names. The prompt had left a lot of room for interpretation here - specifying only the functional aspects of the game, and even requesting a sixth creature while providing only five abilities. Here is what we ended up with:

The first thing I have to say is that “Blobbo’s Island” is a genuinely hilarious name. I literally laughed out loud when I first read it. I have to give props to K3 for the alliteration (Muddle’s Meadow rolls off the tongue). Shapehaven Island is probably the most game-appropriate name of the group, but none of them are that great.

When it comes to the creature names, they are all pretty good. It’s hard to judge between them - it’s mostly subjective. I don’t think any of the models did a bad job here; each of them feels like they could work (pending the alignment with the visual design). I was fascinated to see some commonality (Aqua/Cinder/Mole/Boulder) across the different models.

Given that each model was free to choose its sixth creature, I was a bit surprised to see a flying moth-like creature line up across three of them. There aren’t too many mechanics to tweak on their ability - having gift giving, lighting, and speed get chosen was also interesting.

The verdict #

I was originally going to come up with a complicated scoring rubric to objectively judge them (albeit using subjective scores), but I decided against that. There was one clear winner here: Fable. Fable cost significantly more than both K3 and Sol, but it was also the only entry that actually delivered on the ask. Each model produced interesting results (K3 with layouts, Sonnet for its audio/icons, Sol for its…well, it was cheap). I do have to give Sol a special callout - given how little effort (and cost!) it put into its entry, I was amazed to see that it worked as well as it did.

What I learned #

Honestly, I’m not sure it’s appropriate to say I “learned” anything from this exercise. I did have a lot of fun doing it. Since this article series is about the Kimi K3 launch, I will say I learned that K3 has an incredibly slow response time and struggles with the actual details. It produced some nice UX that was pretty on a surface level, but once I dug a level deeper it failed to hold up under scrutiny. It’s clearly a powerful model though. If you’re planning on using it for well understood coding problems, I suspect it will do well enough - however, I’m not confident it will be less expensive than another frontier lab. Its real advantage (for large enterprises with enough compute to self-host) will be in how the open-weights release stacks up against other open-weight models. I’m also very curious to see how quantized versions keep their quality - perhaps I’ll rerun this experiment locally when an MLX version gets published.

On Monday, the final part of this series looks at the collision between open weights and government interests - and what that means for everyone building on top of AI. If you missed the first part, earlier this week I posted my initial thoughts on the launch week hype and aftermath. Benchmarks tell you who’s winning - building Blobbo’s Island tells you what they’re like to work with.