Why Does My Browser Game Crash Only After Players Keep Merging?

The most dangerous test result in game development is the one that passes on exactly one machine, and this devlog is a compact example of why. Rock Paper Overkill is a roguelite deckbuilder about merging the everyday objects under a bed into combos, and merging is not a side activity in it. The game page describes merging anything, with 241 merged cards to find, and a demo containing the whole first act, about 90 minutes of play. A game whose core loop is merging will be merged in, again and again, by every player who gets into it. On the author's Mac, that loop ran fine. Uploaded to the browser and playtested, it crashed a few times. The devlog gives no crash count and no browser or device list, so this article will not dress the result up as a measured failure rate. A few crashes in playtest are enough to matter, because a crash is not a blemish on an otherwise good session. It ends the session.

The pattern the author reports is what narrows the search, even without an internal mechanism. Previously, as more merges happened, there were more memory leaks, and the response was to rework the entire way cards and merges were drawn. That sentence is doing two jobs at once. First, it ties the leak to an action the player repeats, which means the leak should grow with play rather than appearing at a fixed moment, and a test that only plays briefly may never see it. Second, it scopes the fix to the drawing of cards and merges, not to the whole game, which is a useful discipline even when the details are not public: change the path the leaking action travels through, rather than hunting everywhere at once. What this article will not do is fill in the missing middle. The devlog does not say that objects were freed incorrectly, that a pool was missing, or that any particular structure accumulated, so none of those explanations appears here, however familiar they may sound to a Godot developer.

A leak that scales with merges has a testable shape, and that shape is the most portable part of this thin case. If the leak truly grows as merges accumulate, then a short session and a long session should look different, a session with few merges and a session with many merges should look different, and a fix that only helps short sessions has not addressed the reported pattern at all. The author's report is that the rework fixed the problem and the game should now be smooth, with an invitation to report any issues. That invitation matters more than it looks: for a browser game whose failure only appeared after upload and playtest, the next round of evidence will come from players on machines and browsers the author does not own, and the author has left the door open for exactly that evidence. Until such reports arrive, the honest status is the author's status. Fixed, smooth, and awaiting the wider test that only release can provide.

The browser part of the story deserves its own emphasis, because it is the part most easily forgotten after a fix. A game that runs fine on the developer's Mac has passed one environment, not the environment its players will use, and browser play adds constraints the desktop test never exercised: the build that players actually load, the browser's memory behaviour over a long session, and the accumulation that only repeated core actions produce. The devlog's file for this update is a web build, and the game page says player progress saves in the browser, which makes a mid-session crash more than an annoyance: it interrupts a session the player expected to persist. None of that turns this thin devlog into a thick technical postmortem. It has no numbers, no mechanism and no measurement, and this article has not invented any of them. What it does offer is a clean, small pattern: desktop fine, browser crashing, leak growing with merges, drawing reworked, author-reported smooth, reports invited.

Nothing below is presented as what frostyshotss did beyond the rework already described; the checklist is general browser-test practice for your own project, not the author's steps, and it stays inside that framing. The reusable idea is to test the build players will actually load, for as long as players will actually play it, doing the core action as often as players will actually do it. A desktop pass is not a browser pass. A short pass is not a long pass. And a fix is not proven by the absence of crashes in the same short test that missed the problem in the first place. If a problem grows with a repeated action, the test that proves the fix must repeat that action past the point where the old problem used to appear, and the report that closes the case should say how long that test ran, on what, and what was watched while it ran.