« February 2011 | Main | April 2011 »

March 16, 2011

The Apprentice

“Always two there are, a Master and an Apprentice...”

My ten-year-old son told me over the weekend that he has a school project where to understand colonial life, they are supposed to find a master craftsman and learn a skill from that craftsman in the way that skills were passed on at that time. After mulling it over for about three, maybe four seconds, I offered to teach him a little bit of video game programming¹ if he’d be interested.

He thought about it and told me the next day that he thought that would be pretty cool, and he seems really excited about it. Tonight we sat down and filled out his apprenticeship contract.

The Contract

After that we talked about how apprentices sometimes got something that they would need for their trade from their masters when they started out, and I told him that probably the most important thing to me when I’m writing a program is to have a good notebook to keep my thoughts in, both to write down ideas as I get them and to keep track of things I still have to do. I happened to have a couple 5”x8” Moleskines with quad lining and so I gave him one of those and we wrote his name and the date in it.

I showed him the notebook I use for personal projects at home, with pages of checklists for various projects in various stages of development. So, the first thing he wrote down in his notebook was “make check lists and keep organized.” So proud!

Well, that was enough of preparation so we jumped right in and I showed him a little something I’m working on, which is a simple tool I’m writing in Javascript and HTML5 for a home project². I showed him the few things it does (I wrote what I have in an hour or so this morning) and then we cracked open the source file and I showed him the script that produced what he was seeing. Part of what it does is to present an image centered on a canvas and allows you to zoom in and out on it, so I showed him how the program responded to keypresses (this took us on a quick detour into ASCII, but only just) and updated a bit of data storing how much to zoom the image and then I went into the place where the image is drawn on the screen and came across this:

    w = picture.width;
    zw = Math.round(w * zoom);
    var x = (dimx >> 1) - (zw >> 1);

Oh, right. Centering on the screen, just wrote this ten hours ago or so not knowing I’d be using it to teach, and there’s bit-twiddling in my very first example.

As it turned out, it was a perfect example. They’ve covered decimals enough for him to understand shifting in principle... he just hadn’t ever been exposed to binary. So we jumped in with both feet and I wrote down the number 12. “So,” says I, “you’re used to this number when it’s written in decimal, what is it?” “Twelve.” “Correct! I can also write that number using only ones and zeros!” And I wrote down 1100 next to it.

“Wait, so, how is that twelve?” I explained that just like with decimal numbers, each column was associated with a value. In decimals, it’s ones, tens, hundreds, and so forth, but in binary it’s just starting with one and doubling as you go:

On your fingers?

He totally got it, which was really thrilling for me. I joked that you shouldn’t really trust someone who can count to a thousand on his fingertips and he gave me a quizzical look, so we moved along.

Next I explained that what I was doing in my little bit of code I showed him was called “shifting” and diagrammed out what was happening, showing the result

Shifting and dividing

He thought that was really cool. So I took the TV remote and the pad of paper and explained how I was figuring out where to start drawing my picture so that it would be centered. We worked through the steps in the math to figure it out.

As it turns out, the little tool I’ve been fiddling with is for rotoscoping some images I have and want to use in a forthcoming personal project, should it see the light of day³. I went up on YouTube and showed J some early examples of rotoscoping in videogames -- particularly Karateka, which was one of the first graphical games I ever played on my old Apple II, and Prince of Persia, which came along a few years later. I even showed him bits of Another World/Out of this World in silent tribute to Chahi, who reminded me of the technique at his GDC postmortem4. We talked about how natural the motion looked even though the graphics were really really simple, and he thought that was really neat. I explained how games had started even simpler, and showed him a video of Pong, too.

This led us to a little discussion of how much more powerful computers are now. I dug up a picture of an Altair 8800, and showed him how there hadn’t really even been monitors on some of those early machines. I explained how I wrote my first programs on something that didn’t even have a hard drive, just floppy disks. I showed him how much performance had changed by opening up the “About this Mac” window in Finder and comparing that with the memory and performance of that Altair 8800. We used our new understanding of binary together to show the big difference between the two -- doubling performance *how many times*?

