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.