← All implementations

IMPLEMENTATION REVIEW

9 Oct 2026 · 13 current branch snapshots

How the scores work

These are editorial judgments about the implementations at the linked commits, including later fixes. They are not measurements of model capability or ratings of the original one-shot commits.

Each category is scored from 0 to 10. Overall is their arithmetic mean, rounded to one decimal. Cards sort by that displayed overall score, then prompt completeness, then game design. Scores around 9 indicate strong implementation with minor gaps; 7–8 indicates a solid result with material weaknesses; 4–6 indicates a partial game; 0–3 indicates fundamental blockers or unfinished systems.

Game design
Playability, fairness, feedback, pacing, visual readability, and how the mall and store mechanics work together.
Code architecture
Separation of rules and presentation, state ownership, determinism, module boundaries, and integration between systems.
Code design
Algorithms, data models, APIs, collision and input handling, correctness, and how easily the implementation can be extended.
Code cleanliness
Readability, naming, formatting, duplication, useful comments, type discipline, and removal of unfinished or disconnected code.
Prompt completeness
Working coverage of the original prompt: traversal, packages, stores, enemies, extras, power-ups, screens, audio, art, input, and technical constraints.

Review scope

The review compared source, assets, tests, build configuration, and gameplay rules with the original prompt. Every implementation's test suite and production build was run. Haiku 4.5 also received a separate TypeScript check because its build does not typecheck.

Browser checks sampled launch, title, arrival, and mall presentation. Stronger implementations also received store-entry checks using prepared player positions; Fable, GPT-6.1, Haiku 5.5 and the two Sonnet 5.5 advisor entries received package-search checks, and GPT-6 Astra a fixture-search check. Haiku 5.5 was also played in real time through elevator boarding, the map and pause, then stepped through an elevator ride to the parking level, level clear, continue and game over. The Sonnet 5.5 + Fable 5.1 entry was played in real time on its published sub-path build through the arrival, walking, an elevator ride, the CRT and mute toggles, the map and pause, then its own scripted player, kept invulnerable, was driven through the complete six-package route to level clear, loop 2, continue, game over, the Konami code and the GameStonk easter egg; that run proves routing and screen flow rather than survivability. The Sonnet 5.5 + Opus 5.5 entry was played the same way on its published build, and its own scripted bot, left vulnerable, completed the six-package route to level clear and loop 2 on seed 5 without a death, matching the Node trajectory frame for frame; continue, game over, the Konami code, the GameStonk cave, an escalator ride and a lamp shot were stepped afterwards. Those are the only two verified full-route completions. GPT-6 Astra was stepped through its debug hook on the published build from splash to loop 2, including a store search, the kiosk, the photo booth, the fountain, the wet floor, the mall cop, death, continue, game over, the Konami code, the GameStonk cave and the sprite gallery, but was not played in real time. Targeted probes reproduced the Haiku 4.5 timing blocker, the Gemini store-exit blocker, and the Haiku 5.5 map-in-store, floor-blind wet-floor, power-up timer and Game Over shutter defects; the Sonnet 5.5 + Fable 5.1 entry's silent cleared-store door and Black Friday title overlap were reproduced in the browser; the Sonnet 5.5 + Opus 5.5 entry's roof respawn after a death inside an elevator car was seen in real-time play and reproduced in Node. GPT-6 Sol's dead-spy and Black Friday defects were reproduced in Node; GPT-6 Astra's banner over the store header, package pose after an empty search and clipped Black Friday title sign were seen in stepped screenshots.

This was not an uninterrupted six-package walkthrough of all thirteen games; the two full routes that were replayed are named above. Unverified full-route completion is not claimed for the others. Test counts are reported as context; they do not determine scores. Other findings come from source inspection and are described as inferences where relevant. Scores describe these source snapshots; published Play builds may change independently. The "written" date on each card is the day the model produced the implementation, taken from the branch README's benchmark notes or, where a README has none, from the branch's first commit.

01Claude Sonnet 5.5 + Fable 5.1 advisor

The most legible mall and the first full route replayed in the live build. Plug-in mall modules; two 1,200-line worlds remain.

Game design
9.2 / 10
Code architecture
9.3 / 10
Code design
9.0 / 10
Code cleanliness
9.0 / 10
Prompt completeness
9.6 / 10
Overall score
9.2 / 10

