Flow puzzles v1

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).

A short time ago, a member of my team at work showed me Rete.js, a framework for building node/graph editors in Javascript. This felt intuitively like how I wanted to construct puzzles, so in the spirit of some rapid prototyping, here are a couple demos working out the characteristics of this space.


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.

Sliding Windows

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.

Bin Packing - Shelf Algorithms

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.

Packing a bunch of rectangles into a texture isn’t the easiest thing to do well. There’s a whole class of algorithms dealing with this “bin packing” problem, each with various tradeoffs. Luckily, I found a very useful paper which covers many of these algorithms (thanks Jukka Jylänki!). To get a feel for how well each of them perform, I decided to implement a few in Javascript (you can see the source here).


On April 17, 2015, Wes, Kalev and I started work on LD32, our third collaboration on a Ludum Dare weekend game jam.

Our resulting entry, Chromos, is a top-down action game reminiscient of Zelda and (blatantly) Titan Souls. It’s the most ambitious game we have tried to make in 48 hours:

Ludum Dare

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

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.


Twitter (@kurrik) Github (kurrik) YouTube (kurrik) Linkedin (kurrik) Instagram (roomanna)


arne (13) reviews (12) cinemaclub (9) work (9) games (7) twitter (7) chrome (7) extensions (6) books (5) html (4) newyear (4) google (4) javascript (4) presentations (3) readinglist (3) go (3) algorithms (3) ludumdare (3) internet (2) estonia (2) appengine (2) management (2) space (1) product (1) recipes (1) http (1) art (1) ciphers (1) questions (1)