We were starting to run out of time, and so I wanted to leave him with a basic lesson for the day, even though I had kind of come into the whole thing unscripted. I returned to my program and pointed out that there were really two kinds of things going on in it, functions and data. I explained that a program was really just a bunch of functions that took data and turned it into other data.

He knew it was important. He jotted it down:

What's a program?

I don’t know what kind of game we’re going to end up with, but I’m glad we’re getting a chance to do it. I hope that we’ll be able to finish something by the time he needs to give his presentation in May, and I think that’s ample time. My apologies to all of you working on or waiting for Skyrim, but I think whatever J’s game is, it’s the most important game I’ll work on this year.



¹His brother did this two years ago and learned how to cook a particular dish from his mother. I think the emphasis is on the master/apprentice relationship and not the historical appropriateness of the skill.

²I’m not convinced that Javascript is the best approach for him, but there are some features which make it nice and a constraint that makes it fairly convenient. First, it has a super quick iteration time, edit text and reload in browser, which I really like -- there’s no compilation step. It also has the virtue of being web-friendly, and the web is something he already sort of understands and sort of uses. As for constraints, well, he won’t be working on things just at my house, so having an environment that I can throw on a thumb drive for him (or even email easily, should it come to that), is really nice.

³If it does, it releases Father’s Day. You heard it here first.

4Well, me and hundreds of others. :)

Posted by Brett Douville at 09:31 PM | Comments (13)

March 11, 2011

GDC 2011 - Late Wednesday to Early Thursday

Here’s the second in a series of posts covering what I saw at GDC 2011, covering from mid-Wednesday to mid-Thursday. I’m going to finish the “reporting” posts and then hopefully return with a post to tie up the kind of “themes” I was pursuing at the conference and what I learned along those themes.

After the microtalks, I walked over to Frank Lantz’ talk on “Go, Poker, and the Middle Way”, which involved an overview of the tensions in Go and a fairly personal reflection of time Lantz spent getting to know the game of poker. With respect to Go, which I gather Lantz hasn’t spent as much time with, he spoke of high-level play being a reflection of wisdom and experience, the interplay between concerns of a global nature and a local nature¹. Turning to poker, he spoke in-depth about his personal experience with the game, talking about how poker will break you, and that that is part of any deep experience with the game. He spoke of how “if poker is a meal, failure is an essential ingredient” and said that it’s not a simple thing that in-depth poker play changes how you view the world, that uncertainty becomes a kind of knowledge, and he intimated that he finds that sublime².

From talk of failure in poker I went to the “Failure Workshop”, where various indies talked about past failures and the lessons thereby learned. These were kind of “live postmortems” with personal reflections about how things went wrong, from the high profile failure of Stardock’s Elemental: Art of Magic, to unreleased work by the likes of Ron Carmel, Chris Hecker, and others. Chris Hecker identified the root issue he faced with his own failure, which was a fear of game design (he found many ways to avoid game design in development of his own failed title, including speaking at conferences, finding multiple technical solutions to problems), and which he has been attempting to address with Spy Party.

For my last seminar on Wednesday, I took in Kent Hudson’s talk about player-driven stories. Hudson presented a good talk last year on how the AI evolved on Bioshock 2, and how they addressed shortcomings in their development process mid-stream to deliver on the gameplay they really needed. Ultimately, I was a little let down by the talk; it seemed like it started to build a case for how to put together truly player-driven stories, and then came to a point where it seemed like “magic” had to happen³. I did think he made good points about story bits overall, that you can present story in some smaller, unique ways and that if you choose to go that way, you really need to “own” it -- really delivering the best you can in the area you choose, whether that be stylized still frames (like a comic) or the right kind of voice-over or what-have-you.

