On Friday, a retired software engineer named Martin S. Martin announced that he had recently discovered a bug in the original Lunar lander the physical code of the PC game while tinkering with the software. Created by a 17-year-old high school student named Jim Storer in 1969, this seminal game featured action only as text-based status updates on a teletype, but set the stage for future versions.
The legendary game, which Storer developed on a PDP-8 minicomputer in a programming language called FOCAL just months after Neil Armstrong and Buzz Aldrin made their historic moon walks, allows players to control the landing of a lunar module on the surface of the moon. Players must carefully manage their fuel consumption to achieve a soft landing, making critical decisions every ten seconds to burn the correct amount of fuel.
In 2009, shortly before the 40th anniversary of the first moon landing, I set out to find the author of the original Lunar lander a game that was then mostly known as a graphics game, thanks to a 1974 graphics version and a 1979 Atari arcade title. When I discovered that Storer had created the earliest known version as a teletype game, I interviewed him and wrote a story of the game. Later, Storer released the source code of the original game written in FOCAL on his website.
Jim Storer
Fast forward to 2024, when Martin—an AI expert, game developer, and former MIT postdoctoral fellow—stumbled upon a bug in Storer’s high school code while researching what he believed to be the optimal strategy for landing the module with maximum fuel efficiency – a technique known among Kerbal Space Program enthusiasts as “suicidal combustion”. This method involves freefalling to build up speed and then firing the engines at the last possible moment to slow down enough to touch down safely. He also tried another approach — a softer landing.
“Recently I researched the optimal fuel burn schedule to land as gently as possible with maximum fuel remaining,” Martin wrote on his blog. “Surprisingly, the best theoretical strategy did not work. The game mistakenly thinks the dropper doesn’t touch the surface when it actually does. Digging in, I was amazed at the complex physics and numerical calculations in the game. Eventually I discovered a bug: a missing ‘division’ that had gone unnoticed for nearly 55 years.”
A matter of division
NASA
Despite implementing what should have been a textbook landing strategy, Martin found that the game inconsistently reported that the lander had missed the lunar surface entirely. Intrigued by the anomaly, Martin dug into the game’s source code and discovered that the landing algorithm was based on extremely complex physics for its time, including the Tsiolkovsky rocket equation and a Taylor series expansion.
As mentioned in the quote above, the root of the problem was a simple calculation error—a missing division by two in the formula used to calculate the lander’s trajectory. This seemingly minor error had major consequences, causing the simulation to underestimate the time for the lander to reach its lowest trajectory point and miscalculate the landing.
Despite the mistake, Martin was impressed that Storer, then a high school senior, was able to incorporate advanced mathematical concepts into his playing, a feat that remains impressive even by today’s standards. Martin turned to Storer himself and Lunar apparatus the author told Martin that his father was a physicist who helped him derive the equations used in the game’s simulation.
While people played and enjoyed Storer’s game for years with the bug, it shows that realism isn’t always the most important part of an immersive interactive experience. And luckily for Aldrin and Armstrong, the actual Apollo moon landing experience didn’t suffer from the same problem.
You can read more about Martin’s exciting debugging adventure on his blog.
