malvasia bianca

(First, a few notes: 1) I have a conflict of interest with respect to the game I’m discussing here. I haven’t worked on it and I don’t have any particular inside information about anything I’m speculating about here, else I’d have to be rather more careful about what I write, but obviously I want it to succeed. 2) Normally, games don’t have a canonical URL to refer to, so I link to a page I create for them in my database. Facebook games (and Flash games, for that matter) do have a URL, but, after some reflection, I am going to maintain the same practice, in order to maintain my automatic game-to-blog back references and to avoid treating them in a non-parallel and potentially second-class manner. I will add the link to the game on the database page, though, so if you want to play them, two clicks will get you to the right place. 3) Facebook games change a lot more quickly than disc-based games, so anything that I say here could be inaccurate by the time you read this. In fact, with the magic of A/B testing, the game that I see could be a significantly different game from the game that you see, even if we’re playing at the same time!)

We launched a couple of games last week: Wild Ones is a social networking take on Worms, while Tiki Farm is our latest entry into the farm genre. And they’re both a lot of fun, go play them! (And send me lots of goo gun ammo…) I want to talk about Tiki Farm in particular for a while, because it’s managed to work its way into my brain in ways that I didn’t expect. (Aside from its theme song, which I find myself whistling at random moments…)

In typical competing farm games, the main constraint (assuming your goal is to level up and accumulate in-game cash) is the player’s time: you can plow or plant all you want, so as long as you’re willing to put in the time to return to your farm to harvest the crops, you can make quite a bit of in-game money. Actually, that’s not quite true: FarmVille puts a limit on the size of your farm unless which you can only expand by having many friends playing the game or by paying its publisher real money (not in-game money); that’s a pretty clever idea from a virality / profit point of view, but it’s still a fairly coarse-grained cap. (Though, I should add, one which emphasizes that the main constraint is the player’s time: do you really want to spend the time to regularly plow and harvest 60 plots? And of course withering crops are another way in which the player’s time is emphasized as a constraint.)

In contrast, the primary constraint in Tiki Farm is the number of plots available: you start off with only ten or so plots available, and you only get access to two more plots each level. Which left me a bit nonplussed at first—that’s kind of a lame artificial constraint, no?—but as I made it through the initial levels, my opinion of that feature changed. For one thing, I found that not having to worry about picking the size (in terms of plots) of my farm relaxed me: a whole set of conscious and subconscious worries went away. (It’s similar, perhaps to the way I relaxed and started enjoying Deus Ex a lot more once I hit the ammo caps.)

But, for another thing, having such a clear constraint focused my game play in a way that it’s not always focused in other similar games. As the Theory of Constraints teaches us, having a constraint isn’t a bad thing: assuming that your constraint is a sensible one, you can use it to focus your actions, by subordinating the rest of your system to that constraint. What that means in Tiki Farm is that you want to use your other resources in such a way that your primary constraint is being used at its maximum capacity. In other words: you always want to be growing something in those plots.

Which is easy enough to accomplish: the in-game currency (shells) is plentiful enough that you shouldn’t be in serious danger of not being able to buy seeds. In particular, you can sell any crop for more than you paid for it, so as long as you make the habit of replanting as soon as you harvest, you’ll be fine. At which point the question becomes: how frequently do you want to return to the game? Once you’ve made that choice, it’s pretty obvious which crop to choose (yams during my initial burst of power-leveling in the game), and you can get a nice little economy going, periodically earning enough excess profit to let you buy other items to decorate your island.

Or so I thought, until the first time when I wanted to do a purchase that would last me overnight. I’d been planting yams (a 15 minute crop); I wanted to shift to a longer timespan crop, and the obvious candidate was taro root (an 8-hour crop). The problem is that yams sell for 23 shells each, while taro root costs 45 shells; I’d get enough higher profit for taro root to be a better choice overnight, but I couldn’t afford to fill my plots with taro root based on the sales I’d just made! (It didn’t help that I’d recently sunk some of my profits into a very stylish cocktail chair.)

So, basically, working strictly on a throughput basis wasn’t good enough: a changing time investment mix led to a changing crop mix led to a changing fixed cost investment mix. In lean terms: I’d been concentrating on muda (waste, in the form of excess inventory of shells), but all of a sudden I needed to worry about mura (unevenness) instead! To be concrete, it’s a lot easier to plan a straightforward Tiki Farm economy if I’m going to play once a day at the same time (just pick a good 1-day crop and stick to it) than if I’m going to play multiple times during the day and (of course) not play at all while I’m sleeping.

An interesting lean lesson there; I still want to spend some time analyzing the economy to figure out the tradeoffs between inventory, throughput, and time. But without such a clear constraint, I’m not sure these issues would have arisen in a fashion that grabbed me so much.

Though, of course, the constraint isn’t as clear as I’m painting it. For one thing, you use plots to grow crops that you plant from seed; you can also buy trees, however, which bear fruit indefinitely after you plant them. So, in effect, a tree is a plot that you can purchase and that’s particularly inflexible; if you want to grow your economy as quickly as possible, you should siphon off your profits towards trees.

And that’s only if you’re playing solo. If you’re playing with friends, you can give each other gifts; a basic question there is, are trees better gifts or seeds? If somebody gives you a seed, it’s pure profit when it grows, so if you have enough friends giving you seeds, the amount of shells you can make increases vastly. But trees give you shells in perpetuity, so they’re probably still a win in the long-term; then again, you have a fixed island size as a hard constraint, so it’s conceivable that the time scales in question are long enough that trees aren’t as big a win as I think they are. (I certainly won’t turn up my nose at either sort of gift from my friends!)

And, while plot size is a major constraint, it’s not fixed: the number of plots does increase as you level up. This suggests another potential win for seeds: they give you opportunities to get experience points more quickly, earning you more plots. I should actually take the time to understand experience point opportunities better: in particular, do all seeds give you the same XP, or does it vary with the seeds? And, again, the social nature of the game increases the complexity here: for a while, a significant component of my leveling up was spending time clearing bugs off of my friends’ farms.

Speaking of which just what are the implications of helping others’ farms? As far as I can tell, opportunities to help others’ farms in FarmVille are largely artificial (I never see raccoons on my own farm); is that true for Tiki Farm, too, or does clearing bugs off of a friends’ farm have a real effect? If it does, it’s a double-edged one: on the one hand, I’m helping their crops grow faster; but, on the other hand, I’m depriving them of the opportunity to earn XP from clearing their own bugs. I kind of hope that clearing bugs is a real effect; if so, we have a much gentler version of the crop-stealing mechanics that are apparently present in Chinese farming games.

Fun stuff; I hope the game does well, there’s more there than meets the eye. Incidentally, if you’re not already my friend on Facebook, please send me a friends request; just identify yourself as a blog reader if you’re not sure that I know who you are. Or, alternatively, don’t send me a friends request: the only items I post on Facebook are stuff forwarded from my Twitter feed plus Facebook-game-related stuff. So if you want to see the Facebook game items or if you don’t use Twitter, then Facebook is the place to go; otherwise, you’re better off just sticking with following me on Twitter. (If you want my microblogging at all!)

