DEV Community

Taehyun Kim
Taehyun Kim

Posted on

Traceroute devlog #3

Most of this week's difficulty lived inside one single rule, and what made it worth writing about isn't any one fix — it's that I didn't actually understand the problem until I'd already "solved" it three times.

The rule sounds small: if you click through a point on your own path that would carry you past your color's still-unreached endpoint, the path should stop right there and count as done. The first version I built didn't do either half of that. Clicking straight through just kept going — the path walked right past the endpoint like it wasn't special at all, and on top of that, nothing registered as complete. So the very first attempt wasn't off by one small detail, it just didn't implement the rule at all, even though I'd been sure it did.

I fixed the "doesn't stop" part, and that's when things got interesting instead of just wrong. Now, clicking through the endpoint did stop — but it stopped the way an illegal move stops: the little rejection motion played, the same one you get from hitting a wall or crossing your own path somewhere you shouldn't. Which is backwards. Reaching your own endpoint isn't a mistake, it's the point of the whole color. I'd fixed the symptom by routing it through the wrong branch of logic entirely — treating "stop here because you're done" as if it were "stop here because that's illegal."

So I fixed that too, and got the path to genuinely halt right at the endpoint on a pass-through click, no rejection animation, just a clean stop. That felt like the actual fix. It wasn't. Playing with it afterward, I noticed that if you stopped at the endpoint and then clicked somewhere else entirely, the path would just keep extending forward from there, like the endpoint had never been reached in any meaningful sense. The stop was cosmetic. Nothing was actually locked — "complete" was a label I was drawing correctly on screen without it controlling anything underneath.

The real fix, the one that finally held, was to make reaching the endpoint freeze the whole path — not just stop drawing at that instant, but lock it against any further change at all, until you deliberately undo or clear it. Only once that existed did the earlier three fixes actually add up to the rule I'd meant to build in the first place.

That freeze fix, though, immediately opened a new question I hadn't planned for: if reaching an endpoint locks the whole path in place, what happens if what got locked in was wrong? A path can be a technically valid connection and still not be what you actually meant to draw, and once it's frozen there's no way back short of reloading the entire level. That question is what turned into the actual case for building real undo, redo, and a full clear button — not as separate nice-to-haves I thought up on the side, but as the direct consequence of the freeze rule itself. Locking something in place is only fair to the player if there's also a way to unlock it.

Looking back at the whole sequence, none of the individual steps were hard. What got me was that each fix was locally correct and globally incomplete — it solved exactly the symptom I could see at that moment, and hid the next one underneath it, so I kept discovering the actual shape of the problem one layer at a time instead of seeing it all at once.

There was one other moment worth a mention, smaller but satisfying in a completely different way: while sketching out how failed puzzle generations should retry, I noticed on paper — before writing any code — that the piece doing the generating already had its own retry allowance built in from earlier work, and stacking a second one on top without accounting for that would have let worst-case attempts multiply into something absurd instead of just adding up. Catching that by re-reading a plan, rather than by something actually breaking, felt like a rare win this week.

By the end of it, the generator, the search process that finds a way to solve a board, and the difficulty-scoring piece were all built and mostly holding up. The very last step — turning a generated board into a finished, playable level — is written but unconfirmed, so that's exactly where next week starts.

Top comments (0)