Someone ran Doom to see how long it takes to crash out. It took 2 and a half years—roughly the same timeframe required to break many a retro game

Have you ever sat there and thought to yourself: 'I wonder how long Doom (1993) would take to crash if I left it running indefinitely?' Well, someone already did and carried out the necessary testing to find out the answer. Phew, we can all rest easy tonight.

We can thank user minki over at Lenowo for running these tests. They booted up Doom on an old PDA, expecting it to crash at some point. That's because every time the game demo would run and then reset, the engine would store a new variable. Then it'd start up again, and again store a new variable. All in one long string until, blam-o, it'd crash due to an overflow—the data exceeding the possible bounds of the value used to store it. Though how long it'd take to crash was all theoretical, until it wasn't.

Minki ran a physical test on an old PDA—you don't need much to run Doom, as proven by that time someone played it in a PDF file, or a badge for a hacking conference, or even on its own box. They then left the game running, which would cause the demo to loop over and over, to see how long it'd take to crash.

It took two and a half years.

"The game had crashed, only hours after the two and a half year mark, proving that the variable did indeed overflow and cause the expected hard crash of the game," minki says.

In the comments over at Hacker News, some intrigued onlookers noted a few other examples of similar proclivities in older games.

Such as if you leave Crash Bandicoot 3 to run for a little over two years, the global timer will overflow. This ends up causing enemies to move backwards through time, objects to freeze, and some levels to break altogether. There's a fun video on this anomaly from Jimmy Breck-McKye on YouTube, which you can watch below.

There's also a sword in Final Fantasy IX that can only be earned if the player reaches the final dungeon in under 12 hours of game time. That, or they play long enough to overflow the internal clock counter, you can reset the timer and grab the sword. This takes, you guessed it, around two years of unbroken playtime. This has earned the sword the title of 'missable within reason' on the Final Fantasy Fandom, as it's not technically missable.

There's also another famous case of this involving a cake in Paper Mario. In the game, you have to try to bake a perfect cake, though to do so, you need to leave it in the oven for around 30 seconds. However, if you leave the game for long enough, a mere 4.5 years, you get a perfectly baked cake all the same. That's because the timer storing how long the cake has been cooking for exceeds its maximum value, and, luckily in this instance, resets.

The values that can be stored in an integer vary depending on whether it's signed, unsigned or depending on how many bits there are. As shown to various degrees here, you can exceed these values, especially on games with some sort of integral timer. Sometimes when that happens, it can cause the value to wrap around, becoming negative, which the programme doesn't understand. Thus, pure chaos, fun behaviour quirks, or crashing. Other times, you get a genuine security vulnerability.

Though you have to give it to the developers here. They didn't plan for this, because why would you? There are likely many games that run into the same issue, as it's more about the limits of arithmetic than poor programming. And hey, if you're leaving a game running for over two years to get an elusive weapon in Final Fantasy, maybe you deserve it as much as anybody else.