Go Bootstrap

June 15th, 2012

I attended A Tour of the Go Programming Language with Russ Cox on Tuesday. It was a good presentation (although the quality of the youtube video is poor) and left me eager to spend more time with Go. One of the answers from the Q&A portion made me laugh:

Audience: Is there any plan to bootstrap Go in Go?

Russ Cox: Not right now...oh also, I don't know if you've read the paper by Ken Thompson, the Turing award lecturer, about trusting trust, where he puts the backdoor into the compiler and when it sees itself it perpetuates the backdoor. So when we were originally doing launch, we joked that no one would trust us if we had written Go in Go and were handing out a compiler that Ken Thompson had written.

Update: Russ re-recorded his talk and posted it here: A Tour of Go

The Programmer's Ultimate Goal

June 7th, 2012

"A simple, powerful program that delights its users and does not vex its builders -- that is the programmer's ultimate goal."

- Jon Bentley, Programming Pearls

2011 Year In Review

December 31st, 2011

2011 was a year for change. I made the jump from developing AAA console games to developing browser based social games. I helped ship Indiana Jones Adventure World which was picked as the #3 social game of 2011 by Gamasutra, the #5 recommended game by facebook, and one of the 5 Best Games on Facebook by Kotaku.

Prior to Adventure World, I spent a few weeks on my own developing a version of Connect 4 using html5, javascript, python, google app engine, and facebook. I dubbed it Connected 4 - the idea being that the player is settling a debt to "connected" mobsters by playing the game. It included both single player with AI and async multiplayer with your facebook friends. As a game, it was a failure. Single player quickly got boring and there wasn't enough depth or choice in a multiplayer turn. However, I learned a lot about technologies and languages that were new to me and shipped a game on my own, which were my main goals for the project. Overall it was a personal success.

In the year ahead I'm looking forward to even more programming, writing, and most importantly, shipping!

Sun Pixel Shader

May 18th, 2011

Over the weekend I wrote a simple pixel shader using Inigo Quilez's Shader Toy. The inspiration to experiment came from the ro.me and Angry Birds announcements at Google I/O. It's exciting that WebGL, canvas, and HTML5 are gaining momentum.

Starting a Game

April 30th, 2011

When starting development on a new game, creating a concept video or a playable prototype can be extremely useful. The bigger the project and the larger the team, the more useful the video or prototype becomes. Traditionally, written design documents have been used to describe developer ideas. While a written document can be useful, the concept video excels in a few areas:

Quickly get viewer feedback as to whether the game looks fun. Not sure whether to spend millions of dollars on a risky game concept? Create a concept video and post it online. Measure the view count and read the comments. Viewers will be brutally honest and you will quickly find out if they love it, hate it, or are indifferent. The Limbo developers posted their concept video online several years before they shipped the finished product. Better yet, numerous indie developers have bypassed the video altogether, created a playable prototype, and released it online. The prototype gains enough attention and praise that they decide to turn it into a full fledged game.

Provide the development team with a concrete vision. The downside of a written document is that it leaves too much room for imagination. Each team member will read the same document but end up with a different vision in their mind. A concept video leaves less room for imagination and points the team in a common direction.

Provide more detail, quicker. Getting each team member to sit down and read a 10, 20, or 100 page document and remember all of it is tough. Watching a 1-2 minute video is much quicker and has greater information density. (A picture is worth a thousand words?)

Illustrate a concept or feature that might be too hard to describe on paper or might not sound fun. An art style may be unique enough that it is difficult to describe. A gameplay feature might be difficult to imagine because it has never been done before. Sometimes showing them is the only way to turn them into believers.

Realistically, you won’t be forced to choose between a design document and a concept video. They can serve different purposes and be made to complement each other. However, showing someone a concept video or letting them play a prototype is one of the best ways to gain support for your game idea.

Here are some of my favorites.

Carmack's Values

April 6th, 2011

Well, I think a lot of people put too much emphasis on the epiphanies. Epiphanies are there, you do get them where you see clearly into something and all that. But it really is true that most great works aren’t a result of epiphanies, they’re the result of lots of hard labor. That is a trap that a lot of people fall into where you think that the epiphany is the important thing. Sometimes it is, but in 95% of cases it’s just a matter of smooth, calm integration of everything you know.

It’s not the one brilliant decision, it’s the 500 smart decisions that really make things good. It’s more a matter of being able to keep making smart decisions. Making one brilliant decision and a whole bunch of mediocre ones isn’t as good as making a whole bunch of generally smart decisions throughout the whole process. And there’s so many of them that have to be made.

Even at the end of Quake 3, I had a to-do list of a thousand things that could potentially be improved on. So it’s a matter of going through and knowing all these things that could be done, and prioritizing what the "sweet spots" are. Like "This amount of effort would get this batch of things done and it would have this side effect." Or "it would take all day to do this thing but it would probably destablize something else, so I’m not going to do it."

