Tank game benchmark / 2026-11-10
Six models · high reasoning · Custom skills supplied: 0
Main prompt
Create a top aerial view realistic single player tank game on a field with trees and other elements, the gameplay would be moving the tank around with arrow keys and space to shoot, mobile should have its own controls, the game should have realistic physics and shooting at objects would cause explosions, cause elements to catch on fire and burn, objects can be destroyed matching realworld behaviours
Follow-up instruction
Make the tank game efficient so that it runs smoothly on desktop and mobile, including during explosions, spreading fire, and object destruction. Profile performance where possible and optimize physics, rendering, effects, and memory use while preserving the requested gameplay, convincing physical behavior, and visual quality. Test demanding scenes and report measured performance and limitations honestly. Rebuild the final app, update the retained public preview, and update benchmark-result.json. Continue the same task and session; do not delegate or change model or reasoning settings.
One independent task per model, with fresh Boat workspaces and identical task and platform instructions. Model effort names do not imply equal compute budgets. Timings exclude setup, independent review, and publication; token-cost estimates exclude VM, proxy, tool, subscription, and tax charges. Apps retain the generated gameplay code. Publication adds the model name to each browser title. Browser checks use headless Chrome and SwiftShader software graphics on a shared CPU host. Host load was not controlled; frame-rate samples are not comparable across apps and do not establish real-device FPS. This single comparison does not establish a quality winner. The efficiency instruction arrived after launch. Each agent received the same follow-up in its original session. Execution time and cost include both turns; total time also includes the wait between turns.
Sorted by time taken, fastest first.
2028.2s · $2.1134
Browser checks passed
Agent-reported limits: Final software-rendered stress measurements are 11.9 FPS desktop and 27.3 FPS mobile emulation; smooth 30/60 FPS is not achieved consistently in this environment. Physical phones and hardware-accelerated GPUs were not tested. Adaptive quality may lower the 3D buffer to DPR .65, shadows to 1024 pixels/10 updates per second, decorative grass density, and HUD blur. Geometry detail and rough-surface shaders are simplified; gameplay damage and fire propagation are preserved.
Custom skills supplied: 0
2054.3s · $12.6909
Browser checks passed
Agent-reported limits: Smooth 30 or 60 FPS was NOT achieved in the available environment; final stress results were 7.16 FPS desktop and 16.32 FPS mobile emulation. Further GPU-focused optimization and physical-device validation remain necessary. Mobile testing used touch emulation on the desktop Intel UHD 620 GPU. It does not establish performance, thermal behavior, battery use, or compatibility on physical phones.
Custom skills supplied: 0
3083.3s · $14.5778
Browser checks passed
Agent-reported limits: Performance was measured only in headless Chrome with SwiftShader (CPU rasteriser) and CDP CPU throttling; real phones/GPUs will differ (likely better raster, possibly worse JS). No real device was available. Under heavy load the game trades visual density for frame rate: low quality means fewer/shorter-lived particles, no fire glow, fewer debris bodies and 1x DPR on phones. The first ~1.5 s of a sudden large blast on a slow device can dip (measured 24-33 fps) before the controller reacts.
Custom skills supplied: 0
4859.9s · $14.5498
Browser checks passed
Agent-reported limits: There is no real GPU in this sandbox and no physical phone. All fps figures come from headless Chrome on software-backed GL paths and from mobile emulation with CPU throttling, so they are proxies. Real hardware will differ, and on GPUs these paths are typically much faster at canvas fill. The heaviest scenes do not reach a steady 60 fps on the slow default GL path: about 18-30 fps adaptive on desktop and 20-33 fps on emulated mobile. On the SwiftShader path, desktop adaptive holds 56-60 fps, but full-quality inferno is ~29 fps and emulated mobile is 26-38 fps.
Custom skills supplied: 0
6285.6s · $1.2126
Browser checks passed
Agent-reported limits: All browser verification ran on headless Chrome with SwiftShader (software rasteriser): wall-clock frame time there is dominated by a fixed present/composite cost (a 480x300 canvas still costs ~130 ms/frame while render submission is 0.6 ms), so the frame-time numbers are not a proxy for real GPU hardware. The hardware-independent signals reported are per-subsystem CPU ms, per-call micro-benchmarks, draw calls / triangles / point sprites and heap after GC. GPU raster/fill cost could not be isolated in this environment; the fill-rate work (fewer and smaller point sprites, ~29% fewer triangles, per-tier pixel-ratio cap, shadows on a cadence) is justified by counters and the resolution-scaling result, not by a measured GPU frame time.
Custom skills supplied: 0
9335.9s · $39.0376
Browser checks passed
Agent-reported limits: Frame rates on real GPUs and phones are still unmeasured. The software-rendering figures show the optimised build is roughly 1.3-2.8x faster than the baseline in the same environment, not that it reaches 60 fps on any particular device. Under software GL the heavy scenes remain at 10-16 fps at 1440x900. A resolution test there (rendering 44% fewer pixels) did not make frames 10% faster, so that mode appears limited by per-draw overhead rather than pixel fill; heavy scenes still issue about 1,600-1,750 canvas draws per frame on desktop and about 920-950 on touch devices.
Custom skills supplied: 0
