« December 2010 | Main | February 2011 »

January 31, 2011

Birdhouse

Hank answered the door to find his friend Ralph waiting outside. “Oh, hi, Ralph, come on in, the wind is blowing cold off the pond out there! I’m just working on a little project, come on back.”

The two shook hands and went back to Hank’s workroom, where bundles of sticks lay strewn about and on a worktable, a small house fashioned of sticks was beginning to take shape.

“What’s this, Hank? You thinking of starting a fire in here?”

“What? Oh, the sticks. No, that’s all for this little project I’m working on in here. What you see before you is the beginnings of a birdhouse I’m putting together to hang outside come springtime.”

“From sticks? I wouldn’t have thought that even possible. How are you holding it all together?”

“Well, I found that if I carefully heated some green pine, I could get some nice warm sap to use as a bit of glue at the joints here in the corners. It took some experimenting to get just right, but that’s one of the things I came up with.”

“But that must take forever! Why not just go buy a couple of pieces and some lumber, bang ‘em together with some nails, you’d be done in an afternoon.”

“Well, Ralph, as you know I’ve been trying to keep myself from taking odd jobs -- I find when I work for others, my conscience makes me use a lot of my mental power on the work, and I find I have little energy left for my writing when I come to take pen to paper. Lumber is cheap, but it’s not free, and neither are nails. These sticks dropped down in that Nor’easter we had a couple of months back.”

“Sure, I recall.”

“Anyways, that birch by the front porch came down in that storm and I found myself thinking the birds who nested there would need a place to nest come spring, and I do so like hearing them in the mornings when I write before breakfast. They’ve done me a lot of good, and I decided I’d repay the favor to have them back again. I plan to hang this house under the eaves.”

“I can understand that.” Ralph sighed. “It just seems as if you’re putting in a lot of work, and having to figure out a whole lot. It just seems unusual to me.”

“Well, sure. It’s not what most would do. But this works for me: not only do I not have to take a job to pay for the lumber, but it gives me something that I can write about. This project is a birdhouse now, but in a week from now it might be an essay I can sell. Now, what do you say you help me get this roof on, and then we can go smoke our pipes on the porch? Hand me that little pot of pitch off the wood stove...”


One of the things I’m aiming for with this series of posts I’m doing with the AltDevBlogADay group is to find a constraint that helps me improve my writing, and I’ve chosen to do so by restricting myself to telling a parable and then spending a little time explaining what I mean by that parable or anecdote. I don’t often have time for creative writing, although I enjoy it, and so I’ve put myself under a constraint that forces me to write at least a little bit every couple of weeks in hopes that it’ll inspire creativity. In this parable, I recall an author who most elegantly introduced me to the topic under discussion.¹

One would tend to think that having as much time and money and resources of all kinds will lead to the very best games and products. In fact, often engineers will say or think to themselves that if they just had more time or more people, they could really make this library or module sing.² It could do x, y, and z. Indeed, many programmers will start out with a lot of architecture to solve a large domain of related problems, and end up leaving many loose ends when it turns out they don’t have the time to fill out all the functionality, which I’ve seen both in novice code and commercially licensed engines.

But, as it turns out, this is exactly the opposite of what really works, in engineering, in design, in craftsmanship of any kind. What really works is to identify constraints and work within them. Constraints inspire creativity.

In the parable above, what Hank really wanted to do was to have time and material for writing, not money for goods and services. He had identified a constraint he wished to place on his own efforts -- to work as little as possible for others, because that work cost him things that were more precious to him. Indeed, reminding himself constantly of that constraint made him able to creatively solve problems -- in choosing to build a birdhouse by hand, he found he needed to manufacture glue, which lent itself to a creative solution. There were a few elements at work here:

  • He didn’t shirk the problem. Sure, Hank could have said good-bye to the birds once and for all, but he decided that this was a problem he wanted to solve, even if it meant difficult work. It’s easy to avoid problems altogether, rather than trying to solve them within your constraints.
  • He kept his constraints always in mind. He didn’t run to the hardware store at the first sign of trouble, which left him problems that he needed to find solutions to within his constraints.
  • He chose his constraints. What he wanted was time and space to write and think, not money he would likely not even have the time to fully spend. It was a conscious decision not forced upon him, in this case, though external constraints themselves can have value.

Time and again I’ve seen the value of constraints in game development, or heard wonderful anecdotes about how some problem was creatively solved despite the lack of engineering time to fix it “properly”. Here are a couple of memorable ones.

  • Dark Forces had a simple scripting language but no variables -- it was a simple command language, where certain types of world state could be set, but it didn’t have variable support. One of the things that could be controlled from script was moving elevators. So, unable to get direct language support for variables, level designers instead would place elevators in the world, unreachable by the player and never rendered, and move them up and down to represent variables.³
  • Star Wars: Jedi Starfighter had inherited a very simple scripting environment from its predecessor, and although we extended it in some simple ways, it wasn’t a language that had a lot of state. When level designer John Drake approached me and said he wanted to implement a tug-of-war between the player’s forces and the AI, moving resources back and forth through a space in the level, I thought it couldn’t be done without code support (which we didn’t have to spare). But John pushed that language to its very limits to produce one of the most interesting and tense battles of the game.4