Thursday morning started off with a bang, with Eric Chahi presenting a post-mortem of Another World, a highly regarded game for many4. It was a really personal reflection of successful development, starting with a statement that for Chahi, “the nourishment of ideas is as important as the ideas themselves.” He described how he established his constraints early on and improvised within those constraints. From a technical standpoint, the game was built to be run with an interpreted language -- this made for the quick turn-around that permitted inspiration to flower. Chahi was really interested in the flow and rhythm of films, and he tried to replicate that rhythm in the rise and fall of action in the game. Furthermore, how scenes played out often reflected his personal feelings at the time, especially the loneliness he felt as a lone developer on this early title. This was a really terrific talk and it further amplified my interest in Chahi’s upcoming title with Ubisoft, Dust.

I'll pick up next time with another old-timer, Chris Crawford, the founder of the now 25-year-old conference.

¹As it happens, I was reading David Mitchell’s The Thousand Autumns of Jacob de Zoet shortly thereafter, which features Go analogies somewhat heavily between two Japanese officials.
²Watch that word, “sublime”, it’s going to come back when I discuss Moriarty’s talk which was on Friday.
³Perhaps this just means a “significantly advanced technology” at this point, but the two have been epigrammatically linked as indistinguishable from each other.
4I admit that I haven’t played it, but I intend to rectify that when the game becomes available for the iPad, which Chahi announced late in the talk. It’s one I always wanted to play but never found time for.

Posted by Brett Douville at 07:51 AM | Comments (0)

March 07, 2011

GDC 2011 - Wednesday, Part 1

This is the first in a short series of posts about last week’s GDC in San Francisco. I’m not sure how many posts as yet, but probably no more than three or four.

I came to GDC early this year to participate in some pre-GDC stuff. Game night with friends Saturday night, pre-GDC Board Games on Sunday night, and then Monday and Tuesday caught up on the city, including a visit to SFMOMA, which is one of my favorite museums in the world, and a little time with a friend from Double Fine. Tuesday night, too, was time for friends, with dinner with some great friends from Sonoma County and a visit to the bookstore with them.

Wednesday morning opened early with a keynote from Satoru Iwata, president of Nintendo. It started well, showing trends in the industry over the past few years, and also recapped a little of his personal history with games and game development. Unfortunately, this was interrupted with a visit from Reggie Fils-Aime, who came up to the stage to sell us all on the 3DS. It wasn’t what I had come for, and although I wasn’t entirely surprised, I did feel like I was sold a bit of a false bill of goods by the lecture title. Iwata returned to the stage with his concerns for the future, which were loosely as follows:

  • Craftsmanship: Iwata is concerned about game quality, as we all should be.
  • Talent development: Modern game design and development has become more and more about specialization¹, and Iwata feels a well-rounded, balanced person is where the really great work comes from. He asked rhetorically, “Where will the next generation of master developers come from?”
  • Price pressure: This one was a little jarring, coming as it did while Jobs prepared to announce the iPad2 literally next door to Moscone North. Iwata is concerned that it will be difficult to provide experiences like the Zelda games should prices be driven low, and that game quality will suffer. I could, and may, write a whole post about this, but my quick gloss would be that the landscape is changing; we need either to provide an experience which justifies its cost or bend to the current environment.

Next up was Clint Hocking, who tackled the origin of meaning. I’m looking forward to his slides, since over the course I took few notes (knowing that the slides will be forthcoming). Hocking subscribes to the MDA Framework (Mechanics, Dynamics, Aesthetics), about which much has been written, and he used it as a means to examine the potential sets of meanings which came from his own games. It was a really terrific talk, and I look forward to thinking it over further once the slides appear on his site. I spoke with Clint later in the day and commended him on what I felt was likely to be the finest talk I saw this year, and he cautioned me that it was early yet -- he was right about that, and more on that when I discuss Friday’s talks.

