Why a World of Goo dev made a puzzle game about programming humans

There was a weird bit of synchronicity to my life this week when, shortly after publishing an interview with Zach Barth and Matthew Burns about the development of Zachtronics' assembly language puzzle game TIS-100, I got word that World of Goo studio Tomorrow Corporation was getting ready to launch its own "drag 'n drop" assembly language programming game this summer: Human Resource Machine.

The game looks quite a bit more approachable than TIS-100, but it has the same low-level programming language underpinnings. So what is it about assembly languages that makes them so appealing to game designers?

"Assembly languages lend themselves so naturally to tinkering in games because it's like Legos," Tomorrow Corp.'s Kyle Gabler tells me. "But instead of building physical things out of blocks, you're building behavioral things out of little commands."

Oddly, Gabler says that trying to market a thinly-disguised programming puzzle game is actually quite a bit easier than Tomorrow Corporation's previous game, the IGF-nominated 2012 fireplace simulator Little Inferno.

At GDC that year Gabler's compatriot Kyle Gray spoke frankly about the many mistakes Tomorrow Corp. made in developing Little Inferno, and in a recent conversation over email Gabler opened up about how the team applied learnings from those mistakes to the design and development of Human Resource Machine. It was an interesting conversation, so I've taken the liberty of reprinting an edited version here.

Let's talk about the design of Human Resource Machine. How does it reflect Tomorrow Corp.'s design sensibilities? What were your specific influences and inspirations?

Gabler: In Human Resource Machine, you program little office workers to perform little tasks. Your office has an inbox, an outbox, some spaces on the floor to store stuff for later, etc - and it all works together as a real working computer.

As a player, you don't have to know any of this, but you're basically doing drag n' drop assembly programming. And if you don't know what that is, don't worry. It's just a language of simple little commands like "grab the next input" or "store this thing over there for later" that CPU's understand.

This game continues the rich tradition of building games based on real life stuff. World of Goo (that I made with 2DBOY) was about playing with masses connected by springs simulated with Hooke's Law. Little Inferno was about the value of time (and blowing stuff up).

And now computers, which are so ripe for gameplay, it's no surprise we've seen other fascinating computer games appear, like TIS-100 by Zachtronics that I can't wait to play, and Manufactoria, which I loved.

What lessons did you learn from previous projects, and how did you apply them while developing HRM?

We learned a lot of hard lessons about how a game's design affects your ability to promote it.

Our previous game Little Inferno was incredibly difficult to describe - it appeared (intentionally) to be a silly fireplace simulator on the surface, but with a dark story brewing in the background, and with an abrupt change near the end - none of which we could talk about without spoiling. I imagine it was similarly difficult to promote The Crying Game!

Human Resource Machine, in comparison, is fun and easy to discuss! There are no real secrets or mystery, just a series of really good puzzles. (We think!) The source material we're working with - computers and programming - is so naturally interesting and fun and well designed by really smart people decades ago, that we have a lot less work to do as game designers.

So what technical and design challenges did you face in developing such a game? 

Tech/Design challenge: In Human Resource Machine, you're playing around with a computer inside a computer. The challenge here was designing how this little simulated computer would work. What exactly is the computer's architecture? Do you have registers? Some sort of stack? How do you access memory? What instructions do we want to provide?

Placing the game in an office environment, where you're a little worker moving physical boxes around, helped narrow it down somewhat. Nearly all decisions in the design of the computer were evaluated based on the question "Will this make the computer simpler / more intuitive for players?"

We can talk about the design of the computer forever, if anyone is interested to know more. We also wrote a bit more about it here in the "expert" section. Maybe our next game will be "Design Your Own Computer: The Game!" because it's so fun.

Thematic challenge: Beginners and non-programmers can get really scared of the idea of programming - so we've put a lot of work into making the game, and everything surrounding the game, simple and accessible. No idea how we did yet, but we'll find out soon if we succeeded I suppose!

Writing challenge: In each level, your fat little boss tells you what you need to do. The boss's words here had to dispense technical requirements in a way that was clear, unambiguous, and brief as possible - and hopefully with a little sassiness along the way.

Playtesting and iterating on getting each word exactly right, and coming up with a vocabulary that was consistent across all levels, required a good amount of effort...even though we all know players will just click through as fast as they can.