« A Smoky Kitchen | Main | Alienated from the Arcade »

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 January 31, 2011 09:01 AM

Comments