No. 04 · Comparison · Browser game
Artillery, four ways
One prompt, four models, and where my feedback took three of them
I gave four AI models the same prompt for a two-player artillery game. Claude Opus 5.5 had one go. With the other three I kept playing and giving feedback, and each game went its own way. Play all four.
The four games
Pick a game to see how it was made, or press Play to try it.
Not a benchmark this time
For Same brief, different models, every model got one go and I ranked the results. This one started the same way, as a vibe coding challenge (you describe what you want, the AI writes all the code) with a strict prompt: two castles on a landscape that’s new every game, wind and gravity, and two players passing one device back and forth.
Then I kept going, with three of them. Claude Opus 5.5 had its one go and no more, for a plain reason: Claude is my main work tool, and I needed its usage limits for work. The other three are mostly what I play with. With Gemini 3.8 Flash, GPT-6.1 Sol and Grok (in Grok Bot), I played each version, said what bothered me, and let the model improve it. I asked each one for different things, so the runs aren’t equal and I’m not ranking them. What you get instead is four takes on the same idea, and a look at what feedback does to a game.
The same flaw, three times
The first versions of the three I kept working on all had the same flaw. Nothing stood between the castles, so you could lower the barrel, fire at full power and hit every time. And at least one version of each started with settings that hit, or nearly hit, on the first turn. That meets the prompt, but it isn’t much of a game.
So my feedback in the early rounds was nearly the same each time: put a mountain in the way, move the castles apart, and start each cannon on a setting that misses. From there, the games went in different directions, partly because I asked each one for different things. Gemini’s peaks rise so high that only arcs between 50° and 75° clear them, and its peasants shout “MY CABBAGES!” when you hit them. GPT-6.1 Sol got a computer opponent that learns from its misses, a camera you have to move to scout the valley, and villages that repair your castle and forge better ammunition. Grok made the weather change every turn, so the settings of your last hit rarely work twice, and gave each castle an armory and a workshop the other side can destroy.
Opus’s single version already had a mountain between the castles and villages in the valleys. The prompt asks for neither.
What it shows
Every first version met the prompt on paper. Whether a game is fun only shows when you play it, and that’s what the feedback rounds were for. It’s the same with AI at work: treat the first answer as a draft, say what’s wrong with it, and go another round.
The prompt is at the bottom of this page. Give it to the model you use, play what comes back, and tell it what’s wrong.
All 4 versions, one by one
Each game opens on its own page, as the model delivered it. The run facts for all 4 are in one table further down.
-
Worth knowing: One go, no feedback: what you play is its first and only version.
-
From the prompt, then my feedback
Gemini 3.8 Flash
in Antigravity
It called the game Artillery: Two-Player Fortress Siege
What my feedback changed
Two versions, one round of feedback. The first met the prompt on paper, but winning was too easy. Nothing stood between the castles, so a flat shot at full power hit every time, the starting settings almost guaranteed a hit on the first turn, and the castles stood too close together. My feedback: block the line of sight with mountains, push the castles apart, start each cannon on a short sighting shot instead of a free hit, and put countryside you can destroy between the kingdoms. In the version you can play, peaks rise well above both castles, so only high arcs between 50° and 75° clear them, the default aim lands in the near foothills, and cottages, trees, haystacks and windmills stand in the valleys, with peasants who complain when you hit them ("MY CABBAGES!").
-
What my feedback changed
Five versions. The early ones looked good, but winning was too easy: low shots at full power reliably hit, and one revision even started with settings close to a hit. So the castles moved further apart, mountains block direct fire, you have to adjust the starting settings before you can hit, and trees and farms can be destroyed. Then I asked for a computer opponent that learns from its misses, so you win by finding the range faster than it does, and for a camera you have to move to scout the valley. Last came villages: masons repair the castle and forges make stronger ammunition, so destroying them is a tactical choice. Along with them came stronger wind changes, mist and rain, which make a repeated shot unreliable without any randomness during flight.
Worth knowing: The only one with a computer opponent, which the prompt ruled out; it was my idea in a later round. You can still play it with two players. By Codex's own report, it checked the last version with 250 simulated matches, 1,800 trajectory cases and browser tests.
-
What my feedback changed
Three versions, each starting from a problem I found while playing. In the first, a flat shot at full power always hit, so the second moved the castles far apart behind a mountain that always blocks the line of sight, and added trees, farmhouses and peasants you can destroy. Then I noticed the default aim already hit, so each cannon now starts at a random setting that's checked to miss. For the third, I wanted a shot that hit once not to hit again with the same settings: wind and weather change every turn, with gusts, rain, snow and storms, and the camera stays near your castle with no overview of the map. Each castle also got a village with an armory for special shells and a workshop that repairs the walls, and both can be destroyed.
Worth knowing: Grok Bot doesn't show which model it used. I assume Grok 4.7, xAI's strongest model at the time. By its own account, it tested the game with hundreds of thousands of simulated shots: a flat shot never got through, and repeating the settings of a hit landed only about 1 time in 10. Reading the wind first got that to about 3 in 4.
The runs in numbers
Effort is the reasoning setting, named the way each tool names it. Size counts what the model wrote, without the site's link back to this page. For the three I iterated on, it's the size of the last version.
| Version | Tool | Effort | Size |
|---|---|---|---|
| Claude Opus 5.5 | Claude Code | Max | 4,378 lines · 251 KB |
| Gemini 3.8 Flash | Antigravity | High | 2,816 lines · 103 KB |
| GPT-6.1 Sol | Codex | Ultra | 328 lines · 85 KB |
| Grok 4.7 | Grok Bot | Not recorded | 877 lines · 104 KB |
How these were made
- Every model started from the same prompt, shown at the bottom of this page. It asks for a two-player game with no computer opponent, built in one go without feedback, and it still lists judging criteria, because that's how this started.
- Claude Opus 5.5 had exactly that: one go, no feedback from me.
- With the other three, I kept going after the first version (one round with Gemini, to make it more challenging, and more with the others): I played it, said what bothered me, and let the model improve it. I asked each one for different things, so the games moved in different directions. GPT-6.1 Sol got a computer opponent, which I asked for even though the prompt ruled one out.
- Each model ran in the tool I'd use it in (Claude Code, Antigravity, Codex, Grok Bot).
- Each game is published as delivered; for the three I iterated on, that's the last version. The site only adds a link back to this page and a description for sharing.
- No ranking and no scores. The runs weren't equal, so this is a look at four different results, not a benchmark.
The prompt all four started from About 800 words, pasted as it is. Use it for your own run.
Vibe Coding Challenge: "Artillery"
The task
Build a two-player artillery game as one standalone HTML file. Two castles stand on a 2D landscape that is newly generated for every game, each with an artillery gun mounted in its middle. The players take turns aiming and firing at each other's castle until one is destroyed. Both players play on the same device and pass the controls back and forth after every shot. There is no computer opponent.
The goal is the best possible version of this: beautiful graphics, satisfying sound, and smooth, fun gameplay.
The genre, briefly
This is a classic artillery game: side view, a landscape of hills and valleys, and shots that fly in an arc pulled down by gravity and pushed sideways by wind. Each turn the active player sets the barrel angle and the shot power, then fires. Explosions blow craters into the ground and smash parts of the castles. The fun comes from reading the terrain and the wind and adjusting your aim after every miss.
Requirements
Map
* Generate a new landscape for every game, with natural-looking hills and valleys. It must be fair: castles at roughly equal height and distance, and no terrain that makes hitting the other side impossible.
* Put one castle on each half of the map, each with a gun in its middle.
* Make the terrain destructible. Explosions carve craters, and the craters stay for the rest of the game.
Turns and controls
* Players alternate strictly: player 1, then player 2, then player 1 again. Who starts the first game is up to you, but it must be fair over a rematch.
* The active player adjusts the angle and the power, then fires. It must work with the keyboard and with the mouse or touch.
* The screen must always make clear whose turn it is, the current angle and power, and the wind.
* Wind changes between turns and affects the shots in a way players can see and understand.
Physics and combat
* Shots fly on believable arcs under gravity and wind.
* Hits damage the castles visibly, and a castle's state (for example its health or its remaining structure) must be easy to read.
* A player wins by destroying the other castle. Show a clear victory screen with an option to play again on a new map.
* You decide whether to add extra ammunition types, special shots or other mechanics, but only if they make the game more fun and not more confusing.
Graphics
* Aim for the best-looking game you can make: an atmospheric sky, a detailed landscape, castles with character, and juicy effects such as explosions, debris, smoke, screen shake and shot trails.
* Generate all graphics in code. No image files and no external assets.
Sound
* Generate all sound in code with the Web Audio API: cannon fire, the shot in flight, explosions, hits, the turn change and the victory, plus ambience or music if you like. No audio files.
* Include a mute toggle.
Technical
* Deliver a single HTML file that runs offline by opening it in a current desktop browser. No libraries, no CDNs, no external fonts, no network requests.
* It must not store any data: no localStorage, sessionStorage, cookies or IndexedDB.
* It must run smoothly (target 60 fps), adapt to the window size, and throw no console errors.
Competition rules
* Build from scratch, using only this brief. Do not search connected repositories, drives or the web.
* Work on your own until the game is finished. I won't give feedback or answer questions during the build, so wherever the brief leaves something open, decide for yourself.
* Write the game from scratch. Don't look for existing versions of this game or reuse their code.
* If you can run code or open a browser in this environment, test the game as much as you like before you hand it over. If you can't, check your code carefully instead.
* Deliver the finished game as one complete HTML file. If you can create files, save it as an HTML file whose name contains your model name, version and effort level (for example `artillery-<model>-<version>-<effort>.html`). If you can't, put the entire file in a single code block, without shortening or leaving out any part of it.
* After the file, write at most five sentences: what you're most proud of, and what you'd improve with more time.
How the games will be judged
1. How much fun it is to play: the feel of the controls, the physics, the fairness, and wanting one more round.
2. The graphics and visual polish.
3. The sound design.
4. Stability: no bugs, no errors, smooth performance.