Written · snapshot 94755064ac81 · branch sonnet-5-5-fable-5-1

Game design
Clean, readable storefronts with a wide corridor palette, a legible HUD with an LED floor panel and scrolling store marquee, and well-staged screens: a SPYGRAM card, a receipt-style tally, THE DAILY MALL, a vector-grid continue countdown and typewriter shutters at game over. Elevators glide, floor banners announce, the directory map is clear and shows the current store from inside a room. Fairness was tuned with scripted players over 40 seeds, not with a human. A cleared or closed store door gives no feedback on Up, and the Black Friday flash overlaps the copyright line on the title. Survivability by a human was not tested here.
Code architecture
A scene machine (Game) owns a Level that holds the mall, the current store, the overlays and the fades, so the map and pause work identically in both views. Rules are pure and frame-based, emit sound requests through the Run and expose music through state; a grep test keeps the rule layers free of the DOM, Math.random and timers. Mall extras (lamps, janitor, walkers, cop, kiosks, booth, fountains) are plug-in modules with typed state the renderer reads, which keeps the core world smaller than its siblings. The mall and store worlds are still about 1,200 lines each.
Code design
The elevator model (drive, glide, call protection, occupancy, grate and pit states), shaft-wall door windows, tile collision with corner assist, a tap queue that preserves fast taps across catch-up steps, and a store room system that already supports any size with a camera are all well modelled and tested. A scripted player that only presses buttons doubles as a routing proof and a fairness probe. Spy AI is deliberately simple, the cop ignores escalators, and a few interactions fall through silently.
Code cleanliness
Strict TypeScript with no escape hatches, no stray TODOs or console calls, every line of copy in one module with fit tests, named constants for all timings, and comments that explain gameplay decisions. The README and AGENTS.md are precise about what was and was not verified. There is no lint or format configuration and unused locals are not flagged, and the two world modules are long.
Prompt completeness
Every screen, mall fixture, store extra, power-up, song slot and debug option from the brief is present, and 754 tests cover rules, art contracts, music theory and seeded playthroughs. This review drove the branch's own scripted player, kept invulnerable, through the whole route in the published sub-path build, which proves routing and screen flow rather than survivability: splash, title, arrival, walking, an elevator ride and escalator, a lamp shot, all six package stores, the refused re-entry of a cleared store, the exit firing once, the tally, newspaper and post, a harder loop 2, continue, game over, the Konami code and the GameStonk easter egg, with an empty console. Music was checked numerically by the author and not listened to here.

Verification

  • 754 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Real-time splash, title, arrival, walking, elevator ride, floor banner, CRT and mute toggles, map and pause passed on the published build; stepped checks with the scripted player kept invulnerable completed the full six-package route to level clear, loop 2, continue, game over, Konami, easter egg, map inside a store, escalator and lamp shot with no console messages.

Source evidence: Level owns overlays, fades and store transitions · Plug-in mall modules · Silent cleared-store door · Scripted full playthrough

Back to implementations

02Claude Sonnet 5.5 + Opus 5.5 advisor

A legible mall whose own bot finished the live route without dying. Untyped events, unused-import hacks, and car deaths respawn far away.

Game design
9.1 / 10
Code architecture
9.1 / 10
Code design
8.9 / 10
Code cleanliness
8.6 / 10
Prompt completeness
9.6 / 10
Overall score
9.1 / 10

Written · snapshot aca8cc817c2e · branch sonnet-5-5-opus-5-5

