Two brothers lost their data twice in a row, and only one of them got it back. The artist lost every model and texture and had to rebuild them from scratch. The programmer lost his whole machine and lost no code at all, because he kept redundant Git copies somewhere else. Same team, same disaster, opposite outcomes. The difference was not luck. It was where the second copy lived.
At a glance
The source: the Hypercane Studios postmortem Rage Runner Postmortem, published on Game Developer on January 29,
2014. Every fact about the team below comes from that postmortem.
The game: Rage Runner, a fast-paced 3D obstacle-avoidance game for OUYA, released March 28, 2013, built in ShiVa 3D over about six months by two brothers.
The correction to the simple version of this story: this was not one disk loss saved by Git. It was two failures back to back. The artist's files were gone for good; only the programmer's code came back through Git.
Not claimed here: no calendar dates for either crash, no Git host or push frequency, no surnames, and no claim that art assets were in Git. The postmortem says none of those things.
Last verified: October 31, 2026.
The artist lost everything first
Jacob handled art, modeling, texturing, level design and marketing; Zach handled programming and level design. Their first major release was a game about hurtling down miles of hand-crafted trench as fast as possible while dodging obstacles, with no procedural levels and no hand-holding. Jacob had been fighting a lag issue in 3D Max when the program froze. He reopened it and the ship model would not load. In his own words, the crash wiped all his project files, all his models, all his textures, everything. An undelete utility recovered only a trickle of data. Most of what was lost was gone for good.
He nearly quit. Instead he did his third and final remodel and retexture of the ship, trench and obstacles, and this time he knew more. He calls 20,000 polys ridiculous for a game asset. His new target for the ship was under 5,000 polys, which he hit, and he dropped the trench to under 500 polys. Losing the assets, he writes, was probably the best thing that happened to him, because the remade game looks better. That is a real recovery, but notice what kind it is. It is recovery by redoing the work, not recovery by restoring it. The hours were spent again, with better skill, and the original files never came back.
Then the programmer's machine died, and nothing was lost
Shortly after Jacob's hard disk corruption, in Zach's summary of the event, Zach's RAID array failed and destroyed all of his data. He writes honestly that if he had lost their entire project he would probably have thrown in the towel. Instead, his overly zealous worst-case-scenario backup plan paid off: he grabbed one of his redundant Git repo copies and was ready to rock without a line of code lost. Read that sentence carefully. The claim is code, not the whole project, and the operative word is redundant, plural copies, not a single repo on the machine that died. The postmortem does not name a Git host, a push schedule, or whether uncommitted work survived, so this article claims none of that.
Zach's recovery even came with a second, self-inflicted wound, and it is worth keeping because it shows what a backup does not fix. While rebuilding the machine he installed a developer preview of Windows
8. About a month later the preview expired and the machine rebooted involuntarily every two hours, so he set a one-hour-and-fifty-minute timer to save before each forced reboot and survived that way for a good month. He did it because reconfiguring the development environment, Android SDK and NDK, 32-bit and 64-bit JDKs, environment variables and build scripts, would cost a full one to two days of productivity. Git saved his code. It did not save his working machine, and a careless rebuild choice cost him a month of timers.
What to reuse
Nothing below is presented as what the Hypercane team did; their postmortem gives no backup checklist, so the steps are general practice rewritten for your own project, and they stay inside it. The lesson is not that Git is magic. A repo on the only machine that dies is not a backup, and a backup that only covers code does not cover art, which is exactly why the two brothers had opposite outcomes. Your test is simple: if your machine died tonight, which parts of your own project would come back from somewhere else, and which would have to be remade like Jacob's ship?
What to do Monday morning
For your own project, list what lives only on one machine: code, art sources, textures, level files, build settings. Anything on that list is Jacob's pile, not Zach's.
Put a second copy of your own code somewhere other than your work machine, and test that you can clone it onto a different machine. A copy you have never restored is a hope, not a backup.
Give your own art and level sources a second home too, separate from code. Do not assume they are covered because your code is covered.
Write down your own environment rebuild notes: SDKs, tool versions, environment variables, build scripts. Zach's month of timers was the price of rebuilding from memory.
Never rebuild a dead machine with a preview or expiring operating system on your only work machine. Keep your recovery path boring, stable, and tested.
After any data scare in your own project, record what was actually lost and what actually came back, before memory turns a partial recovery into a full one.