Grezzo's Workshop

[SoulofDeity]

So I was reading the dumped information for TP, OoT3D, and MM3D in speculation of the kind of tools they use to make games.


To begin with, the Nintendo64 sdk uses a build of GCC v2.7.2 targetting 'MIPSE'. This is a deprecated target, where the current version of GCC (v4.9.2) instead uses MIPSEL and MIPSEB, which stands for "MIPS Embedded Little/Big-endian". Despite the name, MIPSEL can still build big-endian binaries and vice-versa, so why they made a second target is a mystery.

 

Anyhow, all of the libraries and demos in the N64 sdk were written in C, and there was no C++ compiler. All N64 games were written in C. The OoT MQ debug rom references a ton of *.c files, one of which to keep in mind for future reference is a file called 'z_player.c', which is listed 12 times at 0x00C240E0 in the rom.

 

The N64 sdk also came with a suite of tools for converting and debugging audio and graphics. In particular, Nintendo used something called a "Nintendo Intermediate File Format', or 'NIFF' for short. It's basically an interchangeable container for multiple other file formats, much like the RIFF format used by Microsoft for AVI and WAV files. They would convert their 3D models to NIFF files, and then use a specific tool to convert the NIFF files into raw display lists for the RCP of the N64.

 

When GC games came along, the game data took on the form of individual files. Zelda and Mario games in particular used BAS (audio source), BDL (display list), BMD (model), BCK (combined keys), BRK (rotation keys), BTK (translation keys), BMT (material), BTI (texture image), BTP (texture pointer), and BLO (layout) files. While vastly different, this separation of data gives us a bit of insight as to how resources are developed. For example, texture frame animation uses a separate file containing pointers. For the N64, they could toss out the pointers to reduce memory by simply dumping the textures used by the pointer list into the object file back-to-back and referencing them by index. Additionally, their GUI design is based on layouts.

 

Finally, when we take a look at the information dumped from OoT3D and MM3D, we notice a lot of peculiar things. The things that tells us the most about how their development cycle works is a simple file path: 'd:\home\queen\dailyBuild\game_eu\sources\z_player.cpp'. What does this say exactly? Well, firstly, starting with Windows Vista, the 'd:/' drive has been reserved for the system recovery partition. This means that the developers are using either WindowsXP or earlier to perform their daily builds. The second thing is that they are using a Unix system for their main development (implied by the FHS-structured path). The third thing is that the developers are exchanging their daily builds via cd's. How can we tell this? Well, on Windows, drive letters A and B are reserved for floppies and C is reserved for the first hard drive. Everything after that is labelled D through Z. This means that D will be a second logical partition on the hard drive, a secondary hard drive, or a CD/DVD drive. Unix systems rely heavily on symlinks which are not supported by FAT32 or NTFS partitions. Since we know they are using Windows to perform daily builds and it can't detect EXT/XFS volumes, we can rule out that drive D is a secondary logical partition or hard drive. The fourth thing is that they contain all the resources for all their games in one directory. This is implied by the fact that the project is merely called 'game' and that each file has a 'z_' prefix that would otherwise serve no purpose. It also explains why OoT3D and MM3D would have leftover N64 graphics, and why some OoT3D models somehow made it into MM3D (sheik, ganondorf, impa, saria) despite there being no reason to copy the resources deliberately. The fifth thing is that they are now using C++, as shown by the filename 'z_player.cpp'. Nowadays, there are C++ compilers, but in the past it used to be translated to C and then compiled. So from this we can assume that the game was either entirely rewritten in C++ or that OoT and MM for the N64 were originally written in C++ and translated to C to compile for the N64. The sixth thing is that the developers were not using autotools or gettext despite using GCC. Otherwise, the 'sources' directory would likely be called 'src' or not exist at all and there would be no need for 2 letter language codes like 'eu' or 'jp' in file names.

 

Another thing that can be inferred from filenames like 'z_en_choo.cpp' is that the game engine is based on the Entity-Component System. This name in particular says, 'Zelda - Entity - Choo'. I haven't tinkered much with the 3DS game files, but in the N64 ones, other prefixes like 'bg' and 'obj' for 'BackGround' and 'OBJect' are sometimes used instead of 'en'. The ones marked as 'en' typically were either characters, enemies, or unique objects.

 

 

While it may not serve much purpose, I think it's kind of interesting to have a little insight like this as to how the Grezzo team works.

[xdaniel]

Some thoughts about the file path:

 

Well, firstly, starting with Windows Vista, the 'd:/' drive has been reserved for the system recovery partition. This means that the developers are using either WindowsXP or earlier to perform their daily builds.

My laptop came with Windows 7, its HDD split into two partitions from the factory - C: "System" and D: "Data" - with E: being the DVD-RW drive. The recovery partition is not directly visible in Windows.

 

The second thing is that they are using a Unix system for their main development (implied by the FHS-structured path).

The leaked 3DS SDK contains Cygwin, so it might very well be that.

 

The third thing is that the developers are exchanging their daily builds via cd's. [...] Since we know they are using Windows to perform daily builds and it can't detect EXT/XFS volumes, we can rule out that drive D is a secondary logical partition or hard drive.

"subst D: C:\cygwin\" or however you create those nowadays? Would mean "D:\home\[...]" really is ex. "C:\cygwin\home\[...]", etc...

 

The fourth thing is that they contain all the resources for all their games in one directory. This is implied by the fact that the project is merely called 'game' and that each file has a 'z_' prefix that would otherwise serve no purpose.

Wouldn't "queen" be the project name for OoT3D? Same for MM3D's being "jenkins", seeing how where OoT3D's ZSI files say "queen" in their header, MM3D's say "jenkins"?

[SoulofDeity]

Wouldn't "queen" be the project name for OoT3D? Same for MM3D's being "jenkins", seeing how where OoT3D's ZSI files say "queen" in their header, MM3D's say "jenkins"?

 

Nah, "queen" is the name of the user. Eg. On my Mint desktop, my username is "wajideu", so my home directory is /home/wajideu". Judging by the reference to ShUnqueen in the game, it's a possibility that Shun (the leader of the Grezzo team) uses the username queen. So an 8th thing the path tells us would be that that OoT was built on the project leader's PC while MM wasn't.

 

[kyrin64]

This is all really interesting thanks for sharing this  

[SoulofDeity]

Was on a phone before, so I couldn't do a full response well.

 

Some thoughts about the file path:

 

My laptop came with Windows 7, its HDD split into two partitions from the factory - C: "System" and D: "Data" - with E: being the DVD-RW drive. The recovery partition is not directly visible in Windows.

It sounds like you're using a custom partition layout. Regardless though, Windows doesn't recognize EXT/XFS partitions and Unix systems can't be installed on FAT/NTFS, so it's almost certain that they're using an external media.

 

The leaked 3DS SDK contains Cygwin, so it might very well be that.

 

"subst D: C:\cygwin\" or however you create those nowadays? Would mean "D:\home\[...]" really is ex. "C:\cygwin\home\[...]", etc...

Unless they have a single partition hard drive and no CD/DVD drive or have gone out of their way to remap the drive letters on their system (highly unlikely), their D is guaranteed to be a physical drive and not a substitution.