Same prompt · Four AI models
I gave four AI models the exact same Mario-style platformer prompt. Pick a tab to play that model's build and see what it cost.
DeepSeek V4.1 Flashclick the game, then use keys
Fullscreen →DeepSeek V4.1 Flash
Total cost
$3.72
Input tokens
14.90M
Output tokens
74.3K
Requests
1,073
Identical for all four models. Served from public/game-prompt.md.
Build a complete, polished, playable 2D Super Mario Bros.-style side-scrolling browser game in the current workspace. This must be a working game, not a mockup, animation, or screenshot recreation. The highest priority is correct gameplay: satisfying movement, reliable collisions, collecting coins, working power-ups, and defeating enemies by stomping them from above. A beautiful game with broken physics is an unsuccessful implementation. 1. SCOPE AND TECHNOLOGY Use TypeScript, Vite, and HTML5 Canvas 2D. Use the existing starter if present; otherwise initialize the project. Do not use a game engine, prebuilt platformer, or copied game implementation. Development and testing libraries are allowed. Create one handcrafted, horizontally scrolling level intended to take roughly 60–120 seconds on a successful first playthrough. Do not build extra levels, multiplayer, accounts, or a backend. Draw the graphics yourself in code or create local assets. Do not depend on remote images, downloaded Nintendo assets, external services, or runtime network access. Include all necessary project files and npm scripts for development, production build, and tests. These are the rules of this benchmark's Mario-style game; an exact reproduction of the original game's physics or internal engine is not required. 2. VISUAL PRESENTATION AND CONTROLS Use a cohesive, expressive pixel-art style: a red-capped, overall-wearing protagonist, blue sky, clouds, layered hills, green pipes, brick blocks, question blocks, spinning coins, animated walking enemies, and a finish flag. Characters must be recognizable sprites, not unadorned rectangles. Include player idle, run, jump, damage, and death feedback, plus clear enemy defeat and item collection effects. Keep the game readable; effects must not obscure hazards. Controls: - A/D or Left/Right: move. - Space, W, or Up: jump. - Shift: run faster. - Enter: start or confirm a new game. - Escape: pause/resume. - R: restart the entire run, resetting its state. - M: mute/unmute. Show controls on the title screen and a compact HUD with coins, score, lives, and current power-up state. Display remaining star time when active. Add simple generated sound effects, enabled only after user interaction. Scale to the browser window while preserving aspect ratio. Resizing must not change world physics. Prevent gameplay keys from scrolling the page while the game has focus. Clear held inputs and pause on focus loss; returning to the tab must not teleport the player or fast-forward the simulation. 3. MOVEMENT AND WORLD PHYSICS Make movement responsive, with acceleration, deceleration, limited air control, gravity, and a terminal falling speed. Holding jump must produce a higher jump than tapping it. Holding the button must not repeatedly trigger new jumps on landing. Allow about 100 ms of coyote time and about 120 ms of jump buffering. Apart from that grace period, jumping requires a valid grounded state: no double jumps, infinite jumps, or wall climbing. Use a fixed simulation timestep with bounded catch-up, separate from rendering. Gameplay speed and jump height must remain consistent at 30, 60, and 144 rendered frames per second. Handle long frame gaps safely. Resolve collisions with floors, walls, ceilings, pipes, and blocks. The player must not sink into terrain, pass through thin platforms at high speed, snag on adjacent tile seams, or remain grounded after leaving an edge. Use swept collision or sufficient bounded substeps where needed. Keep physics values centralized and tune the level to the actual jump envelope. The main route must be completable in the small form without a power-up, damage boost, or blind leap. 4. ENEMY INTERACTIONS: CRITICAL ACCEPTANCE REQUIREMENT Include at least eight walking enemies. They must obey gravity and terrain collision and reverse direction at walls. They may walk off ledges, but must not float in the air. A stomp occurs only when the player approaches an enemy from above, descends relative to it, and crosses its top surface with horizontal overlap at impact. Use previous positions and first-contact/swept collision information, or an equally reliable method. Merely being airborne or falling beside an enemy does not count as a stomp. A valid stomp must: - Defeat the enemy immediately. - Bounce the player upward. - Award defeat points exactly once. - Make the defeated enemy immediately non-damaging. - Never also damage the player from that same enemy in the same simulation step. Side contact or contact from below damages the player unless temporary damage immunity or a star is active. Ordinary side contact must not defeat the enemy. Resolve ambiguous corner contacts consistently according to the first contact, not a broad overlap or center-height guess. Verify stomps while moving horizontally, near an enemy's edge, and at high falling speed, as well as straightforward centered stomps. 5. COINS, BLOCKS, AND POWER-UPS Place at least 25 collectible coins along the main route and optional reachable paths. Collection removes the coin and updates the HUD and score exactly once. Coins must not be collected from a distance or repeatedly while overlapping. Question blocks activate only when struck from below by the player's upward movement. Each releases its predefined coin or power-up once, then visibly becomes a used solid block. Side contact and standing on a block must not activate it. Items must emerge clear of their block before becoming collectible. Include both required power-ups in the playable level: Growth mushroom: - Emerges from a question block, moves, and obeys terrain collision. - Changes the player from small to large and visibly changes the form and collision height. - Keeps the player's feet anchored. Handle insufficient headroom safely; never expand a collider into solid terrain. - A large player taking ordinary enemy damage becomes small rather than dying. - Shrinking grants 1.5 seconds of visibly indicated damage immunity, preventing repeated damage from continuous overlap. - Additional mushrooms while large do not keep increasing size. Invincibility star: - Is visibly distinct and collectible. - Grants eight seconds of invincibility measured in active simulation time. - Defeats enemies on contact from any direction, awarding points only once per enemy. - Clearly communicates activation, remaining duration, and expiration. - Does not prevent death from falling into a pit. - Picking up another star refreshes the duration to eight seconds, rather than stacking indefinitely. Small players die from ordinary enemy damage when not immune. Use explicit state and timers so death, shrinking, stomping, and invincibility cannot conflict. 6. LEVEL AND GAME LOOP Build a fixed, thoughtfully arranged level with a safe opening area, coins that guide the player, platforms of different heights, pipes, question blocks, pits, progressively introduced enemies, and an unmistakable finish flag. All required mechanics must be reachable through normal play. Use a smooth horizontal camera that follows the player and clamps to world boundaries. Keep enough view ahead to make hazards readable. Falling below the level is a death, not an infinite fall. Start with three lives. On death, subtract exactly one life. If lives remain, restart the level with the player small, power-up timers cleared, level coins and score reset, and enemies, blocks, and pickups restored. Do not reset the remaining lives. At zero lives, show Game Over rather than silently starting again. Touching the finish flag triggers a clear victory state and freezes further gameplay damage and scoring. Starting a new game restores the initial three-life state. Pause freezes simulation and gameplay timers. Repeated restarts must not duplicate input handlers, audio loops, entities, or animation loops. 7. VERIFICATION: EXECUTE, DO NOT JUST DESCRIBE Use the available terminal and browser tools to implement, build, launch, inspect, playtest, and repair the game. Do not stop after generating files or seeing that the page renders. Keep simulation logic sufficiently separate from drawing to support deterministic tests that exercise the same code used during gameplay. Tests must check real state transitions, not hard-coded success messages or parallel toy implementations. At minimum, verify: - Movement, short versus held jumps, landing, and wall/ceiling collisions. - Center, edge, and high-speed stomps defeat the enemy without damaging the player. - Side and underside contact cause damage, not a false stomp. - Coins and question-block rewards trigger exactly once. - Growth, safe collider resizing, shrinking, and the damage-immunity interval. - Star activation, contact defeats, expiration, refresh, and pit death. - Exactly one life lost per death, correct reset, and Game Over at zero. - Level completion, pause/resume, focus loss, and repeated restarts. - Equivalent movement and jump results for the same timestamped input at 30, 60, and 144 Hz render schedules, within a documented small numerical tolerance. Run the production build and automated tests. Use actual browser keyboard input to check the title-to-game transition and movement. Inspect the browser console and exercise the full level through normal controls, including the finish flag. Save screenshots or a trace/video when your tools support it. Screenshots alone are not proof that mechanics work. Fix discovered failures and rerun the relevant tests. Do not weaken requirements or delete failing assertions to obtain a green result. If a tool is unavailable or a check cannot be performed, state precisely what remains unverified; do not claim a pass. 8. DELIVERY Deliver the runnable project, test files, and a short README with installation, launch, build, test, and control instructions. Your final response must briefly report what was implemented, which commands and checks actually ran, their results, and any remaining bugs or unverified behavior. Do not claim everything works without evidence. Work autonomously within the provided execution budget. Make reasonable decisions where details are unspecified. Prioritize correct physics and enemy interactions, then the complete game loop and required mechanics, then visual polish. Build the game now.