Game design
Clean pastel storefronts whose windows read at a glance, a wide corridor palette, a 16 px HUD with an LED floor panel and a store marquee, a floor banner on every stop, and well-staged screens: the SPYGRAM card, a MISSION COMPLETE drive-off with the receipt-waving spy, a receipt-style tally, THE DAILY MALL and a typewriter message that stays readable over the game-over shutters. Searching is forgiving, with a progress bar under the store name. Fairness was tuned with a non-dodging bot over 24 seeds, and the same bot finished loop 1 on seed 5 in the live build without a death. The safe spot is never updated while riding, so a death inside an elevator car respawns the agent where it boarded; in real-time play a death at 2F sent the agent back to the roof. Checkerboard store floors are busier than the mall.
Code architecture
A Game state machine owns a RunState shared by the mall and the stores, a Mall and a StoreRoom; the map and pause remember which view is underneath, power-up timers tick in both views and stop on the overlays. The rules layer has no DOM, timers or Math.random, by inspection rather than a guard test, and emits plain events through one queue; the renderer keeps its own door, popup and toast state clocked by simulation frames, so visuals do not depend on the display refresh rate. Spies and NPCs are split out of the 1,300-line mall module and the store room system takes any size with a camera. Event payloads are untyped and consumers cast them.
Code design
The elevator model (glide, one ding per stop, call protection, grate, pit and roof states), the input mapper with printed-letter bindings, exact release and a tap queue, tile collision with corner assist, once-per-volley spy dodges, lamps placed by computing the corridor gaps from the geometry, and a goal-based BFS bot that doubles as a softlock detector are all well modelled and tested. The safe-spot rule ignores elevator rides, spy AI is simple, the cop ignores escalators, and one hazard check carries an empty branch.
Code cleanliness
Strict TypeScript, every line of copy in one module with fit tests, named frame constants, comments that explain decisions, and a README and AGENTS.md that record the advisor consultations and the gotchas. Unused locals are not flagged, so a dozen void statements silence unused imports; event data is typed as any, there is a placeholder draw call and an empty if block, and there is no lint or format configuration.
Prompt completeness
Every screen, mall fixture, store extra, power-up, song slot and debug option from the brief is present, and 240 tests cover rules, input layouts, art contracts, songs, copy fit, refresh-rate timing, a 24-seed fairness run and a scripted full level on 8 seeds. This review played the published sub-path build in real time through splash, title, arrival, walking, an elevator ride, the map, pause and the CRT and mute toggles, then drove the branch's own scripted bot, left vulnerable, through the full six-package route on seed 5 to level clear, THE DAILY MALL, the post and loop 2 with no deaths, matching the Node trajectory frame for frame; continue, game over, the Konami code, the GameStonk cave, the map inside a store, an escalator ride and a lamp shot were stepped, with an empty console. Music was not listened to.

Verification

  • 240 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Real-time splash, title, arrival, walking, elevator ride, floor banner, map, pause, CRT and mute toggles passed on the published build; the branch's scripted bot, left vulnerable, completed the full six-package route to level clear and loop 2 with no deaths; continue, game over, Konami, GameStonk cave, map inside a store, escalator and lamp shot stepped with no console messages; the roof respawn after a death inside a car was seen live and reproduced in Node.

Source evidence: Screen machine and shared run state · Safe spot not updated while riding · Printed-letter bindings and tap queue · Refresh-rate independent visuals · Scripted full level on 8 seeds

Back to implementations

03Claude Sonnet 5.5

A convincing mall: rich art, fair encounters, and broad coverage. Strong rule boundaries; the store module is oversized.

Game design
9.0 / 10
Code architecture
9.2 / 10
Code design
8.8 / 10
Code cleanliness
8.8 / 10
Prompt completeness
9.5 / 10
Overall score
9.1 / 10

Written · snapshot c15cebfb129a · branch sonnet-5-5

Game design
Detailed storefronts, lively characters, themed rooms, and clear search feedback make the caper feel coherent. Entry protection and guard delays improve fairness. Busy patterns and a dense HUD sometimes compete with the action.
Code architecture
A frame-driven Session owns the game flow; seeded rules and typed events are separated from browser, audio, and drawing. The boundaries are consistently exercised in Node. Some presentation state lives in the overlay rather than the simulation.
Code design
Input preserves printed-letter layouts and repeated taps; store movement, collision, searching, and guard behavior share explicit models. The roughly 1,200-line store module concentrates too many responsibilities despite otherwise focused modules.
Code cleanliness
Strict TypeScript, clear contracts, useful comments, and descriptive behavior tests make the implementation easy to follow. A few large modules and dense rendering code reduce local readability.
Prompt completeness
Very broad coverage of traversal, store extras, power-ups, generated art and music, and session screens. Its 477 tests include long seeded simulation runs. Sampled title, arrival, and store entry worked; this review did not establish a complete uninterrupted playthrough.

