📱 Mobile2011Imangi StudiosFIDDLYTemple Run rebuild deck
FIDDLY
The corner needs a turn zone and a 300ms swipe buffer, and without them the game feels like it hates the player in a way testers will misreport to you as lag.
You will get it, but one specific system will fight you.
The turn buffer is your whole review. Agents implement the swipe as an instantaneous test against a corner trigger, and the result is a very specific flavour of unfun that people describe as laggy when it is a windowing bug. The other trap is rotating the camera at corners rather than the world: it works fine until minute eight, when accumulated float error starts jittering geometry. Imangi was three people when this shipped in August 2011, which makes it one of the few entries here where the effort gap is genuinely narrow.
- Difficulty
- FIDDLY · 2 of 5
- First playable
- A weekend
- The original
- 2 team-years
- Released
- 2011 · Mobile
- Genre
- Endless Runner
Build an endless runner where a character sprints along a raised path through ruins. Browser, portrait, single HTML file using three.js via an import map. 60fps on a mid-range Android is the constraint, so keep draw calls low and pool every mesh. Requirements: - The path is a graph of straight segments joined by ninety-degree corners. Move the world past a fixed camera rather than flying a camera through the world; that keeps floating-point drift out of the maths after ten minutes of running. - The turn is the entire game. A left or right swipe only counts inside a turn zone starting four metres before a corner and ending at the corner. Buffer any swipe made up to 300ms early and fire it on entering the zone. Without that buffer the game feels like it hates the player, and testers will report it as lag. - Swipe up jumps with a 0.55s arc, swipe down slides for 0.5s with the hitbox halved, accelerometer tilt or drag strafes between three lateral offsets independently of turn state. Jump and strafe must overlap cleanly. - Speed starts at 9 m/s and gains 0.35 m/s every 10 seconds, capped at 22. - Segment templates, obstacle sets and coin patterns in JSON, sampled with a seeded RNG so any run is reproducible. - Missing a turn sends you off the edge with a fall, never an instant cut to black. Definition of done: I can chain three corners at top speed using only early swipes, and coins bank on death.
- The escalation curve, where speed ramps to just past the point you can reliably react
- The demon monkeys, the idol, and every trademark Imangi actually owns
- A friends leaderboard, which was most of the reason anyone played it twice
- Accelerometer tilt tuned on real handsets, which desktop testing will never approximate
Swipe recognition by dominant axis and threshold
Every mobile web game gets gesture recognition wrong in the same way: an atan2 across the start and end points, no distance threshold, no ambiguous case, so diagonal thumbs produce random directions and the player blames the game. Dominant axis with a dominance ratio, recognised before the finger lifts, is about thirty lines and it is the entire difference.
ScopeAn evening— build just this, not the game
Build a swipe recogniser test bed. Single self-contained HTML file, Canvas 2D, pointer events, no build step. It must work with a mouse and with a finger. - Record the pointer path from down to up: points, timestamps, total displacement. - Classify: under 24px of displacement it is a tap. Above that it is a swipe only if the dominant axis beats the other by a ratio, exposed as a slider, default 1.6. Below that ratio the gesture is ambiguous and must be rejected, not guessed. - Recognise early: fire the instant both threshold and ratio are satisfied, before the pointer lifts, then swallow the remainder of that gesture. Waiting for release adds latency players report as lag. - A 400ms cap, past which a drag is not a swipe. - Draw every path, its bounding box, the measured ratio and the verdict, and log the last twenty. Definition of done: a 45-degree drag reads as ambiguous rather than randomly left or up, and a fast flick registers before I lift my finger.
Not a clone — Temple Run 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. 5,880 ways to land.
Ragnarok Offline
Temple Run, but against bots — no netcode at all, set in Norse myth. Rendered in photocopied zine.
Build a browser game called "Ragnarok Offline". The pitch in one line: a endless runner in the spirit of Temple Run, but against bots — no netcode at all, set in Norse myth. WHAT THIS IS Take the SHAPE of Temple Run — 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 Against bots — no netcode at all. Everything runs locally. No server, no lobby, no lag compensation. Bots use a small behaviour tree with a tunable reaction time. This single cut removes the hardest engineering in most multiplayer games. 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 Norse myth. Cold, doomed and knowingly so. Everything is on its way to an ending everybody has already been told about. 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 Photocopied zine. Blown-out high contrast, dithered halftones, visible toner streaks and a page that shifts a pixel or two per frame. 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.
- three.js — the least painful route to a browser corridor runner
- Kenney — free low-poly kits and UI packs
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 2 team-years to the counter on the homepage.
Then try these
Questions
How hard is Temple Run to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and Temple Run is FIDDLY (2 of 5). You will get it, but one specific system will fight you. The corner needs a turn zone and a 300ms swipe buffer, and without them the game feels like it hates the player in a way testers will misreport to you as lag. Reckon on a weekend to something you can actually play — not to something that matches the 2 team-years Imangi Studios spent.
What makes Temple Run hard to rebuild?
The corner needs a turn zone and a 300ms swipe buffer, and without them the game feels like it hates the player in a way testers will misreport to you as lag. 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 swipe recognition by dominant axis and threshold — an evening of work.
How long does it take to build a Temple Run clone?
Wrong question, and it is worth saying why. Nobody rebuilds Temple Run — the original took Imangi Studios on the order of 2 team-years, released in 2011 on Mobile. What you can do is reach something playable and genuinely yours in about a weekend, 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 Temple Run?
The escalation curve, where speed ramps to just past the point you can reliably react. The demon monkeys, the idol, and every trademark Imangi actually owns. A friends leaderboard, which was most of the reason anyone played it twice. 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.