Random walk
Each frame, nudge a point's X and Y by a small random amount, letting it wander the canvas; the same technique can perturb color instead of position.
What it is
A random walk moves a point by adding a fresh random offset to its position every frame, so the point drifts instead of following a fixed path. Nature of Code frames it plainly: it is “a path defined as a series of random steps.” The state needed is minimal — “a walker needs only two pieces of data: a number for its x-position and a number for its y-position” — which is why it shows up as one of the first exercises in both Nature of Code (as the “Walker” class) and happy-coding (as the “Random Walker,” also called the “drunkard’s walk”). The same nudge-every-frame idea is not limited to position: the technique generalizes to perturbing any numeric quantity frame to frame, including a colour’s channels instead of x and y.
How it works
- Store two numbers as state —
xandy— nothing else persists between frames. - Each frame, produce one random step. Nature of Code’s version does this by drawing a random choice among four fixed outcomes — “0, 1, 2, or 3. The random choice determines the step” — so each frame the walker moves according to whichever of the four outcomes was drawn. happy-coding’s version is commented simply
//randomly move; the evidence here doesn’t spell out its exact distribution, only that the position is nudged. - Add the step to the stored position.
- Draw the point (or a line segment from the previous position to the new one) at the updated
x, y. - Repeat every frame. Step 2 has no memory beyond the current position — the whole path is re-derived one fresh random draw at a time, with no lookahead and no plan.
Parameters & tuning
The one knob that actually matters is which distribution the step comes from — everything else downstream in this family (see Variants & neighbours below) is that single swap. A walk drawing its step from a small, fixed set of outcomes, as in Nature of Code’s four-choice version, can only ever move along that fixed vocabulary of moves; the resulting path is built from repeated, discrete jumps rather than a free meander. Step size sets how far each jump can carry the point — too small and the drift barely reads as motion across a frame’s timescale; too large and successive frames stop looking like the same walker, because the new position has no visible relationship to the last.
Boundary handling is a separate decision from the step distribution: what a walker does at the edge of the canvas (stop, clip, reflect, or wrap) is not fixed by “random walk” itself, which is exactly where toroidal random walk differs (below).
Where it’s been used
The evidence gathered here covers two teaching sources — Nature of Code and happy-coding — both of which present the random walk as an introductory exercise in randomness and animation state, not as a named artwork. No specific artwork’s use of the plain random walk is evidenced in this bundle.
Variants & neighbours
The family is defined entirely by what supplies the step:
- Perlin noise walker replaces the independent, memoryless random draw with p5’s
noise()function, evaluated at a continuously advancing time offset and mapped from its 0–1 output to a position range. Because Perlin noise is continuous and correlated across nearby inputs, the resulting path is smooth and directional rather than jittery — the walker still wanders, but consecutive steps agree with each other instead of being drawn fresh and independent each frame. - Lévy flight keeps the frame-by-frame walking loop but redraws the step-length distribution as heavy-tailed: usually small, occasionally very large. That occasional long jump is the whole point — it reduces the oversampling a plain random walker suffers from, where a memoryless small-step walk keeps revisiting the same local neighbourhood instead of covering new ground.
- Toroidal random walk is a discrete, eight-direction random walk whose position wraps back onto the opposite edge instead of stopping or clipping at the canvas boundary — the step choice stays discrete, as in Nature of Code’s version, but the boundary rule is what changes.
- Random Colors looks superficially similar — both involve drawing something at a random-ish value every frame — but there is no walk in it: it loops over every pixel position and assigns an independently random RGB colour with no relationship to the previous frame or to neighbouring pixels. A random walk is defined by state carried from one step to the next; Random Colors carries none.
- Accept-reject sampling solves a different problem entirely: building samples from an arbitrary target probability distribution by drawing a candidate and a qualifying value and discarding candidates that fail a test. A random walk never needs to reason about a target distribution shape at all; it just adds noise to wherever it already is.
Go deeper
The two sources behind this page are worth reading directly for their full code: Nature of Code’s random walk chapter builds the Walker class step by step, and happy-coding’s Random Walker tutorial is the shorter, more code-first version of the same idea.
Connected to
Variant of: Levy flight
Variants: Levy flight · Perlin noise walker · toroidal random walk
Try it yourself
Replace Nature of Code's four-outcome step choice (0, 1, 2, or 3) with a continuous per-frame offset of the same average size. What changes about the resulting path, and what stays the same?
The four-outcome version can only ever move along the same fixed set of steps each frame, so the path is built from a small, repeated vocabulary of moves and reads as constrained and grid-like. A continuous offset can point in any direction each frame, so the path meanders freely instead of snapping to a lattice — but in both cases the position at frame N still depends only on the position at frame N-1 plus one fresh random draw, with no memory of anything earlier.