My heartfelt thanks to all of you who contributed to Michael’s and my efforts to gather money to fly Ben to GDC. We raised $935.50 from 40 contributions by the deadline, and a couple other people chipped in right after the widget closed to bring us up to the $1100 goal, making the effort a rousing success.

I am extraordinarily grateful to all of you who contributed; it was a wonderful sign of what this community means to all of us, and I’m sure that Ben will more than repay the trust that you have placed in him. I’m very much looking forward to meeting him in person (along with any of my other blog readers who will be there; I registered for GDC myself earlier this week!) and reading his articles that will come out of this.

I just got called for survey purposes (about the economy, health care, and the like); I thought that it was a bit odd when they asked me if I was a blogger (not just a journalist), but hey, maybe that’s the new best standard? And they seemed happy enough when I said that I generally blog about entertainment topics. At any rate, I was willing to devote five minutes of my time to the cause of statistics.

Or at least I was until I heard the first question: “do you think the country is basically going in the right direction or do you think things are going pretty seriously off track?” Yeah, survey purposes, right.

Time to go e-mail my various representatives, I think, just to provide a bit of a nudge in the direction I want?

Update: I have been convinced by some of my commentors that, at the very least, the title of this post is inappropriate.

I try to write a blog post after every game that I finish playing (or, in this case, take a temporary break from playing), but really: what more do I have to say about Rock Band 2? As Bill Harris put it, it’s “more of a lifestyle than a game”, and it’s a lifestyle that I’ve discussed enough here. Well, actually, I probably haven’t discussed it enough here, but thoughts are fleeting at times, and I’m not coming up with further inspiration at the moment.

If there’s a game I’ve played more this decade, though, I don’t know what it is.

One of my biggest surprises when learning Haskell has been how my typical test-driven development steps fail: it’s easy to write a couple of tests and get them to pass gracelessly, but surprisingly quickly I run into a test that I can’t get to pass without actually being smart, forcing me to make a leap that’s uncomfortably large from my previous position.

I ran into a situation like that last night, and I decided to try to take that big step apart; here’s what I ended up with. The problem in question was exercise 3 on page 84: it told me to print out the first word of each line of its input. My first two tests were as follows:

firstWordsTests =
    TestList["empty" ~: "" @=? firstWords "",
             "one line" ~: "first\n" @=? firstWords "first words\n"]

which I got passing with this implementation:

firstWords "" = ""
firstWords line = head (words line) ++ "\n"

The third test was where I ran into trouble, though:

firstWordsTests =
    TestList["empty" ~: "" @=? firstWords "",
             "one line" ~: "first\n" @=? firstWords "first words\n",
             "two lines" ~: "one\ntwo\n" @=?
                         firstWords "one line\ntwo lines\n"]]

How can I write a pattern which will match the third case? Not at all clear to me, but at least it points out the direction I’m going in: I want to add lines to the test cases until some sort of looping construct falls out. Given that, let’s try to refactor against one red bar in a way that brings out the decomposition into lines that’s latent here.

Fortunately, Haskell has a function lines that transforms a string into a list of the lines making up that string; let’s rewrite firstWords to use it. The smallest step that I managed to come up with to do so was this:

firstWords input = concatFirstWordsOfLineArray (lines input) where
    concatFirstWordsOfLineArray [] = ""
    concatFirstWordsOfLineArray [line] = head (words line) ++ "\n"

Which is a larger step than I’m comfortable with, but at least it’s small enough conceptually that I don’t feel like I’ve leapt into the unknown. I’m not sure what to call this sort of transformation—maybe “Insert Intermediate List”?

(Incidentally, the observant reader will note that this transformation isn’t a refactoring: it preserves the red and green bars, but the nature of the red bar goes from an unexpected result to an exception being thrown. That’s okay with me; what I’m doing is still useful as an implementation pattern. Hmm, maybe I should try writing these transformations up in an Alexandrian style?)

And, after that step, it’s now obvious how to get my test to pass:

firstWords input = concatFirstWordsOfLineArray (lines input) where
    concatFirstWordsOfLineArray [] = ""
    concatFirstWordsOfLineArray [line] = head (words line) ++ "\n"
    concatFirstWordsOfLineArray (line1 : line2 : []) =
        (head (words line1) ++ "\n") ++ (head (words line2) ++ "\n")

At this point, we have some obvious code duplication; Extract Method turns it into

firstWords input = concatFirstWordsOfLineArray (lines input) where
    concatFirstWordsOfLineArray [] = ""
    concatFirstWordsOfLineArray [line] = firstWordLine line
    concatFirstWordsOfLineArray (line1 : line2 : []) =
        firstWordLine line1 ++ firstWordLine line2
    firstWordLine line = head (words line) ++ "\n"

At which point it’s pretty obvious that we’re doing something quite similar to all elements on the list, so we want to transform this into a map plus a subsequent operation. And, in fact, the subsequent operation is concatenating all of the list elements together; keeping that in mind, we do an Insert Intermediate List on the third case, giving us:

firstWords input = concatFirstWordsOfLineArray (lines input) where
    concatFirstWordsOfLineArray [] = ""
    concatFirstWordsOfLineArray [line] = firstWordLine line
    concatFirstWordsOfLineArray (line1 : line2 : []) =
        concat [firstWordLine line1, firstWordLine line2]
    firstWordLine line = head (words line) ++ "\n"

That makes the structure clear for the third branch, and also makes it obvious that we can write the first two branches the same way:

firstWords input = concatFirstWordsOfLineArray (lines input) where
    concatFirstWordsOfLineArray [] = concat []
    concatFirstWordsOfLineArray [line] = concat [firstWordLine line]
    concatFirstWordsOfLineArray (line1 : line2 : []) =
        concat [firstWordLine line1, firstWordLine line2]
    firstWordLine line = head (words line) ++ "\n"

So now we have our map operation:

firstWords input = concatFirstWordsOfLineArray (lines input) where
    concatFirstWordsOfLineArray lines = concat (map firstWordLine lines)
    firstWordLine line = head (words line) ++ "\n"

(These last three steps seem like they should all go together: Extract Identical List Operation?)

Now the code is looking nice (and, in addition, would pass more tests should we choose to write them), and the challenge turns towards expressing it as tersely and clearly as possible. First, Replace Unaltered Parameter with Composition to get:

firstWords = concatFirstWordsOfLineArray . lines where
    concatFirstWordsOfLineArray lines = concat (map firstWordLine lines)
    firstWordLine line = head (words line) ++ "\n"

Do it again (throwing a bit of currying into the mix):

firstWords = concatFirstWordsOfLineArray . lines where
    concatFirstWordsOfLineArray = concat . (map firstWordLine)
    firstWordLine line = head (words line) ++ "\n"

And, by now, concatFirstWordsOfLineArray clearly isn’t pulling its weight, so we Inline Method:

firstWords = (concat . (map firstWordLine) . lines) where
    firstWordLine line = head (words line) ++ "\n"

