🌐 Browser2014Google Chrome UX TeamFIDDLYChrome Dino rebuild deck
FIDDLY
It comes out correct on the first pass apart from one number: spawn gaps expressed in pixels instead of in seconds of jump make the game literally unclearable at the speed players actually reach.
You will get it, but one specific system will fight you.
The original ships inside Chromium, is genuinely readable, and an agent has seen it, so the mechanics come out correct on the first pass. The failure mode is spacing: models happily spawn obstacles on a fixed pixel interval and then act baffled when the game becomes impossible at top speed. Insist on the fixed timestep too, otherwise your high-refresh monitor plays a quietly different game to everyone else's and your leaderboard is nonsense.
- Difficulty
- FIDDLY · 2 of 5
- First playable
- An evening
- The original
- 1 team-years
- Released
- 2014 · Browser
- Genre
- Endless Runner
Build a one-button endless side-scrolling runner as a single self-contained HTML file. Canvas 2D, Web Audio for sound, no build step, no dependencies. Requirements: - A ground line, a character fixed at the left third of the screen, obstacles scrolling right to left. Space jumps, down arrow fast-falls. - Jump is a fixed impulse of -10 px/frame at 60fps against gravity of 0.6 px/frame squared, with a variable-height cutoff: releasing early clamps upward velocity to -4. Down arrow triples gravity. - World speed starts at 6 px/frame, accelerates by 0.001 per frame, caps at 13. - The load-bearing rule: minimum spacing between consecutive obstacles is derived from the CURRENT world speed, not a fixed pixel constant. Use gap = obstacleWidth * speed * 0.6 plus a random extra up to 1.5x that, and never spawn until the previous obstacle has cleared it. A fixed gap produces a game that is literally unclearable past speed 11. - Obstacle definitions in a JSON file: three cactus widths below 450 score, plus flying hazards at three heights above it. - Score in tenths of distance travelled, a blip and a flash every 100, and a full palette inversion at every 700 points that reverts on the next threshold. - Fixed timestep accumulator so a 144Hz monitor gets the same game as a 60Hz one. - Persist the high score in localStorage. Definition of done: I can reach 900 points, the palette has inverted and reverted, and no obstacle pair is ever unjumpable.
- Nothing mechanical. The original is a couple of thousand lines of JavaScript hiding in a browser
- The context, which is the entire joke: it only turns up when your connection dies
- Google's sprite sheet, and the specific comic weight of that pixel cactus
Spawn gaps measured in reaction time, not pixels
A spacing constant in pixels is a bug with a delay fuse: it plays fine at the speed you tested and becomes literally impossible at the speed players actually reach. Measure the jump once at load, express every gap in seconds of that jump, and the game stays fair at speeds you never thought to test.
ScopeAn evening— build just this, not the game
Build a spawn-spacing rig as a single self-contained HTML file. Canvas 2D, fixed timestep, no build step. - A scrolling ground, a character at the left third, one-button jump, obstacles moving right to left. World speed on a slider from 200 to 2000 px/s. - At load, simulate one jump arc and store its airborne duration and horizontal reach. Every spacing rule reads those measured numbers. No hard-coded pixel constants anywhere in the spawner. - Minimum gap is expressed in seconds: jump duration times 1.4, converted to pixels using the CURRENT speed at spawn time, plus a randomised extra of up to the same again. Never spawn until the previous obstacle has cleared that distance. - Draw the constraint: a translucent band on the ground showing the minimum gap at the present speed, and a readout of the actual gap in seconds between the last two obstacles. - An unfair-mode toggle that swaps in a fixed pixel gap. Definition of done: I hold the speed slider at maximum for a minute and the measured gap never falls below the jump duration, and flipping unfair mode makes it unclearable within seconds.
Not a clone — Chrome Dino re-themed and cut down to something you can finish. The angle is the important reel: it is what turns a project into a weekend. 24,360 ways to land.
Once Idle
Chrome Dino, but an idle version that plays while you are away, set in a fairy tale gone wrong. Rendered in modern low-poly diorama.
Build a browser game called "Once Idle". The pitch in one line: a endless runner in the spirit of Chrome Dino, but an idle version that plays while you are away, set in a fairy tale gone wrong. WHAT THIS IS Take the SHAPE of Chrome Dino — its core loop, and whatever makes that loop good — and rebuild it as your own game in a different world at a smaller scope. Use your own names, art and audio, which you want anyway: a reskin of somebody else's game is less interesting than a new one that works the same way. THE ANGLE — this is the important constraint, honour it above everything else An idle version that plays while you are away. Offline progress on load, big-number maths from line one, and a prestige reset. The fantasy survives; the input does not. This is what makes the project finishable. If a decision would push the scope back towards the original's, take the smaller option every time. THE THEME A fairy tale gone wrong. Rules of stories treated as physics — deals, thirds, true names — and a moral that costs something. The theme is not a coat of paint. Let it change what the mechanics mean — a reload, a health pack and a locked door should all be things that make sense in this world and nowhere else. LOOK Modern low-poly diorama. Facetted meshes, baked AO, miniature tilt-shift feel, and a colour script of 5–6 base hues max. REQUIREMENTS - Runs in a browser with no build step. Canvas 2D unless the angle genuinely requires 3D, in which case three.js. - Fixed-timestep update loop with interpolated rendering, so it behaves the same at 60Hz and 144Hz. - Every tuning constant in one CONFIG object at the top, exposed as live sliders in a debug panel. You will find the feel by dragging those, not by prompting. - All content — levels, entities, balance numbers — in JSON or plain data files, never inline in the logic. - Audio generated with the Web Audio API rather than asset files. - Respect prefers-reduced-motion: keep the fades, drop the shake and the parallax. BUILD ORDER 1. The core loop with placeholder rectangles, at the reduced scope the angle demands. No theme, no art, no audio. Make it fun as rectangles first. 2. The angle's consequences. Cutting to bots, or to turn-based, or to one level changes the design rather than just shrinking it — find out how and rewrite step 1. 3. The theme, as content and data. 4. The look, applied last as a rendering layer over a game that already works. Start by writing a one-page plan: the core loop, what the angle removes and what that frees you to do properly, and what you are deliberately leaving out. Wait for me to approve it before writing code.
Half the time one of these already does what you wanted, and the other half it saves you a week of solving a problem someone documented in 1997.
One count per game. No account — it is tied to a salted hash of your IP, which is not stored in a form anyone can reverse. Every build adds 1 team-years to the counter on the homepage.
Then try these
Questions
How hard is Chrome Dino to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and Chrome Dino is FIDDLY (2 of 5). You will get it, but one specific system will fight you. It comes out correct on the first pass apart from one number: spawn gaps expressed in pixels instead of in seconds of jump make the game literally unclearable at the speed players actually reach. Reckon on an evening to something you can actually play — not to something that matches the 1 team-years Google Chrome UX Team spent.
What makes Chrome Dino hard to rebuild?
It comes out correct on the first pass apart from one number: spawn gaps expressed in pixels instead of in seconds of jump make the game literally unclearable at the speed players actually reach. That is why it sits at FIDDLY rather than a tier either side of it. If you want the idea without the project, the transferable part is spawn gaps measured in reaction time, not pixels — an evening of work.
How long does it take to build a Chrome Dino clone?
Wrong question, and it is worth saying why. Nobody rebuilds Chrome Dino — the original took Google Chrome UX Team on the order of 1 team-years, released in 2014 on Browser. What you can do is reach something playable and genuinely yours in about an evening, and then keep going for as long as it stays interesting. Any figure that claims otherwise is measuring a prototype and calling it a game.
What do I lose by building my own Chrome Dino?
Nothing mechanical. The original is a couple of thousand lines of JavaScript hiding in a browser. The context, which is the entire joke: it only turns up when your connection dies. Google's sprite sheet, and the specific comic weight of that pixel cactus. Those are the parts a prompt will not hand you.
Which AI coding agent should I use to build it?
Any of Claude Code, Codex or Cursor will handle this prompt. Paste it as your first message, let the agent scaffold the project, then iterate on feel — the second, third and tenth prompts are where a game actually gets good. Work in an empty folder or a fresh git branch so you can throw it away cheaply.
One email when new games go on the list. No other reason to email you, ever.