Verification

  • 477 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Title, arrival, mall and prepared store entry passed.

Source evidence: Session and state ownership · Store rules and collisions

Back to implementations

04Claude Fable 5.1

Colorful, generous, and feature-rich, with dependable seeded rules. Large mall and store modules and busy floors limit polish.

Game design
8.7 / 10
Code architecture
8.7 / 10
Code design
8.4 / 10
Code cleanliness
8.5 / 10
Prompt completeness
9.4 / 10
Overall score
8.7 / 10

Written · snapshot de6cd0d974dc · branch fable-5-1

Game design
Distinct stores, strong feedback, generous entry protection, and considerate search controls support the exploration loop. The busy floor patterns and compact HUD reduce readability in otherwise attractive scenes.
Code architecture
Pure frame-based game modules emit typed events to a separate renderer and audio layer. State and seeded setup are explicit. Type-only references to art and audio identities introduce mild coupling, and the mall module remains large.
Code design
Connected room layouts, accessible fixtures, corner assistance, and explicit interaction rules are thoughtfully implemented. The roughly 1,350-line mall and 650-line store modules would benefit from smaller responsibility boundaries.
Code cleanliness
Consistent strict TypeScript and readable names make the rules approachable. Comments explain deliberate gameplay choices. Long rule files and occasional tightly packed branches add maintenance cost.
Prompt completeness
The broad prompt coverage includes store-specific jokes, traversal, loot, powers, generated graphics, and sound. All 321 tests and the typechecked build passed. Browser sampling confirmed a real store transition and package search after preparing the player's position.

Verification

  • 321 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Title, arrival, mall, prepared store entry and package collection passed.

Source evidence: Game flow and events · Mall behavior · Store behavior

Back to implementations

05Claude Opus 5

A thorough, playable caper with strong palette rules and safety fixes. Huge rule files and injected callbacks complicate maintenance.

Game design
8.6 / 10
Code architecture
8.3 / 10
Code design
8.1 / 10
Code cleanliness
8.4 / 10
Prompt completeness
9.3 / 10
Overall score
8.5 / 10

Written · snapshot 6bb30716daec · branch opus-5

Game design
The mall and themed stores feel substantial, with useful feedback and safeguards against unavoidable spawn and ambush deaths. The detailed art is undermined slightly by busy backgrounds and a cramped HUD.
Code architecture
A pure core communicates through a typed EventBus; rendering and audio read state. Seeded frame timing and structural palette limits are strong choices. Globally injected transition callbacks and very large mall/store modules weaken isolation.
Code design
Collision, floor geometry, fixture reachability, elevator latches, and emergence grace receive careful treatment and regression coverage. The callback wiring and roughly 1,800-line mall module make extensions harder than the underlying models require.
Code cleanliness
Strict typing, centralized constants and copy, and comments explaining design decisions keep the implementation consistent. Long functions and files make it harder to trace a single interaction through the rules.
Prompt completeness
Extensive coverage of the game loop, store extras, powers, generated assets, and CRT requirements. All 217 tests and the typechecked build passed. Sampled title, mall, and prepared store entry worked; full-route completion was not independently replayed here.

Verification

  • 217 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Title, arrival, mall and prepared store entry passed.

Source evidence: Core event boundary · Mall rules · Store rules

Back to implementations

06Claude Opus 5.5

Rich arcade detail and focused rule modules. Pixi scenes own some scoring and timing, and busy rooms weaken visual clarity.

Game design
8.0 / 10
Code architecture
7.8 / 10
Code design
8.0 / 10
Code cleanliness
8.0 / 10
Prompt completeness
8.8 / 10
Overall score
8.1 / 10

Written · snapshot 8b77751ed9ff · branch opus-5-5

Game design
Recognizable characters, themed storefronts, and broad arcade interactions create an engaging world. Striped rooms and large speech text can obscure the action; the presentation is less legible than its feature coverage suggests.
Code architecture
Physics, elevators, combat, and store worlds have useful rule modules. However, Pixi scenes also own scoring, transition timing, and presentation state; mutable global store hooks introduce initialization dependencies. The pure boundary is incomplete.
Code design
Focused world updates, seeded content, and queued layout-aware input are good foundations. Scene-owned state and fixed store placement make independent simulation and larger-room extensions less straightforward.
Code cleanliness
Most modules are short, sensibly named, and supported by behavior tests. Task-number comments and scene/world overlap add noise, and untyped shared hooks provide weaker contracts than the strongest TypeScript entries.
Prompt completeness
A broad implementation with many mechanics, generated sprites and sounds, and a working sampled store transition. All 319 tests and the production build passed; a sizable portion of the suite validates assets. Scene coupling and room-camera limitations leave technical prompt gaps.