I still want to make this shorter, which in Haskell land frequently seems to mean using Replace Unaltered Parameter with Composition; to that end, we rewrite the latter definition as

firstWords = concat . (map firstWordLine) . lines where
    firstWordLine line = (++ "\n") . (head (words line))

That lets us turn it into:

firstWords = concat . (map firstWordLine) . lines where
    firstWordLine = (++ "\n") . head . words

at which point we can Inline Method again, and get:

firstWords = concat . (map ((++ "\n") . head . words)) . lines

Which is short, but you have to think a little bit as to what it means; what I’d like to do is find a way to get the unlines function in there, which is a function that takes a list of strings and concatenates them with newlines between. The next step in that direction is to realize that map distributes over function composition; so we Distribute Map, giving us

firstWords = concat . (map (++ "\n")) . (map (head . words)) . lines

and, indeed, the first half of that is exactly unlines:

firstWords = unlines . (map (head . words)) . lines

Phew! The code is now about as terse as I can think of while passing those three tests, and it passes several other new tests that I might think of to boot. And, as a bonus, this version is clearer than any of its predecessors: we split the input into a list of lines (lines), then we grab the first word out of each of those lines (map (head . words)), then we smoosh all of those lines back together (unlines). Though, as Bryan pointed out to me, I forgot to write one test (which I’ll leave as an exercise for the reader), but getting the code to pass that last test was a lot easier in this form than it would have been in forms further up the blog page. (Bryan also had some suggestions for how I might use QuickCheck instead of HUnit to test this, which I hope to be able to follow up over the coming months.)

If this sounds interesting (or if it sounds bizarre but if the idea of learning Haskell sounds interesting despite my peculiar approach), it’s not too late to join the reading group: none of us are moving at a very fast pace, so it shouldn’t be much trouble for a newcomer to catch up.

• How to lose an argument online.
• I’d been thinking for a while that ‘hardcore’ was only useful as a term in a polemic I had no interest in making.
• Three false constraints on game design challenges.
• I’m reluctantly coming to the conclusion that I won’t be able to avoid playing Dragon Age. (But I’ll hold off until after Mass Effect 2…)
• A nice flash game puzzle concept. (Via Chewing Pixels.)
• I had no idea that the roots of integer polynomials made such an interesting picture.
• Ben has made a book out of his Permadeath saga, and it’s wonderful to read.
• A pleasantly sensible list of teamwork skills. (Via @DavidChilcott.)
• Canadian Football fans are kind of weird. (Via @TimBray.)
• The downside of geek social cues. (Via @martinfowler, though Twitter is insisting that I instead credit @sylvanstargazer.)
• I continue to be a 37 Signals fan. (Via @dhh, unsurprisingly.)
• Google has a public DNS server now? That could be useful. (Via @therealfitz.)

I don’t have a lot to say about Professor Layton and the Diabolical Box—it’s a great game (my wife and I both blew through it in a few days, and Miranda also zoomed through most of it), but it adds essentially nothing to the formula created by its predecessor.

One thing that struck me: when you launch the game from a save, it gives you a little cut scene that brings you back into the game world by reminding you what you’ve just done and where you’re going. A nice touch, one that games could adopt more, though perhaps it’s better suited to 2D games than 3D games.

There hasn’t been much blogged about the game, but I did run into a few posts: from the Experience Points Blog, Jorge Albor gives us a review and Scott Juster discusses the main character and the game’s linearity; Chas of Boldstate talks about how the tea-drinking minigame has changed his life.

As I mentioned a couple of months ago, the Big Surf Island expansion expansion to Burnout Paradise got me appreciating the game in a rather more visceral way than I had before then: all the different gameplay options crammed together in one small package hooked me on the game fairly seriously. So I decided to go back and give the main game more of a try, both for fun and to see if I could make sense of it all.

It’s a rather open-ended game; I could potentially keep on playing it indefinitely, but right now I’m playing too many open-ended games rather than too few. (Until a couple of weeks ago, the only games I had in progress were Burnout Paradise, Rock Band 2, and The Beatles: Rock Band, which could easily work together to use up all of my free game-playing time for half a year if I let them.) So I knew that I had to set goals for my Burnout play: clearly I should try to get a Burnout license, but equally clearly I shouldn’t try to get an Elite license, and I should probably throw in some more exploratory goals as well.

While earning my Burnout license, I put a heavy emphasis on burning routes, because I hadn’t completed almost any of them. (In fact, when I started my recent round of play, I’d only unlocked five or so cars from the original game.) And I’m really glad I did: for one thing, on a pure gameplay level, I enjoy them more than the traditional race events. And collecting stuff is always nice, too. But it also game me a feel for the different cars: in particular, doing a road rage event in the higher licenses with an early trick car is a completely different feel from doing that same event with a good aggression car. (And getting a takedown rampage is very satisfying indeed!) I still like to use a good trick car most of the time, and I haven’t yet found much use for speed cars, but I’m glad to have been exposed to the variety.

So that worked well to get me more familiar with the different events and with the different cars. But I wanted to spend time exploring the environment as well: to that end, I decided to try to get 100% completion on Big Surf Island, and to do all the time road rules.

The former brought home the difference between the different discovery objectives. The smash gates are everywhere, giving you lots of little rewards, but finding the last few can be a bit annoying; not too annoying, though, it turns out. (The small size of the island may have helped.) The jumps are much fewer in number; the plus side is that they’re a lot of fun to do, but the down side is that there’s no visual clue as to whether or not you’ve already completed a jump. (Fortunately, I ended up completing all the Big Surf Island jumps while looking for other stuff.) And the billboards are by far the most satisfying of the three: they’re obvious enough that you can locate them all without too much work (though it didn’t hurt that I had Miranda as a spotter while I was driving around), but once you’ve found one, it can take several minutes to figure out the proper approach to it, and a couple more minutes to actually pull off your jump at the correct speed and angle. Which, in the wrong situation, could be frustrating, but somehow that never happened to me.

So finishing Big Surf Island was great. (And unlocking toy cars was a nice bonus!) But I still wanted to delve into the layout of the main game a bit more deeply; doing the time road routes on every road seemed like the best vehicle for that, since it would force me to cross every road on the map.

Which I would normally have assumed that I would already have done, if there weren’t several counters that proved to me otherwise. At this point, I’d done close to a hundred missions, and spent several hours just wandering around during VGHVI multiplayer nights: the map wasn’t that large, surely I’d driven all over it by then, except perhaps for a few cleverly hidden crannies? But no: I hadn’t yet found all the events, even though they’re all located at intersections; I hadn’t found a couple of the drive-throughs; and there was even a car park somewhere that I hadn’t found. (That last still boggles my mind: there aren’t that many, they’re all right there in the city, but I still didn’t find the last one until I had something like 15 road rules left to earn.)

This is an area of the game’s design that I came to appreciate more and more. When you first start playing the game, the events seem somewhat random: you can trigger an event by pulling up to any of over 100 intersections in the city, many of them have you driving to another location, and my initial assumption was that the ending locations were distributed in much the same way that the starting locations were. This turns out not to be the case, though I didn’t realize that until I had put quite a bit of time into the game: in fact, there are only eight final destinations.

