But between this article and the one that was posted last week (the Nebraska problem http://mollyrocket.com/casey/stream_0015.html)...it's really thought-provoking to see the ways that a visuals-first debugger can at least spark a faster iteration of ideas, if not uniquely identify them...the OP wrote this in another of his Working on the Witness pieces (http://mollyrocket.com/casey/stream_0013.html):
> Instead of stepping through the code or even carefully reading it to see what it was doing, I did what I often do these days and added debug visualization code right away. I’ve been through these kinds of problems enough times that I know, more often than not, if you’re going to debug one thing in a piece of code, you’re going to debug a bunch of things, so you might as well add the debug code early and leverage it throughout the whole process. Why wait for the really hard bug before adding the debug code? It takes the same amount of time to write debug code earlier as it does later, but earlier means you can use it to speed debugging of all those not-as-hard bugs along the way.
It's not test-driven-development obviously, but am I wrong in assuming that this preemptive custom debugging is rare in game development? What kind of frameworks/scaffolding exist to do such testing? I thought the situation described in the OP was interesting in that it showed how one of the most annoying gamebreaking bugs can slip through...but if consistency of boundaries is dependent on designers/artists meticulously cleaning up their "blocks"...and/or a dev-type who has hacked together a tool to make inconsistencies more noticeable...I'm surprised that games don't have broken surfaces as a rule rather than an exception. Or maybe way more time goes into mundane, repetitive game testing than I had thought.