Verification

  • 319 tests passed.
  • Build: Pass.
  • Runtime: Title, arrival, mall and prepared store entry passed.

Source evidence: Store simulation · Session state · Scene-owned scoring

Back to implementations

07GPT-6.1 Sol

A compact, broadly working game with useful route tests. One large rules file, simpler art, and uneven encounter protection hold it back.

Game design
7.5 / 10
Code architecture
7.5 / 10
Code design
7.2 / 10
Code cleanliness
7.7 / 10
Prompt completeness
8.5 / 10
Overall score
7.7 / 10

Written · snapshot c02a646e080f · branch gpt-6-1-sol

Game design
Readable characters, clear package feedback, and functional movement support a convincing core loop. Store decoration is comparatively sparse, first-visit interruptions freeze the player, and ambush protection is less considerate than in the strongest entries.
Code architecture
The rules are pure and seeded, with separate drawing, input, and audio. A roughly 1,650-line game file owns most systems, and string events plus shared actor collections blur subsystem boundaries.
Code design
BFS navigation, fixture geometry, corner assistance, and explicit search controls are solid. A very broad Game state, short variable names, shared mall/store actors, and UI-string power identities make the model harder to extend.
Code cleanliness
Strict typing, a small dependency footprint, and useful verification documentation are strengths. Large files and compressed branches reduce readability, though the code is substantially clearer than the earlier Sol implementation.
Prompt completeness
Most gameplay systems, extras, powers, and generated audio are represented. All 75 tests and the typechecked build passed. Browser sampling confirmed prepared store entry and package collection. Art detail and some encounter behavior fall short of the most complete implementations.

Verification

  • 75 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Title, arrival, mall, prepared store entry and package collection passed.

Source evidence: Rules and state model · Presentation · Implementation's browser harness

Back to implementations

08GPT-6 Astra

A complete, legible mall with no dependencies, built in forty minutes. Store rooms are flat identical grids; songs are eight-note loops.

Game design
7.4 / 10
Code architecture
7.8 / 10
Code design
7.2 / 10
Code cleanliness
7.0 / 10
Prompt completeness
8.0 / 10
Overall score
7.5 / 10

Written · snapshot 483c7038c153 · branch gpt-6-astra