Around lunchtime was the GDC Microtalks, which I thoroughly enjoyed last year. This year was no different -- the format is that each speaker presents 20 slides which are visible for 16 seconds; all presentations are meant to touch on a particular theme, which this year was “Say What You Play.” Though I took notes on each speaker and enjoyed each talk, I particularly took things away from:

  • Michael John, who spoke about “playing” with games by working with his daughter on building one with Scratch, something that I’d like to do with my own kids
  • Jamin Warren, who urged game players to talk with non-players about what experiences they’ve had, to tell stories to encourage others to give it another look. It called to mind the gentlemen at the Radio Lab podcast and radio show, who have made similar points about the importance of storytelling to changing public perception about science.
  • Asi Burak, who suggested that maybe our immense financial success has caused us to cease challenging ourselves. I’m not certain that’s true, but it gave me pause to think about it, and
  • Brandon Boyer, chairman of the IGF this year, who exhorted us to speak more to the human condition, to delve into sincerity, to bring into existence what we must.²

Well, I’ve got to get up and out to work, so this will have to do for the first post. I’m about halfway through the first day, so at this rate it’ll be about six posts, but I suspect it will actually be fewer. In any case, we’ll see, join me over the next few days (and in the RSS feeds if you prefer).

¹Particularly true of programming, but not just true of programming.
²For my own small efforts in this area, see “Personal Games” in the sidebar.

Posted by Brett Douville at 08:39 AM | Comments (2)

March 05, 2011

Knives

Jacques tied the apron around his waist as he finished surveying the ingredients in front of him.

“You know, Dad, I’ve always wondered why you keep so many knives.” His daughter Claudine had come up behind him while he was collecting materials for dinner. “Can’t you just have one or two? I mean, you have several knives even at the same length!”

“Oh, hi, Claudine. Pour yourself a glass of wine and a little more for me, and I’ll answer that as best I can.”

As Claudine poured Bordeaux into two glasses, Jacques picked out several short-bladed knives and moved some raw foodstuffs to a nearby cutting board.

“Now, see here, Claudine. I’ve taken many of my three-inch blades and laid them out here before you. Can you see any obvious differences?”

“Sure. That one there has a serrated edge, that one has a weird curve to the blade, and that one looks a little like your big chef’s knife.”

“Very good, Claudine. Each is different.”

“But why do you need all of those?”

“Well, each of these is better at a different sort of job. That serrated one you mentioned is particularly good for cutting tomatoes, or perhaps sausage. Its wavy edge allows it to slice cleanly into something that is a little bit soft in the center but has an outer skin. You see?” He sliced cleanly into a tomato, slicing it very thinly indeed.

“What about this curved one?”

“That’s a great tool for peeling fruits and vegetables -- the curve of the blade fits to the curve of the fruit.”

“And this one with the wedge point?”

“For removing the eyes of potatoes.” He demonstrated deftly, with a flick of his wrist.

“But couldn’t you do all of these tasks with any old knife? I’ve seen you make full meals with just your chef’s knife, especially when we’ve been vacationing.”

“Oh, certainly I could, Claudine. Most knives are good at doing many things, but these other knives are particularly good at doing one thing. And that lets me move a little more quickly in the kitchen, or make something just a little bit better. For example, when I use the serrated knife to cut tomatoes, it’s much easier to do so without bruising the fruit where the knife goes in.”

“Oh! Didn’t it take you time to learn to use all of these?”

“Well, of course, Claudine. It’s taken you a long time to learn the proper glass to use for each type of wine you drink, and why, n’est-ce pas? With knives, it is much the same thing -- I have some basic skills I use again and again, but I have to tell you, getting familiar with a new blade is such a pleasure.”

“A pleasure? I know you love to cook, but why such a pleasure from this specifically?”

“Well, each knife I’ve come to know has changed how I look at the ingredients I use for my cooking. I might realize that there are ways to look at preparing foods I’ve prepared before just a little bit better, or come up with a new way of thinking about a dish. Perhaps I can slice something thinner, and get a subtler flavor.”

