Metroid Prime devs put GameCube dev kit in freezer to fix post-release issue
Believe it or not, the developers at Retro Studios working on Metroid Prime back in the day actually put their dev kit in a freezer while attempting to fix a particular issue that affected a small portion of GameCube owners.
Jack Mathews, a technical lead engineer that worked on the project, shared this story while reflecting on the 20th anniversary of the game. Nintendo had shipped a “bad batch” of GameCubes that affected the CPU, but it turns out that Metroid Prime was the only game that wasn’t working properly. Because of this, animated objects weren’t acting the way they normally would on any other console.
To test the issue, Retro Studios was using a single dev kit with the irregular CPU, but it had to be “freezer cold.” That meant the team “literally had to put the kit in the freezer, test the game for 15 minutes tops, then start all over.”
You can Mathews’ full story about the situation below.
Shortly after Prime shipped, Nintendo told us that a “bad batch” of GameCube CPU’s shipped, and apparently Prime was the only game that misbehaved on them. We saw videos and it was clear what was going on.
All animated objects were freaking out. I’ll get into the techy reasons later, but the point was we needed to actually slow down some of our code, because it was running too fast for these CPUs to handle! We needed to be able to test this, but Nintendo only had one dev kit with this CPU. We couldn’t detect the CPU, and if we slowed it down too much, the game’s framerate would tank. If we didn’t slow it down enough, it would glitch. Even worse, we had to burn disks for this kit. So each test was hours. Even weirder was to see the problem, the kit had to be cold. Like, freezer cold. So we literally had to put the kit in the freezer, test the game for 15 minutes tops, then start all over. It was crazy.
We literally were running the kit from the break room freezer to the TV, and loading save games as fast as possible to as many places as possible in 15 minutes, then trying new code, re-freezing, and back. I’ll never forget it.
Techy stuff: Our skinning used the locked cache DMA to read in data and the write gather pipeline to write it out. Most of the Nintendo samples used the locked cache for both read and write, so my method was a bit faster. But it also hit memory bandwidth limits. As I recall, the issue was that the write gather pipe on these broken CPU’s wouldn’t stall when it was full or properly report its status, so we had to keep inserting NOPs in the code to slow it down just enough to stop stalls from happening, but not so much to slow down the game.
In case you were wondering, when someone called support about this animation problem, Nintendo actually sent them a new game disc with this updated code! That’s how we did “patches” back in the old days!
Metroid Prime senior engineer Zoid Kirsch is another developer who has been reflecting on Metroid Prime’s 20th anniversary by sharing development tidbits. You can read his stories on Twitter here.