One benefit of this is pretty straightforward: the map and its wealth of alternate routes can be overwhelming at first. And having a fixed list of destinations helps you get a grasp on this: you may be starting at a relatively random location (or you may not be—for all I know, the starting locations for events with a fixed destination may be carefully chosen as well), but it doesn’t take too much driving along towards the destination before you start funneling onto a familiar route, which you become more and more familiar with as you play more of the game.

But there’s a flip side to that funneling: there are various routes that are almost never going to be natural paths to take to get to those eight destinations. And this, in turn, leaves surprisingly large areas of the map that you’re less likely to have explored; even with some amount of wandering on your own, you’ll still have several lurking gaps on your map.

And the process of becoming aware of those gaps is brilliant: rather than the game designers overtly telling you what you’ve done and what you haven’t, they simultaneously give you counters that you can use to measure how much is unexplored (events / drive-throughs found) and a game play mechanism that lets you keep track of those areas one by one if you take the effort to do so (time road rules). Also note that ticking off the latter requires you to complete a task, not just to be present in that location: this not only made the ticking off more interesting than it would have been otherwise but also served as a further masking effect, hiding the fact that there were locations to tick off (as opposed to actions to tick off that happened to be at those locations) until I’d put quite a bit of time into the game.

The result is the most subtly unfolding open-world game I’ve ever seen: on the one hand, the entire map is open right from the start (no bridges to magically get repaired), on the other hand you’re always finding that there are more areas for you to explore than you realized, and on the third hand you’re given gentle guidance in that exploration, you’re not just dropped in a world with a map that you can’t even color in yourself and told to have fun.

So the time road rules were quietly awesome from a game construction point of view; as a bonus, they were quite a bit of fun as well. I particularly liked the range of times (sub-10-seconds all the way to 2-minutes-plus) and of difficulty levels. Also, doing the road rules (and driving back if I spotted something interesting) revealed that the exploration discoverables were distributed in a fair manner across the map: in particular, without making an exhaustive effort to search them out, I’ve gone through all the smash gates in a couple of the map regions, and 391 of the 400 in the game overall.

A great game, and I could easily keep on playing for quite a bit longer: I’m so close on the discoverables that it’s very tempting to finish them off (and I know I would have a lot of fun on the billboards), there are still quite a few more burning routes for me to do, and doing some googling while writing this blog post reminds me that there’s bike-specific content that I haven’t done. But there are quite a few games out there that I really want to play, starting with the sequel to last year’s game-of-the-year. So I’m giving the game a pause for now, stopping to collect my thoughts one more time.

Incidentally, as part of the prep work for this blog post, I searched for what other bloggers had said about Burnout Paradise. There’s a fair amount of good stuff, and I’ll include links to what I turned up at the bottom of this post, but there’s one particular dialogue that interested me. Mitch Krpata posted a trio of posts on the subject; he and Michael Abbott then discussed the game on a podcast episode. And reading/listening to them, my first reaction was: how can a couple of people whose opinions I generally respect a lot be so wrong on this game? They treat it as a racing game with open-world elements grafted on in a faddish and misguided manner; Mitch, for example, goes on about how the inclusion of “hidden collectables” (the smash gates, billboards, etc.) is “obligatory inclusion” of items which are “anithetical to the Burnout ideal” (because they “reward stopping”) and “worse still, … [don’t] actually have an impact on gameplay.”

That last quote in particular reveals the lens that Mitch was looking at the game through, equating gameplay with races. In fact, though, there’s quite a lot more gameplay that you can do; the list that I came up with is as follows:

• Races.
• Road rage events.
• Stunt runs.
• Mixtures between the above, e.g. marked man events.
• Online variants of the above.
• Unlocking cars, via three different mechanisms.
• Discovering objects/actions strategically placed through the game. (Smash gates, jumps, drive-throughs, car parks.)
• Discovering billboards and figure out how to smash them.
• Systematically exploring all the roads in the game.
• Showtime mode.
• Objective-based online gameplay.
• Exploring sandbox areas of the map that are particularly well suited to a specific style of play.
• Just drive around the map seeing what there is to see.

That’s a lot of stuff to do; and I personally found each item in that list to be rewarding on its own merits, rather than to be judged solely as to how it helps or fails to help another row in the list.

But, having said that, and assuming you accept my claim that Michael and Mitch were coming at the game from a needlessly limiting perspective, I think their having done so is fairly reasonable. I don’t know if Mitch changed his mind on the game, but Michael did a complete about-face on it: it just took him four months to reach that point. And, while it’s hard for me to reach back into my memories of first playing the game, I’m fairly sure that I started off with opinions a lot closer to Mitch’s than to my current state of mind: while I’d never played a Burnout game before, I’d played a bunch of racing games, so the events were what I focused on, and the races were my priority within those events.

And it took me quite a while to get over that; I doubt, if Big Surf Island hadn’t come along, that I would have chosen to invest the time in the game that I needed to get to where I appreciated the range of what it offered for me. Maybe somebody without prior racing game experience (or somebody who had racing game experience but didn’t like them) would be more open to the gameplay possibilities than I was; but I suspect that Michael and I aren’t alone among traditional gamers in needing time to see what’s there in front of us. (In fact, here’s another example!)

Doing something new is hard for developers, and helping players appreciate those new aspects is doubly hard; I’m grateful to Criterion for the work they’ve put in changing the game and making it easier to appreciate the variety that is there. And, while I’m taking a break from the game now, I wouldn’t be at all surprised if, in a month or three, I find myself taking a spin through downtown Paradise City again trying to find all the billboards, smash gates, and jumps, or taking the bikes for a more serious rice, or trying to improve my stunt run scores.

Some posts that other people have written on the game; my apologies for not touching on most of them:

• The three articles by Mitch Krpata and the two Brainy Gamer podcast episodes that I mentioned above.
• N’Gai Croal and Stephen Totilo devoted a Vs. Mode to the game
• Iroquois Pliskin of Versus CluClu Land on how BP simultaneously solves problems that open-world games have and problems that racing games have.
• Sean Beanland of Finding the Fun also took a while to get hooked on the game; he returned later with a discussion of how the game handles difficulty.
• Bonnie Ruberg of Heroine Sheik calls it “a driving game for girls”.
• Matthew Gallant of The Quixotic Engineer on Restarting, Downtime, and Variety.
• Jebus of Noise Tanks! on Criterion’s continued support for the game; Michael Abbott also lauded Criterion for this.
• Nelson Minar on in-game advertising; remember the Obama ads?
• Chris Dahlen of Save the Robot talks about The Empty Streets of Paradise City.

I would like to thank everybody who has contributed so far to our effort to fly Ben to GDC; it’s been a week, and we’re halfway there! ($557.50 out of $1100, as of this writing, to be specific.) Of course, the flip side is that we still have over five hundred dollars to go; we’ll find the money somehow, but it would be easier if we had more contributions.

