malvasia bianca

• I’m kind of thinking I’m not doing nearly enough to minimize waste. (Via @littleidea.)
• Playing a bigger game. (Via @DianaOfPortland.)
• Luck as a skill. (Via @superkiy.)
• A good list of tech blogs.
• This round’s Pink Tentacle link is an anatomy of folk monsters.

• Magnetic Ink:

  (Via Dubious Quality.)

• And on (rather than just from) Dubious Quality we also have a four part series going through the Beatles’ albums.
• Speaking of which, Heroine Sheik talks about Beatles: Rock Band and the female gaze.

• Some videos on the power of play:

  (Via Evolving Excellence.)

• High anxiety.

In a recent podcast, Justin Keverne talked about how it was odd that we define genre in video games almost exclusively in terms of what you do, whereas in other media genre is linked more with the themes that are under consideration in the works. I’m still not sure what I think about this (and, indeed, poking around a bit has just brought home how little I understand the concept of genre; incidentally, CDC podcast episode 4 also had some interesting things to say on the topic), but I do tend to agree that the notion that, say, “first-person shooter” defines a genre is a pretty peculiar one. As Justin pointed out, think how odd it would be to talk about “single-camera TV shows” versus “three-camera TV shows”!

Which got me wondering: what differences are our conceptions of video game genre blinding us to? What are the video games that we think of as being part of the same genre (because of their shared mechanics), while cutting across quite different areas of the theme and design space in ways other than their mechanics?

I’ve been thinking about this recently because of the Beatles game. Which I adore, as do many others; some people, however, even people who are as big Rock Band fans as I am, are less impressed. It generally comes down to the Beatles’ music not being to their taste; if you combine that with the gameplay being in many ways identical to earlier Rock Band iterations, then of course you’d prefer the wider musical variety in the earlier games.

Having said that, however, The Beatles: Rock Band isn’t quite the same as a reskinned Rock Band 2. Some differences:

• The songs are (almost) all unlocked from the beginning.
• Which doesn’t mean that there aren’t unlockables: you can unlock pictures and other historical artifacts.
• If you play through the game in its story-based mode, you encounter the songs in chronological order rather than a difficulty-based order.
• There are fewer ways in which your play affect the music that is played. (E.g. no drum free play to activate star power.)
• On the easiest setting (which is the default), you can’t fail out of a song.
• You can’t customize your avatar.
• Each song has custom artwork, custom animations.

And these are not random differences or a collection of isolated refinements: they all point in the direction of moving the game away from focusing on players’ generic mastery of techniques and towards a focus on the Beatles’ music and their surrounding history. I’ll even claim that the game’s achievements show this difference: the achievements have moved away from generic gameplay accomplishments and towards achievements that get you focusing on individual songs, and even on techniques within those songs. (I’m thinking of the hammer-on/pull-off achievements for Dear Prudence and Octopus’s Garden; or the achievements for double-fab and triple-fab singing, which will lead you to appreciate just how differently the harmonies play out in different songs.)

The picture that I’m getting from this is a game that, on a non-mechanics genre level, is profoundly different from the vast majority of video games. At its core, the Beatles game is a non-fiction game in the sense that most video games are fiction games: while the game certainly takes its liberties with the historical material that it’s presenting, it’s easy to imagine reaching the game by starting from a book about the Beatles or a course about the Beatles, and dreaming about how to make it more interactive, more immersive, enabling the learner to view the music from different perspectives and to isolate different aspects of their music. (I’m not the only person who appreciates Paul McCartney’s bass lines a lot more after going through the game on bass than I did before playing it.) I’ve been hearing about the Serious Games movement for years; in its own way, this game is one of the best examples of a serious game that I can think of.

Having written the above, now that I’ve had my eyes opened to the nonfiction nature of the Beatles game, I think that other Rock Band games actually largely fit within the nonfiction space as well: they’re much more of a representation and exploration of externally constructed subjects than (to pick another game within the rhythm game genre) Space Channel 5 is. I think it took the kick of a game saying “no, we’re not going to organize the game’s progression in terms of difficulty” to open my eyes to non-fiction video games that surround me, but now that my eyes are opened, I see them there.

Or maybe they don’t surround me, actually—looking at my game shelf, Wii Fit, the Brain Age games, and (I suspect, I haven’t played it) Endless Ocean qualify, but not much else. So maybe what’s really going on here is that two companies, Nintendo and Harmonix, are doing something special; five or ten years from now we’ll look back and marvel at the changes in the possibilities that games represent that are getting their first big market successes right now. (Yes, I am aware that non-fiction games have been around for quite some time; I had a lot of fun playing Robot Odyssey a quarter-decade ago!)

Of course, everybody’s aware of what Nintendo is doing in this vein (it’s certainly hard to ignore Wii Fit); Harmonix’s efforts are, to me, going underappreciated. I’m very excited about the possibilities of Rock Band Network: I now find it frustrating that there’s any music that I can listen to but can’t play along with in a game. So I’m very much looking forward to a future world where that is no longer the case, where we have a continuum moving gradually from recordings of music that we purchase to performances of the music that we play ourselves. (Though, as mashups remind us, the linear notion of a continuum is quite misleading here!)

And just as video games will make their presence known in various places in that continuum, so too will they make themselves known increasingly broadly across our culture. But breaking free of the narrow focus on game classification into genres based on gameplay mechanics is, I think, an important step in that broadening influence.

Sorry for the delay between posts; Miranda asked recently if she could watch Haibane Renmei (which I highly recommend), so we’ve spent many of our recent evenings going through that. And I don’t have a real post now, either, but I’ll at least give a link round-up. (Besides, the Zork walkthrough is much more awesome than anything I’m likely to generate myself.)

• Joe Armstrong and Simon Peyton Jones discussing Erlang and Haskell. (Via @timbray.)
• SuperBetter, Jane McGonigal’s serious-injury-recovery game. (Via @therealfitz.)

