I don’t like the idea of three years of a person’s life going to waste on any level, so I contacted him to try and find out what was going through his head.

Tell us a bit about yourself

I’m a software developer from Seattle. Most of the time I’ve worked on game technology, so I worked on the product called Granny at RAD game tools, which is a 3D character animation system. Right now I’m working on Bink 2, which is a video compression program. It’s the program that all games play their rendered cutscenes through.

_{[When he says “all” games, he means it. Bink has been used in 15,000 games and counting]}

You regularly do podcasts with the head of RAD game tools, Jeff Roberts. The impression I get from hearing you talk about software is that you take programming extremely seriously

Definitely. I’ve been a programmer since I was seven years old -- for my age that’s pretty rare. My father happened to be a programmer, and I used to keep asking him “How do you do this stuff?”, and so he taught me. The culture I grew up in was with people who had originally learned to program with punch cards, where knowing assembly language was a pretty standard thing.

These days, a cellphone has the same resolution as a computer I was using in 1986, it’s a thousand if not tens of thousands of times faster -- and it’s still lagging all over the fucking place. Programmers today have no appreciation for the hardware that they have, and they piss it all away.

I’m curmudgeonly at this point because of where I learned to program and who I admire and the kinds of things I admire about programming. I see basically no one doing that today, and so RAD game tools is a good place for me.

Is programming an art form? Using whatever definition of “art form” you think is most relevant.

I’ll give you a two-pronged answer.

One way I could take “art form” is “there is no prescriptive way to get a result”. People sit down and say “I need you to program x for me”. “Art form” there becomes a craftsmanship term, like making furniture or building a house. A very skilled craftsman creates works in a way that is not necessarily easy to duplicate, and not prescribed in the original statement of what they were trying to do. In that sense, I think almost all programming is an art form. In general, anything of any sufficient complexity is going to have a lot of subtle, personal decisions that get made in the way that you construct what you construct.

There’s another way I could take “art form” which is “creating something which communicates between the person who made it, and the person who consumes or uses or experiences it”. In that case, there are some types of programming which are a communication between you and the person who’s experiencing the program, and there’s others that aren’t.

You’re friends with Chris Hecker, Jon Blow, and Sean Barret, three people who did the same thing as you: worked programming software and graphics for a long time, but then decided to make your own games. Why did you all do that?

Again, with the “two types of art” definition, If you like communicating, and I think all the people you’ve mentioned do, then writing functional code that people use is a bit limiting. You’re not able to communicate with an audience in any way, or get any communication back from that audience in the way you do with a game. People who work on code for a living will get that feeling, if they are natural communicators.

Jon Blow is a natural communicator with games -- he was made to do it. Me, on the other hand ... I don’t know if that’s true. My experience with Sushi Bar Samurai may have been largely because I’m not ready to take that step yet. Or because I’m not a natural communicator with games.

What were you trying to communicate with Sushi Bar Samurai?

I didn’t know that [communication] was important when I started, and that’s why I didn’t finish that game. The things I’ve just said are with the benefit of hindsight.

I really didn’t know what to do with the project. If you look at its evolution over the first year or so ... there is a game within the first month, January 2005. I had a game which was basically Diner Dash. There were people ordering, and you had to make basic sushi orders that you had to feed to them. That game was almost finished.


_{Diner Dash}

But when I looked at it, I was like: “this is a game about someone having to do a menial task ... ” There’s a reason why I’m not a short order cook -- it’s because I think that would be a really boring job, and here I am making something where this is what you have to do, and by the way you have to pay for it.

Oddly enough, it turns out, that’s a totally moneymaking strategy! There’s a long history of games like that and it totally works. And it’s a pretty easy thing to make! But it’s like: “Why am I making this?”.

So I tried to branch out from there, and I tried many incarnations over the next two years, leading up to the PAX demo version. Although that version was marginally more interesting, it still didn’t have anything unique about it that I really understood.

If I was starting again today, before I would ever start making a game, I’d have a very concrete explanation of what the game is supposed to express, and how I’d want to express it. That, above all else (if you’re not just trying to make money) is the only way you can really know if your game is done or good. You can tell if it’s fun, or if it’s addictive, just by having someone play the game. But you can’t tell if it’s good, or meaningful, by your own definition, if you don’t know what [that definition] is.

So you’re not releasing the game because you feel it doesn't communicate enough?

It doesn’t really communicate anything.

You recorded a podcast after demonstrating the game at PAX. You sounded so inspired by the people you’d seen on the floor that you were overcome with new eagerness and zest to improve the game. And yet, paradoxically, it sounds as if those people who inspired you are part of why you’re not releasing the game?

That’s a very good way of saying that.

Of indie developers, some of them start out making their own games, and then some are like me -- you work at EA or something like that, you go through that system, and then you strike out on your own. One thing that happens uniquely to people in the second category is that ... there’s a great deal of commoditization of the audience that happens from your perspective, whether you like it or not. Once you’re through that system, once you’ve been in that culture long enough -- five years, ten years -- you start to think not about individual people and who they are playing your game, but about numbers. Like, how many people bought this game, how many people played this game, what did Metacritic say about this game. And that’s not because you’ve become cynical, it’s just that that’s all anyone ever talks about.

The thing that’s really eye-opening about showing your game at PAX (or at least the PAX 10 booth) is that the people who come by are a much more individualistic and thoughtful audience than you would ever believe existed for games. The questions they ask, the way they play the game, give you a much more respectful opinion of the audience. And, again, that makes it very difficult to ship a game where you were just thinking about the abstract “is this a fun game (i.e. will this sell copies)?”.

Once you’ve had that kind of experience ... that changes the kind of game that you want to ship to that audience.



You’re now writing fiction. Has game design taught you much about writing?

It’s almost the reverse. The Technician was originally a game design which I decided to turn into a book since I didn’t like how game design went.

I sat down and asked, of Sushi Bar Samurai: where did I think it was going to be before I started? How did it end up? What was missing from it? Was it wrong when I started or were there things I wanted to have that got lost along the way?

The core conclusion I came to is that I’m not a mechanics-oriented game player. I can’t sit down to enjoy a game of Tetris. I like to have a fictional experience; I like there to be some wonder and exploration, and characters. And in the original plan for how Sushi Bar Samurai was going to be, I had all that. That was more essential to what was supposed to happen but it got stripped out because I focused too much on thinking that the mechanics were wrong.

With The Technician I thought: “I’m just going to see about doing some writing”. To be satisfied with a game product in future I’ll have to learn to deliver a good fictional experience. Fiction is much easier to deal with in its traditional, linear form. Practice there, get good at that, then go back and see if you can do that in a game.