🌐 Browser2008Bennett FoddyFIDDLYQWOP rebuild deck
FIDDLY
Drive the hips and knees toward target angles with a capped PD controller and you have it in an evening; apply forces to the limbs instead, which is the default, and you get a puppet that is never once funny.
You will get it, but one specific system will fight you.
This is a tuning job wearing a programming job's clothes, and the tuning is reachable in an evening, which is why it is a yes. Any competent agent hands you a flailing ragdoll in twenty minutes, and then you spend six hours on torque caps and joint limits chasing one very specific sensation: this is possible and I am an idiot. Watch for forces applied straight to limb bodies, which yields a runner that either glides serenely or convulses, and both are boring. Keep the PD gains in data and keep a log of the values you have already rejected.
- Difficulty
- FIDDLY · 2 of 5
- First playable
- A weekend
- The original
- 1 team-years
- Released
- 2008 · Browser
- Genre
- Ragdoll Physics
Build a ragdoll sprinting game in which four keys drive a runner's leg muscles. Single HTML file, Canvas 2D, Matter.js vendored locally, no build step. Requirements: - A side-on ragdoll: head, torso, two thighs, two calves, two feet, joined by revolute joints with angle limits. - The four keys must NOT apply forces to limbs. Q and W set opposing TARGET ANGLES on the two hip joints; O and P do the same for the knees. Drive each joint toward its target with a proportional-derivative controller and a hard torque cap, returning to a slack neutral on release. Everything unfunny about a clone comes from skipping this and shoving limbs around directly. - The torso is completely unactuated. It falls over on its own. That is the game. - Fixed 60Hz physics step with an accumulator. A variable timestep changes the difficulty frame to frame, which is fatal in a game whose entire appeal is a cruel but fair control scheme. - Any ground contact by anything other than a foot ends the run and freezes the ragdoll where it lands. - Distance read from the torso's x position in metres, one decimal, finish line at 100. - Put torque cap, joint limits, friction and PD gains in a JSON file so they can be iterated without touching logic. Most of the build lives here. - Trailing camera, plain stadium backdrop, crowd noise via Web Audio. Definition of done: my first ten attempts all end face-down inside three metres, and by attempt fifty I can reliably pass ten.
- Foddy's exact torque caps and joint limits. You land near them in an evening, not on them
- Being the reference point every ragdoll control scheme has been measured against since 2008
- GIRP and CLOP, which prove the joke generalises and which you will now want to build too
Joints driven by target angle, not force
Driving a joint towards a target angle instead of shoving the limb with a force is the difference between a puppet and a body — it flails convincingly because it is trying and failing, not because you randomised it. The same controller drives camera follow, doors, turret aim and anything you want to arrive somewhere without snapping.
ScopeAn evening— build just this, not the game
Build a two-link arm driven entirely by target angles. Single self-contained HTML file, Canvas 2D, hand-written rigid-body maths or Matter.js vendored locally, no build step. - A shoulder joint pinned to a wall, an upper arm, an elbow, a forearm. Gravity on, angle limits on both joints. - The mechanic: never apply a force to a limb. Each joint holds a target angle, and a proportional-derivative controller turns (target minus current) and the joint's angular velocity into a torque, clamped to a hard cap. Keys set target angles; releasing a key returns that target to a slack neutral. - Fixed 1/60 s physics step with an accumulator, so behaviour does not change with refresh rate. - Sliders for P gain, D gain and torque cap, plus a live plot of target against actual elbow angle over the last four seconds. - A drag handle on the forearm so I can yank it and watch the controller fight back. Definition of done: with D at zero the elbow oscillates around its target indefinitely, and raising D settles it within one second without overshoot.
Not a clone — QWOP 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.
Fathomless One Run
QWOP, but a roguelike run instead of a campaign, set in cosmic horror. Rendered in silhouette against one light.
Build a browser game called "Fathomless One Run". The pitch in one line: a ragdoll physics in the spirit of QWOP, but a roguelike run instead of a campaign, set in cosmic horror. WHAT THIS IS Take the SHAPE of QWOP — 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 A roguelike run instead of a campaign. Twenty to forty minutes, procedurally assembled from hand-authored chunks, permadeath, and a meta-progression drip. Replaces authored content volume with combinatorics. 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 Cosmic horror. The threat should be mostly absent. Information the player uncovers should make things worse rather than better. 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 Silhouette against one light. Everything renders pure black against a lit background, with depth from four parallax layers of increasing blur, grain and a heavy vignette. 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 QWOP to rebuild with an AI agent?
Yes — every game is buildable at some scope. The question is how hard, and QWOP is FIDDLY (2 of 5). You will get it, but one specific system will fight you. Drive the hips and knees toward target angles with a capped PD controller and you have it in an evening; apply forces to the limbs instead, which is the default, and you get a puppet that is never once funny. Reckon on a weekend to something you can actually play — not to something that matches the 1 team-years Bennett Foddy spent.
What makes QWOP hard to rebuild?
Drive the hips and knees toward target angles with a capped PD controller and you have it in an evening; apply forces to the limbs instead, which is the default, and you get a puppet that is never once funny. 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 joints driven by target angle, not force — an evening of work.
How long does it take to build a QWOP clone?
Wrong question, and it is worth saying why. Nobody rebuilds QWOP — the original took Bennett Foddy on the order of 1 team-years, released in 2008 on Browser. 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 QWOP?
Foddy's exact torque caps and joint limits. You land near them in an evening, not on them. Being the reference point every ragdoll control scheme has been measured against since 2008. GIRP and CLOP, which prove the joke generalises and which you will now want to build too. 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.