Those are a couple of areas where craft had to respond to constraint with creativity. There are ample examples in narrative and design as well. Consider:

  • The storyline behind both Ico and Shadow of the Colossus, two of my favorite games, boils down to “young man rescues the princess”. Each use a pared down design as well, constrained to few player actions in compelling environments.
  • Take your favorite indie game. Indies are severely constrained in resources, limiting all aspects of their process, from development to marketing. Yet each successful indie finds creative ways through the morass, from new business models to clever marketing to innovative gameplay to simply crazy fiction.

Constraints don’t just apply to your development or design environment, such as coding languages or scripting, or how you can spend your polygon budget, but also to development itself. As a parent with a couple of grammar-school-aged sons, I have quite a number of constraints on my time that I’ve chosen. When I started at my current employer, I let them know about those constraints -- that I have kids, that there are nights of the week where I am their sole guardian, that I’m very involved in their sports and activities, and that I simply wasn’t available to be at work during those times, even if the team was crunching. This was definitely a choice as some of these constraints are more flexible than others; while I must be around when they are in my care, I’m not obligated to coach their teams.

I try to keep this constraint in mind throughout the life of the project; early in the project, when it’s easy to lose focus and meander through your tasks, both those that you choose and those that are chosen for you. But keeping in mind at all times that the time you are spending is all the time you’ll have helps focus you on remaining efficient, removing as much waste from your workday as possible.5 Early on, I invested in projects that would pay off not only immediately, but in keeping me able to maintain that constraint when the ship date was looming. It’s far better to choose that constraint early than to have a different set of constraints forced on you at the end.

So, I turn it on you, fellow developers. Pull up a chair, grab a pipe, sit a spell, and tell me: how would you comport yourself if you had that constraint? How would you act today if you knew you could only work the forty hours a week we theoretically sign up for? And what other constraints would help inspire your creativity?

¹Bonus points if you can identify the characters here and where they are.
²I’ve been very guilty of this myself. It’s an easy trap to fall into. I call it "worshiping at the altar of Yagni".
³We had a similar limitation in the first Star Wars: Starfighter game, where although there was no variable support, an LD used the fact that he could react to changing properties on an object to set the radius of a waypoint up and down and fire off scripts based on those, depending on where the player was in the level. It was crazy, but it worked.
4The level as originally designed and balanced was made for and by expert Starfighter players and it really gave me a run for my money when I played it during our beta period. We ultimately made it easier, but beating that level on its original difficulty was some of the most fun I had building that game and testing it during development.
5I often jest with a colleague, “Hey, we gotta get going, we only have three years to build this thing!”

Posted by Brett Douville at 09:01 AM | Comments (0)

January 16, 2011

A Smoky Kitchen

David boarded the tour bus, smelling acrid smoke as he entered the main cabin. “Nigel, what’s going on in the kitchen, it smells like you let the Stonehenge effects off in here!”

Nigel indicated a pan aside the stove. “I overcooked the pork patties.”

“How did that happen? They take like four minutes, you throw them on medium and just make sure you turn them.”

“Well, I put them on the front burner and...”

“The front burner? In that pan? You know you have to use the heavy pan on that burner, it runs hot. Don’t you remember Derek’s Bean Surprise?”

Both shuddered involuntarily. Derek had had his cooking responsibilities delegated away after they had lost a drummer to Derek’s Bean Surprise.

“I wasn’t thinking, I was thinking about that hot pink 12-string I picked up in Pittsburgh. I put a cover on the pan and got the guitar out to tune it.”

“Yeah, but man, didn’t you smell the smoke?”

Nigel stared. “You know how I am with a guitar in my hands. I only noticed once I had tuned the first neck. Smoke was everywhere.”

“Great. Just great. Well, that’s all we’ve got for breakfast, and we can’t stop because we’ve got to get to Sioux City for the 7pm show.”

Just then Derek entered the bus. He took a whiff and said, hopefully, “Bean Surprise?”


This little parable¹ illustrates a few problems that I think constantly assault us in game development, either as small developers or parts of big teams. But the big one I want to talk about today is the trap of divided attention/multi-tasking.

When he went over to tune his guitar, Nigel got caught up in a new feedback loop, and his senses were attending to that -- putting all of his focus on the guitar caused him to slip easily into a flow state² where the feedback of tuning his guitar occupied all his attention. Only when he had a natural break did his senses have a moment to attend to the environment around him, and that led to the discovery of a ruined breakfast.³

Despite our hopes and dreams to the contrary, human beings are not actually able to multi-task. We use machines which can do so many different things at once that we begin to think we ourselves can do more than thing at once. What we're able to do is fool ourselves into thinking we are multi-tasking by switching rapidly between tasks that we focus on completely. Indeed, doing little chunks of tasks like this is insidious precisely because accomplishing little bits of things constantly causes our brains to release dopamine, which is a tasty little reward4. So it becomes a vicious cycle of check Twitter-type three lines-kick compile-browse RSS-respond to email interruption-Twitter again-oh wait, compile is done, what was I doing?

