April 30, 2015

Wednesday Workout: Coding the Classics

So, I've decided to start streaming some game development -- but I'm not yet at a point where I want to show the game I spend most of my time working on. A dilemma!

What I've decided to do instead is once a week, code up an old video game in the space of an hour or two each Wednesday at 4pm Eastern, over at my Twitch channel. There are a couple of reasons:

  • I often tell people who are trying to learn how to code games that I think there's value in simply coding up older, simpler games. But it's hard to know where to start, so why not go ahead and show how.
  • Longer term coding streams don't have a lot of closure; you aren't really putting a bow on the game at any time in the near future. I figure there's some value in something a little shorter term -- like an hour or two. See a game from beginning to end.

I did the first one on Wednesday April 29th (yesterday, as I write this post) and it's archived in two parts on my Twitch channel and also on my YouTube channel. I got really flustered with some non-working code in the middle, paused the stream, and came back.

It is really hard to code and talk and pay attention to chat/answer questions and all of that at the same time. I'll get better. Kudos to Casey Muratori and my friend and former colleague Jean Simonet for doing it on a regular basis. As well as anyone else who does it. Yikes.

Finally, I have a little bit of template code that I use to code this stuff up. You can download it here. Just right-click and "Save as", etc. There are build scripts in there for both OSX and Win64. You'll need to download your own copy of SDL2 and install it on either platform. (I go ahead and just put the DLL inside the Windows "Run" directory on my system, so it gets copied every time I make a new project, but haven't included it in the zip so as not to confuse OSX folks following along.)

Posted by Brett Douville at 01:56 PM | Comments (0)

May 19, 2011

Interview on the Bethesda Blog

Quick post (real ones coming soon, promise); an interview with yours truly has shown up today (or perhaps yesterday) on the Bethesda Blog.

Posted by Brett Douville at 02:45 PM | Comments (1)

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)