Game design
The mall reads well at NES scale: every storefront shows its goods in the windows, blinking red doors mark the targets, closed shops carry FOR LEASE and CLOSING SALE shutters, floors are labelled, and the elevator cars have doors that close while moving. The title screen, the SPYGRAM cards, the kiosk panel, the photo strip, MISSION COMPLETE with the receipt-waving spy, THE DAILY MALL and the shutters rolling down over the mall at game over are all staged with care. The stores let it down: all ten rooms are the same 16 by 11 checkerboard with eight identical fixture boxes topped by one sprite per theme, no counters or walls, and two guards at fixed positions, so the Zelda half of the game is a flat grid. Music is one monophonic eight-note loop per track over a bass and a triangle, so the ten store songs are barely distinguishable. The banner box covers the store name header, the agent holds a package overhead after an empty or trapped search, and the Black Friday sign on the title is clipped by the storefront row.
Code architecture
A 1,782-line rules module owns the whole simulation as a plain state object stepped at 60 Hz with the state's own xorshift PRNG and no DOM, timers or Math.random; it emits events that the audio layer consumes, and the renderer only reads state. The fixed loop caps catch-up at five steps, the input layer merges keyboard and gamepad into held and pressed sets with a tap queue that survives catch-up, and the browser adapter is 175 lines. The room system clamps a camera to the room size, so bigger rooms would work, but nothing else is modular: mall, store, elevators, NPCs, lamps, scoring and screens all share one file, and the renderer imports the rules module to ask which fixture is touched.
Code design
The elevator model (floor-to-floor glide, one ding per stop, called cars that pick up instead of crush, the automatic car waiting for an occupant), the printed-letter input mapping with release by physical key, the forgiving touch-based search and the once-per-volley spy dodge are modelled cleanly and each has a test. Against that, the code is terse to a fault: state, player, elevator and fixture are s, p, e and f throughout, positions such as the wagon at 626, the booth at 410 and the kiosks at 384 are bare literals, and fixture contents are chosen by a ternary nested five deep. The search pose is reused for every outcome, which is why the agent lifts a package he did not find.
Code cleanliness
Prettier-style formatting is consistent, every line of copy sits in one module with a fit test, and the README and AGENTS.md are short and honest, including the note that the run began inside an existing conversation rather than a fresh session. There is no type checking, no lint configuration and almost no commenting, and the single-letter naming makes the rules file hard to scan. Tests are 56 broad cases in two files, several asserting a dozen things each.
Prompt completeness
Every screen, mall fixture, store extra, power-up, song slot and debug option in the brief is present, and 56 tests cover the fixed step, input layouts, the art pipeline, room reachability, elevators, scoring, power-up timers, NPCs, the Konami code, spy fairness, searching, the extras, the exit rule, continues, splash timing and copy limits. This review stepped the published sub-path build through its debug hook with the CRT on: splash, title, arrival and selfie, an elevator ride with its floor banner, a store visit with the first-visit lines, a search, the map and pause, a spy kill with last words, a falling lamp, an escalator, the kiosk, the photo booth, the fountain, the wet floor, the mall cop's detention, death and respawn, continue, game over, the Konami code and Black Friday signs, the GameStonk cave, the parking level, level clear, the newspaper, the post, loop 2, the CRT and mute toggles and the sprite gallery, with an empty console. Real-time keyboard play and the music were not checked by this review; the branch README reports its own real-time run. Store themes differ only by palette, Circuit Pity shows FOR LEASE instead of a half-open shutter, and guards are always two.

Verification

  • 56 tests passed.
  • Build: Pass; no dependencies, static copy to dist/.
  • Runtime: The published build was stepped through the debug hook with the CRT on: splash, title, arrival, selfie, elevator ride, store entry, search, map, pause, spy kill, lamp, escalator, kiosk, photo booth, fountain, wet floor, cop, death, continue, game over, Konami and Black Friday, GameStonk cave, level clear, newspaper, post, loop 2, CRT and mute toggles and the gallery, with no console messages; the banner over the store header, the package pose on an empty search and the clipped Black Friday sign were seen in screenshots. Real-time keyboard play was not exercised by this review.

Source evidence: Single rules module with state PRNG · Search pose reused for every outcome · Package drawn whenever pose is set · Black Friday box under the storefront row · Tap queue and printed-letter mapping · 56 rules tests

Back to implementations

09Claude Haiku 5.5

A complete, playable caper with clean rule boundaries. Power-ups never expire, the map breaks stores, and Game Over hides behind shutters.

Game design
6.2 / 10
Code architecture
7.4 / 10
Code design
6.5 / 10
Code cleanliness
7.4 / 10
Prompt completeness
7.5 / 10
Overall score
7.0 / 10

Written · snapshot 1ec98345999f · branch haiku-5-5