• Elite Beat Agents, meet Phoenix Wright!

  (Via GameSetWatch.

• A light-and-mirror puzzle in a tabletop RPG.
• Cloud pictures. (Via Dubious Quality; the fungus-infected violin link is pretty good, too.)

• A music video version of Danc’s Flash Love Letters.

• Mitu Khandaker on immersion and controllers.

• The best Zork walkthrough I’ve ever heard.

  (Via MTV Multiplayer.)

• And, because I seem to be incapable of doing one of these without some sort of random Japanese offering:

  (Via Pink Tentacle, of course.)

The one flaw I’m seeing so far in the Beatles game is its microphone support. I really want to try out the vocal harmonies, but I don’t have many suitable devices around the house: I have two Xbox headsets, but the game only supports USB mics, and I have a USB headset for Skype usage, but apparently that doesn’t qualify either. So the USB mic that I got with the original Rock Band seems to be the only device that I have that works with the game.

So I need two more mics; and I don’t want to have to hold them, so my wife and I can sing along while playing instruments. Does anybody have any recommendations on the topic? Honestly, what I’d find most ideal would be something like a USB headset except without the earphones, so the game would recognize it as a mic. But if there’s not anything available like that, then I guess a mic plus a stand would work okay. Wireless is nice but not a big deal, we sit pretty close to the TV and Xbox.

• Really, everybody should have their own domain these days.
• Rands on Your People.
• Cave photos. (Via 25 Times a Second.)
• A handy list of Rails security tips, and a lesson on timing attacks.
• Sections.
• Tetris meets Magic Eye. (Via Offworld.)
• Being a blogger.
• A different look at the Beatles. (Via @dan_schmidt.)
• Two on programming hardware, software, and paradigm evolution: foldl and foldr are slightly harmful, and flux and stability. (Via @decklin and @timbray, respectively.)
• I’m starting to get won over by the Mac’s insistence on the primacy of the foreground application.
• This “fidelity swap” idea seems like a useful concept.

• Sometimes I don’t understand Japan. (Possibly NSFW.)

  (Via @kateri_t.)

• A modern-day ghost fleet.

I very much enjoy the VGHVI game nights on Thursday evenings (we’re playing the Beatles game this week, by the way), but they don’t interact well with my normal style of going through games. I have to budget my game play time fairly strictly; since I normally like to go through games in depth, this means that I’m lucky if I can finish two games a month. And my time budget for multiplayer is even more limited than that for single player, so I generally favor single player games.

The upshot is that, while I think our choice in VGHVI games to play is quite good, they’re almost always games that I have very little experience with. I give them a brief solo spin before to get my fingers used to the controls, and we frequently return to games; even so, I constantly feel like a novice on Thursday nights. (The two exceptions being Rock Band 2, which I play quite a bit at home, and Catan, the board game version of which I played several times a decade ago.)

Burnout Paradise is a perfect example of this. It was the game we inaugurated the VGHVI gaming nights with, and we’ve returned to it six times since. It’s a quite good game, but each time I finish another game, I’ve asked myself “what game do I most feel like playing next?”, and Burnout Paradise has never been the answer. The result is that, when playing it together, I always feel a bit lost: I know my way around at a basic level, but I still find myself making wrong turns frequently, and I’ve unlocked a tenth as many cars as other players. (Fortunately, these flaws rarely restrict from enjoyment of most of the game’s fine multiplayer modes!)

But then, earlier this month, we gave Burnout Paradise yet another go; for a change of pace, we decided to explore the Big Surf Island expansion. I wasn’t all that actively excited about the expansion going in—I’d gotten the impression that it was rural sandboxy areas, and in general I prefer a bit more structure than that—but playing it has completely changed that opinion.

First, let me step back and talk more about the original Burnout Paradise content. It’s an open-world driving game, with a quite large map. The objects in the world generally have excellent affordances, with yellow signs clearly inviting you to smash through gates to explore; blue cones inviting you to step on the gas and try a big jump; red billboards inviting you to figure out how to set up a jump and smash them; and so forth. (And you get a little reward in the form of an incrementing counter the first time you smash each gate / make each jump / smash each billboard.)

This makes it a fair amount of fun to just tool around the map with no particular goal in mind, seeing where your interests lead you; if you want a goal, though, most intersections present you with challenges of various forms (traditional races, stunt runs, aggression runs). Combine this with a well-done license system, a range of cars to earn, and focused multiplayer challenges (“all players should meet at location A on the map; then drive to the top of parking structure B and jump off of it to the top of the building across the street”), and you’ve got a really good game.

Having said that, it didn’t quite grab me enough to put in huge amounts of single-player time. I’m sure I would have enjoyed doing so; but I’m not lacking in games I haven’t played that I’m sure I would enjoy. And the big map is a double-edged sword: in particular, when a race led me up the mountains on the west side of the map, I’d often get a bit frustrated by getting lost on the roads up there, and then I’d find myself up there with relatively few events that I could use to try to make my way back. There are enough fun jumps that making your way down is pretty entertaining the first half-dozen times, but eventually it got a bit stale for me.

So, while I was happy to play it on VGHVI nights, I gave up on the single-player mode once I earned my second or third license. (Which is, admittedly, more time than I’d spent on single player compared to almost any other VGHVI game!)

And then came Big Surf Island. It turned out that the others had gone through it on a previous VGHVI night when I’d been on vacation, but they were willing to indulge me and go through the 10 Big Surf Island online challenges a second time. And I quickly figured out why: the challenges are excellent. From a newcomer’s point of view, they bring you all over the island, giving you a lovely tour of it without having you feel that you’re repeating yourself. The island, rather than being the monoculture that I’d feared, turns out to be a microcosm of all the different sorts of locations in the main game: mostly urban space, but some nice playgrounds even within that urban space, and there is a more rural side as well. Unlike the original game, though, the island is compact enough that you can get quickly from any point in the island to any other; the 10 challenges do a great job of showing you the high points of the island without exposing all of its secrets. Also, they take that “high points” quite literally: the island has many more vertical spaces than the original content did, and a couple of jumps in particular are just stunning.

So we spent an hour or so going through those, and then finished off with the usual tooling around various areas of the city. After which, looking at my Big Surf Island license, I realized that I had a very nice chunk of content remaining for me there. In particular, I had 15 single-player events waiting for me to accomplish them; I’d enjoyed the online challenges enough that I was confident that I’d enjoy playing through those challenges, and it was a a small enough collection that I figured I could spend a couple of hours going through them and stop, without its interfering with other games I was in the middle of playing. Also, I was somewhat surprised to learn that I’d only discovered 8 of the 15 events: the island is small enough that I would have assumed that we’d driven through all of the intersections while going around the island, but apparently there were more nooks and crannies than I’d realized?

So, that weekend, I turned on the game again and wandered around the island. I did complete all 15 of the events, and had quite a bit of fun doing so. The small size of the island meant that point-to-point races didn’t work, and I was fine with two-lap races with intermediate checkpoints. Also, some of the races were “island tours”, which forced you to go off the roads in various areas, giving many of the same benefits that the online challenges had. The trick runs had point targets higher than I’d had to deal with in the main game; I turned out to be ready for that, though, partly because the default island car is a really good trick car, partly because the more compact nature of the game meant that good lines were easier to find, and partly because it finally dawned on me how to properly use taps of the boost button to chain. (I can be a bit slow at times.)

While doing that, though, I got to appreciate more of what the game has to offer. Even with the small size of the island, I was spending some time just driving around to get from event to event; every once in a while, when doing that, a car zoomed by inviting me to take it down. Which isn’t specific to the island—in fact, I don’t think you can unlock cars that way by only playing island content, you have to beat events in the regular game to make cars available as challenges—but it’s yet another mechanism by which the game is always giving you something to do. Also, I’d somehow avoided ever trying the showtime mode until it came up in that VGHVI night; I’m not convinced that mode has long legs, but it’s quite a bit of fun in its own unique way, and there are few enough roads on the island that I figured I’d go and earn showtime road rules on all of them. And, once I’d done that, the natural thing to do was to earn time road rules on all of the roads, which had yet another surprise: again, despite the small size of the island and despite my finding all of the events, there were places on the main roads that I hadn’t noticed yet, places that I only saw when the timed road rules forced me to drive past them.

The upshot was that, three or so hours later, I’d completed almost everything on my island license and gotten quite a bit more appreciation for the different modes that the game offers, the different ways in which it supports various forms of exploration. (The only things on the license that I hadn’t done were a few gates, billboards, and jumps; the island is small enough, though, that I’m fairly sure I should be able to find all of those, and am in fact looking forward to returning to complete those challenges!) So, with that experience freshly behind me, I went back to the main game, and started going through events there, bumping up my license.

And it’s great stuff. As I’d come to expect, it does indeed turn out that there are quite a few areas of the city in the main game that I hadn’t explored at all: you naturally end up funneling through a relatively narrow set of routes on most of the courses, so there’s street after street that I hadn’t explored. In general, I prefer the more compact nature of the island, and would support having the next iteration of the game be somewhat denser than this iteration; but it’s great to have so much to do, the larger point-to-point races have their own charms, and showtime works better on the main city streets than on the island streets. I started exploring the burning routes (and have, as a result of all of this, gone from having four cars to having over 25 of them), and I fully support those as a gameplay option. My improved trick mode skills are carrying over, and I’m starting to find some of the good trick lines; if I don’t get a few hundred thousand points, I feel like I haven’t done my job, I’ve gotten 1.5 million on one of my runs, and I’m sure I could do rather better than that with more practice. Also, billboards have changed from something that I smash into when I happen to run into them into something that can get me to stop and think about where the approach is that would allow me to smash into them.

I don’t think I’m going to end up turning into a super completist for the game, but at this point I won’t rule out the possibility. I’m certainly going to earn my Burnout license and do burning routes for all the cars I can; I’ll probably use the time road rules as a vehicle for exploring the whole map, too.

So: quite a game. As I said at the start, great affordances; and a great variety of options, which (as I’ve come to appreciate) work very well together to introduce you to more and more of the possibilities of the game. The original and its expansion also provide what I suspect could be a quite fruitful lesson in the pros and cons of open-world game design: I love the idea of having a huge map with everything open at the start, but I also didn’t really start appreciating the game until I was given a much smaller subset of the map to focus on. I’m not sure how to meld the virtues of the two approaches, or indeed if my appreciation for the smaller space has more to do with my time constraints than any universal rule of game design (and, I should note, the sequence of licenses and the achievements do a good job of providing a staged set of goals even in the original game). But I would recommend that anybody who is thinking about open-world game design should give both the original game and the expansion a look: having an optional geographically restricted playground worked very well for this player.

Art Style: Boxlife, like the last game I talked about, is a short puzzle concept game with a mix of set-piece puzzles and random input puzzles. This time, though, the mixture is treated in a more traditional fashion, by separating the two gameplay ideas into into two separate modes.

The set-piece mode is rather good, I think. One sign of a good puzzle game is: if I were lying in bed sick with a fever, would my brain be constantly making up puzzles for this game and testing me on them? Fortunately, I didn’t get to test that exactly (I was sick late last week, but I’d mostly stopped playing Boxlife before then), but my brain was happy enough to spend time folding boxes in the shower.

The random part of the game wasn’t, to me, nearly as successful. One flaw is that it’s (I assume) really hard to create random infinitely growing layouts that people can actually manage to cut up into strips of paper of the appropriate shapes without leaving a remainder. So the game gives up on that, and instead lets you discard excess bits at a point penalty. Which is not particularly elegant (and, in general, I don’t support points as a scoring mechanism in puzzle games: the valid scoring mechanisms are completion, time, and distance), though they do try to make up for that by giving you adorable little bits to add to a house scene as you earn more points.

With this game, I’ve finished the 10 dollars of DSiWare credit that came with the purchase of the system. My guess is that I’ll probably buy more DSiWare eventually (and, in fact, that what I’ll buy will be more Art Style games), but I’ve got enough else to play that it will take me a while to get around to doing so.

I want to talk about a couple of talks I attended at Agile 2009. Both relate to experts, expertise, and how one develops the latter to become the former.

The first was given by Jon Dahl, on “Aristotle and the Art of Software Development”. You can see video and slides of an earlier delivery of the talk. (I don’t think it changed much between deliveries; I also don’t know how much sense the slides will make out of context.) He viewed this subject through a lens of ethics: a Kantian view focusing on actions (and, in particular, universal principles motivating them); a Millsian view focusing on outcomes; and an Aristotelian view focusing on actors.

As you might suspect from the title of the talk, Dahl was most taken with the third point of view. (Which begins about 15 minutes into the video or 70 slides into the deck.) He presented Aristotle as linking ethics with happiness and a life well lived, and with virtue (in the sense of performing your function well). Honestly, it may be the case that many of these words had significantly different meanings for Aristotle than they would for us; in particular, Dahl glossed the Greek term that he translates as “happiness” as coming from “good” plus “spirit”; depending on how one takes the compound, I could imagine that as meaning “one whose spirit is good”, which makes the idea that ethical people are happy potentially more of a tautology than an an interesting statement.

Leaving these glosses aside: the point is that being good (virtuous) at something is inherent in the people who are good, rather than being rule-based. Which raises the question: how do you become a virtuous person? In the talk at Agile 2009, it sounded like at least some of Aristotle’s answer to that is fatalist: virtuous people are born, not made. (And—stop me if you’ve heard this before—virtuous people always turn out to be rich non-barbarian males. Sigh.) Watching the video of the RubyConf version, though, there’s a less fatalistic point of view: you gain virtue through practice and through modeling. So, to become an expert, you should hang out with experts, and practice; as you gain expertise, use your improved understanding to improve both your expert detection and your practice.

In contrast, if you’re a Kantian, instead of looking for good people, you look out for good principles, and follow them rigorously. In an Aristotelian point of view (again, with the caveat that it’s been decades since I’ve read any Aristotle myself, I’m just going by the talk), it would be possible to have virtues without formalizing the principles at all; furthermore, Aristotle’s virtues are means between excesses and defects (see slide 95; this gives me a Buddhist vibe, too), so following rules too strictly may actually be a sign that you’re straying from virtue.

The other talk was one by Mary Poppendieck on “Deliberate Practice in Software Development”. It discussed the nature versus nurture question of becoming an expert. My memory of the talk is that she strongly came down on the nurture side of that; rereading the slides, I’m not sure my memory is correct, but what is correct is that she claimed that nature alone is not enough: the way you get to Carnegie Hall is, indeed, to practice. Specifically: people need to practice their field for about 10,000 hours before becoming experts; and those who do eventually become experts practice longer and harder than those who don’t.

This last sentence, of course, doesn’t settle the nature or nurture debate: it may be that those who aren’t naturally gifted won’t become expert violinists no matter how long they practice. On a more meta level, it may also be the case that, without the appropriate nature, you’ll find practicing violin for 10,000 hours so offputting that you’ll give it up long before then. So it’s not clear (at least to me) to what extent nature is necessary; it does seem to be the case, however, that nurture (in the form of practicing) is necessary to become an expert, and in fact quite a bit of nurture is.

It’s not the case, however, that any old 10,000 hours of practice will do. As the title of the talk says, it should be “deliberate practice”, and Poppendieck listed four key factors in making the practice successful: a mentor, a challenge, feedback, and dedication. You want somebody else to guide you; you don’t want to be complacent; you want to know how your work is turning out; and, even with that, you need to put in the sweat. And she gave examples of how you might structure your work to support this. (Looking at it through a lean viewpoint; the slides don’t mention them, though the talk may well have, but I’ll bring up A3 reports.)

I was planning to turn this post into some sort of grand overarching pulling together of the above with some other articles that had come across my twitter feed. But, after listening to Dahl’s talk again, I’m having a hard time finding any nice symmetries. So, I’ll conclude with talking off the top of my head (as if I ever do anything else!):

Poppendieck’s recommendations don’t contradict the Aristotelian point of view: in particular, it sounds like Aristotle would wholeheartedly support having a mentor. Can we make other links: maybe Mill’s utilitarian point of view resonates with feedback, for example? Actually, I’m surprised at how hard it is to find explicit Kantian resonances with the deliberate practice model; is that a sign of something deep, or is that just a sign that the idea of having principles to guide us is to obvious as to not need stating? (As a side note, right now I’m finding the idea of following quite detailed Kantian principles in software development to be strangely appealing.)

The nature versus practice question is one that I’m interested in for both personal reasons and parental reasons. Take the question of how nature affects our practice habits: I’m a decent musician, but I was never one who was drawn to spend hour after hour after hour in practice rooms honing my art. I’m sure I could have become a better musician than I actually am, though I don’t know where my ceiling would be (if that concept even makes sense), but I do know that doing so would have required quite a bit more desire out of me. And I certainly support Poppendieck’s claim that not all practice is created equal: I’ve seen more than enough of people doing “practice” in ways that strike me as noticeably suboptimal.

As for nature and raw talent: I’ve seen enough exceptional people that I don’t believe that nature is irrelevant to becoming a world-class expert, from an outside point of view. But, from an internal point of view, it’s probably best to pretend that it is irrelevant: Poppendieck’s deliberate practice recommendations sound pretty solid to me, and I’m fairly sure that anybody following them and putting in the time would improve anybody’s skills. They also suggest a meta-approach: improve your skills at deliberate practice. Though, of course, you can’t just do that in isolation: you want to deliberately practice deliberate practice, which (among other things) means actually learning stuff.

Looking at holes in my own practice: of Poppendieck’s four recommendations, the area where I probably do worst is in finding mentors. (Indeed, in retrospect I probably should have spent rather more time acting as a mentor while managing the last few years. Sorry!) I imagine I shy away from feedback (both giving and receiving), too.

Important stuff; I hope we can all figure this out.

I’ve been using a program I wrote to help me memorize stuff (mostly Japanese vocabulary) for more than a year now. And for almost all of that time, I haven’t modified the program at all: I had plans right from the beginning to add multiuser support (if for no other reason than to make it safely accessible outside my LAN), but ssh tunneling worked well enough for remote access, and in general the program worked fine for my purposes. (Well enough, in fact, that I have almost 5000 items stored in it!)

Buying an iPod Touch changed that, though. Once I took a bit of care to add a stylesheet that looked good on the device, I found that it was just as easy to go through my vocabulary on the iPod as it was on the computer, and it was hugely easier to fit the review into spare moments of the day. So I switched from doing one big review a day to at least three a day, plus a few more when I had spare moments around the house.

So that was a huge help. I still couldn’t review vocabulary during spare moments at work, though; and once I got an iPhone, the number of places where I could conceivably review vocabulary but couldn’t actually do so got even larger! This made making the program available safely on the internet a lot more urgent.

I ended up using authlogic for authentication support; there were a few odd testing issues, but in general it worked quite well. (I think I’ve figured out at least one of the testing issues; I hope to have time soon to confirm my hypothesis and submit a patch.) And once that was in place, adding the general plumbing to link items with users was straightforward. (And I learned something about Rails in the bargain.)

I still don’t necessarily recommend that anybody else use it. For one thing, I suspect that the spacing of my review sessions isn’t optimal: I’m using exponential spacing more out of optimism than any strong evidence that it’s the best pattern to use, and in fact I get the feeling that some of my gaps in the months-out range are a little bit off. And, for another thing, I’m sure that there are features that I don’t need that others would find important; I can’t promise to be able to add them.

I will, however, strongly recommend that, if you have an iPhone or an iPod Touch and are considering using some sort of timed review program, that you don’t choose a desktop-only solution (unless you have a desktop computer in your bathroom): it makes a huge difference to be able to nibble away at your items when you have free time instead of having to do larger batches at less frequent intervals. And I hope that I’ll be able to add feature requests that I deem sensible without making you wait too much; alternatively, I’m happy to make a Mercurial repository available if you want to tinker with it yourself. I will also back up your data offsite nightly (though I make no uptime guarantees for the server my program is hosted on: it’s my home computer, and if something bad happens while I’m on vacation, it could take a couple of weeks to get it fixed). And you should be able to export your items / timing information as an XML file at will, if you want to change solutions. (Though it’s your problem getting that XML file translated into whatever format the other solution wants!) Having used it for more than a year gives me confidence that I’ll remain interested enough that it shouldn’t disappear for the forseeable future.

So if any of you wants to give it a try, let me know and I’ll set you up with an account.

Incidentally, I mentioned a few months ago that I was feeling a bit swamped with projects and conference prep, and was planning to step back some from my normal blogging schedule. (Especially the video game related parts of it.) Fortunately, Agile 2009 is now over (though, don’t get me wrong, I enjoyed both the preparation and conference very much!), and some of my side projects are winding down, so things should be getting back to normal around here. In fact, over the last week and a half things have been much more prolific than normal on this blog; I don’t plan to keep that up, but it is very nice both to have the time and energy to blog like that and to remind myself that I really enjoy doing so.

I finished adding multiuser support to my memory project this weekend. I’d added the ability for users to log in and out while I was on vacation this summer, but I hadn’t actually linked up the users with their lists of items to memorize.

The relevant models are a User model and an Item model. A user has_many :items; part of the Item class definition was the following:

class Item < ActiveRecord::Base
  ...
  def self.next
    find(:first,
         :order => "next_review_time",
         :conditions => pending_item_condition)
  end

  def self.pending_review_count
    count :conditions => pending_item_condition
  end

  def self.pending_item_condition
    ["next_review_time <= ?", Time.now.utc]
  end
  ...
end

As written, those would, for example, add up the total count of all users’ pending items; I wanted instead to be able to ask those questions on a per-user basis.

The has_many declaration gives me a collection user.items for each user. And if I pass a block to has_many, I can add methods to that collection; that seemed more stylish than, for example, adding a user parameter to the above methods. So I modified my User unit tests to make sure that there were items owned by multiple users, and copied over the Item unit tests for the above methods, replacing, e.g. calls to Item.next with calls to user.items.next.

Which I expected to fail, complaining about an undefined method “next”. But not only did the tests not fail for that reason, they in fact passed, ignoring the items for other users! At first, I assumed I’d made a mistake in my tests, but no: when I replaced the calls to user.items.next with calls to Item.next, they failed as expected. So the functionality I wanted really did seem to be working without my having to lift a finger.

But how? I could imagine some sort of method_missing implementation that forwarded functions on the collection to functions on Item. But if it were doing that, how was the functionality getting restricted to items owned by the user in question? I would hope that it wasn’t doing a broader search in SQL and then subsequently ditching inappropriate items in Ruby; sure enough, a look at the logs shows that the SQL queries that are issued do include the user_id restriction.

I haven’t verified it yet, but the only hypothesis that I’ve come up with so far is that the collection objects that are returned by user.items start off life as clones of Item; so they have all of the class methods on Item. And then some key method (find, say) is overridden so that the user restriction always gets applied, and all other lookup methods are implemented in terms of that key method, so they get the restriction in question for free.

Which, once I thought about it, makes sense. Consider Item, not as a class but as an object: you can think of it as a collection object, namely the collection of all items. With that in mind, it makes sense for other objects that are also collections of items to be closely related to it, and if we can express that tight linkage in terms of the implementation, by thinking of Item as the primordial collection of items, so much the better!

An interesting journey. At first, I thought I must be writing bad tests; then I thought I was seeing magic; and eventually I came around to a realization that what I was seeing made a lot of sense conceptually, so I was happy that I was working with a language and a framework where I could get such sensible behavior for free. And, no matter what, it was a useful reminder that there’s a reason why the TDD cycle is red, green, refactor, not just green (with simultaneous test+implementation changes), refactor: if I’d done the latter, I would have missed a useful learning opportunity.

Though there’s a postscript to the story. I’d learned that my original implementation idea was unnecessary; the question remains, though, whether the original implementation idea was a good one or not. And, after giving it some thought, I decided that I preferred having these methods in the User model rather than in the Item model. If I left them in Item, it would be easy to write code representing concepts like “what’s the next item that any user will be asked?” or “what’s the total pending item count across all users?” Which aren’t natural questions to ask, so I was setting myself up for bugs by leaving those methods in Item.

So, with my tests in place, I moved them to User:

class User < ActiveRecord::Base
  ...
  has_many :items do
    def next
      find(:first,
           :order => "next_review_time",
           :conditions => pending_item_condition)
    end

    def pending_review_count
      count :conditions => pending_item_condition
    end

    def pending_item_condition
      ["next_review_time <= ?", Time.now.utc]
    end
  end
  ...
end

Leaving me where I expected to end up when I began, but having taken a much more interesting route.

• I mentioned Roger’s Operation KTHMA last time, but it’s actually started now and sounds awesome enough that I’ll mention it again: day 1, day 2, day 3.
• Our whole household was playing Bunni Game: How We First Met last week. (You should be able to see my world at this link.)
• Victorian Homes of the Mission District, great pictures and commentary.
• Michael Bolton’s distinction between testing and checking seems useful.
• 100 year old color photos of Russia. (Via @timbray.)
• Margaret Robertson on games making us cry. (Via @kateri_t.)

Art Style: Pictobits is a funny mix for a puzzle game. Many puzzle games challenge you by throwing random input at you faster and faster until you break. (Tetris is a classic example.) And many puzzle games give you set-piece challenges that, while perhaps requiring some quick thinking and precision (and even having a bit of randomness), let you develop approaches that are targeted to the layout of a specific level. (Bust-A-Move levels can be examples of this.)

Pictobits, however, is in the middle. At first, it looks like a straightforward example of the “faster and faster random input” school: blocks fall from the top of the screen, the game’s designers actually manage to come up with a new but not particularly gripping twist on how to deal with that, and if you survive long enough, you win. (And unlock a picture from an NES game: Nintendo loves milking the nostalgia.)

That winning is the first sign that it’s not in the “faster and faster” school: you’re not supposed to win in games like that! Anyways, as you progress through the levels, you first run into one additional gameplay wrinkle, and, as the stages harder, you start to fail. And, on replaying the levels, you notice that the patterns seem pretty familiar, that you run into the same sorts of shapes at the same points in the level, and have to figure out ways to quickly arrange your squares to eliminate most or all of the falling shapes most thoroughly. So it really is a “set piece” game, it’s just that the set pieces are quite a bit longer than in most games of that subgenre and have quite a bit more flexibility in how to deal with them.

And then, if you’re like me, the game eventually gets hard enough that you stop playing. Which is okay. It’s the first DSiWare game that I bought; it would have cost me all of five dollars, except that you get ten dollars of credit when you purchase the system, so I effectively got it for free. And I got five bucks worth of enjoyment out of it: a puzzle system with a few new ideas, that ultimately didn’t come together for me, but that I was perfectly happy to have spent two or three hours with, to have had with me on a recent plane ride. I remain a supporter of Nintendo’s Art Style experimental series: I’ve enjoyed the games that I’ve tried in it, and I imagine one of them will end up really pushing one of my buttons.

I feel like I should have more to say about Rhythm Heaven. It’s a rhythm game; I like rhythm games. It has quirky Japanese music and images; I like quirky Japanese music and images. It’s a small-scale experiment that was quite popular in Japan; I’m all for that sort of thing.

But I don’t have much to say. I played the game, I liked it okay, I didn’t like it as much as I expected. Part of that has to do with the progression mechanic: you have to finish each stage before progressing to the next one, and there isn’t clear feedback on what you did wrong. So when I found myself stuck at a stage where things just weren’t going right, I just got annoyed. Having said that, I didn’t have much trouble making it through all the regular stages; but I didn’t have the energy to either systematically get bonuses on the stages to unlock further rewards or to go through the harder versions of the stages that appear after you hit the credits. (At least I assume that all the stages after the credits are harder versions, I stopped after the first one, where I did what seemed decently well to me but not well enough to progress. Which is another way that the game doesn’t give you feedback: if you fail, you don’t know how close you were.)

The images and music were pleasant enough, amusing enough. Several of the pieces of music got stuck in my head, but that’s not necessarily a good thing: in particular, this happened to me with the very first stage, whose “music” consists of playing five notes of a scale over and over again. I have no idea why my brain decided to latch on to that, but I don’t particularly thank my brain or the game for that outcome.

Don’t get me wrong, I’m happy enough to have spent a few hours with it, but I’m also glad that I stopped when I did and moved on.

Not much discussion of the game on the blogosphere, but I did enjoy this Offworld article on otaku culture.

One of the GDC sessions I attended this year was a charming panel discussion including, among other people, Steve Meretzky of Infocom fame. Which got me curious what he was up to these days—I don’t generally expect people from that era to still be active in the game industry—and was pleasantly surprised to find out that he’s the VP of game design at a company, Playdom, that’s located in Mountain View all of a mile and a half away from my house.

So I filed away their existence in the back of my brain (well, actually, in my GTD someday/maybe list) and mostly forgot about them. Not completely: at the time, I was thinking about possibly changing jobs. But my general conclusion was that I was in general rather happy with my current job, and that while I was starting to feel a bit antsy, I’d probably prefer to change jobs towards the end of 2009 than towards the middle. I sent out a few feelers at the time, but none of them paid off, so I was happy enough to shelve the issue.

It turned out, though, that one of the feelers wasn’t dead, it had just gotten buried for a bit. It resurrected itself in the middle of the summer, and shortly after that happened, I got cold-called by a recruiter who mentioned Playdom! So I sent in my resume, and went in to interview. And I’m very glad I did, they look like they’ll be a very nice match for what I’m looking for. In fact, going down the checklist from the aforementioned blog post, they hit on almost every front: a local game company working in small, cross-functional teams with very fast iterations and which would expose me to many domain and technological areas that I’m not very well steeped in yet. (No Erlang, but I can certainly live with that. It’s also not clear to me how many of the agile technical practices they use, but that’s an area where I should be able to contribute if doing so turns out to be useful; anyways, right now I’m a lot more curious to see what a fast-moving team looks like on the business side than the technical side.)

They focus on social games. Which might seem like a bad fit for me, because my taste in games is fairly traditional. Actually, though, it’s something that I’m rather excited about, for two reasons. (Or perhaps one reason with two sides?) One reason is an aesthetic one, or a cultural one: a new art medium is a gift that we should cherish, so the last thing that I want is to see it have its practitioners bore into a tiny area of the design space, ignoring vast reaches of what is possible. That is, unfortunately, exactly what several major players in the game industry have been doing over the last decade, so I’m very glad to see companies like Playdom consciously setting their sights elsewhere.

The other is perhaps the business side of the same argument: one excellent book that I’ve read recently is The Innovator’s Dilemma. (Ironically, I read it because my current boss made it sound so interesting.) The thesis of that book is that highly successful companies, exactly by doing such a good job of paying attention to their best customers, end up refining their current technologies to make them more and more appealing to the core of their customer base. As part of this, they discount customers that are on the fringes (low-margin customers, frequently with somewhat different interests); new companies can then take slightly modified (and less technologically advanced) versions of those same technologies and use them to build up a following in a new customer base. (And, more importantly, using a new value network: their suppliers, their income sources, their distributors are all different from those of established companies.) What starts as a small market soon grows to a quite respectable size: also, the companies in the new market can typically improve the quality of their technology at a faster pace than companies in the original market, so after a few years, the new companies end up making products that are technically quite adequate for the majority of customers in the original market (but with lower prices and otherwise more appealing!), which quickly spells doom for those original companies. And, as far as I can tell, Playdom looks like a textbook example of a company at the early stages of such market innovation; if they follow the course outlined in that book, the sky’s the limit.

Of course, future promise is one thing, but the question remains of how interesting their current games are. Some of their early games seemed to me more like experiments than compelling packages (though they’re experiments that many people were happy to play); within the last month, though, they launched Mobsters 2, which I’m really quite enjoying. It took me a few days to figure out how the mechanisms in the game worked, what they meant and how they interacted together; that was enough time to get me sufficiently hooked that, even though I’m in general not uncovering too much more in the mechanics, I still happily log into the game a couple of times a day to do some leveling up. (And, as I said before, they iterate quickly, so for all I know they’ll introduce interesting new mechanics next week, next month!) So if that’s what their second wave of games looks like, I have high hopes for what they’ll be producing a year or two from now.

Ironically, the one part of the game that I haven’t explored is its social aspects: I’m currently not much of a Facebook user (follow me on Twitter instead if you want to know my hour-to-hour activities), so I don’t have a big pool of friends to draw from to expand my mob. I would like to change that: if you’re a blog reader, feel free to add me as a friend; if you do so, please give the game a try and ask me to join your mob! (Do Facebook friend requests include a note? If not, and if you’re not sure I know you, just e-mail me or leave a comment or something—I’m happy to add any blog reader as a friend.)

I’ve very much enjoyed my current job: it’s been a wonderful place to spend the last few years, I’ll miss my coworkers very much, and it looks like the product is going through an exciting phase in its development right now that I wish I could see the other side of. Having said that, I’m very excited to be joining Playdom at the end of the month, and I can’t wait to see where that journey will lead me.

Neither my wife or I has ever had a mobile phone. This marks both of us as somewhat eccentric, and it’s not a dogmatic choice for either of us; the truth is simply that neither of us uses a phone much, so why bother paying extra to carry one around? For various reasons, though (probably most notably my iPod Touch enjoyment), my brain started thinking earlier this year that having an iPhone might actually be worth seventy-five bucks a month. So I spent some time investigating that possibility, and then set it aside waiting until something gave me a further nudge.

Which happened last month: some events occurred which made me think that it would be wise for somebody in our family to have a cell phone, we were about to go on vacation, and I was in an Apple store for an unrelated reason. (Repairing the new iPod; good thing it was still under warranty, but I continue not to be impressed with the reliability of Apple’s hardware.) So I walked out of the store with my first cell phone.

About which I have no complaints at all. I was getting a lot of the iPhone’s benefits from having an iPod Touch (I spend a lot of the time at home and work, both of which have WiFi reception, and I can even get WiFi wandering around Mountain View), but it’s still useful having internet access even more frequently. And right before that trip was a good time to get one: the hotel we stayed in on the trip advertised itself as providing free WiFi, but it didn’t actually reach into our room, so I had to go down to the lobby to use it. (Other downsides of the hotel: they used funny-smelling cleaning chemicals; while trying to figure out if they had wired internet, I noted that their phone jacks had no cover, leaving an unsightly hole in the wall; the phone also didn’t have instructions on how to call various locations within the hotel (though pressing 0 got me to the front desk); they shuffled me to an 800 number for my questions about WiFi access; and one evening even the lobby WiFi didn’t work. I will try to avoid the Holiday Inn in Decatur, Georgia in the future, and indeed the chain as a whole.) And it also never crossed my mind that my father-in-law wouldn’t have internet access at all in his house. So I was glad to have a phone available to feed my Twitter habit and look up the occasional piece of useful information.

Fortunately, my mother-in-law had perfectly nice internet access; I even got some reasonable programming done on vacation while in her house. In general, it was a quite pleasant trip; very relaxing, and our hosts were fine with me lounging around and programming rather than, say, visiting Stone Mountain. Though I did go see some sights; in particular, the manta ray at the Atlanta aquarium really is wonderful. We had some quite nice food, too, most notably at Rathbun’s.

And, as I write this, I’m at Agile 2009; having a phone is proving useful to allow me to call home without worrying about exorbitant hotel phone charges. It’s only being moderately useful in terms of internet access, though: the interior of the hotel is pretty much one big dead zone. (I would have naively thought that Hyatt would find it useful to work with AT&T to ensure that one can get cell phone coverage in their hotel, but apparently not? Speaking of hotels that I’m not too impressed with, I’ll add Hyatt to the list: they charge for internet access; the ethernet cable in the room has the plastic locking bit at the end broken (which they could certainly afford to replace, given that they’d make up the cost in a fraction of a day of internet charges); the food prices are ridiculous; and the bathroom manages to hide the light switch, the toilet handle, and the kleenex in odd locations. I may be imagining this, but there may even be something wrong with some of the power jacks in the room; though it may be that my power supply is going south.)

I still think that $75/month is overpriced, especially since I can’t, say, use the phone to get internet access for my computer. But the iPhone and the iPod Touch really are wonderful devices, with their mix of being a solid music player, a very credible internet access device, and a very credible application platform: a more than worthy addition to my pocket.

• Tanuki testicle art.
• One day in kanban land.
• Pixie Driven Development.
• A plain-text version of the Declaration of Independence. (Via Kelley Eskridge.)
• Rock Band as a music theory teacher.
• Maira Kalman on Thomas Jefferson and Benjamin Franklin. (Via @bos31337 and The Edge of the American West.)
• The red handprints are a particularly nice touch.
• Another way to approach poems/stories.
• I never get tired of seeing new optical illusions.
• Glad to see I won’t be reverse-polish-deprived when/if my current HP calculator bites the dust.

• Nice use of webcams:

  (Via @garb.)

• Trompe l’oeil murals. (Via @scottmccloud.)

• Japan still gets weirder games than we do. (Yes, the game apparently involves writing songs which are then sung in game by a polar bear.)

  (Via @tinysubversions.)

• Glad the meme still has some life in it.
• I can’t wait for the Beatles game.
• The secret history of Ada Lovelace. (Via @elenielstorm.)
• Thoughts on the order in which to implement a video game. Interesting how many of the ones that don’t work seem compatible with agile. (Via @kateri_t.)
• This is going to be awesome. (Or, maybe, a complete disaster! I doubt it, though.)
• Nels chiming in further on the save game issue.

I still haven’t made up my mind about Puzzle Quest: Galactrix. It never grabbed me in the same way as its predecessor; how much of that is due to novelty wearing off, how much is due to the strangely low quality of the DS port, and how much of that is due to the core mechanics?

I actually don’t think it’s the core mechanics, though it may be due to the peripheral mechanics. The non-fixed gravity, once I got used to it, does make the game slightly richer: in particular, any time you swap gems, you have the choice of two directions in which to carry out that swap (and to have pieces subsequently fill in from). That gives you something extra to think about, and meant that playing the game wasn’t exclusively an extension of the habits that I’d built up with its predecessor.

That’s the main combat mode; like its predecessor, there are another half-dozen or so variants of the gameplay, used in different situations. These took me a while to get used to—in particular, like Bill Harris, I didn’t initially appreciate the way that the leap gate mode punished you for setting off chains. (Incidentally, Bill has two other posts on the game; not so much blog discussion of it in general.)

Thinking about it a bit more, though, I eventually changed my mind on that issue. If all the mini-games had the same rules, there wouldn’t be much point of having mini-games; so there’s a real benefit in having what’s good in one mini-game be indifferent or even bad in another. And, on a more subtle point, the main attack game is probably the deepest of all the gameplay modes (which is a good thing!); the other games are typically more focused, and it turns out that the tricks that you learn to focus on from them can help broaden the range of your tactics in the main attack game. For example, a key part of the attack mode game play involves making sure that your moves don’t set up good attacks by your opponent. Controlling cascades is an important aspect of that; the rumor game mode focuses on that, and (as noted above) controlling cascades is also an important part of the warp gate game. Similarly, you have various items which will allow you to move twice in a row; the warp gate game helps you focus on setting up attacks one move out.

So it’s a nicely crafted set of games, one which adds up to more than the sum of its parts. Though they’re not all fabulous; in particular, the games that try to get you to use up most or all of a fixed set of gems didn’t work too well for me, certainly not as well as the monster capture game in Challenge of the Warlords.

The upshot of all of that is that I support the game’s primary mechanics, and some of its peripheral mechanics. Other parts of the peripheral mechanics, though, didn’t work as well for me. In the game’s predecessor, you had a leveling up system that was most important mechanism for acquiring new abilities (not just buffing your stats), which culminated (when you reach the level cap) in a spell that let you largely take control of battles; the game controlled the levels/abilities of enemies that you fought to generally give you well-matched battles. In Galactrix, however, abilities are controlled by buying items for your ships (and you may need to get better ships to have more slots for items). So you have access to abilities earlier, and it’s harder for the game to match your level.

The result is that, on the one hand, I had some early boss fights that were way too hard for me; on the other hand, about halfway through the game I had a ship that had enough slots for a set of items that enabled me to control the playing field whenever I needed to. So, while having more choices for customization sounded nice in theory, in practice it didn’t work out too well. (And, I will add, the way it turned out is a bit of a blessing in disguise: if I’d had to do more customization, I would have had to spend more time grinding on areas of the game that I didn’t particularly enjoy.)

Some interesting seeds here, but I’m still left with an unsettled feel for the game. Coming in, I wasn’t sure if the original Puzzle Quest was a one-trick pony; having played the second game, I’m still not sure! Or rather, it’s clearly not a one-trick pony, but it might be a one-and-a-half trick pony; on the other hand, it wouldn’t completely shock me if the next iteration put it all together in a satisfying way.

There’s been a lot of discussion recently about choices in games, and the effect that game save mechanisms have on the ethical impact of those choices. I won’t even attempt to link to the vast majority of the conversation, but two contributions (both involving Nels Anderson) particularly struck me today: slides for a talk by Randy Smith called “How to Help Your Players Stop Saving All The Time” that Nels mentioned on twitter, and an Experience Points Podcast episode on “The Decision Dilemma”.

I’m an obsessive saver when I play games (though, fortunately, these days less obsessive a reloader than I used to be), but listening to Jorge, Scott, and Nels talk on the latter made me realize that many people save games for completely different reasons than I do. The typical scenario that they discussed is a player who saves a game right before a big choice in a game (typically a moral one) and then plays through the different branches, reloading as necessary, before deciding which route to commit to.

The thought of doing that almost never crosses my mind. (Especially if the choice is a moral one.) And when it does, I reject it out of hand. For example, when playing Mass Effect, I wasn’t really thinking too hard when going through the dialogue tree that leads to a choice of which party member dies. I ended up inadvertently choosing to save the party member I liked less; once I realized that, I could have reloaded and not lost much time, but instead I felt a pang of regret and continued playing. (Though, to be sure, I’m not sure I made the “wrong” choice even there—it struck me as the sort of choice that, in the real world, I would want to not make based on personal likes and dislikes, and it’s not clear to me that other factors wouldn’t have swayed me to make the choice I actually made in game.)

Instead, the reasons why I save are quite different: I save because I don’t want to spend time doing stuff that I don’t enjoy. I do not want to have to fight through a stretch of the game, to die, and to have to replay that section. (Unless, of course, it’s a game whose mechanics I’m particularly fond of.) Perhaps worse, I do not want to survive the next section of the game but end up in a weakened state, making battles half an hour later much more difficult. (And probably requiring extra reloading when I reach them!) And, of course, the absolute worst is when I survive by avoiding encounters that would otherwise have given me experience points, forcing me to repeat battles (or grind in order to level up) for the entire rest of the game.

The above mostly plays out in tactical situations. If the outcome of a battle went well enough and it’s easy enough and fast enough to save, then I will typically save; if it went badly enough, I will typically reload; and if it’s in the middle, I’ll play along for a while longer. As I said above, the more strategic choices are much less likely to make me think seriously about reloading; and, even when I’m nervous about a choice, it’s not usually an ethical choice, it’s much more likely to be a choice about which branch of a skill tree to improve my character in.

So the podcast episode was, to me, more a glimpse into other people’s minds than anything that spoke to me directly. Randy Smith’s slides, however, were a different matter—indeed, right near the beginning he talks about frequent saves being driven by a need for safety, which is a good match for my feelings. (Though he branches out into other motivations later in the slide deck.)

I wish I’d heard him actually give the talk; I’m having a hard time grasping the nuances just from the slides. He ends the first part of the talk with a claim that “reducing compulsion is good, regardless of save/load design”, which I tend to agree with—in particular, I don’t claim that my obsessive saving is a good thing, in fact I’m willing to accept that it’s a bad thing. (E.g. because, as he says, it takes my attention outside the game.) I also agree with him that cheap save/load sets up a feedback loop encouraging people to do so more often. (I played Doom rather differently from Marathon, for example.)

It’s not clear to me, however, that I prefer for games to solve this problem by limiting the contexts in which you could save: I’d much prefer to solve the problem by limiting the lack of safety that drives me to save in the first place. (Though I’m also willing to believe that this is a false choice, and that a deeper analysis would lead to a more satisfying resolution. In fact, I’m willing to believe that, if I’d been at Randy’s talk, I would understand him as doing exactly that sort of deeper analysis!)

Consider the basic choices that I outlined above: if I don’t save and then die, or if I do save but don’t reload after a stretch in which I played badly, then I will get punished for my actions, with that punishment lasting in some cases for the entire rest of the game. In other words: if I play badly (or even less than perfectly), the game will reduce my enjoyment of the game for hours to come.

This is a lousy way to treat players. If the game really is about challenging the player’s skills, then of course you want bad play to have consequences; such a game, however, then it should hedge its bets in two ways, both by putting skill-driven play front and center and by having individual bouts be bounded with no lasting in-game consequences from one bout to the next. (E.g. puzzle games, rhythm games, fighting games, multiplayer FPS games.) But if you want your game to have a long-term flow, then don’t treat your players this way.

So: at the very least, bound the negative consequences. There are lots of tactics for doing this; checkpoints are a tried-and-true one, but I also rather like the Zelda technique of both having the game be kind enough that death is relatively rare and having the consequences of death be limited to needing to refill your hearts / bombs / arrows (all of which are available from clumps of grass) and perhaps needing to traverse a part of a dungeon. (Usually a small part: in particular, Zelda dungeons are generally good about giving you a shortcut from the entrance to the boss fight once you’ve gone through the rest of the dungeon once.) (Incidentally, I think part of people’s dissatisfaction with Majora’s Mask is in the ways in which this principle doesn’t hold, or at least doesn’t manifest itself in the same fashion as it does in other games in the series.)

I also really enjoyed the way Lego Star Wars handled this issue: in that game, your character has almost no state at all, which means that the game can simply respawn you when you die. A skill-based player can still take pride in rarely dying when progressing through a level; other people can have no end of fun by simply mashing buttons.

Another issue around saving and loading is the lack of information: most of the time (pre-boss save points being an exception), I save not because I know I’m likely to die in the upcoming area or because I’m likely to play in a sub-optimal manner, but rather because I want to limit my losses in the face of an uncertain probability of death. And, perhaps more interestingly, the reason why I reload isn’t that I know that I played sub-optimally in a fashion that will hurt me down the road, it’s because I know that I played sub-optimally and I don’t know what the consequences of that will be.

If you treat this simply as an information problem, it can be significantly improved without harming gameplay. Start with the reload problem: that shows up most starkly if the game doesn’t put any limits on your capabilities (e.g. your health, your ammo supply, the level of your character). In that situation, if you do anything suboptimal (e.g. miss a single shot!), you may fear that it will hurt you going forward.

If, however, you have caps on these attributes, this problem goes away. For example, if there’s a maximum amount of ammo that you can hold, then if it takes you three shots to kill an enemy whom you could have killed with two shots, and if you subsequently pick up enough ammo that you’re at the ammo limit even after wasting that shot, then you know that the missed shot didn’t hurt you. Concretely, my worry level in Deus Ex declined notably once I started hitting limits of this sort.

These sorts of attribute caps are most effective in directly attacking the problem of when to reload, but they also help with the problem of needing to save in the first place. Your character’s status with respect to various attribute caps give you a concrete way of measuring how vulnerable your character is; assuming that the game has earned your trust that it won’t throw major challenges at you without some advance warning, this will frequently allow you to avoid saving without seriously worrying that doing so will hurt you.

I’d love to see more games with significant moral choices. And I’d be delighted to have not saving be a part of that, as long as that doesn’t destroy my enjoyment of the game in a more mundane aspect.

As far as I can tell, the last time I shaved was twenty years ago yesterday. If you’re curious what two decades of beard looks like, here’s a recentish picture of me:

That’s actually from three and a half years ago (I don’t take pictures very often, and appear in them less), but while I have somewhat less hair on top now than when that picture was taken, my beard looks about the same. (White hairs have started to appear in the interim, but they’re still very much in the minority.)

As you’ll note, my beard does not in fact extend to ZZ Top proportions. It’s fairly curly (much more so than the hair on the top of my head), so it extends down to my collarbone if you stretch it out. The hairs are still growing, but hairs fall out if I run my hand through my beard, and that’s the equilibrium point between those two forces.

My moustache in particular doesn’t look like it’s been growing for 20 years. My moustache hair grows notably more slowly than my beard hair; in fact, for the first year or two of growing the beard, the moustache hair and the beard hair didn’t meet around the corners of my mouth.

As to why I started growing the beard: shaving was a pain, both literally and metaphorically. So I stopped, and haven’t seen any reason to restart. It may not be to everybody’s taste, but I’m happy with it, as is Liesl, and that’s really all that matters to me. And I’ve worked in professions in which my beard is only mildly eccentric, if that, so there really aren’t any social pressures for me to shave.

I also don’t cut the hair on the top of my hair regularly, and in fact I haven’t been cutting it regularly it for one year longer than the beard. That hair has gotten cut on two or three occasions over the intervening decades, however, unlike my beard. In general, I’m less attached to having long hair on top of my head (or, indeed, any hair on top of my head) than I am to my beard, but I can’t imagine getting back in the habit of cutting it regularly, either.

The last chapter of Galison’s Image & Logic is about the relationship between (breaks in) different strands of practice within physics. If you treat the notion of paradigms sufficiently seriously, you’re led to think that theoretical breaks and experimental breaks come hand in hand: the two sides of a paradigm shift are incommensurable, so the change in the theoretical viewpoint also means that experimentalists on either side of the break can’t really talk to each other, because they’re referring to different objects, different concepts, even if they use the same words.

Which Galison takes issue with, both for conceptual and historical reasons. As he says, “When a radically new theory is introduced, we would expect experimenters to use their best-established instruments, not their unproven ones.” (p. 799) And indeed, as he discusses on pp. 811–812, when theorists were fighting over the nature of space and time, they took great care to translate their theories into terms that could be tested by the experimentalists of the time; different paradigms fought, one of them (special relativity) won, but the results were agreed to by all parties, there was no incommensurability that the notion of a paradigm shift might suggest.

So, rather than breaking at the same time, the experimental practices and theoretical practices underwent changes at different times. In fact, Galison introduces a third strand here, namely instrumentalists, with its own pattern of breaks, and several other practices (electrical engineers, the military)make a showing at various points in the book as well.

And the fact that breaks occur at different times in different strands, Galison claims, is a source of strength. One analogy to think of here is a brick wall: when you line up bricks, you want them overlapping rather than sitting directly on top of each other. That way, the weak points of one row are supported by the strong points of adjacent rows.

So: what does this have to do with agile? The first strands with breaks that come to mind are the TDD cycle. You don’t simultaneously write new code and new tests: instead, you write the test first, giving a break in the testing strand (manifesting itself as a red bar), and subsequently advance in the implementation strand (manifesting itself as that red bar changing to green). And then, of course, you refactor; I’m not sure yet if this is a break in a third strand or if it’s a further advance in the implementation strand. (For that matter, the refactoring can be an advance in the testing strand, as well.)

One special aspect of this example: while the strands don’t have their breaks at the same time, they have their breaks in close sequence, in a specific order. Is this a general property of best practice in interwoven traditions? I tend to think not; having said that, it doesn’t seem all that unnatural to me for breaks in one tradition to be followed reasonably closely by breaks in closely related traditions. So perhaps if you measure this with a sufficiently coarse granularity, these breaks look simultaneous, giving rise to the paradigm shift idea; I’m not sure.

Another example from the agile realm: iterations. Here we have breaks in the implementation, in the testing, and in the customer requests. And they’re all supposed to happen at the same time! Which looks dubious from Galison’s point of view; does that mean that Galison is wrong, that iterations are a bad idea, that I’m misreading him or stretching his analogy, or that these breaks aren’t in fact simultaneous?

It certainly seems likely that I’m stretching Galison’s analogy; having said that, I think you can also make a case that these breaks aren’t simultaneous. It’s not the case that Customers approach the planning meeting that kicks off an iteration with a blank mind: they’ve been thinking about what’s most important to work on next, and while they’ll certainly use feedback during the planning meeting to inform the details of what the team should do in the next iteration, there’s not a split in the Customer practice right before the planning meeting. And there isn’t one right after the planning meeting, either: the Customer has to spend a fair amount of time at the start of the iteration helping the rest of the team understand what that iteration’s stories means. And breaks in the testing and implementation strands don’t happen simultaneously in this example any more than they do in the TDD example.

This last case, in fact, brings us to the second point of Galison’s chapter. The chapter is titled “The Trading Zone: Coordinating Action and Belief”, and he claims that these “adjacent” strands can’t naturally talk to each other without misunderstandings. Instead, members of different strands have to work quite hard to find a way to work together that allows the two strands to learn from each other, to find a common way forward that advances both of their interests. (C.f. Star and Griesemer’s notion of boundary objects, which Galison comments favorably on in a note on page 47.) To do this, the parties develop pidgins or creoles; these languages aren’t enough to allow complete understanding between the two sides, but they are enough to let both sides agree on some amount of focused exchange.

I particularly enjoyed the example that Galison gave on pp. 820–827 of a pidgin language developed during World War II to allow theoretical physicists and electrical engineers to discuss the construction of radar and microwave devices using circuit diagrams. Returning to our programming examples: while, in the TDD case, there’s relatively little scope for misunderstanding (since the same people are doing the testing and the implementing!), we can nonetheless see unit tests as a pidgin language (or perhaps more of a creole) in this case. In fact, maybe that’s exactly the strength of unit testing: forcing a creole language into the situation sets up an explicit trading zone where one would have only been latent without that language, and in doing so it makes you aware of the split betwen the latent testing and implementing strands, increasing the strength of your work. The example of Customers, testers, and implementers working together is more clear-cut: agile suggests that the three groups spend quite a bit of time talking together, and acceptance tests give an example of a pidgin language that they can use to coordinate their activities.

And, as with the second agile example, Galison suggests reinforcing these trading zones with a shared physical space, to increase the chances that active trading will happen. The physical layout of the MIT Radiation Lab was designed to increase the amount of chatter between different groups; he gives examples of areas in later buildings designed to support particle physics research that are intended to increase the chances that members from different specialties will spend time together.

Though one aspect of agile practice that Galison’s text, to me, doesn’t clearly support is an erasing of boundaries: Galison seems happy to have these specialties to remain largely distinct, whereas the agile ideal is the concept of generalizing specialist. Or at least that’s the agile idea in the context of implementation; agile draws a particularly bright boundary between the business and implementation sides. (Though the lean tradition prefers to create an explicit bridge there in the person of the Chief Engineer.) Galison’s book is full of examples of fertile cross-pollination between disciplines, and even of individuals moving between disciplines (from meteorology to particle physics!), but the disciplines nonetheless retain their own individual character.

What should agile learn from this latter difference? I can think of two arguments in favor of breaking down such boundaries in the agile tradition: one is that it increases knowledge sharing (and the fertilization that results), and the other is that it increases resource flexibility. Galison certainly agrees with the former, but, as we’ve seen above, provides other mechanisms by which it can occur. He doesn’t, as far as I’m aware, address the latter; certainly something for me to think about in the future.

It’s an excellent book. I’ve only discussed the last chapter here, but I really enjoyed the more historical sections that preceded it. Great stories, great pictures, I found something new and interesting in every section.