Earlier today I was reading a Nintendo Life article about how the file size for the Switch version of A Hat in Time sits at a massive 16GB (four times larger than the existing versions on other consoles). I broke one of the cardinal rules of the internet by reading through the comments section to see what folks were saying about this, and props to Nintendo Life, your commenters are great!

I did appreciate one comment from a user named Pod who is a graphics programmer in games, and offered a succinct guess as to their thoughts as to why. Basically, it boiled down to how those doing the port work likely didn’t have time to optimize, by re-using the same assets in different places. Rather than optimize and repeatedly use the same asset in a clever way, they may instead have used unique assets for every instance. This is absolutely a likely candidate for the ballooning file size, but I have another hunch.

To quickly contextualize, I have worked as a professional programmer since 2014 and have developed many games in that time (17 by my last count, most of which being small experiences). I have also developed a custom engine, as well as one of the first publicly available VR experiences (back when Oculus Dev Kit 1 came out). With that out of the way, let’s put our detective hats on and see if we can’t sniff out what’s going on.

I do agree with Pod that reusing assets likely contributes to a decent amount of the file size increase, but this also assumes that they are using HD assets for their visuals. It’s pretty common for devs to downscale their visuals for Switch, often leading to smaller file sizes because it has to render things in lower fidelity. However, if they continue to use HD assets and then are dynamically downscaling, then Pod’s explanation is definitely one possible factor.

The one which seems more likely to me comes to mind because of my recent experience with playing AI: The Somnium Files on Switch (you can find my review for it here). In its late-game, there are some heinous performance issues. These issues arose when it would do flashbacks to earlier points in the game. These would dynamically render a scene which happened earlier in the game – often times taking place in a different environment with characters who weren’t currently present on screen. Despite the flashbacks taking place in a very tiny on-screen window, sometimes it would take upwards of 15 – 20 seconds for these one-line flashbacks to finish loading.

From what I could tell by looking at it in a black-box way (meaning analyzing the game from the outside with no access to the source code), this is symptomatic of straight porting the code over from the PS4/PC version and expecting it to behave the same way on the Switch. Those other platforms have access to more discrete threads, a more powerful GPU, and more RAM – meaning dynamic rendering can be more fluid. There are many reasons a developer would want to dynamically render, with a major one being for optimizing localization.

Localization is the act of translating the game’s contents to various languages (usually Japanese and EFIGS – English, French, Italian, German, Spanish). When doing dynamic rendering, if you’re in Japanse, you just pipe in a specific sound asset and animation for that locale. English? Same thing, pipe in the English asset and the English animation; but the rendering of the visuals is exactly the same – it is a shared resource. The problem this avoids is one which is my suspect for what is causing A Hat in Time to be so giant – lots of prerendered stuff.

Usually the biggest culprits for file size hogs come from uncompressed media assets (audio, video, etc). One of the reasons that Nintendo-developed games are so tiny is because they heavily optimize these assets, and often downsample them (for example, with audio, you can think of it as using SD audio instead of HD audio).

If A Hat in Time is using HD, uncompressed assets for every localization, that is probably taking up a ton of space. Couple that with the possibility that they were running into performance issues with dynamic rendering, and the first solution I’d go to as a programmer would be prerendering everything for every locale. This tradeoff would give us better performance in exchange for a larger overall file size.

For the sake of argument, let’s say we did this and then generated ~1GB of prerendered assets across multiple languages (let’s go with the 6 languages mentioned above) which gives us an additional ~6GB on top of our original file size. It’s pretty easy to see how these file sizes can start to snowball really fast as soon as you’re doing localization! And especially why it can be far more space efficient to dynamically render.

This would be my best guess for why the game is so enormous compared to its counterparts on other consoles, but this is looking purely objectively without having played the game, nor looked at the source code. No matter the case, hopefully this quick read could give you some insight into what goes on behind the scenes while making games!

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

10 games better than Brothers

Scroll to Top