Game design
The whole loop plays: zip-line arrival, elevators and escalators, timed searches with a progress bar, banners and popups, first-visit lines, level clear and harder loops, with telegraphed shots, store grace and respawn invulnerability for fairness. Opening the map inside a store leaves the room frozen on screen while the mall rules keep moving the agent, the wet-floor slide applies on every floor and can block the getaway wagon, timed power-ups never run out, and the Game Over screen ends fully covered by its shutters. Dark backdrops, abstract window displays and overflowing two-line signs make the mall less readable than the strongest entries.
Code architecture
Pure, seeded rules in core, mall and store modules emit typed events that a state-reading renderer and an audio layer consume; the input mapper and the splash are standalone and the browser shell is thin. The roughly 1,450-line mall module concentrates most behaviour, the game never ticks the power-up timers it owns, the map screen ignores which screen opened it, and banners persist across scene changes. Debug mode pauses real time, so the hooks cannot observe live play.
Code design
The elevator state machine, printed-letter input with exact key release and a tap queue, tile collision with corner assist, and once-per-volley dodge rolls are well modelled. The wet-floor check ignores floors, closing the map inside a store returns to the mall with the room still attached, timed power-ups last until death, the shutter animation covers the Game Over text, and the room system is fixed at 16 by 11 tiles without a camera.
Code cleanliness
Strict TypeScript with no escape hatches, short focused modules outside the mall world, readable names, and comments that explain gameplay decisions. Copy is duplicated inside rule modules despite the stated single-source rule, several sound effects, the shake output and some copy constants are defined but never used, and the README contradicts itself about the browser playtest.
Prompt completeness
Nearly every screen, mall fixture, store extra, power-up, song slot and debug option from the brief is present, with 115 tests across the listed rule areas; the strict build and the published sub-path deployment work, and browser checks logged no console errors. Real-time play covered splash, title, arrival, walking, elevator boarding, the map, pause and the CRT and mute toggles; stepped checks covered store entry, a package search, an elevator ride to the parking level, level clear, continue and game over. The unticked power-up timers, the map inside stores, the floor-blind wet patch and the hidden Game Over text are working-coverage gaps; the room camera, photo strip and automatic-car ride are simplified.

Verification

  • 115 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Real-time splash, title, arrival, walking, elevator boarding, map, pause and toggles passed; prepared store entry, package search, an elevator ride to the parking level, level clear, continue and game over stepped; map-in-store, wet-floor and shutter defects reproduced.

Source evidence: Map screen returns to the mall · Wet-floor check without a floor · Power-up tick never called · Game Over shutters

Back to implementations

10Claude Opus 4.6

A substantial core, but several features stop at emitted events. Simplified collisions, mismatched audio hooks, and dark art hurt play.

Game design
6.0 / 10
Code architecture
6.5 / 10
Code design
5.3 / 10
Code cleanliness
6.3 / 10
Prompt completeness
6.2 / 10
Overall score
6.1 / 10

Written · snapshot dc90ad97ff84 · branch opus-4-6

Game design
The sampled title, mall, and store transition work, and many arcade systems are present. Dark sprites, simplified room interactions, missing visible dialogue, and inconsistent hazard handling make the experience less convincing.
Code architecture
Seeded rules, event output, and separate rendering/audio form a sound outline. The roughly 2,500-line simulation and 1,850-line renderer duplicate geometry and behavior, while event names disagree with their consumers.
Code design
Store movement largely clamps to bounds instead of colliding with the rendered layout. Re-entry preserves dead guards, repeated taps collapse into booleans, and physical-key lookup takes precedence over printed letters. Several store extras emit events without implementing their intended interactions.
Code cleanliness
Conventional TypeScript formatting and descriptive names help navigation. Duplicated store initialization, large files, loose string events, and explanatory comments attached to incomplete behavior increase maintenance risk.
Prompt completeness
Many systems exist and all 219 tests plus the typechecked build passed. However, music and speech events are disconnected, store collision and extras are simplified, and level-clear scoring awards package points again. Passing tests overstate integration coverage.

Verification

  • 219 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Title, arrival, mall and prepared store entry passed; presentation sampled.

Source evidence: Rules and emitted events · Event consumers · Keyboard mapping

Back to implementations

11GPT-6 Sol

A recognizable, lightweight prototype. Compressed rules hide revived dead spies, loot gaps, weak collisions, and a very small sprite set.

Game design
5.2 / 10
Code architecture
5.8 / 10
Code design
4.2 / 10
Code cleanliness
2.5 / 10
Prompt completeness
5.8 / 10
Overall score
4.7 / 10

Written · snapshot ef387d79eb3a · branch gpt-6-sol

