Making a Game the Nintendo Way - Luigi's Mansion: Dark Moon

Nintendo is famous for its game design craft. Satoru Iwata and Shigeru Miyamoto have both spoken about how the company simply won't let a concept leave the studio until it's ready -- in some cases abandoning half-done games, or just letting them simmer until they start to heat up.

How, though, does that process actually work? Is there a way to institute a similar process at your studio? It can't be as haphazard as all that, can it?

In this interview, conducted just before the release of Luigi's Mansion: Dark Moon (aka Luigi's Mansion 2), two developers from Vancouver's Next Level Games, which handled the game's development, and two from Nintendo HQ in Kyoto -- who joined the conversation via video link -- discuss how the creative process worked during the development of the 3DS title.

Bryce Holliday, director, and Brian Davis, gameplay engineer tell the story from their perspective, while Yoshihito Ikebata and Ryuichi Nakada, who both supervised development of the game, add their thoughts on how they got an external partner to make a game the Nintendo way.

First of all, when you were devising the idea of doing a new game in the franchise, how much did you feel you could tear down what had already happened in the past and did that change because of any factors such as new developer working on the franchise, the platform, the delay since the original game -- all those factors?

Bryce Holliday: Ikebata-san and Nakada-san were kind of like the keepers of the vision, and the original vision was Luigi, vacuum, and the dollhouse 3D camera.

They'd done experiments with the original game. Konno-san was the director of that game. And, they'd experimented with, actually, 3D technology at that time, and so internally, they were working out to try to do another demo.

So those were really the only three rules that we had at the very beginning, was basically: Luigi, a vacuum, dollhouse camera in a 3D dollhouse game. That was about it.

Brian Davis: In terms of gameplay, we were exploring new ideas throughout the entire development, but there was a big fan base of Nintendo games within the company, so we also wanted to retain certain features of the original to have that nostalgic feeling to it.

BH: The fishing game, in particular, with the circle pad was something that -- it was on the table as possibly changing it at the very beginning, but [from] our first demos it was pretty clear that that was the core essence of the game, so just actually added to it and improved it, rather than threw it out. That's kinda how it started.

The original Luigi's Mansion, from 2001, for Gamecube

Yoshihito Ikebata: Basically, at the beginning, we had a lot of analysis on the good and bad points of the original game, and made an effort to focus on the good points to draw them out and make them a bigger part of the game. And the original game was made to be played on the Gamecube controller, but this time it was a 3DS, so there was definitely an effort to shift make the controls more comfortable for the 3DS and also to really take advantage of the 3DS as a system to highlight features of the game.

You mentioned "nostalgia." I want to know how important it is to Nintendo when it's developing products to play up on that nostalgia. I don't know if you worked on it personally, but Next Level Games made Punch-Out!! for the Wii, and in general Nintendo has a dedicated fan base that they've had for years, so I'm curious about that.

YI: So, it's of course really important that we include elements that are appealing to fans of the original version. But we also don't want to leave people out or provide any barriers to entry by adding too much that's new. So, it's really hard to say with a percentage, or something, just how important we find including nostalgic elements is. But it's definitely a consideration.

BH: In development, at the beginning -- looking back it looks quite different how much nostalgia's in the game -- but at the beginning, Ikebata-san and Nakada-san were kind of holders of the framework, so to say. They said, "No Mario references, no nostalgia," at the very beginning. "Make a game" -- or make demos or proof of concepts -- "that don't need to rely on that support."

It's pretty easy to throw Yoshi into anything, and you'll get a Yoshi game, but we wanted to really explore what Luigi's Mansion was. So we weren't allowed to mess around with any IP or crossover stuff. And then eventually as the game -- as the core solidified, then we would push the limits and start adding some of the nostalgia in from the first game, and from the universe.  

BD: A lot of the driving force behind the nostalgia for the game actually just came from our gameplay team, because we're such huge fans. Like, "We should put the humming back in the game," where Luigi used to hum with the music, or, "We should try and see if we can get the communication where Luigi is shouting out to the mansion and add that as a driving force to the gameplay." The multiplayer, you actually communicate with the other players through the D-pad. And we actually worked that back in to the single-player. So there's a lot of surprises like that that were implemented because the people working on the game were so passionate about it.

The reason I ask is because it can be sort of a double-edged sword. People love Nintendo games and Nintendo franchises, so you have that there, but as Bryce was saying, if you over-rely on it, it could end up keeping you keeping from making creative decisions.

YI: Yeah, as you mentioned, if you rely too much on those nostalgic elements, it really limits your ability to try new things, and then at that point you're hampering the game experience. And I guess you could say that it's pretty common for us to then go in and add some of those nostalgic elements once the game is in a position where adding all those elements won't interfere with the core game.

BD: A lot of the stuff we put in for nostalgic reasons was toward the end of the project. We had a long period of time where we were just experimenting with gameplay.

BH: It's used as polish rather than as core.

BD: It's kinda like, "Brian really wants this feature in the game because he thought a fan might've appreciated it in the first one." And that went in, like, four months ago. But throughout the development of the game, it was just, "Create new ideas." That's the one unique thing about Nintendo that I like -- they are always creating new ideas, but with familiar IP. It's always gameplay first.

What is the first thing you think about when you start a project? When you decided that, "Yes, we're going to make a new Luigi's Mansion," what did you say was important to launching this project from Nintendo's perspective?