So I have two requests. First: if you were planning to donate but hadn’t gotten around to doing so, please let this serve as a reminder. Second: if you have already donated, could you please publicize this somehow? (E.g. by mentioning it on twitter.) We’d really appreciate it. And, again, thanks to everybody who has donated already or who is prompted by this to do so.

• Gerald Weinberg is, sadly, in poor health.

• Never tried doing Rock Band vocals this way… (Takes 15 seconds or so to actually start.)

  (Via @dan_schmidt.)

• R.I.P., Brother Blue. (Via @scottros.)
• The difference between motion and action. (Via @harlan_knight.)
• An unforeseen design problem. (Via @shawnr.)
• Nice perspective on slow programming languages.
• Glad to see non-Miyazaki Ghibli getting some love.
• Some great pictures on here. (Via Dubious Quality.)

I’m sure that most of the readers of my blog are familiar with Ben Abraham. He’s been a key figure in the video game blogging community for the last couple of years, both through his own blog (most recently with his permadeath series) and his tireless participation in discussions in other blogs and fora (I’ve certainly enjoyed his Vintage Game Club contributions). Earlier this year, he founded Critical Distance, not to act as a home for his own writings but to highlight others’ writings, to enrich our discussions by making us aware of thoughts and works that we would otherwise have missed.

I had a great time earlier this year in the heady mix of conversations and ideas that is the Game Developer’s Conference; but, during and after that time, I kept wishing that Ben had been there, because I really would have liked to hear his perspective on the event, to hear about what he would have dug up that I missed in all the hubbub. And, chatting with Michael Abbott recently, I found that he felt the same way.

So Michael and I have decided to draft Ben to serve as a sort of roving reporter for GDC! And in a happy turn of events, Gamasutra has graciously consented to arrange for him to have access to the event: as part of the agreement that is allowing them to publish Ben’s This Week in Videogame Blogging series, they are kindly providing a GDC 2010 all-access entry pass for Ben.

Which gets the major hurdle out of the way; but there remains a rather large ocean between Ben and GDC. And this is where I would like to enlist your assistance, because intercontinental plane flights aren’t cheap. If you’ve appreciated Ben’s nurturing of our community the way I have, please use the widget below to help defray his plane flight expenses. If you’ll chip in the price of the last video game you bought, we’ll easily be able to pay for his plane flight; if that’s too much, smaller amounts are also welcome. All the money we gather will go directly to Ben’s GDC expenses (except for the credit card processing fees that PayPal deducts); I’d also appreciate people putting this widget on their blog (click on its ‘Copy’ tab), or publicizing this on twitter.

We thank you in advance for all of your help.

(Edit: The values the widget gives below are broken; in fact, rather frustratingly, as I type this it shows less money having been contributed now than it was showing this afternoon! Thanks for those of you who have contributed so far; we’re up to $160 as I type this, which is certainly an encouraging start!)

(Edit 2: Chipin seems to be doing something wrong with their caching headers, or something, because emptying the cache seems to fix the issue. We’re up to $428 now! (now = morning of 11/19))

(Side note: the widget is acting a little funny; there’s normally a 5-minute delay before its total gets updated, but I’m still waiting on one contribution to show up. I’ve got an e-mail in to ChipIn’s support; in the mean time, rest assured that, if you’ve clicked on the widget and told PayPal to send money, it goes directly into a PayPal account I’ve set up for this purpose, whether or not the widget updates properly.)

I read a fair amount of blogs, and I listen to a fair amount of podcasts. In fact, one of the reasons why I’m walking to work now instead of driving is so that my commute will remain reasonably long, and hence I’ll continue to have enough time to listen to podcasts! And I spend a good-sized chunk of most weekday evenings reading blogs.

But the chinks in my system have been showing. As we know from queueing theory, if you keep your queues too close to their average capacity, then, when something goes wrong, things go out of control pretty fast. And, a couple of weeks ago, I had a cold that dragged on for a while; that, combined with some evening events that I had to drive to, meant that I didn’t walk to work for two weeks straight. The result was that I now have way too many podcasts to listen to.

Which has caused me to re-evaluate my behavior. One question that it raises: why do I feel that I have to listen to those podcasts? Just what does it mean to me to be subscribed to a podcast? My meaning had been that I intended to listen to every episode of that podcast; as I’m discovering, that’s a significant commitment, enough so that I should make it consciously instead of through inertia.

And, now that I think about it, I’m realizing that that compulsion conflicts with one of my planning rules. I try to structure my life so that, as much as possible, I’m doing what I’m most interested in at any given moment; the mere existence of subscriptions encourage me to not even think about that question. And, to the extent that I do think about the question, it biases my results: for example, it makes it less likely for me to listen to CDs, because I have to fit them in between my podcast subscriptions.

Don’t get my wrong, I really like the podcasts that I’m subscribed to. Having said that, if I didn’t have time to listen to, say, In Our Time last week, is there any reason for me to make a point of finding time to listen to last week’s episode? Stated that way, my behavior is a bit silly: there are no end of episodes that were made before I started to subscribe to the podcast; I haven’t listened to them, so what makes the more recent episodes so special?

And that’s not an isolated example. Looking through what I have in iTunes, most of the podcasts that I’m subscribed to are ones that I don’t really have a reason to commit to listening to every episode. So, while I’m not unsubscribing from any of them, I’m also going to pause on listening to several of them while I catch up on other listening, and I’m unchecking the box that will cause them to be synced to my iPhone until I’m more confident that I want to spend time listening to them.

Having said that, I’m not completely giving up on my old conception of subscriptions. In particular, I really do like JapanesePod101, This American Life, and Planet Money enough to want to listen to every episode. (There are other podcasts that I also plan to listen to every episode of, but those three are the only ones that regularly come out at least once a week.) That’s about three hours a week of listening; that will leave me with quite a bit of unscheduled listening time where I’ll be able to explore more widely than I have been in the past.

My blog reading has gotten out of control a little more subtly: it’s not that I don’t have enough time to read the blogs in my feed reader, it’s more that doing so eats up enough of my time that I find it hard to get a solid hour to really concentrate. So, if I catch up on my reading on some evening, then doing so rarely leaves me able to, say, write a blog post of my own or play a game or read a book. (The latter of which I’m not doing nearly enough these days!) So, while I am spending too much time reading blogs, it’s also interfering with my time usage out of promotion to the total time I’m spending on it. Also, constantly feeling like I’m under pressure to clear out my reader means that I don’t always take the time to really think about longer form posts, posts that are saying something new to me. (Which is more than a bit ironic, given the average length of my own posts; I’m very grateful to those of you who actually read these!)

This is pretty screwed up: I need time to think and do, to not always be hitting the ‘j’ button. Fortunately, phrasing my behavior that way makes the next step pretty clear: I should cut out larger chunks of free time explicitly by timeboxing my blog reading. Concretely, I’m going to experiment with only reading blogs three days a week: Tuesdays, Thursdays, and once on the weekend. And I’ll try to clear out my feed reader every time: if I don’t make it through my feeds, that’s a sign that either I have to unsubscribe from feeds to fit my time budget or I have to get used to the “mark all as read” button.