“Does it make you a better cook?”

“Having more equipment doesn’t make me better in the kitchen, I don’t think. But it does let me use my skills in more ways, which might make me capable of doing more things, or doing some of them a little better. Being a good chef is in the soul and the hands and the senses. Now shoo, if we’re to eat tonight I’d better focus.”

“May I help?”

“Absolument. Take this serrated bread knife and cut that baguette on a diagonal...”

Today I want to talk a little bit about the very fundamental tools of programming: the languages themselves and some ways in which I’ve come to view these languages over the past few years.

When I began programming professionally, I spent a great deal of effort becoming proficient with C++¹, reading as much as I could and attempting to apply new techniques to problems as I encountered them. I learned from experience and the wisdom of those around me, and I would say that I had learned many of the fundamentals of programming. In the little parable above, this is like learning to use a single knife² proficiently -- one learns many techniques that will allow you to prepare ingredients in the service of your meals.

I spent a lot of years coding exclusively in C++. I read numberless books on the subject, designed systems in it, coded tools in it. It became the lens through which I viewed many problems in game development³. I refined my thinking about when certain types of approaches were appropriate, discarded that thinking in the face of new evidence, and rethought it all again and again.

But in the end, I started to become like a chef with only a single knife. It wasn’t the best tool for many jobs I would approach, but I didn’t have anything more specialized for the different tasks I would perform.

Over the past few years I’ve sought to remedy that. I’ve been re-reading and playing with LISP lately (via Abelson and Sussman’s classic), I learned a bit of javascript, some PHP, some of the latest version of Inform, and quite a lot of Python4. I wasn’t surprised that this made me a better programmer, really; having more tools is likely to make a better craftsman of anyone. But I was a little surprised that I feel it has made me a better C++ programmer.

The thing about learning new tools is that not only does it give you the ability to solve new problems in new ways, but it also changes what sort of problems you find yourself able to think about. Just as getting knives that have certain features, additional languages force you to rethink how you solve different problems, and being able to solve different problems grows your thinking altogether.

I can’t recommend enough trying some new languages, for any professional programmer. A few things have been helpful for me:


  • Learning by doing. Rather than attempt to read a bunch and apply what I know later, I try and sit down with a text editor and go -- referring constantly to the web. When learning Python, I put a book on my desk, pointed my browser at python.org, and fired up an interpreter.
  • Reading samples of substantial size. Taking apart a good-sized project is a great way to familiarize yourself with how programs are put together, and might suggest features you’re not aware are present. In playing with Javascript and the HTML5 canvas, it has been immensely helpful to be able to dig into Darius Kazemi’s ALES project, a platformer builder that runs in the browser.
  • Attacking “real” problems. Toy problems are useful for learning fundamentals of programming, but trying to solve a real development problem you have is useful for actually learning a language. Over the past few years I’ve built tools for work in python, presented data from those tools in PHP, and I’ve been coding up games in Inform7 and Javascript (with HTML5 canvas).

I think that’s about all I have on this subject for now. I hope you’ll go out and get yourself some spectacular new knives... and keep them sharp.

¹This is, I note, a process that continues to this day. I hope to be learning new things in whatever languages I use professionally to the day I die.
²Typically a chef’s knife, if one cooks in the Western tradition, or perhaps a butcher’s knife in the Eastern tradition. The Eastern version of a butcher’s knife is a lot more flexible and of greater utility than the one you see hacking away at cuts at your local butcher’s shop.
³Development process was the other lens I would apply, but that’s a whole different can of worms.
4Also a little bit of SQL, and yes, I’ve played around with C# from time to time. The former doesn’t really feel like a programming language like the others, its domain being so specific, and I’m not much of a fan of C#, though I think it also has its uses. In the case of C#, it’s enough like C++ to me to not feel like a new language at all. I’m also not fond of it being tied to a single platform.

Posted by Brett Douville at 02:23 PM | Comments (0)