BD: Internally, we have our own toolset that we've developed over the years. So we've always had the mindset of improved iteration time with all our systems. We build in data-driven -- we call them "tweakers" into the game so that when we create something we can give it to NCL and they can play around with numbers and adjust things. So they're able to do it on their end, and we're able to do it on our end.

Like Bryce said, when we make stuff we have to be in that mindset. It doesn't happen overnight. It's like you develop your skill set to work that way. And over time you actually get better and better at it, you get quicker, so that you can create an idea, put it in the game, play it. We've had situations where we thought something was going to take a week to build and I did it in an hour, and Ikebata-san was there, and he got to play it with me during one of their visits, and we were able to get feedback right there.

There are other cases where I'll do something, put it in the game, and the next day we'll get feedback from them because of the time difference -- which is actually an advantage, because when we sleep, they're awake playing the game. We wake up; we have their feedback already.

BH: The example was they were here in Vancouver and Miyamoto had called and said, "Let's try this." Brian just basically, instead of talking about it in a meeting, we just built it as we discussed it, and they were able to ask for a build to be sent back to Japan later that night. The next morning, we had the feedback already. So, our commitment to rapid prototyping and feedback really helped out. That's a really good example.

YI: Yeah, actually, having the time difference actually ended up being sort of a gift in that you wake up in the morning and suddenly you have a new present to play. And in regards to going on visits to the office in Vancouver, it's really hard to have face-to-face time and to really get to know people, so, having a chance to go onsite and visit with development partners, however rare it might be, is really important for the relationship.

From your perspective at NCL, I was wondering if you could tell me about the prototyping process as you generally envision it. Not specifically on this project, but in general. Is it completely loose? Is it feature-by-feature? Is it structured in any way? I'd like to get a little bit of a picture of it, if I could.

Ryuichi Nakada: So, internally there's a really relaxed atmosphere about giving a lot of freedom to the person in charge to try out whatever it is that they want to try out.

BH: In the context of Luigi's Mansion, it's either imitate or innovate. So sometimes there'll be a challenge from Ikebata-san or someone saying, "Let's make it exactly like Luigi's Mansion 1." Or on Punch-Out!!, there was a challenge: "Let's recreate the Glass Joe fight exactly as it was in the Nintendo, down to the finest detail." And that's just to basically prove out your tech and figure out what was that game like to build, or that type of game, or that type of concept.

And then other times, like they're saying, it's just "innovate time." Experiment with anything and start throwing them back and forth at each other. This is our game, or this is a different game, and let's start throwing these new ideas at it. So, it depends on where you are and in what point on the project, and even case-by-case [depending on] the project, it can change.

BD: With even the ghosts in our game, we had an idea of their function, so we knew that over time. But we also had a period where we were just trying a ton of different things to see what new ideas would've come out of that. You try 10, 20 things and maybe you'll get two of them that actually fit within our game. But you can sit in the meeting room and talk about them forever, but the best way to do it is to just build it.

BH: And analyze. You have to actually have something to play and analyze to get good decisions.

How do you know when something's right? When do you start cutting the experiments? When do you start selecting the experiments that you know are successful?

YI: You're always experimenting. In fact, there's no particular time where you stop adding new features. If it fits, then it fits, and you add it.

RN: But as far as making the determination about when something is good enough, there's not a lot of science to it. It's just playing it, and if it feels right, then it's ready.

BH: If you're looking for the context of when something goes from experimental to core feature, like the decision-making there -- Ikebata-san and Nakada-san, and myself and most of the team at NLG, would take the point when you're playing something, you're playing an experiment, and then, quickly, thinking about the context of the game, you can rifle off 10 variations that would be fun and interesting of that experiment, and would still fit in the context of the game.

So, if the idea can't bear more ideas, or variations on the idea, then it's probably time to throw it out, rethink it. But if all of a sudden you have something where it's ballooning, "Oh, this really works well with vertical transitions." "Oh, we need vertical transitions here, here, and here!" "Ice level!" "Oh, we can do this!" So, when a POC idea actually can generate a quick list of ideas in five minutes, like in a conference call or a brainstorm meeting, then you know it's good. It's sticky.

BD: From the gameplay developer point of view, I know a feature is good when it can be communicated without me telling them how to use it. If I can just give it to you and you can start playing it and you're like, "Oh, that's cool," without me even saying anything, that means that feature is playable. Like, if you're adding effects and animation and all this stuff to try to teach the user how to use it, it might not be the most intuitive thing.

YI: Those are certainly two good examples of standards.

How do you not let yourself say, "this is good enough" -- how do you stop yourself?

BH: Nakada-san's famous for, in the conference calls, talking through ideas and then at the last minute he'll say, "however..." in Japanese.

RN: [In English] Mister However. [Everyone laughs.]

BH: He's got a meticulous commitment to never saying it's good enough. To rephrase the question, when do you say it's good enough? I think the way it works is those two guys in Japan say it's never good enough, and we keep going and going until we run out of time, or it's time to do something different. So, you need to have that separation.

RN: And as I mentioned earlier, it's really important that it feels right when you actually play it.

YI: So, the process goes: The development staff plays it, and if it feels right, you let someone else play it, and if they achieve the same feeling that you intended, then that's when you know it's good.