Bitboy - How The Game Pulls Off The Refresh Mechanic

Hello!
This is the first of a two or three posts meant to go through how I managed to pull off certain things in Bitboy that left some people wondering how they worked. As a result, this post does contain spoilers. If you haven't checked out Bitboy yet, I'd appreciate it if you would. I've been going and reviewing the games of those who've reviewed mine. If you want to read anyways, go ahead!
This specific post is meant to answer how the game sets up its save data and how it uses that data at startup to drop the player at the right point in the story, as the game uses browser refreshes as a mechanic to move the game story forward. While this factor was something that surprised people in the game, the way Bitboy does it is actually really simple, and a lot of the surprise is more due to the way the game sets up expectations.
How Does Bitboy Save
The secret weapon here is Unity PlayerPrefs. While this answer isn't exactly shocking, what is interesting is the fact that PlayerPrefs are available within WebGL. The way they work in WebGL is via the use of the IndexedDB API for browsers. While this seems exciting, it is very limited. For example, once a person quits Safari after playing a WebGL game with PlayerPrefs save data, that save data will immediately be wiped. While Chrome and Firefox aren't as limited as Safari, they will also wipe the data once someone turns off their computer.
As a result, PlayerPrefs for WebGL is not a great solution for long-term saves. However, for Bitboy, where the point is for it to be played within one sitting-just after multiple refreshes of the browser page-it works perfectly.
Progressing The Game
Bitboy, story wise, is set up to 'loop' through the same situation where player attempts to prevent the deletion of the game itself. As a result, all game progress is primarily done via two integers: 'GameProgress' and 'ResetCount'. 'GameProgress' tracks the players general progress within a loop, and 'ResetCount' tracks how many loops the player has gone through in order to apply unique properties per loop. It is important to note here that WebGL PlayerPrefs require the calling of PlayerPrefs.Save() in order to actually save all the variables-if this isn't called, it saves nothing.
So, how are these variables used?
At bootup, Bitboy actually loads into a simple Unity scene that only displays a black screen. This scene has only one purpose-to go through a script that checks 'GameProgress' and 'ResetCount', and load up the appropriate scene for the player's current progress. You can see the script below.

Some integers for 'GameProgress' here are only used for 1 loop of the game-for example, 'GameProgress' will only be set to 0 during the very first loop of the game, where the player has first boot up the game. As can be seen in the photo, 'GameProgress' being set to 0 has the game go to the foreboding Delete screen that first meets players. When the player "resets" the game at the end of a loop, 'GameProgress' is set to 1, bringing players to the animated logo splash and the title screen instead.
Again, most of this information is well-known to Unity developers, with PlayerPrefs being the simplest way to save data within the engine. However, the fact that it works for WebGL builds is not as known, which is what gave the game its surprise here (in addition to purposefully making the game initially seem like nothing but a average infinite runner). Next time, I'll make a post covering how two of the more impressive corruption effects worked in the game.
Until then, stay curious.