How to Build a Working Stickman Ragdoll System

I spent way too long trying to get a simple stickman ragdoll running smoothly in JavaScript before I figured out what was actually going wrong. The problem wasn't complicated, but the number of tutorials that get it subtly wrong is frustrating. Here is how I ended up doing it and where most people trip up. A stickman ragdoll is a set of points (joints) connected by constraints (bones) that are driven by a physics solver. Each joint has position, velocity, and mass. Each bone enforces a distance constraint between two joints. Gravity pulls everything down, and you apply forces or impulses to make it move. That's the whole thing. The reason it looks like a living, flailing character instead of a collapsing pile of lines is entirely in the solver quality and how you initialize the poses. I usually build mine in a plain HTML canvas with a simple Verlet integrator. It's not the most performant approach if you're building a commercial game, but it's by far the easiest to understand and debug. Here's the core structure I use:

Points array: each point has x, y, oldX, oldY, and pinned (a boolean). The Verlet step is just current minus old, giving you velocity implicitly. Constraints: each constraint stores two point indices and a rest length. You solve constraints by pulling the two points toward the midpoint so the distance matches the rest length. Iteration count: you run the constraint solver 5 to 10 times per frame. More iterations make the skeleton stiffer. Less makes it floppy. Five is usually the sweet spot for a stickman that still feels responsive without expensive computation.

The rendering is just drawing lines between connected joints and a circle at each joint if you want to see the skeleton.

Get the Full Details

Best Stickman Ragdoll at William Justice blog
Best Stickman Ragdoll at William Justice blog

My First Real Problem and How I Fixed It

The first time I built this, the ragdoll kept folding in on itself at the knees and elbows. I thought it was a constraint solver issue. It wasn't. The problem was that I was setting the initial pose by placing joints at exact positions and then letting the solver start from zero velocity, which caused the constraints to massively over-correct in the first frame because the rest lengths didn't match the distances between my placed joints. I had measured the distances wrong when placing them by hand. The fix was two-part. First, I added an initialization pass that ran the constraint solver 50 times before the simulation started, with the hip joint pinned, so everything settled into a stable pose. Second, I stopped hardcoding joint positions and instead built the stickman from a template system where I defined rest lengths for each bone and let the initialization routine place the joints automatically by walking the skeleton hierarchy. That eliminated the mismatch entirely. The fold-over problem disappeared after that. I also learned the hard way that pinning only the hip isn't enough if you want to do anything interactive. I started pinning the foot that's planted on the ground during walking simulations. That simple change made the ragdoll feel dramatically more controllable.

Advanced Stuff Most Tutorials Skip

One thing that comes up constantly and almost no beginner tutorial addresses is angular constraints. Pure distance constraints let limbs rotate freely around joints, which is fine for a dead ragdoll, but if you want the stickman to do anything intentional — stand up, swing an arm, kick — you need some rotational stiffness. I solved this by adding angle constraints between three consecutive joints. For example, the angle between the upper leg, lower leg, and foot should stay within a range. You compute the current angle and apply a corrective impulse to the middle joint. Another thing: friction and collision. A ragdoll in freefall is boring. You need ground collision. The simplest approach that actually works is to treat the ground as a series of segments and do circle-segment intersection tests for each joint. When a joint penetrates the ground, you push it out along the collision normal and dampen its velocity. I also added simple circle-circle collision between joints so the stickman's own body parts don't pass through each other. Two iterations of this per frame is plenty. Here's a concrete implementation detail I wish I'd known earlier. When you apply an impulse to a joint, you have to be careful about how Verlet integration handles it. The velocity in Verlet is (current - old), so to apply an impulse you modify the old position, not the current one. Adding delta to old position moves the point in the opposite direction of the impulse, which is counterintuitive but correct. If you modify current position instead, the impulse gets eaten by the next integration step.

I spent about three hours debugging a bug that turned out to be exactly this — I was applying forces to the wrong coordinate. Once I switched to modifying oldX and oldY, the ragdoll responded to mouse input immediately and predictably.

Lighting Stickman Game at Sam Meyer blog
Lighting Stickman Game at Sam Meyer blog

Where This Approach Breaks Down

Verlet-based ragdolls are simple, but they have real limitations. They struggle with high-speed collisions because the discrete time step causes tunneling — a joint can pass through a surface between frames if it's moving fast enough. The fix is continuous collision detection, which adds significant complexity. For most hobby projects, reducing the time step or increasing solver iterations is enough, but it's not a free solution. Memory and performance scale poorly if you add too many joints. A simple stickman with 10-15 joints runs fine at 60fps on anything. Once you go above 30 joints with 10 solver iterations and collision checks against a complex terrain, you'll start seeing frame drops on older hardware. I've seen people try to add ragdoll physics to dozens of stickmen on screen at once and then wonder why their browser tab crashes. It's not a conspiracy. Another honest limitation: Verlet integration doesn't handle very stiff springs well. If you crank up the constraint iterations to make the skeleton rock-solid, you'll hit diminishing returns and eventually numerical instability. The ragdoll will start jittering or exploding. I've found that capping iterations at 15 and accepting a small amount of flex is better than pushing for perfection.

Alternatives Worth Considering

If you need production-quality ragdoll physics, don't build your own. Use a library. Matter.js handles 2D rigid body physics with constraints and is good enough for stickman-style projects. Box2D is the industry standard if you're doing something more serious. These libraries have optimized solvers, proper continuous collision detection, and documentation that doesn't consist of a single GitHub gist from 2013. For learning purposes though, building from scratch is still the best way to understand what's happening under the hood. I still maintain a minimal Verlet ragdoll implementation alongside my production code because it's useful for prototyping movement and animations quickly. It takes about 15 to 20 minutes to get a basic version running if you already know the pattern, which is faster than configuring a full physics engine for a simple test. The code I ended up using lives on GitHub under a fairly generic name, but searching for "verlet stickman ragdoll javascript" will turn up plenty of implementations. Just be aware that most of them have the initialization bug I described — they look fine at first but collapse when you try to interact with them. My workaround of the 50-iteration pre-solve pass is the thing that actually makes them usable.