It speaks volumes that, in the last month, the only games I have touched are Grand Theft Auto IV and Puzzle Farter. Hell, Puzzle Farter is the only game that I’ve finished since Rez HD in March. Of course, I’ve had other priorities.
The developer of Puzzle Farter is also a member of a
secret cabal internet community that I’m in and it was there that the alpha and final builds were posted. I linked to it, giving a fellow member a plug, and it somehow ended up on Kotaku. The link there was regurgitation (hi McWhertor!) so I felt I should follow it up with some real content1. Here’s a small email interview with the developer of Puzzle Farter, Pet Tomato‘s Austin “astro” Haas.
About Pet Tomato:
We are a two person company. It’s just me and my wife. I do all the
game design, programming, and sound fx, and my wife, Yoko Imanishi,
does all of the art. The little music tags were done by Ben Jastatt of
On the origins of Pet Tomato and Puzzle Farter:
My partner and I met at Cartoon Network. We were both employed there,
as part of their internal game development team. We left 3 years ago
to start our own company. Since leaving, we’ve done a lot of work for
Our motivation for creating Puzzle Farter was part of a larger strategy and direction for our company. Ultimately, we’d love to be
doing nothing but our own independent games, but in the meantime we
are doing work for hire. We designed Puzzle Farter to be a game that
we could put out on our own, use to attract new clients, and also to
build off of when we get client work. We believe this type of
character based platform game supports the widest array of scenarios
Normally, with client work, we need to pitch a complete idea from the
start. Since we weren’t under any pressure for this project, I wanted
to start with some simple mechanics that we knew would be fun and then
just see where it goes. I really just wanted to make a game that I
would want to play.
On how they created the character designs:
We go to the bar. In all seriousness, this is a new approach for us
and it works really well. We determine what we need to figure out,
then we go to the bar and we don’t leave until we’ve got it figured
out. I don’t think that would work for most developers, but we’ve had
a lot of success with it. The main advantage is that we aren’t in a
hurry to wrap it up.
Features scrapped or never fulfilled:
We added in the duck from the very beginning, but we never had a use
for it. The hero is too short for it to be significant. We left it in
just because it felt nice.
We also had the hero throwing these large berry things around. He
could run past a bush and then it would be in his hand and you could
throw it with the spacebar. We had several ideas for it, but nothing
that merited the extra complexity.
In the alpha discussion, it was often suggested that you should have a UI gauge to show your fart “fuel.” Can you elaborate on why you chose not to implement this?
Simplicity. I’m still not sure about it, though. Lately, I’ve
considered the idea of having him fade-in/out and sweat a little to
indicate when you are really tapped and shouldn’t try to fart so soon.
I was also thinking about adding a “Tips” page to the menu to describe
some of the nuances, like “you can jump higher by holding UP longer”
and “you can jump higher if you take a few steps first.” I really hate
when Flash games have instructions that require reading more than a
few words, though, but maybe burying it under “Tips” would be a good
There is a lot of variety in the fart noises, I think it’s safe to say that you enjoyed recording these. How were these recorded and how easy was it to channel your inner nine year old?
It was pretty fun. It took me a few hours. They needed to be about a
second and a half long and I wanted them to get higher toward the end,
like he was really squeezing it out. It took a bit of rehearsing.
We tried to release this one as soon as we had something complete, but
the next version will also allow people to create and submit
levels. We have that working now, but we need to clean it up. We also
created another enemy. It’s a vase-shaped plant guy that launches the
balls up in the air. He’s a little more musical than the others, which
is something that I really wanted to expand on.
I want to thank Austin Haas for the short interview. Go play Puzzle Farter but don’t be disappointed with the no-reward NES era “You Win” screen at the end. He promises me he’s working on it!
Lastly, I was curious about how this Flash game was built since this is something relevant to my interests. His response to my curiosity follows. It might be useful to some people. It certainly is for me.
GNU/Linux for OS
Emacs for editing
cpp for preprocessing
mxmlc for compiling
git for version control
my own build system, written in elisp
my own swf obfuscator, written in Common Lisp (new for this project)
My partner does all of the art on OSX with the usual commercial tools.
For my own code libraries, I keep it pretty simple. I have a folder
called ‘standard’ and one called ‘game.’ ‘standard’ is in it’s own
repository and I include it in all projects. ‘game’ is specific to the
current project. A lot of things start out in ‘game’ and then I try to
push them down to ‘standard’ by making them more general.
Keeping ‘standard’ in it’s own repo was a big gain for me. It forced
me to design better interfaces and abstractions, rather that copying
the directory over and butchering it for each game.
I highly recommend having a build system, too. Once you have a build
system, you discover more and more things that you can automate with
it. I can flip a switch to publish to testing or staging servers (with
cpp using directives to conditionally include relevant sections of
code). For instance, debug code and cheats are only included when
publishing to my testing server and the ads are only included when
publishing to my staging server.
- Look at me, I’m a games journalist.