Greg Wohlwend and Mike Boxleiter are independent game authors at Intuition Games. Authors of Dinowaurs and such laudable titles as Gray and the upcoming Liferaft. Recently they launched Fig. 8 over at YoArcade. Colin Northway speaks to them about how they design games and found out that sometimes fighting like cats and dogs is the best way to keep a studio together.


Hey Greg, hey Mike. Thanks for taking the time to answer a few questions. How did you guys end up making games?

G: Our story is kind of similar. We went to college together.

M: We almost worked on a project together in college but then Greg flaked out and I thought he was a douche bag.

G: We had this game class together and I was like "Mike has this game in progress, so maybe I'll see what I can do". So I went over there for a meeting and made some horrible alien drawings and then I quit.

M: (laughs) It was a bad project. Every project we worked on up until we graduated was bad.


Have you always worked together on the design?

G: Yeah. Whoever has the initial spark, they have to get things going and communicate the idea. But then eventually it becomes this thing that we share. And that's certainly how it happened with Fig. 8.


Greg and Mike (left to right)


Can you each point to the parts of Fig. 8 that are specifically your ideas? Or do all the design decisions run together and seem to come from both of you?

M: There are definitely ideas that we can look at and say "Yeah, the initial idea was mine". The visual stuff for Fig. 8 was pretty much all Greg. It was even connected to an art project that he did in college. So a lot of the visual stuff is his but the way the bike is controlled and moves around is completely done by me with very little input from Greg. I fit the controls to the visual ideas he had come up with, with the way that the bike wheels come together and flow apart.

G: More details, like the mechanics and how we do score is something that we... well there's a lot of argument. That's pretty normal for us, we fight a lot. It's just the nature of two people being really passionate about their ideas. But that's why we've stuck together through Dinowaurs and all these projects. There's a lot of fighting, but we've found a way to fight productively and we think it's one of our greatest strengths.


Do you both do implementation? Do you both write code?

M: I'm strictly code and he's strictly art. We were both really focused on our field when we were going through school and now sort of locked into it. I would like to do art and Greg would like to do code but we don't really have the time to develop those skills. It's game design that we're both really interested in. I like coding. It's fun and rewarding. And Greg likes art. But what we both want to do is game design. And that's what we want to innovate on.


Do you think Greg is at a disadvantage because he can't prototype ideas?

M: When I'm developing the controls on something or the way the AI works, or whatever, I make a hundred decisions that Greg isn't even involved in. And that kind of sucks.

G: But also, I think there is some good that comes out of me not being in that world or at least coming from a different background. I think there's a certain kind of mindset that a programmer comes to a project with. Whereas I approach it from almost the opposite angle. Like for Fig. 8, I'm not sure Mike would have come up with that idea.

M: Definitely. Greg started Fig. 8. Which is a really really unique style that I would never do. If I was making games the theme and the style would be so "classic gaming" that we wouldn't be reaching the bigger audience that we're reaching right now. We create really unique stuff both in terms of gameplay and visual style and that's a huge asset.


It almost sounds like you guys have a left-brain right-brain thing going.

G: Yeah, I think that's pretty accurate. Mike definitely comes at it from a logical perspective. I think, though, in a lot of ways working together for the last few years has brought one another across to the other side a bit.

I usually notice working with programmers that they have this misconception about creativity. Creativity is really just a skill. It's not something, in my opinion, that you're born with. Creativity is the ability to take other bits of the world or experiences you have and apply them to what you're working on.


So you feel like you can practice and learn that?

G: Yeah, definitely. I think it just takes an awareness. People need to realize that they can do it.

M: A lot of it is forcing yourself to do it. You can just do things the easy way. The way you've seen a bunch of other games do it. Or you can force yourself to stand back a bit and think of it in a unique perspective. Take things from other parts of your life and let yourself be influenced by more than just one thing.



How did Fig. 8 start then? Did you have a thematic idea for Fig. 8?

G: Yeah Fig. 8 was based on an art project I did in college called "US". It was kind of a romantic tale. One night I was walking along a sidewalk in the middle of winter going to my girlfriends dorm room and I saw these bike tracks in the snow. It was just a single bike track and I was following it, thinking. When I'm doing something idle, like walking, my mind tends to wander to these wonderful creative places. I thought maybe the bike crashed and I kept trying to find where the crash tracks would be. With my mind half on my girlfriend, I thought of two people in a relationship and how sometimes they get off the track and then come back together. I always find breaking up is like tipping over a pop machine (which is a Seinfeld reference). You have to tip over the pop machine and it takes at least three or four tips to get the momentum to crash it to the ground. So this bike is very similar in a lot of ways. If you crash then the bike gets less stable and the two trails separate and come together and separate and then finally crash. So the installation was based around that.

For the installation I actually spray-painted a bike. I painted the tires red and blue and crashed it in the corner of an art gallery.

So one night I was thinking about the installation and I brought the idea in to Mike: maybe we can make a game around keeping your wheels together.

M: And it actually just sat on the whiteboard for four months before we finally said "hey we need a new idea". Then I prototyped the movement of the bike and it just sort of went from there.

G: Originally we just had the movement which is what we usually start with in a new prototype. The second to second control which Mike is a genius at. He's awesome at making realtime controls feel really great. So we start with that and if it feels great and it's enjoyable to tool around in a blank space then you can start to visualize how the game will unfold.


