https://technologizer.com/2009/07/19/lunar-lander/index.html
My favorite part is this:
“After leaving high school I never thought about the game again,” says Storer. “Until about a couple of months ago when someone e-mailed me about this, I was completely unaware of any Lunar Lander game other than the one I wrote in high school.”
When I applied for a job to work on Lotus Notes (back in 1989), I showed the interviewer (Tim Halvorsen) my Lander game. He said, "That's pretty cool--let's try running it on Windows 3."
At first, I thought, cool! I get to see Windows 3 (which had not yet been released). But then he said, "Windows 3 runs everything in protected mode, so if you have any out-of-bounds pointer access, it will crash instantly. Let's see how you did."
I was on pins and needles the entire time.
But fortunately, Lander didn't crash, and Tim was happy. I ended up getting the job, which forever changed my career.
I just wanted to add, there's also mechanical lander games that pre-date lunar lander
I can't find a picture. IIRC the machine was something like this
https://content.invisioncic.com/r322239/monthly_10_2015/post...
Except it had terrain and pits. A pit would light up and you needed to land in the pit (your ship landing would depress the button in the center of the pit). If you didn't aim well your ship would hit the edge of the pit, tilt, and you'd fail. If you did hit the button then the light would go off and a different pit would light up.
-- update --
now that I think about it, maybe the controls were more like UFO catcher where you'd align at the top and then press "land".
Anyway, it used to be at Disneyland at the Main Street Arcade.
I returned to the museum a few years ago and it was no longer working. I hope they fix it one day.
a) thats awesome b) I am taking a wild leap in deducing you're the same retro-games Benj Edwards journalist that was part of the infamous Retronauts East team. Just wanted to say i always quite enjoyed your presence :)
I thought it was a little odd that he mentioned "impressive for a high school senior in 1969" multiple times throughout -- honestly I would imagine that growing up in the Space Age would have had a massive influence on technically minded folks, reminds me of that movie from a while back called October Sky.
In the interview in TFA with the game's author he mentions being skilled at calculus--seems to me that if you were interested in space/rocketry/etc. and had the aptitude it makes sense that you'd try your hand at programming a lunar landing game.
[1]: https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
---
That explanation still wouldn't mean support the assertion that writing the lander game is the part that's "impressive for a high school senior in 1967."
If anything, all this explanation would show is that their having access to a computer is the "impressive" part.
https://retro365.blog/2021/12/02/bits-from-my-personal-colle...
Wikipedia on FOCAL:
Also, the IF syntax is a little limiting and hard to read, although I suppose programmers would get used to it.
OP here. I see your point. But think of what's needed to create this game:
- From high school physics, you know to start with a free body diagram. There are two forces, gravity and thrust. So far, your average high school student with an A in physics should be able to do that.
- Gravity depends on the distance to the center, which of course is changing, that's the whole point of a lander. I mean, you start 120 miles up. You have to realize it doesn't change much, so can be approximated as a constant. But you've been exposed to that in physics class, so maybe you just assume it's a constant.
- How the hell does thrust work as a function of burn rate? Is the exhaust velocity higher when you burn more? In other words, considering 100 lbs/sec vs 200 lbs/sec, when you double the flow of fuel into the engine, and then you burn it, it turns into twice as much fuel in the same volume. Wouldn't it be forced out at twice the speed? Or at least a higher speed? Maybe you think of the universal gas law, PV=nRT. The volume is constant (the volume of the engine), n is doubled, R is a universal constant. So that means P or T changes, or both. Why is T, which is a function of the velocity of the molecules, constant why P is doubled? Why don't both change?
- So you talk to your Dad, who happens to be a physicist. Most high school students, even those getting an A in physics, don't have a physicist for a father who can look up the properties of rocket engines and find the Tsiolkovsky rocket equation. So a high school senior finding the rocket equation is impressive to me.
- To go from velocity to position, you need to integrate. I'm not sure your average A physics senior would think of replace the FLOG() call with a Taylor series and integrating it term by term.
- How many terms of the Taylor series do you need? Does it even converge for you? If he thought of these subtleties, that's impressive. But it's possible that young Jim didn't realize these issues and just uses 5 terms because that seemed like a lot of terms.
- So now you can simulate it in near the moon. Cool! But how do you detect when it hits the ground? You could try to solve for altitude equals zero, and see if there are zero or more solutions. But even if there are solutions, they might be in the past or the future. So instead you decide to look where the velocity is zero, since you know this happens exactly once during the turn. I think that shows some ingenuity there, although I don't know if that was 18 year old Jim's thought process.
- So you try to invert the rocket equation: given a desired delta-V, how much fuel do you need to burn to achieve it? If you try this with pencil and paper and high school math, including Calculus, you keep getting stuck. You don't have the tools to show that it's actually impossible and needs you to introduce a new function, the Lambert W.
- So maybe you give up, or maybe your physicist Dad helps you again. Using your Taylor series, you now have to solve a 5th degree polynomial. So you decide to scrap the 3rd, 4th and 5th term to get yourself a quadratic. Why is it ok to scrap these now, when it wasn't ok when computing the regular dynamics? I'm impressed that he realized he can use different levels of approximation in different circumstances, without it generating some inconsistencies or other problems.
- You somehow figure out how to use the alternate form of the quadratic equation, which means you didn't just look it up and type it in. Possibly impressive.
Years ago I threw out my only copy of the source code, thinking it had no value and would never be re-used, something I regretted later when I realized how early a graphics game it was historically, and how easily it could have beeen resurrected with a simple emulation.
On Lunar Lander and bugs: my first programming book had a version of this game in Basic that I never got to run correctly. 25 years later I came back to it and I was surprised at the ridiculous amount of bugs it had and the convoluted logic ("440 IF <condition> GOTO 450").
I eventually rewrote it as an adult [1] but young me stood no chance. And to this day I wonder what happened inside that forgotten Spanish editorial that turned (almost) working code into whatever made it to the final version.
A lot of this BASIC code had roots in the 1960's-70's. Back then, editors ruled the roost of print magazines where this code often showed up within, and in books of collections of code they especially ruled with an iron fist. There was little notion that source code had to be dropped in verbatim with absolutely zero changes, so editors would make "judicious" changes in the source code. They thought they were "helping" with "obvious" typographical and editorial decisions.
This lesson was slowly, painfully learned until material improvements across the industry started to take hold starting in the 1980's and realization that source code shouldn't be touched in print really began to permeate the print industry. Though sometimes I wonder if this dynamic spurred the rise of BBS' and helped loosen the stranglehold print media had upon source code distribution, and what an alternative timeline might have looked like if the ones in power in print media were more open to "outsiders" having absolute control over some portion of "their" content.
I learned all the above decades later after I first started playing around with coding as a child, from talking with a much older friend who rose up from within the print media world and saw what happened. When I was a child, with zero adult guidance, and only a handful of books from the school and community library about programming, it was a wonder I stuck with coding at all with the countless programs I typed in by hand from print media that were similarly riddled with errors, so your reminiscing brought back powerful memories.
Sounds completely baffling. How does that thought process even work? What did they think the code meant? What changes did they make, anyway? Did they learn to not touch math equations before?
> and the convoluted logic "440 IF <condition> GOTO 450“
To expand a little bit on that, while some instances in the code of your book could indeed use some cleanup (line 440 is especially egregious), the code in the book was likely written for the common BASICs of home computers of the time, which only operated on line numbers and had very limited branching statements?
The BASIC you use seems to be “structured”, which was extremely unusual for home computers of the time. I just recently saw that a C64 magazine from 1984 spent at least 3 issues of the magazine on a lengthy article series that introduced the readers to the wonders of structured programming!
The severe restrictions of the IF statement made assembly-language style conditional branches (using GOTO) extremely common and necessary.
You definitely could not nest IFs (as done in your code), so if you wanted to combine IFs together, you had to jump over the ones not taken. Commodore/C64’s BASIC (effectively Microsoft BASIC) did not even have ELSE, so usually ELSE had to be implemented with a negated condition and jumping over what would be the “ELSE” branch.
C64 BASIC did however have the interesting quirk that any other statement on the same line would belong to the THEN, e.g.
10 IF A=1 THEN PRINT “FOO” : PRINT “BAR”
Would print FOO BAR if A=1, and nothing otherwise. This of course worked only so far as you could fit statements on a (limited) single BASIC line. Other BASIC dialects would consider the PRINT “BAR” to not belong to the ELSE anymore, which is syntactically cleaner, but could be less convenient depending on what else the dialect offered.A lot of the convenience and rigor we take as granted today wasn’t there. C64 BASIC seemed especially “dirty” to me, having lots of bizarre quirks that are more the result of its implementation. (Another random instance: Every function had to have an argument, whether it was required or not, so you had to write something like “?FRE(123)” to print the amount of free memory, where the 123 did not matter at all.)
>It’s also possible to land gently, you just need to end your 14th turn with a low altitude and velocity, and then use low thrust in your 15th turn, landing somewhere after 150 seconds. It’s just the theoretical full-thrust-on-landing suicide burn, that takes around 148 seconds, that eludes us.
I expect the fuel-optimal soft landing strategy (ignored because it doesn't fit the exact form of a "suicide burn") would be to play 164.31426784 lbs/second at t=70 seconds, and then replace one of the subsequent 200 lbs/second inputs with 199.99999999 lbs/second.The earlier you "play" 199.99999999 the better, so just use exhaustive search and select the earliest play that still achieve a soft landing.
Even when the bug is fixed, the code is still only approximating the lowest point. Also, even when it detects that you've landed, now it needs to compute the time when you land, i.e. when the altitude is zero, not velocity. It also uses an approximation for that.
So the times will be a little off. If you're burning 200 or 199 during that last time step, you have a high acceleration so even a small amount of time turns into a large amount of velocity. Instead, if you're burning say 10 lbs/sec, then being off by say 0.08 sec won't change your velocity much.
Rather than a large deviation from a suicide burn at the end of the burn, a small deviation at the beginning of the burn should be a cheaper way (w/r/t fuel burn) to "search" the buggy code for a possible soft landing solution.
Anyway, what a fun write-up! Thanks for posting it.
I guess the idea is that the lower your frame-rate, the less accurate this approach is, or maybe the idea is it's fun to use the actual equations.
I'm curious how perceptible the difference is between the two at the original framerate.
https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
Only updating the mass/acceleration at ten-second intervals would be wildly incorrect!
In terms of physical accuracy, especially when you get near the surface, the mass does change significantly if you have a high rate of fuel burn. But in terms of how challenging/fun it would be, and what strategies you use as a player, I doubt it would make much difference. In fact, there are other lunar lander simulations in the BASIC computer games book, I think one of them does use the naive approach.
If 10 seconds is too long, you could still leave that as the turn in the UI, but internally break each turn into a bunch of smaller time steps, e.g. 10 time steps of 1 second each. Actually, the existing game does that in certain places, which is why his physics simulation takes in an arbitrary time S rather than always the full 10 seconds.
https://www.acriticalhit.com/moonlander-one-giant-leap-for-g...
>The rocket equation is what gives rise to the suicide burn being optimal
Nitpick, but this isn't strictly true.Even if you don't count the vehicle getting lighter as it burns fuel (which is all the rocket equation does here), a suicide burn will still be optimal.
The real reason is because a suicide burn minimizes gravity loss.
I also remember this lunar lander game running on a couple terminals at the Lawrence Hall of Science in Berkeley, California, also in the mid 1970s. I don't know what computer it was running on though.
I never looked at the source code for this program. I had no idea how sophisticated the math was. I wouldn't have understood it anyway, as I was too young in the mid 1970s. Then again, I'm not sure I'd be able to understand it now....
I recall lunar lander being available on, IIRC, ADM-3 terminals at Lawrence in early 1973, usually surrounded by a cluster of male teens. One "feature" of the kiosk mode for games was that a carefully-timed Ctrl-C would escape kiosk mode, and allow the user to play other games. Happenstance, or catnip for proto-hackers?
Memory hazy, but I think I used the inbuilt calculus features of the calculator to get a perfect landing with a burn of 45 (about half the fuel) on say turn 12.
I had no prior expectation of what the optimum burn was and certainly had not heard of a 'suicide burn'.
https://en.wikipedia.org/wiki/Spacewar%21
video of game is at 30 second but whole thing is a great watch
https://upload.wikimedia.org/wikipedia/commons/5/58/Restored...
Myst inspired many people to go into computer science and game development as well, so it's interesting to see how much of a snowball effect this Lunar Lander game had
I learned BASIC programming when I was 11 in 1981 (I think that’s right) at a summer computer camp on an Apple II.
I made a simplified version of lunar lander… it was ridiculously fun to make and play.
One of my cohort mates who was in the “advanced” Pascal class is still my friend to this day.
FWIW, modern flywheel clutch kits are way more expensive than brake pads, so the cost is not so clear cut anyway.
See e.g. Glitchipedia: https://errors.fandom.com/wiki/Glitchipedia:About
Applications were also still measured in bytes (the idea of the average program being so large that everything needed to be described in kilobytes was still in its infancy). So you literally didn't have enough space to hide 100 bugs that would linger unnoticed for 55 years: 100 bugs would be your entire source code. In fact, here's the source code for the game in the article: https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/... - it's 2027 bytes. If it had 100 bugs, or even 5, it either wouldn't run, or it would be obviously wrong.
And that source code also illustrates the kind of "game" this is: it's just a text prompt to get you to fill in the values that set up the flight, and then it runs a simulation with your parameters and spits out the result. That was enough to constitute a game people would play religiously, back in the day.
Things changed a lot since then =D