YI: So, this doesn't just apply to this game, but one of the things from the very beginning that we've held high, of course, is the controls. The gameplay and the controls have to perform.

I don't know how exactly this project got off the ground, but I don't know if they came to you and said, "It's Luigi's Mansion!" But when you're having these initial conversations, what mattered?

BH: Yeah, I can explain that. I was mentioning to the last interviewer: It kind of started as we were working on a demo for a different project completely, and then it was a conference call just like this, and all of a sudden they said, "Hey, we're making Luigi's Mansion," and it needs to have those elements we talked about earlier, about the camera. "We want to experiment with a bunch of controls that highlight the features of the 3DS."

So, I think we did a pretty good job. The game is actually easier -- the ghost-fighting, which is one of the core mechanics -- I believe it's actually easier with the 3D set to on than it is with it off. And that just speaks to the beginning of the game: it was, 3D was an important asset, we knew we were gonna have a circle pad, so let's make a core mechanic that will be enhanced actually viewing it in 3D.

Again, each gameplay-first control experiment that happened had a different reason to start it. So, it's not so much with Nintendo you get a big design document and then you execute. It's: "Here's this toy, and we want you to make a game -- or just think of ideas that highlight its functionality that's unique." That's an important part that Ikebata-san and Nakada-san would always say: "Why is this device unique, and how can we make gameplay around that device?"

And then you start from there, and eventually there's plenty of experimenting, and you start handpicking the best ones. So, from their perspective it's gameplay first, to highlight their technology in unique ways that aren't possible on other systems.

BD: Internally, we have this idea of "proof of concepts," called POCs. We would make hundreds of these POCs, and not all of them would be used in the game. So, it's just a constant, rapid prototyping phase, and ideas come from that.

BH: It jells a little bit later. I think Nintendo's commitment to experimenting and prototyping is known, and there's a long prototyping phase, even overlapping into production, throughout.

YI: We were making changes on the game even leading right up into debug.

BH: We're supposed to keep that quiet! [laughs] Yeah, and one other thing -- that maybe Nakada-san and Ikebata-san can correct my language if it's wrong -- but when you're being mentored by Miyamoto-san, he kind of puts challenges out to you.

And when thinking of the game as a concept, it's either you have to be the best at that type of game, or you have to be a game where nobody can say something like, "Oh, that [game]'s like this [game]."

"So, what's Luigi's Mansion like?" "Well, Luigi's Mansion is like Luigi's Mansion." If you can get that tagline, he finds that compelling, and that's kind of his driving force -- that you own the space. You don't worry about market; you just build a game and see if people will like it. 

YI: So, it was really important to be able to bring out the originality that is afforded by building a game within the Luigi's Mansion world and concept. We asked ourselves questions: What can we do because of this game setting, and because it's Luigi's Mansion? That's definitely a principle that we have throughout development.

BD: One of the points that Miyamoto brought up -- we originally had bosses designed in our game, and they were all designed, and then he said, "No, we actually want to make not just bosses, but Luigi's Mansion bosses." So, each boss is an original design for our game.

BH: You could've seen those other bosses -- the original concepts for the bosses -- in other games. They would look in their style, but you could've seen that animal-character boss in this [other] game. And he's like, "No, it has to be a more Luigi's Mansion boss."

And eventually one of the bosses that came out was you fight against stairs. Which would be a concept that would be pretty hard to do in a first-person shooter. Fight the stairs! But that's actually one of the bosses in the game, is a staircase. And it came out of that discussion of, "How can it be something about Luigi's Mansion?"

BD: A lot of those bosses are rewards for the player to experience. I think that challenge he put out to us, to make Luigi's Mansion bosses, actually brought out a ton of creativity from the team.

BH: You might notice if you've already been playing that only the first boss is a traditional one. After that, they become more awkward and weird... in good ways. In good ways!

I would like to talk a little bit about that process of experimentation, because as Bryce mentioned, it's really become clear from talks and interviews, and Iwata's presentation at GDC a couple years back, that Nintendo is absolutely focused on experimenting and working on games until they're right and if they don't get right, don't put them out.

I want to talk a little bit about not necessarily that process but from the process of working with an external developer, from both your perspectives -- from you working in Japan with them, and them working with you, how you can make that process work and have results.

YI: This was a case of a long distance between us, and the challenges that come with working apart, but having to communicate a lot was definitely the reality of the situation -- and we would do things like a video conference once a week, and while it is still just looking at your screen on your side of the world, it still was a way to have some face-to-face time and communicate.

BH: The commitment to experimentation, it's a little bit of a mindset that the developer has to get into. You have to be willing to throw out work, and that's really hard to do because you've got people -- your entire team, basically, putting their passion into the game and you think you need to get every feature to completion. But if you have this commitment to rapid experimentation, you set the tone of, like, "Hey, certain things are just gonna be thrown out and you won't ever have to finish them." We'll pick the best.

For me, as director, that's actually the hardest thing, trying to convince people that it's tenuous -- that the stuff you're doing might not make it into the final game. And after a little while, you're doing so many experiments it's just a different experience, for that reason.

So you just kind of end up trying a bunch of things that you normally wouldn't try because you're worried about them failing. And that's when you start getting real innovations. If we're trying so many things and we have the time, we're just gonna do things even crazier than we would've if we needed to make sure that that feature made it into the game. Being less conservative. And then there's technical reasons that Brian can get into of how we made it work. 

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.