How long did you spend on the movement?

M: Probably a day. Six hours doing the initial controls and then we had to revisit it later to make it a little more springy and snappy. It probably wasn't more that ten hours total.

We decided "let's give it a day and see what it does" and by the end of the day we had it driving around and it was really fun.

I actually played around a lot with changing the number of wheels you can have. So ten wheels all drawing, which was kind of fun. It almost made the game like a really floaty snake game. That is what's really fun for me. Just to take the idea and mess around with it as much as I can. To push the boundaries to see what the limits are. But we just ended up going with a two wheeled bike. The original idea seemed good enough to go with.


Do you make a lot of design decisions as you're developing?

M: Yeah, our process is that we make all our design decisions while we're developing. We don't want to limit ourselves by the initial idea.

G: All of our emphasis is really about editing. This is something we really align with in terms of philosophy. We just get something down and then we can go from there.

M: Yeah, your initial idea is probably shit and you need to recognise that. While you play the game you're going to have ideas and concepts and things that you think would be better. Just like in someone else's game when you think to yourself "man they should have done this, or this is going to suck, or this is really great". You should listen to those impulses because that's what people who are playing the game are going to think. And if you're thinking "man it would have been really cool if we'd have done this" and you don't do it then you're killing your game. You need to go on those impulses. Don't follow them over the cliff necessarily, but follow them for a while.


So for every game that you actually flesh out and produce how many prototypes do you try?

M: We don't really kill prototypes. We don't make a prototype and say after a few days "ok this sucks, kill it". There's always a reason to hold onto it. Maybe that's wrong. I don't know. In Flash games, since they're so small, there's always a nugget that's good. You can just say "ok lets scrap this stuff, and pursue this angle". Just find what is good and expand on that. I don't really think we just kill a project generally.

We do kill a lot of game jam games. We do game jams as frequently as we can. We've done six of them now and we haven't really pursued any of those projects.


So you do have a source of things that you're playing with at any given time. Thanks to the game jams?

M: Yeah. If we have an idea that we want to pursue in a game jam then great. We can just spend two days on it. And it's a weekend too so it's our off time and not a waste of regular working hours.



Were the technical diagrams that the player rides around in part of the original design idea?

G: No, not at all. That's a product of something that I like to do with these smaller projects which has become a bit of a habit now. I picked it up when I was working with Jiggmin making Effing Hail. As soon as we have the game idea I go right to the library and I immerse myself in whatever faintly connected subject matter I can find and then that will inform where I go. With Fig. 8 I just started researching the history of the bicycle. I feel like there is a bit of romance with the bicycle. It gets me thinking about black and white films where people are riding velocipedes and they're all wearing top hats and coattails. It's sort of romantic and fits with the original idea behind the installation. Then I found these old patents of velocipedes and I thought, "wow, that's really cool", what if the game is actually a patent drawing? So that's where it started.


So you have a bike and technical diagrams that you run around in. How did you take it from being a toy to a game with a goal and a way to lose.

M: That was probably the least organic decision that we made. We just kind of said "well what if you have to follow the camera and the camera is on a set path"? I prototyped it and just stuck with it. In retrospect it wasn't even a great choice. I sort of regret it now.

G: Mike had been playing this game "String Theory" which was an experimental gameplay project game. The camera moves around and the object is to stay on the screen. That's pretty much how we thought of creating some of the tension and the challenge for Fig. 8.

If you were just riding around then it's just a toy at that point. It's hard for us to make just a toy or at least hard to justify that. I think in retrospect we could have explored that more. Certainly we could have looked a little harder and taken longer with more experimentation. Something we were talking about yesterday is exploring more of the free-play whimsical attitude in an iPhone game.

M: And really Fig.8 was about getting a quick buck. (laughing)


Well you've created something of pretty incredible artistic merit for a cash grab.

Let's talk a little about the music. Since the screen moves at a set pace you've been able to make the pace of the game the same as the music. That really adds to the emotional punch. How intentional was that?

G: Definitely fully intentional. We didn't start putting music in until we had the level pretty much fleshed out.

We played around with a lot of things. Maybe we'd do a loop, maybe it'd be more ambient and not really all that musical. But then we found a couple french accordion type songs that were a little bit more romantic and interesting and it became clear that we had to go with that route.

So eventually we came up with a 12 minute long string of music that attempts to take the player along "hills and valleys" with the music.

M: The music syncing perfectly came from the checkpoints. I had the idea that you could save the position of the music and if you did that you could time it so the music and gameplay would perfectly sync up.

It was just kind of a random idea that ended up working really really well.


I agree. I think it was a very successful idea. Thanks for giving us a glimpse into how you design your games. To finish off, are there any overarching design philosophies you'd like to express?

G: Design documents suck.

M: We haven't written one since Dinowaurs.

G: And you saw where that got us. (laughing)

I think in general design documents entrench you in the initial idea too much. You know, it's on paper so it's more solidified as opposed to this living idea that you're playing with and nurturing.

M: It's kind of an ego thing too. It's tempting to think the idea that you came up with in your head while you were on the bus to work is good enough. It's not. You can only make it good by refining and testing, changing and experimenting. You need to follow your intuition.