One solo developer lost his whole game to corrupted partition tables, then got it back from an email he had sent himself. He reverse engineered a build he had mailed to himself, and an open source program rebuilt his project: 343 files, verified, with no errors, in his own account. This is a recovery story, not a backup tutorial, because the tool is never named and the procedure is never described. What it proves is smaller, and more useful, than a tutorial: an off-machine copy saved a project that had no other copy left.
At a glance
The source: the video I Lost My Game, So I Reverse Engineered It by William S. Coolman of Starboard Bow Games, plus the game's itch.io page. The recovery facts below are the developer's own account in the video description; the video narration itself was not transcript-checked for this article.
The game: Shoot the Skeletons, a Halloween arcade survival game made in the Cobra2D engine. In August 2024 the first version was a guy in an arena with no background, collecting crates that did nothing.
The loss and recovery, as the developer describes them: his partition tables corrupted, he lost the whole project, and he recovered it by reverse engineering a build he had emailed himself. An open source program rebuilt the project and recovered 343 files, verified, with no errors.
Not claimed here: no date for the loss, no name for the open source program, no recovery steps, and no price. The video description says the browser version is free to play, while the itch.io page lists 2.99 USD, so this article states no price.
Last verified: October 31, 2026.
A clone that grew its own identity first
Shoot the Skeletons began, in Coolman's own telling, as a simple Halloween-flavored Vampire Survivors clone. The first version in August 2024 was a guy in an arena with no background, collecting crates that did not do anything. What turned it into something with its own identity was a set of player decisions, not automation: crates inspired by Command and Conquer: Sole Survivor, an area-of-effect attack the player chooses when to use, aimable rockets, a combo bar, and what he calls an absolutely overpowered flamethrower. On the itch.io page the controls make that identity concrete: WASD to move, the gun targets and fires automatically, SPACE fires the AOE blast, right click toggles rocket aiming when available, left click fires a rocket when available, and crates spawn on the battlefield and can increase stats while chain kills fill the combo meter.
Then the partition tables corrupted
The video description tells the disaster in one sentence each for loss and recovery, and this article keeps it at that length on purpose. His partition tables corrupted, and he lost the whole project. He recovered it by reverse engineering a build he had emailed himself. An open source program rebuilt his project and recovered 343 files, verified, with no errors. That is the entire verified record in the text sources. The description does not say what form the emailed build took, when it was sent, which program did the rebuilding, what steps were involved, or whether the recovered files needed cleanup before the game worked again. A draft that filled any of those gaps would be inventing the most interesting part of the story, so this article leaves them open and labels the recovery as Coolman's account, not as a tested procedure you can repeat step by step.
Even with those limits, the story earns its place in this series, because it isolates one clean lesson that does not depend on the unnamed tool. The project survived only because a copy existed somewhere other than the machine that failed. The emailed build was not sent as a backup plan in any grand sense described in the sources; it was simply off the machine, and that accident of location is what made recovery possible at all. Contrast that with a project whose only copy lives on one drive: when that drive's partition tables go, there is nothing to reverse engineer, no matter how good the recovery tool would have been.
What to reuse
Nothing below is presented as Coolman's method, because his method is undisclosed; the steps are general practice rewritten for your own project, and they stay inside it. Do not read this case as permission to skip backups and hope a mailed build will save you. Reverse engineering a build is a rescue, not a plan: it depends on having a build somewhere else, on a tool you cannot name in advance, and on files that may or may not come back clean. The reusable part is the unglamorous one: keep a real copy somewhere else before you need it, so you never have to find out whether a rescue would have worked.
What to do Monday morning
For your own project, check right now whether a complete copy exists somewhere other than your work machine. An emailed build saved this game by accident; your copy should exist by intention.
Send or sync your own project to an off-machine location on a schedule you can state, not when you happen to remember. A copy with no schedule is a coincidence waiting to expire.
Include your own source and project files in that copy, not just a built game. A build alone may be recoverable, as here, but source is what you actually want to keep working on.
Test restoring your own copy onto a different machine before disaster strikes. A backup you have never restored is the same hope this developer was lucky enough to see pay off.
Never plan around reverse engineering your own build. Treat any build-only recovery as a last resort, and write down what you would lose if only the build survived.
After any data scare in your own project, record what actually survived and how, while the facts are fresh, so the next scare starts from evidence instead of luck.