KungfuQuickness

Here’s a short story about the importance of load times for development productivity and how small optimisations can get magnified in terms of the total human 'waiting time' in a game like No Man's Sky: Let's rewind time to around 3 years ago, when our Switch version had just come to life with the basic code port done and enough things were working to get into the main game and render some basic elements of a planet. It’s fair to say that at this point, it looked like a buggy mess.. It ran at 5 fps, crashed after 30 seconds, and used 2GB more memory than we could ship with! All of these problems would need to be fixed for us to be able to ship No Man's Sky on Switch… But we did not address any of these critical things to start with, because the game in this initial state had one other rather large problem: it took more than 5 minutes to load! This was making any iteration on bugs untenably slow and more practically in terms of shipping - no player was ever going to wait 5 minutes for the game to load! At this stage of the project, there were two of us working on the Switch version, and with so many things to fix and such a limited amount of runs you could do each day, we dropped nearly everything else and focused on load-times : For over 2 weeks every single aspect of the game's loading profile was optimised. Some days we might get 10 seconds, sometimes 5 seconds—some days, painfully getting no speed-ups, especially as time went on when low hang fruit had been picked off .. and often becoming despondent that this was an impossible task. We persevered... and eventually got loading into the main game to under 2 minutes. This milestone was critical, and so at this point we switched (!) strategy to start to work on the other big things, but still spent perhaps a day each week on load times.. eventually reaching the shipping load-time of 60–70 seconds. From a development perspective, solving the load time issue first allowed a huge amount of other critical bugs to get quickly fixed within the next few months, which then in turn allowed more members of our team to begin work on other game areas. I still regard those two weeks where we did that pass as the most crucial phase of the port - It was a risk to take this approach with so many unproven other things in play, but we could not have saved that 2GB, made the game 6x faster, or completed the engine without this work. It was a real leap of faith to spend this amount of time on optimisation, when so many other unknowns might have subsequently prevented us from shipping on Switch! Throughout my systems and engine programming career, I've often worked on improving load times, and since way back in the PS2 era, I found that a good motivation for load time optimisation is the amount of human time you are saving, When you calculate how much even a small seconds saving gets magnified when a game is played by a lot of people - the thinking goes like this: A human life is roughly 80 years, which is around 2.5 billion seconds. Imagine that we shipped our Switch version with 30 second slower load times and each player loads or warps hundreds of times. For a given game, you can take the sales numbers, and play time and then estimate the total seconds saved - the numbers you get are surprising - into the dozens of human years of time saved or even several human life times, depending on how accurate your metrics are! For a bigger game (for example, Fortnite) if you do that same calculation, you get dozens of “lives saved” in terms of total waiting seconds, for something as simple as a programmer saving 10 seconds in the time taken to load a level. A final note: NMS is a fair more challenging game to work on, than a traditional game in terms of load-time optimisation; the procedural generation aspect means there's not an ideal term to describe the loading process, since more than half the time 'loading' is really a calculation time - I'll try to write some detail on this in a future post!