I'm making a small 8-bit browser RPG called SnowRSPS Mini. This week I shipped version 2.4.2. The big visible stuff was a new layout and some art. But the changes that mattered most were three small fixes that stop players from getting stuck or losing progress. Here they are, in case they save you some time.
1. The bug where Attack froze after F5
A player reported this one. They refreshed the page, and then the Attack button did nothing. The game looked fine. It just wouldn't respond.
The cause was dumb in a good way. When you level up, my game pauses and shows a picker where you choose a perk. That picker was hidden after the refresh, but the game was still paused. The pause flag was saved and restored. The picker was not. So the game waited for a choice nobody could make.
What I did:
- Treat "paused" as something that always needs a reason. If the game is paused for a level-up, the picker must be on screen.
- On load, check for a saved pause. If it is there, show the picker again, or clear the pause if nothing is waiting.
- Add a quick check after load: if the game is paused and no menu is open, unpause and log it.
The lesson: any time you save state, ask what UI has to come back with it. A flag without its screen is a trap.
2. An auto-update banner that saves before it reloads
I push updates often. Players keep the tab open for hours, so they run old code. Reloading them for me felt rude, because they could lose progress.
So now the page checks a small version file every few minutes. If the version changed, it shows a banner: "New version ready." The button does two things in order. It saves the game first. Then it reloads.
A few details that helped:
- Wait for the save to finish before calling reload. Do not fire both at once.
- Never reload on its own in the middle of a fight. Let the player click it.
- Add a cache-busting query to the version file, or you will keep reading the old one.
3. Fast-tap protection
On phones, people tap quickly. Sometimes a double tap fired two actions, like buying an upgrade twice or opening a menu and hitting a button under it by accident.
My fixes were simple:
- Ignore a second tap on the same button for a short moment (about 150 ms worked for me).
- When a menu opens, ignore taps for a tiny moment so the tap that opened it can't also hit something inside.
- Check the cost again at the moment of the action, not just when the button was drawn.
That last one matters. A button can look affordable and still be wrong by the time the tap lands.
What I'd tell my past self
Most of my bugs this week were not about new features. They were about state: what gets saved, what comes back, and what happens when the player does things too fast. Test with refresh, with the tab left open overnight, and with a tired thumb mashing the screen.
If you want to see how it plays, the free browser version is here: snowrsps.com/io
Top comments (0)