It might be better to look at a more documented system, like the DS, but if the wii u is what will retain your interest it is not so bad.
Even without that there are loads of people that pulled apart file formats before, some of it might not apply to your systems (though things rarely go completely out of fashion) but more info in your head is not a bad thing.
http://wiki.xentax.com/index.php/Game_File_Format_Central
https://wiki.multimedia.cx/index.php?title=Category:Game_Formats
In my case there are three things I would look at
1) Pointers. They are something of a boogeyman for C family programmers, and most courses don't teach them in the best way. They do much like they say though and indicate the location of something within a file or memory. Sometimes they will start counting from the start of the file, sometimes it will be a little way in (usually from the end of the given section or start of the one you want), sometimes they will be relative (take the location you are at and add the data from the pointer) and sometimes they will have some kind of crazy maths done to it (a few times I have had pointer contents need to be shifted to display the proper data)
2) The hardware. Hardware is rather limited and only displays things in certain formats and converting on the fly is a pain. To that end many formats will mirror the hardware they are going to go into at some level, or at the very least play to it -- if your system does 16 bit reads especially well you might well have a format aligned to 16 bits rather than everything packed end to end. I don't know what I can point you at for a summary of wii u hardware, however it is very similar to the wii and gamecube so it can be worth learning what goes there
http://wiibrew.org/wiki/Main_Page
http://hitmen.c02.at/files/yagcd/yagcd/frames.html
3) High level formats. Despite what I said above about hardware there are many that will use known, be it in general world or in game specifically (or in whatever other field you are using), formats for their things as said formats may well have existing conversion code, and have solved all the problems likely to come up which saves a lot of effort.
I could go on and talk about text specifics, 2d graphics, 3d graphics, wave music, sample music, level designs, general game code, assembly and whatever else but I won't do it here, mainly as I have done it before with pictures and worked examples
http://gbatemp.net/threads/gbatemp-rom-hacking-documentation-project-new-2016-edition-out.73394/
