You say you got a few dimensions going, prototyped those, and then just looked and said, "this concept." Were you working with multiple concepts or was this the idea that was gestating?

KS: So when I first got together with my team, we were going to decide to do a project like this. We actually had a pitch process where anybody that wanted to submit a game idea could. And so we took a look at everybody's different projects. Everybody got to do a one sheet and talk about it. And at the end of the day, we voted on which ones that we wanted to do, based on the ability to quickly prototype and test the ability for it to be fun. And this had, at the base core, the simplest systems in order to prototype very quickly.

So within like a couple of weeks, we actually had an extremely rough prototype, obviously with no art or anything, but a fluffy dimension, and reverse gravity, and slow motion. And we were just playing around with the different permutations of them, and realized pretty much right away this had potential, this was a lot of fun to play with these different interactions, and just kept iterating and polishing.

What did you use to prototype originally?

KS: We are UE3, so we prototyped on UE3, and are still on UE3.

Have you ever used any other tools or any other methods? Have you always been direct to engine, and are you most comfortable with UE3?

KS: I've done both. I mean, I was at Valve, so I did Source Engine there, and so I actually had to relearn how to use all the editors and scripting and whatnot, so it was actually difficult for me! But easy for everybody else, because everyone else on the team was used to UE3.

I think if your team is capable to go straight to engine, it's nice to be able to test it out in the software that you're going to end up using. But obviously that doesn't work for everybody. So it's about finding what works best for your team.

Did you end up codifying or documenting at any point? It sounds like you went really straight to prototyping off of the pitch process.

KS: I have pictures of whiteboards. We have a game design document that I did at the very beginning of the project, but it hasn't seen much love since then. We're more of a rapid iteration-style team, so I have pictures of whiteboards -- actually, on my phone -- just kind of detailing out particular brainstorming sessions, or level design sessions. And we go kind of off of that. So we'll have a quick meeting, and we'll all get together in front of a whiteboard, and start drawing stuff out, and then go back to our desks and start building.

How did you recruit the people that you have? Was it all people that were already at the studio when you joined?

KS: Yeah. So it was all people at the studio that were interested in working on something different, and we ended up doing some prototypes on an initial game first, that I can't really talk about. But after that, we rolled onto this project, and started working on it right off the bat.

When it comes to using the human psyche, is that something you've done more research into as you've leveled up your design toolset? Or is it stuff that you knew from like your previous studies, as with art, for example?

KS: I think a lot of it was stuff that I kind of knew already. I wasn't exactly the popular kid in school growing up, so I found myself really observing people, and watching how they interact, and how they react to things. Also, watching an obscene amount of nature programs as a kid, as well, actually helped a lot.

I think this is kind of interesting: So at Valve -- I think this was for Half-Life 2, and I could be totally wrong -- they actually brought in an animal psychologist in to have her take a look at the game, and figure out if there was anything that they were missing in terms of cueing the player into doing something. So it's like yeah, we're smart monkeys, but base core, we're animals. And so we're having particular reactions to a stimulus that an animal might.

Do you think it's important, or beneficial, at least, to work with people in disciplines that are just totally outside of the games industry, and bring that kind of stuff in?

KS: I think so. It's interesting to get perspectives on things that you don't have. It's the same reason why I run a more democratic team, because yeah, I can make a decision, but I would like to have multiple disciplines looking at the same problem, because they might have a more efficient way of solving a problem than I would, or an artist would, or a programmer would. So I think having different disciplines taking a look at games to see if there's anything that we might be missing is definitely informative.

How has it been moving from a studio that can publish its own games to a studio that has to work with a publisher? Has that impacted your life?

KS: Honestly our partnership with Square has been amazing. So Mike Fischer is the CEO of Square Enix USA, and he's an awesome guy. And he was very clear with the team straight on -- that he trusts us as game designers, and he wants to give us the freedom to make the game that we want to make. And they've been really hands-off, in terms of letting us do what we need to do, give criticism that is positive, and actually really helpful for us, and at the same time just being incredibly supportive.

And super nice, actually. Like we'll have a deadline coming up, and we'll get emails from the people on our Square team being really excited for the next drop of Quantum Conundrum so they can play new puzzles, because they're addicted to playing. And so hearing that feedback from a publisher has been great because... I don't know. Working at Valve, I'd heard horror stories, and so far my experience has been really positive.