👾 Arcade1981KonamiFIDDLYFrogger rebuild deck
FIDDLY
The river is the exact inverse of the road — lethal by default, survivable only while riding something moving — and one tidy shared collision function hands you a game where logs kill you.
You will get it, but one specific system will fight you.
The trap is treating the river as more traffic. It is the exact inverse, and a model writing one tidy collision function will produce something unplayable in a way that takes twenty minutes to diagnose. Velocity inheritance is the other half; get it slightly wrong and the frog drifts off logs in a manner that reads as broken rather than difficult. Past that it is two hours of lane-speed tuning, which is the only part worth your attention. Konami developed it; Sega distributed the cabinet in North America, which is why the marquee confuses people.
- Difficulty
- FIDDLY · 2 of 5
- First playable
- An evening
- The original
- 3 team-years
- Released
- 1981 · Arcade
- Genre
- Arcade Action
Build a single-screen road-and-river crossing game as one self-contained HTML file. Canvas 2D, Web Audio for sound, no build step, no dependencies. Requirements: - A 13-column by 14-row grid. The bottom half is five lanes of traffic at different speeds and directions, the top half is five lanes of river carrying logs and diving turtles, with a safe median between them and five home bays at the very top. - The player hops one cell at a time with a 90ms tween. Test collision against the tweened pixel position, not the grid cell. - The river rows invert the collision rule: water is lethal by default and you survive only while overlapping a floating platform. Write this as a separate pass. An agent that reuses one generic hit test will hand you a game where logs kill you. - While riding, the player inherits the platform's velocity in pixels per second and dies if carried off either screen edge. - Turtles submerge on a cycle: 3s up, 1s flashing, 1.5s under and lethal. - Lane definitions, speeds, spawn gaps and per-level multipliers live in levels.json. - Five homes to fill per level. A fly and a second frog spawn occasionally for bonus points, and a 30-second timer bar drains per life. - Chunky square-wave audio: a two-note hop, a splash, a squash. Definition of done: I can fill all five home bays, the next level runs measurably faster, and riding a log off the right edge kills me.
- The name and the frog itself, both of which Konami still owns and licenses out
- The four-way leaning joystick on the cabinet, which turns each hop into a physical commitment
- Coin-op difficulty curves tuned by people watching strangers lose real quarters
- The death jingle, which is eight notes and lives rent-free in a generation's head
Hazards on fixed periods, not random spawns
A random hazard can only be reacted to; a hazard on a fixed period can be learnt, and learning is the whole difference between an arcade game and a reflex test. Deriving everything from period and phase also gives the field a known cycle length, which means you can prove a safe path exists rather than hoping one does.
ScopeA weekend— build just this, not the game
Build a readable-hazard field. Single self-contained HTML file, Canvas 2D, no dependencies, no build step. - Eight lanes of moving hazards. Each lane is four numbers: period, phase offset, speed, duty cycle. No spawners, no per-object timers, no accumulated state. A hazard's position is a pure function of its lane's numbers and elapsed time. - Choose periods sharing a small common multiple so the whole field returns to its exact starting arrangement on a known cycle. Print that cycle length and a progress bar through it. - Telegraph: each lane draws its next safe window as a faint marker ahead of the player, so the pattern is learnable rather than merely survivable. - A checker that walks the reachable row-and-time states and proves at least one crossing exists. Refuse any lane set that fails, and name the lane that broke it. - Per-lane sliders, with the cycle length and the checker rerunning live. Definition of done: the field is pixel-identical at t=0 and at one full cycle, and dragging a period until no crossing exists gets me a named rejection instead of an unplayable board.
Not a clone — Frogger 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.
Primeval Flatland
Frogger, but 2D instead of 3D, set in prehistory. Rendered in PS1 low-poly with texture warping.
Build a browser game called "Primeval Flatland". The pitch in one line: a arcade action in the spirit of Frogger, but 2D instead of 3D, set in prehistory. WHAT THIS IS Take the SHAPE of Frogger — 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 2D instead of 3D. Canvas 2D and sprites. The mechanics survive the dimension drop; the asset budget falls by an order of magnitude. 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 Prehistory. No language, no metal, no map. Communication and tools must be invented by the player rather than issued to them. 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 PS1 low-poly with texture warping. Vertex-snap positions to a low-resolution grid in the vertex shader, use affine texture mapping so textures swim, dither to 15-bit colour, and fog the draw distance. 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.
- Museum of the Game — original cabinet and hardware data
- leereilly/games — large index of open browser game source
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 3 team-years to the counter on the homepage.
Then try these
Questions
How hard is Frogger to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and Frogger is FIDDLY (2 of 5). You will get it, but one specific system will fight you. The river is the exact inverse of the road — lethal by default, survivable only while riding something moving — and one tidy shared collision function hands you a game where logs kill you. Reckon on an evening to something you can actually play — not to something that matches the 3 team-years Konami spent.
What makes Frogger hard to rebuild?
The river is the exact inverse of the road — lethal by default, survivable only while riding something moving — and one tidy shared collision function hands you a game where logs kill you. 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 hazards on fixed periods, not random spawns — a weekend of work.
How long does it take to build a Frogger clone?
Wrong question, and it is worth saying why. Nobody rebuilds Frogger — the original took Konami on the order of 3 team-years, released in 1981 on Arcade. 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 Frogger?
The name and the frog itself, both of which Konami still owns and licenses out. The four-way leaning joystick on the cabinet, which turns each hop into a physical commitment. Coin-op difficulty curves tuned by people watching strangers lose real quarters. 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.