It’s an experiment. But I need to make more time for myself; I also need to make more time that I can spend with primary experiences (games, music, books), instead of secondary reflections. I’m overcommitted right now: I need to rediscover the void in my life, or at least a richer texture.

A selection from the Pomodoro Technique book that has, for some reason, stuck with me recently:

According to the work of Bergson and Minkowski, two profoundly interrelated aspects seem to coexist with reference to time:

• Becoming. An abstract, dimensional aspect of time, which gives rise to the habit of measuring time (seconds, minutes, hours); the idea of representing time on an axis, as we would spatial dimensions; the concept of the duration of an event (the distance between two points on the temporal axis); the idea of being late (once again the distance between two points on the temporal axis).
• The succession of events. A concrete aspect of temporal order: we wake up, we take a shower, we have breakfast, we study, we have lunch, we have a nap, we play, we eat, and we go to bed. Children come to have this notion of time before they develop the idea of abstract time which passes regardless of the events that take place.

Of these two aspects, it is becoming that generates anxiety – it is, by nature, elusive, indefinite, infinite: time passes, slips away, moves toward the future. If we try to measure ourselves against the passage of time, we feel inadequate, oppressed, enslaved, defeated, more and more with every second that goes by. We lose our élan vital, our vital contact, which enables us to accomplish things. “Two hours have gone by and I’m still not done; two days have gone by and I’m still not done.” In a moment of weakness, the purpose of the activity at hand is often no longer even clear. The succession of events, instead, seems to be the less anxiety-ridden aspect of time. At times it may even represent the regular succession of activity, a calm-inducing rhythm.

When I started doing GTD, I kept my next action list on a paper notebook in my pocket. (Or, at work, on a pad of paper on my desk.) I did this partly out of a certain technological conservatism and partly because, at the time, I didn’t have any suitable electronic devices that were always with me. The latter changed when I got my iPod Touch (combined with my migrating more and more to Macs as my primary computing platforms, giving me a location to sync with that I would reliably use daily); and I found that, as my paper lists aged, it became increasingly hard to pick out the few undone items on a page amid the sea of items that I’d finished.

So I used my job change as an excuse to try switching my work next action lists to something computerized. I took a look at Things, OmniFocus, and The Hit List; The Hit List didn’t have an iPhone counterpart, OmniFocus seemed a bit heavyweight, so I gave Things a try.

And I ended up rather liking it. At first, I was somewhat taken aback by not being able to map the (to me quite important) GTD concept of waiting items directly to it. But once I decided not to get hung up on that, I enjoyed the program: it’s easy to use, it’s great to be able to pull up a quick entry box to get ideas out of your mind, and the clutter problem that I’d been having with my paper system has completely disappeared.

Things also has one very nice feature that isn’t a standard part of GTD (though it is part of the pomodoro technique): it encourages you to flag actions as ones you’re planning to do today. For several months, I’d been making a tentatively daily plan at the start of the day at work, and I really like the results: it means that I rarely have to refer to my entire next action list during the day, and it makes it easier for me to take care of items that are important but not urgent or ideas that, for some reason, my mind is resisting doing.

In fact, that last point is important enough that I’ll go on a bit of a digression on it. (Partly in hopes that I’ll figure something out, because I don’t claim to have all the answers here.) Too much planning is bad: plans go stale as reality marches on without them (and, in particular, unexpected events can cause priorities to shift quite quickly); and planning takes time, which has a real cost. But avoiding planning entirely isn’t good, either: our lives are too complicated for us to always be able to make the best choices even about a narrow area on the fly, and without plans, it’s too easy to get buffeted around, chasing the urgent over the important.

So you need to balance these two forces. (Or, better yet, come up with a synthesis.) GTD’s next action concept is a great step in that direction: you do just enough planning in advance to be able to make a bit of concrete progress in a project, but you don’t overplan by committing to when you’ll take that next action or by committing to the details of later actions on that project.

That one useful way to ease to this tension: you focus yourself on a single project and are a bit vague about time. But today lists provide an orthogonal easing of tension, this time focusing on a single slice of time but looking across projects. To get them to work, you make sure to have a few minutes of quiet at the start of the day (when walking Zippy when I get up, after checking my e-mail when I show up at work) when you can look across the existing list of next actions on all of your projects and see what might be a good idea to work on next. But you don’t commit to actually doing all of that (surprises can always arise), and if you don’t finish an item on one day’s list, it’s just fine to remove it from the today list when the next morning rolls around. Done well, it only takes a few minutes, it makes it very easy to figure out what to do next, and it helps you make progress across a range of important projects.

So, once the evaluation period ended, I paid for a copy of Things, installed it at both home and work, and bought the iPhone app as well. (Which I sync with my home copy.) And I’m quite happy with my choice; aside from the reasons mentioned above, the iPhone version is quite usable, and it’s made my weekly reviews at home go a good deal more smoothly, for reasons that are idiosyncratic enough to not be worth elaborating on here. It’s not a perfect piece of software—I’m still not convinced by its handing of waiting items, and some of the concepts that it has aren’t sufficiently orthogonal (e.g. there are actions you can do on standalone tasks that you can’t do for tasks that are part of projects)—but it works more than well enough for me.

It’s also changed my GTD usage. For one thing, it has the notion of Areas of Responsibility; that’s a part of GTD that I’d never spent much time with, but once I had software that mentioned it, I started thinking about it a bit more. And I realized that some things that I’d been thinking about as projects (e.g. read books, take care of tasks around the house) are actually areas of responsibility, and are best managed as such. The other thing is its use of tags: that’s the way Things handles GTD contexts, but putting a tag on an item you’re creating on the iPhone version adds just enough friction to be a slight annoyance. And, once I realized that, I also realized that, in fact, GTD contexts are never useful to me! (I’m not saying they’re a bad thing, just that my life isn’t complicated enough in ways where they are helpful.) So now I’m moving away from using tags as GTD contexts, instead just keeping around a few special-purpose tags with other meanings.

I’m very happy with the results, and plan to keep this system for the forseeable future. I still have my paper notebook around, e.g. to take notes about blog posts, but all in all moving the portable part of my system to my phone and the non-portable part to a piece of dedicated software is working nicely.

So far, the talk I attended at Agile 2009 that has had the most impact on me was Renzo Borgatti’s talk on the pomodoro technique:

I’d heard a bit about the technique before, enough to know that it tells you to break your work up into 25 minute chunks and to try to really focus during those chunks, avoiding distractions and interruptions. It turns out that there’s more to the technique than that, however: it gives guidelines about breaks between chunks (3-5 minute breaks normally, longer breaks after every four chunks), there’s a whole planning and estimating mechanic you’re supposed to use with it (starting each day estimating your tasks in terms of pomodori, and reviewing your day at the end), and there are also mechanisms for tracking and actively tabling your interruptions.

What really sold me about the talk, though, was that, 25 minutes into it, a timer went off, and we all took a break for a few minutes! We took another break 25 minutes later; I think that it’s a great idea to break a 90-minute presentation into three chunks like that. As it happened, I’d been feeling over the course of the conference that I hadn’t been getting enough done over the evenings; so, that evening, I decided to give the pomodoro technique a try, and really focus on things for 25 minutes at a time.

