Back in my university days, I fondly recall when our professor for Structured Computer Organization, a seasoned computer scientist who worked on the EDSAC 1 back in the days of yore, asked, “Have any of you worked with Assembly?”. Having had the odd run-in with some flavors Assembly in previous microprogramming classes, I raised my hand.

He followed up the question with, “What’s the first thing that happens when you compile an Assembly program?”.

A notable silence followed, after which I answered, “It doesn’t work.”

“It doesn’t work!” he echoed, we laughed, and he segued into the day’s topic.

In a recent conversation in #rgrd, the oft-discussed topic of “to hack, or not to hack” came up. My stance on this topic is clear: do what you have to do to get it done. There exists a pervasive stigma in the developer community towards “voodoo code”, code that works, but you don’t know how or why. The reality of the matter is, my purpose is to program a game, not to figure out why ActionScript 3’s idiosyncratic handling of Numbers and ints caused the Bresenham code I lifted from RogueBasin and converted from C++ to misbehave on a very specific case!

Time that you spend cracking your head to optimize or understand a particular piece of code is valuable time that could be better spent developing! This approach must however be balanced with what Getting Real calls “paying back your programming debt”, that is, taking time as needed to clean up yesterday’s hacks for a better tomorrow. In following with this balance, I have devoted a small chunk of development time to rework some previously hacked code to make my life easier for the new features I am implementing.

Progress on Dance of Death continues strong. I have worked on the bulk of the goals for the next release, and have only a few (albeit large-ticket) items remaining. Version 0.3 will make an appearance within two weeks at most!