6. The Hands-on Approach

Miyamoto-san, when you're asked what defines Zelda how do you normally respond? Can you give a definite answer?

Sure. For me, what makes a game "Zelda-esque" is actually much the same as what makes a game "Mario-esque".

And what might that be?

Basically, I think it's the way that these games don't leave the players feeling cheated. The players are well aware of what they like about these games, but naturally they will get upset if there are things in the game which are completely wide of the mark. Making sure all those elements the players expect are properly in place is fundamental to these games. If those elements are not where they should be, that’s when the player will say: “This isn’t Zelda!” So when I get upset, it’s on behalf of the player! I think: “This is unbelievable! What's the matter with this game?” (laughs) I have always made games on the basis that my voice is the voice of the player. And if we released it without making adjustments, the situation would ultimately be a lot more serious if we angered our customers. To me this point is absolutely fundamental, and it’s the same whether it’s Zelda or Mario. While both games have that attitude as their foundation, I would say that Mario is fun in a very accessible, immediate way while Zelda really gives you that expansive feeling that you are developing along with the game. Those are really the only differences between the two; fundamentally they are actually the same.

Ah, I see.

It’s fine if someone really likes Zelda’s story: in fact it’s great. But if a person like that starts to work on developing a Zelda game, they won’t necessarily be an ideal match for the project. Something else that is vital to Zelda is that everything fits together seamlessly. This isn’t easy to explain, but what I mean is that with all of the ideas in the game tightly woven together, the various elements of the game will perfectly complement the terrain and scenery. The balance of "sparsity" and "density" in the game works really well. This is something that's important in Zelda. A real challenge with Twilight Princess was that as development moved from the earlier stages into the latter half, that balance was lost. The 3D Modelling Team was steadily expanding the size of the game, but the actual content of the game was not keeping pace. The longer the 3D modelling and the content remain out of step, the emptier the game becomes. Or, game content starts interfering with other content and spoiling it. Trying to get that under control is a real challenge. Putting it another way, perhaps it's controlling the balance of "sparsity" and "density" that actually makes a Zelda game. Maybe this isn't limited to Zelda... Maybe it's the "Nintendo method" of making games...

What you mean is that it's the "Miyamoto method" of making games!

(laughter)

Even if we gathered all the developers together to discuss it, we couldn't get everyone to fully understand what that method actually is. Nor can I adequately communicate it from a position giving instructions from outside the main development process. From the outside, I can see various things on a surface level and could make comments about them, but the person who created those things might feel: "That wasn't what I was trying to do!" We'd always be on different wavelengths. But when I take a more hands-on approach and we all start working together to get the game into its final form, things start to click. When I'm looking at the development process from the outside, even if I were to give them a list of elements in the game which were lacking that Zelda essence, I don't think it would get across what was required. But once I have actually got the team working on implementing these changes to the game, if the developers were to look at that list of parts lacking the essence of Zelda, I think they would understand what had been necessary.

As they see the changes being made to the game, they come to understand. The fact that our core developers have all been through that experience really makes a difference when it comes to making Zelda.

I think that's true. So, for instance early on in the development process, when young developers encounter Miyamoto-san's input from the outside, a lot of them probably think things like: "Do we really have to pay attention to such tiny details?" or "Surely we don't have to worry that much about something like that?" However, when everything starts fitting together into its final form, they understand what he was doing and they'll say: "Ah, I get it! It turns out this way, so we really did need to do that from the start!" When they were working on making the game, they couldn't see this. We just spoke about games that leave the player feeling cheated. But it goes without saying, the developers actually working on the game don't mean to do anything of the sort. They just can't help losing sight of how players are going to react to certain things in the game.

As development progresses, game developers steadily lose the ability to judge how someone coming fresh to the game, with absolutely no previous knowledge, will feel when they play. That's why I think that Miyamoto-san joining the project towards the end is, in a sense, a very rational way of doing things. If Miyamoto-san was involved from the start, I think he would find it more difficult to see clearly how people will respond to a game the first time they play it.

Right. I developed a set rule when Miyamoto-san pointed things out about a game: "If Miyamoto-san says the same thing three times, we're definitely going to have to make a change!"

(laughs)

