Same Prompt, Two Models: Gemini 3.1 Pro vs GLM-5.2 Both One-Shot a Tower Defense Game — With Opposite Architectures

We put Gemini 3.1 Pro and GLM-5.2 head-to-head in a gemini vs glm coding evaluation: build a top-down tower defense game in a single HTML file using vanilla JS and Canvas 2D only — both at max/high effort, with no follow-up corrections. Both came back with a fully playable game on the first try. Where they differ isn't code quality; it's a genuine architectural fork the prompt deliberately left open.

What I asked for: Tower defense game prompt

The prompt was written to force several comparable, hard systems rather than leaving room for either model to dodge the difficult parts: real pathfinding (not a hardcoded waypoint list), a resource economy loop, wave scaling, and — deliberately — an explicit either/or decision on whether towers block the path or sit beside it, with instructions to pick one and enforce it consistently.

You are an expert web game developer working in vanilla JavaScript and the HTML5 Canvas API.
Create a complete tower defense game in ONE SINGLE HTML FILE.
IMPORTANT:

Output ONLY one file: index.html
Put all HTML, CSS, and JavaScript inside this single file.
Do not create any other files.
Do not use external assets, images, or audio files.
Do not use React, TypeScript, or any frameworks.
Do not use any external library — everything, including rendering, must be plain Canvas 2D.
The final file must run by double-clicking index.html.
GAME: A top-down tower defense game. Enemies spawn at a fixed entry point and walk along a path
toward a fixed goal point. The player places towers along or near the path to kill enemies before
they reach the goal. The player loses when a set number of enemies reach the goal; the player
survives and progresses by clearing waves.
MAP & PATHFINDING:

A fixed grid-based map (at least 15x10 tiles) with one entry point and one goal point connected by
a path.
The path must be walkable tiles; towers can only be placed on non-path, buildable tiles.
Enemies must follow the path using actual pathfinding (e.g. a computed shortest path over the
grid), not a hardcoded waypoint list — if you implement tower-blocking rules below, the pathfinding
must be able to react to them.
Decide explicitly and implement consistently: can towers block the path, forcing enemies to
reroute, or do towers sit beside the path without blocking it? Either is acceptable, but pick one
and make sure placement rules enforce it (e.g. don't allow a tower placement that fully blocks the
only path to the goal, if towers are blocking).
TOWERS:

At least 4 distinct tower types with different stats and behavior: e.g. a cheap fast-firing tower,
a slow high-damage tower, a splash/area-damage tower, and a slowing/debuff tower.
Each tower has a cost to place, a range, a damage value, and a fire rate — show these in a
selection UI before placement.
Towers can be upgraded at least once (increased damage/range/fire rate) for an additional cost,
and the UI must show current tower stats when selected.
Visual range indicator when placing or selecting a tower.
ENEMIES:

At least 4 distinct enemy types with different HP, speed, and (for at least one type) special
behavior — e.g. a fast-but-fragile type, a slow-but-tanky type, a type resistant to one tower's
damage type, and a type that speeds up when damaged (or similar meaningful variation).
Enemies show a visible health bar and take visible damage/hit-flash feedback when hit.
Enemies that reach the goal deduct from the player's lives and are removed.
WAVES:

A wave system with a clear "start wave" control, at least 10 progressively harder waves, and
scaling enemy count/HP/speed as waves progress.
Enemies defeated award currency; currency is spent on towers and upgrades.
Some visible indicator of wave progress (current wave number, enemies remaining this wave, time
until next wave or a manual start trigger).
UI:

Currency count, lives remaining, current wave, tower selection/placement panel, and a way to
select and view/upgrade already-placed towers.
Game over screen when lives reach 0, showing waves survived, with a restart button that resets the
map and state.
A win state if all waves are cleared (or an endless mode indicator if waves are designed to
continue indefinitely — either is fine, just make the behavior clear to the player).
PERFORMANCE:

Keep the game performant with multiple towers, projectiles, and enemies on screen simultaneously —
avoid recalculating the full pathfinding grid every frame if enemies aren't rerouting; only
recompute when the buildable/blocked state of the grid actually changes.
CODE: Output the complete, working index.html file only. No explanations before or after the code,
no markdown formatting around it, no separate files — just the finished file.

The fork: blocking maze vs. fixed corridor

The prompt's one deliberately open question was whether towers block the path. Both models had to choose, and they chose opposite answers.

Gemini 3.1 Pro went with a dynamic blocking maze. It generates an open grid and computes a BFS flow field from the goal outward, recalculated only when the buildable grid actually changes — matching the prompt's performance note about not recomputing every frame. Placing a tower speculatively blocks that tile, reruns the flow field, and checks two things before committing: does the spawner still have a path, and does every currently-active enemy still have a path from wherever it's standing? If either check fails, the placement is rejected. That's more defensive than the prompt strictly required — it explicitly protects against stranding enemies already mid-level, not just sealing the route at build time.