Game design
The title, mall, and basic package loop are recognizable. Static sprites, simple rooms, and weak enemy behavior reduce the sense of a finished arcade game. Searching freezes store hazards, which distorts the intended risk and pacing.
Code architecture
Browser I/O, rendering, and seeded rules are separated, and updates clone state. Nearly all session, mall, and store rules are packed into one compressed module, with few explicit subsystem contracts.
Code design
A reproduced rule defect lets dead spies become active after their death timer expires. Black Friday shop generation leaves empty fixtures, guard movement ignores fixture collision, and the listening-booth geometry appears to prevent its activation. Cloning all state each tick adds unnecessary work.
Code cleanliness
Very long, densely compressed lines, single-letter locals, and combined responsibilities make inspection and safe changes difficult. The input module is more considered, but the overall source reads like a compressed prototype.
Prompt completeness
The basic screens and many named mechanics exist; all 25 tests and the build passed. Only six static gameplay sprites are defined, the CRT lacks real curvature, and several traversal, store, and power-up rules are partial or incorrect. The tests miss important gameplay defects.

Verification

  • 25 tests passed.
  • Build: Pass.
  • Runtime: Title, arrival and mall sampled; dead-spy and Black Friday defects reproduced in Node.

Source evidence: Compressed rules and defects · Sprite catalogue · Presentation and CRT

Back to implementations

12Gemini 3.6 Flash

Readable scaffolding, but the game loop is unfinished: stores cannot be exited, elevators do not carry the agent, and combat is incomplete.

Game design
2.0 / 10
Code architecture
4.0 / 10
Code design
3.0 / 10
Code cleanliness
5.0 / 10
Prompt completeness
2.0 / 10
Overall score
3.2 / 10

Written · snapshot 3c26ac0a2574 · branch gemini-3-6-flash

Game design
The mall renders and movement can be sampled, but essential progression is blocked. Store exits are unreachable, elevator movement does not carry the player, and minimal room art offers little feedback or atmosphere.
Code architecture
Logic, renderer, input, and synthesis are in separate modules. The boundary is weakened by non-seeded floating-text IDs, inconsistent private fixture data versus drawing, and incomplete integration of combat and traversal.
Code design
Store movement clamps the player's y position to 144 while exit requires more than 154; a browser probe reproduced the trap. Enemy bullets are created without a complete movement/collision path, and searches and fixtures lack the required collision and cancellation behavior.
Code cleanliness
Conventional formatting and recognizable module names make the scaffolding readable. Loose contracts, hardcoded room drawing, and unused or disconnected behavior obscure what actually works.
Prompt completeness
All 14 tests and the typechecked build passed, but essential traversal and combat, guards, many NPCs/extras, and distinct store experiences are missing or partial. The unreachable store exit prevents completing the requested package loop.

Verification

  • 14 tests passed.
  • Build: Pass; strict typecheck included.
  • Runtime: Title and mall sampled; prepared store exit stayed blocked at y=144.

Source evidence: Traversal, combat and store exit · Hardcoded room presentation

Back to implementations

13Claude Haiku 4.5

The browser never leaves frame zero. Readable pieces exist, but broken timing, disconnected elevators, and instant searches prevent play.

Game design
1.0 / 10
Code architecture
2.5 / 10
Code design
2.0 / 10
Code cleanliness
4.0 / 10
Prompt completeness
1.5 / 10
Overall score
2.2 / 10

Written · snapshot d2b8c71ca66f · branch haiku-4-5

Game design
Normal launch stays on the first splash frame, including after Enter, so there is no usable player experience. Direct rule calls expose basic movement, but the store and traversal systems do not support the intended loop.
Code architecture
Modules suggest useful separation, but rules directly invoke audio, use unseeded randomness, and attach ad hoc store state. Elevator and power-up modules are not reliably integrated, and duplicate state fields disagree.
Code design
The main loop resets its timestamp whenever frame is zero, producing zero elapsed time forever. Elevator updates are not called by mall rules, store movement advances a tile per frame, and searches reveal contents immediately instead of running the specified timed interaction.
Code cleanliness
Formatting and straightforward names are readable. Placeholder comments, disconnected code, casts to any, and extensive TypeScript errors show that the pieces were not brought to a consistent finished state.
Prompt completeness
The 13 unit tests and Vite build passed, but a separate TypeScript check failed. The browser is stuck at frame zero; guards, collision, progression, and multiple extras are absent or incomplete. The existing tests exercise isolated rules and miss the broken entry point.

Verification

  • 13 tests passed.
  • Build: Vite build passes; separate TypeScript check fails.
  • Runtime: Splash remained at frame zero before and after Enter.

Source evidence: Broken browser timing loop · Rule integration · Store interactions

Back to implementations