Link to Gamasutra
We do not learn much out of this interview other than the emphasize made by Shimada on the need to get the "information," in the broad sense of the word, out to every dev teams inside Nintendo.
We also learn that Nintendo is always open to third party middleware solutions.
The interviewer seized his chance and asked about the Wii GPU...
We do not learn much out of this interview other than the emphasize made by Shimada on the need to get the "information," in the broad sense of the word, out to every dev teams inside Nintendo.
We also learn that Nintendo is always open to third party middleware solutions.
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.
The interviewer seized his chance and asked about the Wii GPU...
...in vain.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.