Our brains just don’t work well that way -- we can really only put our attention on one thing at a time.

Clifford Nass is a Stanford researcher that investigates how the human brain works. In the clip above, he suggests dividing your time into 15 minute chunks, and at the end of each 15 minute chunk, simply choosing deliberately at that time what to do for the next 15 minutes.

The key here is to actually commit those 15 minutes -- if you decide you’re going to look at your email, you need to do so for 15 minutes. I can tell you from experience that it only takes spending 15 minutes on email a few times before you start only checking your email once or twice a day, maximum, because it gets really tedious to stare at a bunch of old mail. And as someone who receives quite a lot of email at work, I can say that no one has commented on how slow I’ve gotten on replying to emails or anything like that despite the fact that I am reading and replying with less frequency.

When I decided to start experimenting with 15 minutes, there were times I particularly had difficulty in remaining focused on the one thing I was supposed to be doing. For example, time spent compiling can seem like “dead time”, time when you’d really like to be doing something else, browsing the web or reading things close at hand, whatever. But what I found was that often I would get absorbed in those things and lose track of what my next step had been -- I quickly dropped out of flow.

Here’s how I work in 15-minute allotments:

  • I put my iPhone on my desk near my keyboard, and pop open the clock to set a 15 minute timer which plays an interrupting sound when it’s done. You might think that this interruption would disturb my flow state when I’m coding, but in practice, I’ve found that if I’m hotly pursuing some problem, I immediately start the timer over and dip right back in without missing a beat. It took a couple of days to get to that point, but now it’s basically an automatic, muscle-memory response when I’m working hard on something.
  • I also keep a running tally of tasks I’ve worked on open in a text file minimized on my desktop, as a reminder that I am consciously deciding to spend a chunk of time on something. This turns out to be useful at the end of the day, when I send out a little list of things I worked on to my colleagues5. I only enter items when I actually switch to another task, and I try to pursue that strictly. I can look back at the end of the week and see the trend of having started out reading email too frequently but having trended down to a more reasonable level over time. The other benefit here is that if I put everything in it, I am less likely to spend time on newsfeeds when I want to be working... those are good things to do while I’m at home zoning out on the latest season of Dexter or while eating lunch at my desk.
  • I keep a pad of paper near for thoughts which occur while I’m doing something else. While it can seem silly to have both a text file and a pad of paper, what I’ve found is that I more easily stay in flow if I jot notes to myself on paper. I think it’s because I’m using slightly different parts of my brain to do the work. The break to do something else after 15 minutes is already a time when I expect to drop out of flow, but the key here is to reduce the times when I might get distracted in the middle of a task.
  • As Nass advises, I’ve limited my sources of distraction. I get no email notifications, though I do leave myself open for IM, since I manage a bunch of programmers and like to be available to them. While I leave a twitter client running, it doesn’t make any noise or display any notifications either, it’s simply there to vent off random thoughts I might have. Let me tell you, I spend far less time on twitter now that checking it involves 15 minutes of it. Instead, I find myself looking quickly through it while I wait for my lunch or coffee.

Switching to this way of working has made me more productive overall, despite apparently doing less at any one time, both in my professional work and when working on my home projects.

And it has led to drastically less smoke in my kitchen.

This entry has been cross-posted with #AltDevBlogADay, where a number of game-dev related folks have banded together to provide articles every day, on a rotating schedule.

¹Based on a true story, set in my kitchen, and involving an acoustic, 6-string guitar...
²Flow has been covered by a lot of different folks, so I’m not going to go into it in much detail here. Track down a copy of Mihaly Csikszentmihalyi’s Flow if you’d like to read about the neuroscience. It’s a dense but quite interesting book.
³I used this example in the parable explicitly because this happened to me. I’ve only recently started learning the guitar, and when I went to tune it using an electronic tuner, the feedback loop of tuning strings and seeing the needle move put me into a state of flow almost immediately. Only when I had finished did I actually notice how smoky the room had become. Which reminds me... perhaps it’s time to change the battery in the smoke alarm...
4Farmville anyone? Dopamine production is largely the reason why we think of some games as ‘addictive.’ Something like a World of Warcraft gives frequent feedback in little digestible chunks -- attack effects, loot drops, etc. -- which mask the highly repetitive nature of the time you’re spending. A topic for a whole 'nother article, but just wanted to give you a little bit of context for what I’m talking about when I mention dopamine.
5My group consists of eleven engineers, including myself, and we each send a mail called a “five-one” at the end of the day, on the theory that it takes five minutes to write and one minute to read. With an investment of 15 minutes on a given day, then, we’re up to date on what others are working on in the group. This can be really helpful in quickly tracking down new issues, or noting trends, or avoiding work collisions.

Posted by Brett Douville at 09:00 AM | Comments (2)