What is the first gameplay element that you start with when you're designing? Do you choose that ideal character speed? Do you change the design based on how fast the character is? Does that come first, or do you set up a level and then figure out how fast you want a player to get through it?

SM: We work on both of those at once in parallel.

In the past I've noticed you do a good job of having visual short, medium and long-term goals for the player -- you can see that castle off in the distance, you know you'll eventually get there, and there are a lot of interesting things along the way.

What is your philosophy for those kind of player goals?

SM: I suppose it depends on the game that you're making. Deciding what to show the player and what doesn't need to be shown is part of the total structure of the game, after all.

Some things are best when they're shown off right at the forefront, but other things would spoil the game too early. Figuring out which of those categories each game element fits into is one of the difficult parts of game design.

Do you do a lot of iteration and playtesting to determine when those things should be revealed and when those moments should happen in gameplay, or do you plan it all out at the onset?

SM: That process happens at a pretty early level of development -- figuring out the structures of the stages, you could say, the flow of the game. We decide upon the general structure. We ignore all the little setting details at that point; we take the larger elements of the game and figure out whether to put them in the first or second half, or to have this or that scene serve as the halfway point for the story. That's the basic way we think about it.

You've gained a reputation for knowing when it's time to cut content or switch directions. How do you know when that needs to happen? What advice would you have for other people who are having trouble with their scope getting too large, or development going too far down the wrong path?

SM: Once you build up enough experience over time and learn what works and what doesn't in development, you start to naturally know when it needs to happen. It's really no unique skill on my end. (laughs)

Of course. For yourself, when do you know it's time to do it?

SM: It's a matter of what the time schedule is, and a matter of how motivated the director and his team are. You look at the project schedule and see how much time you have left to implement this or that section, and you say to yourself "If I don't say something about this right now, then it's all over."

We always cut it really close like that, waiting until we absolutely have to make a decision. If I pulled the trigger too soon, team members wouldn't have a full understanding of why their section got cut out so early, and it'd impact their motivation level.