GLM-5.2 went with a fixed, hand-authored corridor. Rather than an open grid, it defines the map as an ASCII layout (MAP_LAYOUT) with the path pre-drawn as a winding double-back corridor, entry and goal fixed at opposite ends. Towers can only be placed on tiles explicitly marked buildable, which are never path tiles — so the blocking question never comes up as a runtime problem. It still computes the path via real BFS (findPath) rather than hardcoding waypoints, satisfying that part of the prompt, but the map itself is static rather than procedurally reconfigurable by the player's tower placements.

Neither choice is wrong — the prompt explicitly allowed both — but they produce different games. Gemini's build lets you actively reshape the maze with each tower placed; GLM's build is closer to a traditional fixed-lane tower defense where placement is about optimal coverage, not routing.

Towers and combat

Both models hit all four required tower archetypes with matching intent — a cheap fast attacker, a slow high-damage tower, a splash/area tower, and a slow/debuff tower — and both show range indicators and live stats on selection, as required. GLM's laser tower is a small standout: instead of firing a projectile like every other tower in both builds, it has a projectileSpeed of zero and resolves as an instant beam, with its own visual treatment (a fading double-stroke line) separate from the projectile-trail rendering used everywhere else. That's a real code-level branch, not a reskin.

Enemy design

Gemini's four enemy types differ by stat curve — HP, speed, and a lookahead-based AI weave for the racing-game-style path following it reused from prior tests. GLM shipped five types and used the extra one to introduce a mechanic the prompt only lightly suggested: an armored enemy takes 60% reduced damage specifically from physical-tagged towers, which means the Frost and Laser towers (tagged magic) counter it meaningfully better than the Arrow and Cannon towers. It's a real damage-type system, not just a bigger health pool labeled "resistant."

GLM also gave its berserker type an enrage state: once it drops below 50% HP, its speed permanently doubles. Gemini's enemy variation is real but stays within stat differences; GLM's adds two enemies with distinct mid-fight behavior changes.

UI and extras

Both UIs meet every required element — currency, lives, wave counter, tower selection, upgrade panel, game-over screen with restart. GLM added three things the prompt didn't ask for: a sell mechanic (60% refund on placed towers), full keyboard shortcuts (1-4 to select tower type, Space to start the next wave, Esc or right-click to cancel a placement), and a next-wave preview line that tells you the exact enemy composition before you commit to starting it. None of these were required, and none of them are decorative — they're the kind of thing that shows up in a shipped game, not a prompt-completion exercise.

Gemini vs GLM coding benchmark results: What impressed me

GLM's canPlaceTower doesn't need any blocking-validation logic at all, because its fixed-corridor design makes the failure case structurally impossible rather than something to check for at runtime — a different, and arguably simpler, way of satisfying the same requirement Gemini solved with active revalidation. Seeing two models take the same underspecified requirement and produce two internally consistent, opposite solutions — neither hacked around the constraint — is a cleaner signal about each model's design instincts than either build would give in isolation.

What needs work

• GLM's fixed map removes player agency over routing — if you wanted a maze-builder tower defense specifically, GLM's corridor design doesn't deliver that, even though it satisfies the letter of the prompt.
• Gemini's enemy variety is shallower — four types differing mainly by numbers, versus GLM's damage-type interplay and mid-fight behavior changes on two of its five types.
• Neither build was tested past a first playthrough — we can confirm both ran cleanly and matched the spec on inspection, but neither has been played to wave 10 to confirm late-game balance or performance under a full board of towers and a large enemy count.

Honest assessment

Try it yourself

You are an expert web game developer working in vanilla JavaScript and the HTML5 Canvas API.
Create a complete tower defense game in ONE SINGLE HTML FILE.
IMPORTANT:

Output ONLY one file: index.html. All HTML, CSS, and JavaScript inside this single file.
No external assets, images, audio files, frameworks, or libraries — plain Canvas 2D only.
Must run by double-clicking index.html.
Enemies spawn at a fixed entry point and walk toward a fixed goal along a real computed path
(actual pathfinding, not hardcoded waypoints). Decide explicitly whether towers block the path,
forcing enemies to reroute, or sit beside it without blocking — pick one and enforce it
consistently, including validating that a placement never fully seals the only route to the goal.
At least 4 tower types (cheap/fast, slow/heavy, splash, slow-debuff) with cost, range, damage,
fire rate, an upgrade path, and a range indicator on placement/selection. At least 4 enemy types
with distinct HP/speed and at least one meaningful special behavior. At least 10 scaling waves,
a currency economy, health bars with hit feedback, and a game-over/restart flow.
Output the complete, working index.html file only — no explanations, no markdown, no separate files.

FAQ