![Illustration of the Apollo lunar lander Eagle over the Moon.](https://cdn.arstechnica.net/wp-content/uploads/2024/06/moonlander_hero_3-800x450.jpg)
On Friday, a retired software engineer named Martin C. Martin announced that he recently discovered a bug in the original Lunar Lander computer game’s physics code while tinkering with the software. Created by a 17-year-old high school student named Jim Storer in 1969, this primordial game rendered the action only as text status updates on a teletype, but it set the stage for future versions to come.
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 moonwalks—allows players to control a lunar module’s descent onto the Moon’s surface. Players must carefully manage their fuel usage to achieve a gentle landing, making critical decisions every ten seconds to burn the right amount of fuel.
In 2009, just short of the 40th anniversary of the first Moon landing, I set out to find the author of the original Lunar Lander game, which was then primarily known as a graphical game, thanks to the graphical version from 1974 and a 1979 Atari arcade title. When I discovered that Storer created the oldest known version as a teletype game, I interviewed him and wrote up a history of the game. Storer later released the source code to the original game, written in FOCAL, on his website.
Fast forward to 2024, when Martin—an AI expert, game developer, and former postdoctoral associate at MIT—stumbled upon a bug in Storer’s high school code while exploring what he believed was the optimal strategy for landing the module with maximum fuel efficiency—a technique known among Kerbal Space Program enthusiasts as the “suicide burn.” This method involves falling freely to build up speed and then igniting the engines at the last possible moment to slow down just enough to touch down safely. He also tried another approach—a more gentle landing.
“I recently explored the optimal fuel burn schedule to land as gently as possible and with maximum remaining fuel,” Martin wrote on his blog. “Surprisingly, the theoretical best strategy didn’t work. The game falsely thinks the lander doesn’t touch down on the surface when in fact it does. Digging in, I was amazed by the sophisticated physics and numerical computing in the game. Eventually I found a bug: a missing ‘divide by two’ that had seemingly gone unnoticed for nearly 55 years.”
A matter of division
![Diagram of launch escape system on top of the Apollo capsule.](https://cdn.arstechnica.net/wp-content/uploads/2019/03/Apollo_Spacecraft_diagram-640x408.jpg)
Despite applying what should have been a textbook landing strategy, Martin found that the game inconsistently reported that the lander had missed the Moon’s surface entirely. Intrigued by the anomaly, Martin dug into the game’s source code and discovered that the landing algorithm was based on highly sophisticated 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 computational oversight—a missing division by two in the formula used to calculate the lander’s trajectory. This seemingly minor error had big consequences, causing the simulation to underestimate the time until the lander reached its lowest trajectory point and miscalculate the landing.
Despite the bug, Martin was impressed that Storer, then a high school senior, managed to incorporate advanced mathematical concepts into his game, a feat that remains impressive even by today’s standards. Martin reached out to Storer himself, and the Lunar Lander author told Martin that his father was a physicist who helped him derive the equations used in the game simulation.
While people played and enjoyed Storer’s game for years with the bug in place, it goes to show that realism isn’t always the most important part of a compelling interactive experience. And thankfully for Aldrin and Armstrong, the real Apollo lunar landing experience didn’t suffer from the same issue.
You can read more about Martin’s exciting debugging adventure over on his blog.