In game development, there is this strange effect known as “tunneling.” It happens when you do collision detection. Imagine a simple situation where every time you move a cube, you also test whether it touches the wall – and if it does, you make it bounce off of it.

This works great, but if you move and detect the collision less frequently, something weird can happen:

Here, the movement was so coarse that there was no point at which the cube touched the wall, so the collision wasn’t detected, and the cube passed cleanly through… as if it made a tunnel.

(You can play with this simulator yourself, by the way.)

The easy answer seems to be “well, run the collision detection more often then,” but… how often? And what if the entire game engine runs off of computer’s frame rate, which you are not in control of it at all? All in all, it’s not a trivial challenge, although various techniques exist to remedy it.

We talked before about another challenge with frame rate dependence. They’re not limited to games; for interfaces that are based on physics, they will rear their ugly head, too. But tunnelling happens in simpler UI situations as well. Here’s an example from Photoshop – I’m holding a button and if I drag slowly, each item will be toggled. But when I start moving fast…

Fortunately, the remedy here is much easier than in the complex world of videogame physics: just remember the last one touched, and toggle everything in between that and the current one.

On the tldraw blog, Steve Ruiz covers a slightly more complicated scenario where you do have to do some physics: an eraser in a drawing tool.

Pointer input isn’t continuous. The browser reports the pointer’s position as a series of discrete samples, and when you move fast, those samples can land far apart. Flick your wrist and two consecutive pointer events might be a hundred pixels from each other, with three small shapes sitting untouched in the gap between them.

A naive eraser asks “what’s under the pointer right now?” on every pointer event. At slow speeds that works fine. At high speeds it tunnels straight through anything that happens to fall between two samples, which is exactly when people use the eraser most aggressively: big, fast, careless swipes to clear a region.

Here’s Ruiz’s example of the eraser in FigJam, with heavy tunneling:

And here’s one in his drawing tool:

You can click through to learn more and see the algorithms, but either way it’s worth remembering: if it applies to your interactions, think about the “flyover states” and make sure to make things deterministic, regardless of whether the mouse is a tortoise, or a hare.

And, I liked Ruiz’s sentiment at the end:

[…] The decision to test segments instead of points is the difference between an eraser you can trust at speed and one that mysteriously leaves survivors behind. Users will never notice it working, and that’s the point.