Which turned out to work remarkably well: I probably got as much done that evening of the conference as in the other four evenings put together. Despite which I didn’t use the technique over the next month or so: I was pairing on a project in my last weeks at Sun, we were doing quite a good job concentrating as it was, and it didn’t seem to be a good time to introduce something new.

When I started work at Playdom, though, I picked up the technique again, and I’m glad I did. When I describe the technique to other people, one frequent concern that comes up is: doesn’t the timer going off interrupt your flow? For me, though, my problem is almost always too little flow rather than too much; and the pomodoro technique works great with that. I can stop myself from wandering for 25 minutes if I try, and I know I have a little release valve coming up in the not-too-distant future if I need one. And it occasionally happens that I’m banging my head against something unproductively and need the cooling off period between pomodoros to get myself thinking that I really should take a different approach. Also, it can be a big help if the next task seems frightening in some way: you’re not faced with wandering through something unknown and probably unpleasant for an unbounded amount of time, you’re faced with spending 25 minutes trying to shed a bit more light on your current situation, which is a much more palatable prospect. And I think the explicit guidelines for both shorter and longer breaks are helpful for me.

I’ve tried other aspects of the technique as well; they have had benefits, but I’m less sold on them. The planning period is a helpful reminder that I should think about all the different things that I’m considering working on (my next actions for my various projects, in GTD speak), and pomodoros give me permission to carve out a bounded amount of time to work on tasks that are important but not urgent. Having said that, I haven’t found much of a benefit from the actual process of estimating how many pomodoros a task will take at the start of the day: it doesn’t seem to be solving any problems that I have, and I have other mechanisms for telling myself when I’m getting stuck. (E.g. if I’m not doing multiple git commits over the course of a pomodoro, that might be a sign that things are going well.) So I’m stopping that for the time being.

And there’s one aspect of the pomodoro technique that I’m actively dubious about. One of the core rules is that the pomodoro is indivisible: if you don’t spend the whole 25 minutes working on what you planned, then it doesn’t count as a pomodoro, and you’re strongly encouraged to have as many pomodoros count as possible. There’s a bit of wiggle room here—if your plan at the start of the day has tasks that you think will take less than one pomodoro, then you can combine multiple of them in your plan to make a single pomodoro, and if you finish a task within the first five minutes of a pomodoro, then you’re encouraged to cancel the pomodoro, with the feeling that it was “really” finished in the last pomodoro. If you go beyond the first five minutes, though, you’re supposed to stick it out until the timer rings: in particular, the technique recommends that you spend spare time overlearning, delving into the area in question more deeply than you would otherwise.

Don’t get me wrong, overlearning is a great idea: it’s a similar philosophy to always doing a bit of refactoring once you’ve got your code working. Except that the pomodoro philosophy is different: you don’t always do it, you only do it if there’s time left on your pomodoro, and the amount of overlearning you should do is proportional to the time left. And that just seems bizarre to me.

Take this blog post, for example: I have a pomodoro timer running as I type this. If the timer goes off when I’ve got it done but not properly edited, I don’t want the pomodoro technique encouraging me to hit publish so that I won’t have a big gap to fill in my next pomodoro. After I’ve hit the publish button, probably a bit of overlearning wouldn’t be a bad idea—e.g. this blog post is suggesting an idea for another blog post I could write, so maybe I’ll take some notes on that. But that sounds like a good idea no matter how much time is left on the pomodoro; and those notes will probably take about 5 minutes, so what am I supposed to do if I turn out to have 15 minutes left on my timer when I hit the publish button?

So that doesn’t make much sense to me. The result is that I’m not feeling any guilt about either canceling a pomodoro if I finish a task in the middle of one or about not canceling the pomodoro and launching into a second task without a break in the same pomodoro. (Hmm, I probably should have a preference for one or the other of those solutions, maybe the former?)

But the core idea seems sound, and many of the surrounding ideas have seeds of something that I quite like (e.g. the concept of overlearning), even if I’m not convinced by their details.

Some resources I’ve found useful:

• The main pomodoro technique site. In particular, it contains a 45-page PDF book giving more details into the technique.
• Pomodoro Technique Illustrated. I haven’t read the final version, but the author had a beta version on his web site for a while, and I quite liked it.
• The pomodoro timer I’m using on my Mac.

• Michael Feathers on testable Java. Good advice, that is of course relevant far beyond Java.
• Quite the Venn diagram. (Via @kateri_t.)

• James Paul Gee on games and teaching.

  (Via @HackerChick.) Lots to think about here; I hope the VGHVI folks can help me figure it out.

• A remarkable meandering about games, genres, Japan, and countless other things. (Via @stephentotilo.)
• Thoughts on the meaning of maturity. (Via @markhneedham.)
• Great quote from Jenova Chen.
• I wasn’t expecting to be so interested in Uncharted 2, but there’s clearly a lot there.
• Cool use of mosaic images. (Via Kelley Eskridge.)
• Yeah, why don’t games have cooldown periods at the end? (*sob* Shenmue 2 *sob*.)
• Asterix is turning 50!
• For whatever reason, I particularly liked this Questionable Content.
• Not sure yet what I think about Google Wave, but this opened my eyes a bit.

I was excited that the Vintage Game Club chose Thief as its eighth game. I’ve never had a very good relation with stealth games (or stealth segments/aspects of non-stealth games); but I’ve heard enough good about Thief (especially from Justin Keverne) to make me cautiously optimistic that I’d like the genre more when I saw it done right.

Which didn’t work out so well at first: aside from my running into slightly more hardware issues with it than with other PC games we’ve played, I found myself spending most of the first couple of levels alternating between waiting, getting caught, and reloading. I didn’t feel a huge sense of accomplishment when making it past obstacles, either, and combining this with my worries about ever using limited inventory meant that I wasn’t having much fun.

One advantage of the VGC, however, is that it’s taught me something about my own play styles. And my early Thief problems reminded my of my early Deus Ex experiences. In that game, I started out frustrated by stealth and by inventory restrictions; as the latter eased, though, I found myself more confident with the range of options at my disposal, and rather enjoyed most of the game. So, combining those memories with other’s claims that the proper way to play to play Thief is to figure out how to actively manipulate your environment, I decided to try to consciously expand my search for options when dealing with obstacles and to be more generous with the tools in my inventory.

Which I dutifully tried to do for the next couple of levels. And, indeed, I enjoyed them more, but not for that reason: I would be proud of myself for using a water arrow to put out a light in an upcoming intersection, but then when I went through it a guard turned out not to be anywhere nearby! Instead, I just had an easier time parsing the levels and knocking out guards.

And then I hit the Thieves’ Guild, the first of the Thief Gold levels. The first section or two was okay, but then I found myself going in circles for ages on end; that was partly my fault, but not entirely, and when I got past that, the game gave me hints that there was quite a bit left to do in the level. I took a break for dinner; after dinner, I asked myself, “is this really what I most want to be doing right now?” And the answer came back that, no, I’d rather spend my time elsewhere.

