The Traveling Salesman Problem is a classic optimization puzzle. Plan a road trip through a list of cities, visit every one exactly once, take the shortest possible path, and end up back home. It sounds simple. Then you add cities, and the number of possible routes explodes past what any computer can check one by one. It isn’t just a brain teaser either. The same problem hides inside delivery routing, chip design, and DNA sequencing, and it pushes algorithms hard enough that the working answers fall into two camps, brute force when the map is small, and clever shortcuts that settle for good enough when it isn’t.

Below is the problem made playable. Pan anywhere on the map, click to drop your stops or scatter some at random, then let nearest neighbor find a fast answer or brute force grind out the perfect one. Distances are real kilometers.

Nearest Neighbor is the greedy approach. Start at a point, go to the closest place you haven’t visited yet, and repeat until every stop is used, then head home. It’s fast, it feels like how a person would actually plan a route, and you can watch it think in half-second steps. The catch is that it never looks ahead. A choice that’s cheapest right now can strand the route on the far side of the map later, so the answer is usually good and almost never perfect.

Brute Force skips the cleverness entirely. Check every possible order of stops, keep the shortest one found, and when it’s done the route isn’t just good, it’s provably the best. The price is the math. With 5 points there are 24 routes to check. With 7 there are 720. By 15 points you’re past 87 billion, which is why this tool caps brute force at 7 and why the whole world runs on shortcuts instead.