Nintendo's Pipelines: An Interview with Nintendo Software Engineer Takeshi Shimada

It’s quite rare that one gets to interview the people behind the technology at Nintendo, but at GDC 2007, that very opportunity was afforded us, when we spoke with Takeshi Shimada, manager of development support and platform software engineering. His job is to manage tools use, creation, and workflow for Nintendo’s creative teams, and his talk at GDC highlighted some of the recent projects he has been working on with his team, such as voice recognition for the DS, and handwriting recognition (specifically for Brain Age).

In this interview, we discussed Nintendo’s tools and workflow, as well as the differences between Japanese and American development processes and tools creation. Shimada is uncommonly forthcoming, and shares some insight into the tools that facilitate the process at Nintendo.

Gamasutra: When did and how did you start with Nintendo?

TS: I joined Nintendo about 14 years ago. After graduating from Industrial University in Nagoya, I decided that I really wanted to make something, but began to feel that my interests were not necessarily in making something that was a practical machine or device. I wanted to make something that would make people happy.

GS: What projects have you worked on so far?

TS: When I first joined Nintendo, I was a hardware engineer at the time, and had a number of different projects. Most recently, I've been working on development tools for various platforms.

GS: Can you say which specific hardware platforms?

TS: During the days when I was working as a hardware engineer when I first started, I was working on the Super Famicom cartridge system. Now I'm no longer doing hardware, just mostly development tools.

GS: In many ways, Japan has been sort of behind the curve in terms of development pipelines, tools development, and middleware adoption. Why do you think this is, or do you disagree?

TS: I feel that America certainly is fast when it comes to creating and adopting middleware, but at the same time, if you consider how to make product development more efficient, Japanese developers have a different approach. Purely in the sense of how you make something more efficient, I feel that they actually line up pretty well, even though it's a different approach.

GS: We've gotten postmortems in our magazine from games in Japan, and quite often they will come upon some sort of pipeline revelation for them, which is usually something like "All developers should talk to each other, and we shouldn't keep the departments separate!" It's a little surprising because it seems so logical. There seems to be a kind of secrecy involved in structure. Is that a setback?

TS: I absolutely do feel that communication is very important. In my role at Nintendo, I end up emphasizing it quite a lot. In my case, I'm the leader of two teams that work on development tools that are used by all of the teams internally at Nintendo, as well as second and third parties. Of course it's important to make sure that each of these different teams can still use these tools the way that they were intended to, so that becomes something that my team has to ensure: that everyone can approach these tools in the same way.

That flow of thinking has been going on more or less since the days of the Nintendo 64 development tools. But because each team has a different way of working, communication is absolutely essential to find out what the needs of each team are and how they're actually using tools, so that I can coordinate my efforts and the efforts of my team to create something that is usable by everyone.

Despite that, I feel that long ago, there was a period where we would end up developing middleware that could not be used by all groups. Over time, we came to match different groups' workflow, to be able to provide middleware and tools that fit into their workflow very well. This was a very gradual process, as we came to understand how to do this. It took a lot of talk between internal teams to figure out what their needs were.

For my part, I found that I needed to be able to develop these tools very flexibly. There were constant demands for different needs for different teams that had to be taken into account, so it was very much an evolutionary process.

GS: A lot of companies were very secretive about their engines, graphical advances and things like that, to the extent that when Hudson was trying to remake their Tengai Makyo series on GameCube, they had to start with the sequel because they lost the source code to the first game, since they had ensconced it away so cleverly that even they couldn't find it.

TS: (laughs) I don't know too much about how Hudson works, but that's pretty amusing. If you look at things purely in terms of how development is working to get teams ahead, I feel like the U.S. is sort of a frontrunner in terms of providing tools and matching workflow with various teams.

GS: How has Nintendo restructured itself to maximize production, in terms of workflow and how assets are passed around?

TS: There's constantly a process of trying different things in that area. It's hard to nail down a single process. It's rather experimental. I find that just the pure penetration of information is something that's very important to consider. One of the most important things in my job is making sure that accurate information gets out to all departments as quickly as possible, so that everyone is on the same page. It's not really a matter of the human communication we were talking about earlier, but also the penetration of information, so that not only are people talking, but they're talking about the same thing. One of my jobs is to make sure that this information sinks in broadly and deeply.

GS: Does Nintendo use only its own internally-developed tools?

TS: Internally-developed tools are used at Nintendo if they're better than anything else that can be found outside the company. Whenever we feel the need for a particular tool that we haven't already developed or don't have the resources to commit to in any given moment, we start to test outside tools and as soon as we find one that fits our needs, we'll begin collaboration with an outside maker.

GS: So Nintendo does currently use some outside tools?

TS: Yes, that's right.

GS: Have you found it difficult at all to provide new libraries for the Wii, since it has a new kind of input?

TS: It's not so much that they're really hard to provide, it's that there's so many needed. There's a lot for us to do.

GS: Microsoft is providing development libraries for anyone with their Game Studio Express. Is this something that Nintendo might be interested in pursuing?

TS: I haven't heard anything about plans to do something like that.

GS: How different is the graphics chip in the Wii from the GameCube's chip, and why create a new one specifically for the Wii?

TS: Very generally speaking, people tend to expect somewhat of a linear progression in terms of the graphical and sound capability of machines like this, but the Wii really represents a departure in that way of thinking in this evolutionary line. One of the things that we have tended to consider in the development of this hardware is that we might consider producing games with lower processing needs, and so as we were thinking about that, that actually went into our hardware development. It wasn't so much that there was like a stall in progress between GameCube and Wii, but rather Wii is a totally different kind of system. We were just thinking of what the needs would be eventually in our development cycle. So, we approached it as a completely new platform with a very different scale.

When thinking about our graphics and audio pipeline on Wii, we needed totally new development tools. This time around, there are so many new features -- things like wireless, the way the remote works -- that it basically meant starting over with new dev tools as well.

GS: What has been your biggest challenge in terms of software and tools development for Wii?

TS: Whether we're talking about the Wii or the DS, what I take as my personal challenge on all of these projects on an ongoing basis is how to help developers bring their ideas to life as easily as possible. When you think about the Wii and the DS, they both have a lot of devices embedded within them, so they're actually both very complicated pieces of hardware. But, if you're going to help a developer bring an idea to fruition, you need to give them tools that are as easy to use as possible.

My constant challenge is to not make anything harder than it needs to be, because every time you do that, it's going to act as some kind of barrier in these developers' otherwise unlimited creativity in their projects.

GS: Game schools are only just now taking off in Japan. Is Nintendo getting involved in this? Do you think that students from game schools will make better employees?

TS: Nintendo is currently involved in a project called the Nintendo Game Seminar, which is a year-long series of courses where people who want to make games can go to classes that are taught by actual developers from Nintendo. This is not necessarily a school that they've started, but they are participating in this educational drive, just with a slightly different approach. This project began right after I started at Nintendo, so I'm now working with several colleagues who did go to the Nintendo Game Seminar, and they're doing excellent work, so I absolutely do feel it has an impact.