So I stopped. And I’m glad I did: judging from the discussion in the VGC forums, I would have found the rest of the level quite frustrating, and I’m confident that I put enough effort into the game as a whole that it wasn’t about to magically click for me. (Plus, this frees up time that I can use to learn Haskell.)

I’m not going to say Thief is a bad game or anything; but its style unfortunately ran into several of my personal mental quirks. (Most notably, when given a choice between paralysis and imperfection, I have a bad habit of choosing the former; this game lets me do that in more than one way.) And there are some unfortunate misfits between it and my living situation: the amount of time that I can spend playing video games is fairly limited, and when I play PC games, I have to isolate myself in a room away from my family and play them in a VirtualBox installation that has both sound and control quirks. Also, if there’s anything I’ve learned from the VGC, it’s that even quite good games from the 90’s made design choices that are more than capable of turning away video game devotees a decade later.

I do wish my experiences had led to a better appreciation of the stealth genre, though. (Or, alternatively, a more cogent understanding of the flaws of the genre.) And it makes me sad to have not seen a VGC game through the end, though I suppose that had to come eventually.

I’ve been working at Playdom for about a month now, and I’ve thoroughly enjoyed it so far. If any of my readers think it might be an interesting place to work as well, I wanted to point out that we’re hiring. (In a fairly big way, as the list of positions suggests.) Feel free to ask me directly if you have any questions or want me to pass your resume along; you can also apply through the web site.

For its seventh game, the Vintage Game Club chose The Legend of Zelda: Majora’s Mask. Which I was really excited about: aside from being a Zelda fan in general, I was curious to see if my memory of the sidequests held up. (Margaret Robinson’s GDC talk was an influence here.)

The short answer: yes and no. For those who aren’t familiar with the game: when you start the game, the world will end in three days, so you’re constantly looping back in time to the beginning of that period. This means that you’re constantly returning to the central town, and seeing the same people doing the same actions at the same times; this is reinforced by a notebook you acquire, the Bombers’ Notebook, which lists people who need help and the days/times at which you can help them.

And, indeed, checking off Bombers’ Notebook tasks was probably my favorite part of the game. But the problem is: there just aren’t that many of them, and you can get a lot of them done on a single cycle. So I probably had a third of the tasks done before I’d ventured out of town for the first time; another nice batch opened up after I finished the second dungeon, but in general I didn’t spend nearly as much time with the notebook as I’d liked.

The Kafei/Anju plot is the crown jewel of the notebook, weaving together several townspeople’s requests; but I made it almost to the end of the plot on my first full cycle in town (possibly aided by my dim memories of playing the game when it came out, I’m not sure I made it so far so quickly last time), and I knew I wasn’t going to be able to do the last part until right before the end of the game, putting quite a damper on my momentum. And, by the time I did get around to doing the last part, I was annoyed enough at the game’s requiring you to replay significant chunks if you miss a time slot that I didn’t take any chances: rather than trying to figure it all out again myself, I looked in a FAQ to make sure I wasn’t going too far off course. So, doubtless largely because of that, the experience wasn’t as fulfilling as I would have hoped. Which, to be sure, is partially my fault; but the game also throws a timed block-pushing puzzle at you in a context where, if you fail, it will take half an hour to get back to your current state! I can’t imagine art works in other media putting a barrier in front of you like that to get the emotional impact out of the work; I don’t think it was the right choice here, either.

Actually, my favorite notebook sidequest this time was one that I’d completely forgotten about. There’s a postman in the town who is constantly running around delivering mail. It turns out that, beneath his tireless worker facade, he’s terrified by the moon coming down from the sky, and that his overdeveloped sense of duty is the only thing keeping him from getting as far away as he possibly can. And you save him from this by, on the very last night, waking him up to deliver an urgent piece of mail to somebody who has the authority to tell him that, yes, he can and should get the hell out of there.

So: the notebook is a great idea, but it’s minor enough in terms of time spent that most of my feelings about the game came from elsewhere. Which raises the question: how does the time loop affect that?

Unfortunately, the effects of the time loop on your progress through the rest of the game is almost exclusively either neutral or negative. The neutral far outweighs the negative, and the negatives are mostly small, but I ended up liking the game less than I expected because of this.

I’d remembered that your consumables went away at the end of each time loop. In general, this isn’t a big deal: money and arrows are easy to come by, and the fact that you can optionally deposit money in the bank and that chests are restocked each loop means that the money situation in particular isn’t bad at all. Though I was annoyed by consumables disappearing on one or two occasions: I was actively excited to go explore one of the spider houses only to discover that I needed to go somewhere else and buy some magic beans first, which rather deflated my enthusiasm. And, in general, having to warp back and forth collecting fairies before venturing into a dungeon is a waste of time. Still, a minor annoyance all things considered.

What is a less minor annoyance is that the dungeon state resets on each loop. So woe be unto the player who starts a dungeon late in the loop and isn’t able to finish it in time! Fortunately, you’ll only make that mistake once at most; and the game’s designers put warp points at the entrance to each dungeon, making it easy to get to the mouth of the dungeon, loop back in time, and then play through the dungeon.

But the main boss isn’t the only thing to do in a dungeon: there are fifteen fairies sprinkled throughout each dungeon. In a normal game, I’d be happy to find most of the fairies on my first trip through, go and beat the boss, and then come back some other time, wandering through the unlocked doors of the dungeon at my leisure, to grab the rest of them. But the time loop makes that impossible: if I don’t get all the fairies in a single loop, then I’ll have to go through the whole dungeon solving every puzzle again when I want to get them all! (And the benefits from getting them all are pretty substantial, too, except for the last dungeon.) Which, again, turns what could be a pleasant challenge into a reason to go running to gamefaqs when things get at all tricky.

Don’t get me wrong: I still enjoyed the dungeons, still enjoyed the main quest line. (Though quite a few VGC members didn’t—I was surprised by how many people dropped out over the course of the game.) But the game does put some structural barriers in the way of that enjoyment.

And then there are the little touches. In Ocarina, it was the music; there’s nothing in this game like that (in particular, most of the new ocarina music isn’t very good), but I’d completely forgotten the giants who appear after each dungeon. And they’re wonderful: these huge melancholy figures shrouded in mist with haunting music playing. Also, the tree in front of the final save-the-world battle was very soothing, grounding, refreshing. (Is there some archetypal game with a tree on a hill like that that both Majora’s Mask and Flower were borrowing from?)

And, when all is said and done: it’s still a Zelda game and a noble experiment, and those are both very good things. But, like many of the most productive experiments, its value comes as much from the hypothesis that are found wanting as the hypothesis that it supports.

Early in the summer I started going through Real World Haskell; unfortunately, conferences and job changes and other programming side projects kept me busy enough that I stopped reading it after a few chapters. That’s calmed down now; and, conveniently, a friend of mine got a copy recently and some others also expressed interest in it.

So we’re forming a book club. And I figured a few of my readers might be curious about the language as well. If you fall into that bucket, let me know and I’ll add you to the mailing list.