John Carmack (Firing Squad Interview)

When you hear stories about John Carmack, it's easy to assume you'll never achieve his level of success because he's a genius programmer. Even though Carmack might have quite a bit of "natural" ability, that's not where he credits his success. And I don't think it's because he's being modest either. According to that quote, the qualities he finds most valuable are:

1. Hard work.
2. Consistently making smart decisions.
3. Prioritizing your time and effort correctly.

I think these qualities can be achieved by any developer. Sure, they might not be easy. But as games become more and more complex, they are only going to become more valuable.

GDC 2011 Theme

March 16th, 2011

The most important theme I observed at GDC 2011 was: good tools are what make the difference. Funny considering I didn't attend any talks that were specifically about tools.

Playdead's level design talk revealed that their real-time level-building tools were what allowed them to quickly create, test, and iterate on Limbo's puzzles. This speed of development allowed them to create enough content that they were able to discard approximately 70% of their puzzles and only keep the cream of the crop.

In the Halo Reach networking talk, David Aldridge said that debugging tools are what allowed Bungie to reduce bandwidth requirements to less than 20% of Halo 3's. Adding the ability to splice network profiling data into their recorded game sessions let them play back traffic data along with game data. This profiling data could be viewed at any point in the replay using a graphical overlay. Alridge said these tools took about 6 weeks to implement.

In her SPU-Based Deferred Shading talk, Christina Coffin stated that good debug visualizations are key to both guiding their content optimization and validating the aggressive culling required by their complex scenes.

While development is in full swing, it's often hard to convince yourself and your team to invest the time and resources necessary to build an effective tool suite. These talks served as a great reminder that investing in tools can enable you to produce features and content that would not otherwise be possible.

Brute Force Rendering Using Google App Engine

January 6th, 2011

A few months ago I was feeding my internet addiction on programming.reddit and stumbled upon Kevin Beason's smallpt, a global illumination renderer in 99 lines of c++. He uses Monte Carlo path tracing. In this approach, the radiance at each pixel is estimated by taking the average of many independent samples. Producing good visual results is slow (compared with other approaches) because quadrupling the number of samples only reduces the error by half. However, the solution is "embarrassingly parallel" so it can be sped up substantially if you have the horsepower to throw at it.

Around the same time I discovered smallpt I was learning about Google App Engine. App Engine lets you write web apps that run on Google's infrastructure. It is designed to automagically scale as traffic increases, spawning new instances of an app that run in parallel. The natural question was, could smallpt be ported to App Engine? How much of a speedup was possible?

smallpt is clearly CPU bound and App Engine has a max rate limit of 72 CPU-minutes/minute. This basically means the equivalent of 72 1.2 GHz processors can be used at once. Beason's highest quality example took 10.3 hrs to render at 1024x768 using a 2.4 GHz quad core. A rough estimate of the potential speedup was (72 * 1.2) / (4 * 2.4) = 9x. This was a bit less than I had hoped for (I wanted a lightning fast render farm!), but I decided to move forward anyway.

My first step was to port smallpt from c++ to python. This turned out to be a mistake. My implementation was about 300x slower than the c++ version. I'm sure there was plenty of opportunity for improvement. I'm a python novice, I didn't check that I was following "best practices" for performance, and I didn't try running it on an optimized interpreter (I think Google uses one). However, after taking a look at language benchmarks, I wasn't convinced I could obtain the performance I wanted. I decided to switch to Java. Much to my surprise, my Java implementation performed nearly as well as the c++ version! Next, I built a web interface for telling app instances to trace a specific section of the image. At this point, my time and interest shifted to other projects. Rather than let the source code slowly be forgotten on my hard drive I'm releasing it. Maybe it will serve as a reference or starting point for others. Proceed at your own risk.



- Send multiple HTTP requests at once from the computer coordinating the rendering distribution (NIO?)
- App instances need to track their runtime to prevent going over the 30 second request limit
- App instances need to track their cpu usage to prevent going over the 72 CPU-minutes/minute limit (it's not guaranteed that all machines will be 1.2 GHz)
- Each App Engine account supports up to 10 unique apps. It's against the rules to have multiple apps that act as one. If you want to briefly "bend the rules" for learning purposes, you could try creating 10 copies of the same thing. This would have a potential 90x speedup. (I'm kind of curious if Google has a way to detect when someone creates identical or near identical copies of the same app.)
- If you really want to break the rules, you could try creating multiple App Engine accounts that each have 10 copies of the app. This would be a bit challenging because the signup process requires a unique cell phone number. Google sends you a registration code via SMS. You might be able to get around this by purchasing a few phones numbers using twilio @ $1/each. The second challenge is that getting the full 72 CPU-minutes/minute requires enabling billing which requires a Google Checkout account. Will Google allow you to use the same credit card for multiple Checkout accounts?
- Optimization pass
- Standards/documentation/best practices pass