I’ve had a game idea bouncing around in the back of my head for a few years now. In fact, many of my goals in the past few years (i.e. watching more art films, learning to paint, and publishing a small game) have been in service of expanding my repertoire to be able to work on this larger meta project.
The game itself is structured as a puzzle-based adventure game, where solving puzzle challenges in effect unlock skills which can be used to advance the story. The puzzles themselves are supposed to be abstractions of programming challenges, but presented in a way so that non-programmers could complete them. I wanted to explore the space of manipulating a stream of data, rather than some kind of Turing complete programming environment like Shenzen I/O (which does that really, really well).
The first time I remember hearing the term “hackathon” out loud was when I was a couple weeks into my employment on Google’s Developer Relations team. I was trying to figure out what I was going to do to help bootstrap developers for the nascent OpenSocial project. Patrick Chanezon, the Developer Advocate on the project, said something like “we’re going to cold call a bunch of social app authors and hold a hackathon to test out the API” which hadn’t really been done before—we were helping pave a new path for the company at the time. That first event was kind of a mess. I remember stalling for time with a room full of developers since our test server wasn’t booting correctly. An engineer was hurriedly trying to fix things so that the attendees could get to work.
I’ve been working on a small interactive iPad experience for my daughter Ada. I wanted to create a world where objects would respond to touch, break apart, and evolve into different forms. She’s limited to a slappy/flailing motion and I wanted the game playable with only these rough moves. Gestures such as pinch-to-zoom or even panning the camera purposefully would not be appropriate. My v1 build therefore added a camera which zoomed to focus the most recently touched item. This worked well with my (more purposeful) testing, but zoomed around crazily once Ada got her hands on it.
I’ve recently been working on an update to the twodee library we use for Ludum Dare games. One (of many) areas I’ll be focusing on is speeding up text rendering.
Text is currently very slow because we have to create and bind a new texture, render glyphs to it, then draw geometry for each piece of text in a scene. One simple optimization is to pack frequently-used text into a single texture which will remove many (expensive) texture binds.
Ludum Dare is a game jam. Every 4 months a weekend is selected and a theme is announced. Thousands of game developers have the weekend to design, create, and release games for a competition where there are no official judges and no grand prize.
It’s been the most rewarding creative outlet I’ve ever had.
Racing the Beam is kind of like a biography for the Atari systems and their unique underlying circuit design. Actually, it’s kind of like one of those band documentaries where the band is already established so you just follow them around and see their interactions with common folk. Eventually there’s some scene where a band member blows up or throws a tantrum and probably didn’t mean anything at the time but foreshadows the band’s eventual downfall/breakup and so forth.