alex kuang

professional yak shaver

Zelda as a Metaphor for Complexity

Recently, my gaming bandwidth has been taken up by the new Zelda game, A Link Between Worlds. It’s been a while since my last trip to Hyrule, but I’ve always loved the ingenuity behind the dungeons, especially the ones in Ocarina of Time which could take upwards of hours (Water Temple, I’m looking at you) to complete on the first run. One of them jumps to mind particularly: The Forest Temple, a dungeon you encounter in the early-mid game immediately after gaining access to adult Link.

At first glance, it seems like a completely normal dungeon–You’ve got your wolves, you’ve got your carnivorous plants, and the obvious puzzle in the form of 4 torches that have to be lit. Fairly straightforward, until the game hits you with this:

The first time you hit the twisting hallway, you have to follow it as-is to the other side, your perspective being warped, to end up in a room with you standing on its “wall”. On the “floor” is a chest, inaccessible in your current state, and further on is a door you don’t have the key to. After a few more rooms and a battle with some wolves, you end up with the bow which allows you to hit a switch to un-twist the hallway, bringing a completely new perspective to the rooms–Most obviously, the chest from the earlier “floor” is now reachable, and after a little contemplation and a lot of climbing, you get the key to the previously locked door… Which you can’t access until you re-twist the hallway.

This simple sequence is, in essence, what makes the classical Zelda dungeons challenging and oh so much fun. In addition to an “item of the moment”, each area contains an inventive mechanic that completely changes the landscape of the entire dungeon. A room is completely different when your perspective is rotated, platforms become traversable after you flood the floor with sand, and so on. It’s no longer just Push a block over here, it’s Push a block over here to change the water level so we can push that other block, and then change the water level back to align the two blocks properly and maybe we can finally get to that chest over there. Oh wait, that didn’t work, maybe if I switch the water level back BEFORE moving the second block…

Sound familiar? The hardest dungeons’ mechanics tend to use some piece of outside state to introduce exponentially more complex interactions between the existing items that Link already has access to. Interactions that now depend not only on the current environment, but also the configuration of surrounding environments, and probably the order that everything was done as well. Keeping track of all that is welcome, even enjoyable, when I’m playing Zelda. But I have no wish to be dealing with such things when I’m trying to make sure my code is doing what I want it to.

A Neophyte’s Take on Scala

A blog post has recently been making the rounds in all the usual programming fora–/r/programming, hackernews, and so on–even eliciting a response from Scala’s creator himself. There’s a lot of discussion both productive and inflammatory out there already, but I thought I’d jot down my perspective on the common points as someone who: 1. picked scala up relatively recently (2.9.2 and 2.10), 2. has worked with it for a few months on the side, and 3. comes from a background of dynamic languages.

Long Compile Times

I can definitely see where this is coming from. Scala’s compile times can be pretty long, though I had pegged that as the cost of using a compiled language anyway. I, at least, felt a marked increase in times upgrading from 2.9.2 to 2.10, presumably from the slew of new features like macros. However, it seems that 2.11 will thankfully be focused on compiler optimizations. In the meantime, I’ve found that judicious use of some of Scala’s heavier features (such as implicits) keeps the compile times manageable. JRebel has been a godsend as well for hot-reloading in incremental compilation, and they do offer a personal Scala license for free. Without JRebel my life as a scala user would have been a lot harder.

Opaque Syntax

I agree completely here. Scala’s flexibility in parsing + its allowance of symbolic method names obviously allows for a lot of flexibility. This allows the construction of all sorts of DSLs; whether these DSLs end up being expressive or just plain confusing, is another thing altogether. In this case, I’d have to say that just because something is possible does not mean it should be done all the time.

Fibonacci Stream

I was going to test out some of the codeblock functionality in octopress, but as it turns out the fancy stuff I wanted to test is not available in master and I’m far too lazy to sync to 2.1 at the moment. As such, everyone will have to settle for this plain jane snippet:

// e.g., fibStream.take(5)
def fibStream: Stream[BigInt] = {
  def loop(prev1: BigInt, prev2: BigInt): Stream[BigInt] = prev1 #:: loop(prev2, prev1 + prev2)

Nothing fancy, just one of many possible variations of the fibonacci sequence. This one is done via a Stream, which is Scala’s memoized lazily evaluated list. (More here).

Will probably write more about the why/how of the nested loop def (mostly for my own reference), but for now I think the codeblock looks pretty neat. It’s still a shame I didn’t get to play with funny line numbers/highlighting stuff though.