If he pointed something out once, I wouldn't rush to fix things. I would decide that for the time being, I'd rely on my own interpretation of the issue and make a judgement accordingly. But while I was thinking about it, he'd then point the issue out for a second time. Now that it had been mentioned twice, I'd be thinking that he really wanted to make that change, but I'd still be formulating a plan. Then, as there were other pressing issues requiring attention, I'd set the issue to one side for the time being. At that moment, Miyamoto-san would ask: "Why haven't you done it yet?" That was the third warning! (laughs) From then on, that issue would take top priority. That has been how things have worked up to now, but this time I didn't really have that luxury. The first time something was pointed out, I felt that we had no choice but to change it.

So you did it without waiting to be told three times? (laughs)

That's right.

You're finally seeing things my way, right? (laughs)

Did you keep getting "sob story e-mails" from Miyamoto-san?^{1 1}"Sob story e-mails" were discussed in Part 1 of the Zelda interviews. These were e-mails that Shigeru Miyamoto sent in the later stages of development where he would describe elements of the game which he was unhappy with.s

Ah, the "sob story e-mails"! Did the young developers mention those when you interviewed them? (laughs)

They did! (laughs)

But in my case, I wasn't getting "sob story e-mails", I was getting messages sent to my mobile phone with instructions as to what should be changed! I'd be on the train to work in the morning, when my mobile would beep and there'd be a message from Miyamoto-san: "About that feature we were discussing..."! (laughs)

(laughs)

And it wouldn't just be one; I was getting four, one right after the other! I kept willing the train to get there faster, thinking: "I've got work to do!" What I heard later was that somehow when Miyamoto-san had been sending those messages, he'd actually been in an important meeting!

He was sending messages on his mobile phone about changing features while he was in a meeting? (laughs)

Well, there was no time to be lost! The seconds were ticking away… (laughs)

I suppose that's true. In any case, it's a fact that if Miyamoto-san thinks of something, he wants to tell you straight away; he can't wait to tell you in person. So a lot of his instructions this time came in the form of e-mail.

Right, it was the first time I have done it through e-mail.

When we were working on Wind Waker, he would simply hand me two-page documents with all his comments gathered together, saying: "There you go!"

In the past I would often gather my comments in one document and hand them to the people in charge. I also used to make a point of avoiding going directly to the development area and to only deal with team leaders. That's because the management of the development team had been entrusted to them. This time round however, there were of course a huge number of people involved as well as a lot of young developers. That's why I thought that rather than all these instructions appearing out of nowhere, it was better if the developers could actually see the process behind these decisions.

I see.

Any staff who want to read those e-mails in detail can read them, and people who don't think they apply to them can ignore them as they see fit. Basically, I thought that it was best to get everyone to be aware of everything, including the way in which the people in charge take on board my instructions and how they respond to them. It's not as if I sent every mail to everyone working on the project. Perhaps what I would have once said to two or three people, I said to around ten people this time around.

This time there were a large number of staff, so if all your instructions were given to me alone, for instance, even making all the necessary arrangements and laying down preliminary plans would have entailed a lot of work. In that sense the system this time, where your instructions were communicated directly to all the people involved, was a good idea. All the people in charge of a particular task would see your e-mails and were able to give feedback based on their individual take on things. As a result of this, I think we were able to decide quite efficiently what we should do next.

An ulterior motive I had when I chose that way of doing things was that all the staff, not just the people in charge, would understand the criteria we use when assessing a problem. This meant that the criteria the developers applied to situations became standardised. Subsequent problems that came up were then dealt with much more swiftly. Naturally, as the number of people on a project increases, it becomes more difficult to have clear discussions of these issues.

But with dozens of people, even when you allow everyone to keep up with what's going on, it's still very difficult to standardise that criteria.

It is.

That's why I was adamant that people be made aware of the entire background and decision-making process, not simply the final conclusion or instructions that come out of it. But even so...

Even so, there were lots of e-mails which someone involved with Zelda for the first time wouldn't be able to make head nor tail of.

Right. If they hadn't been following the discussions closely, they would have been totally lost! (laughs)

But as everyone already knows they won't be able to make sense of the e-mails, lots of the staff would come and ask for clarification: "What on earth is Miyamoto-san trying to say with this?"

Well, the important thing is that they came and asked for clarification. At least then you can give them an explanation.

Right. Even if they don't fully grasp the meaning of the instructions, everyone will have some idea of what it's about. They can then come to have it clarified, saying something like: "I think it's saying something like this…" In this way, everyone became steadily more proactive in their attitudes so I think the way we did things this time was really positive for all the staff, as well as being a great help for me.

Was it really?

Yes, it helped a great deal.

That's good to hear! (laughs)