Hacker News new | past | comments | ask | show | jobs | submit login
I found a 55 year old bug in the first Lunar Lander game (martincmartin.com)
426 points by martincmartin 6 months ago | hide | past | favorite | 114 comments



If anyone is curious, in 2009, I discovered that Jim Storer was the author of the first Lunar Lander game and interviewed him about it (and also chronicled the history of the game beyond that). He later provided the source code, which was awesome.

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.”


I'm honored to be included in this article--I wrote Lander (1990) originally for Windows 2.x.

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 was a huge Anacreon fan back in the day, thank you for hours and hours of entertainment!


I really appreciate that! I had a lot of fun working on it. Thank you!


Thats awesome an story


That's awesome

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 played the game in this picture at the pinball museum in vegas. One lever operates the rear fan and the other operates the bottom fan. It was a lot of fun for an analog arcade game.

I returned to the museum a few years ago and it was no longer working. I hope they fix it one day.


Seems unlikely that a computer was involved in this.


Lunar Lander was one of the early games I tried to make a copy of as I was learning programming in high school: (Java applet!) https://github.com/celwell/space-landing


Wow, that is a great article. Incredible research and depth. Thanks for the contribution.


Well yea, two points:

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 :)


dude,that's awesome!


Pretty cool, the offending line seems to be 08.10 [1].

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/...


There were on the order of hundreds of high school students with computer access in the US in 1969, and even fewer with computer literacy. Growing up in the Space Age probably was inspirational, but that doesn't change the fact that computers basically didn't exist to the general public at that time. Unlike now, software development wasn't a widely known career. There wasn't a CS major in the US until 1962. I think that makes it pretty notable he was a high school senior in 1969.


EDIT Personally, for clarification, I do think the code is impressive, but the above back-and-forth doesn't really explain why.

---

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.


It needs access to a computer, creativity, and an impressive amount of capability for a high school senior.

This is 5 years before pong - you are inventing game concepts from scratch rather than standing on the shoulders of giants.


> and an impressive amount of capability for a high school senior

It's only impressive because very few (none?) high schools teach calculus at the level required for his implementation. High schoolers are quite capable of handling that kind of calculus, it's just that the high schools don't teach it.


It's not about the level of calculus knowledge for me - it's about building this from scratch with 1960's technology in 50 lines of basic and very little prior art.

It's easier to be the second person to do something.


For accuracy, it was written in FOCAL, not BASIC.


Thanks, my mistake!


I agree with that.


I’m fairly certain that while schools might be capable of teaching calculus at this level, the amount of interest in that roughly corresponds with the number of students that already know calculus at that level anyway.


The UK stopped including calculus as part of physics even!

I got told off for doing an integral.


How sad.


Yeah but being first is part of it, no? In my mid 20s I read Karl Popper's Conjectures and Refutations and realized I'd reached the falsification pathway to epistemology as a teenager. But was I a genius or was I just lucky to be born in this age where the soup of concepts we're bathed in makes that obvious? I think the latter. Same with Goldbach's Conjecture, I came up with an equivalent conjecture as a pre-teen.

Evidence since has shown I'm reasonably intelligent but not the Popper or Goldbach or even the Walter Bright of our times.

Humanity the organism evolves so more things become obvious to more average members. Perhaps ten year olds will see the intuitive use of monadic structures in the future.


I think both. It's likely only very impressive high school students got that much access to a computer in 1967.

It reminds me of an article I read about Jai alai years ago: the sport is long, long past its peak, and one of the people interviewed said the players nowadays are some of the best ever, because only people who are really, really good and really, really love the game still try to play professionally.


That doesn't make any sense.


Not disagreeing with the overall point here, but there definitely were some high schools with computers and programming classes by then---my mom was teaching programming (FORTRAN) in a Chicago high school starting in 1967. I think she was one of the first dozen or so high school programming teachers in the country but I don't think she was _the_ first.


yeah bill gates at lakeside in Seattle was one of like 3 high schools in the country that had a computer.


It’s unsurprising that at least one of the hundreds would write such a game though? In particular when those having access already are self-selected to some degree.


It’s unsurprising that anything was done by somebody. In fact it is inevitable that the most impressive thing is done by somebody out there, because otherwise it wouldn’t be a thing that was done. But, being that person can still be impressive.


It's unsurprising that someone is the best at the world at running, but it's still pretty impressive when they do it.


I was in high school in 1969, knew some calculus, and was very interesting in programming. In a good size city with a major engineering university and a large high school the main barrier was access to computers. Our school had teletypes connected to a remote mainframe. My friends and I found a few computers at the university we could use at night, but most had card readers and line printers, and none had graphics terminals of any kind. I think the particular combination of skills, interest, and access would have been pretty rare at the time.


I needed to know what language that is written in. Turns out it's something called FOCAL, as mentioned in this article about the game:

https://retro365.blog/2021/12/02/bits-from-my-personal-colle...

Wikipedia on FOCAL:

https://en.wikipedia.org/wiki/FOCAL_(programming_language)


OP here. One interesting thing about FOCAL is that * has higher precedence than /. So in Lunar Lander, M*G/Z*K is what mathematicians and other languages would write M*G/(Z*K). I did a double take when I first saw that. :) As the Wikipedia article says, "This can cause subtle errors when converting FOCAL source code to other systems."

Also, the IF syntax is a little limiting and hard to read, although I suppose programmers would get used to it.


That's surprising from today's perspective, but when I imagine the thought process, it seems reasonable, especially for math and science purposes where multiplication and division operators usually get grouped into a series of multiplications above the division bar, and a series of multiplications below it.


True. + also has higher precedence than -, so that a - b + c means a - (b + c).


Ah, the old

    My
    Dear
    Aunt
    Sally
vs.

    My Dear
    Aunt Sally
debate. :)


Your code got munged, use backslash to escape * (otherwise it starts a span of italicised text), or use four leading blanks for code blocks (in which escaping is usually not needed):

M*G/Z*K

I think you meant, the above and

    M*G/(Z*K)
respectively.


Thanks. Fixed!


Another curious feature is that the labels appears to be floating point, as in "G 5.9" appears to transfer control to line starting at "05.90".


They aren't actually floating-point: each label is a pair of numbers, the first denoting the group and the second denoting the line within that group. The groups have no semantic importance, they are only for organization.


Actually, I was mistaken. The line numbers aren't even numbers, so much as digit pairs, given how one-digit labels take the first digit.

And the "DO" command takes a group number, runs each line within the group, then returns after the end of the group. So each group can effectively act as a subroutine. (In this particular game, this can be seen in groups 6 and 9.)


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.

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.


Though famous as the first lunar lander game, the impressive part was the specific numerical techniques used.


OP here. Yes, that's what I meant. Using the rocket equation, truncated Taylor series approximation, truncating even more to make things solvable, then iterating to improve the solution, were all things I wouldn't have expected.


It wouldn’t be quick for me and I have done University calculus.


In the mid 70's I wrote a 2D vector graphics moon lander game for the Adage graphics terminal. You came in fast horizontally and had to use push buttons for the LEM side thrusters and main engine to slow down and land horizontally, resulting in either a crater if you were too fast, or if you ran out of fuel, otherwise you saw one or more planted American flags depending on the quality of the landing.

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.


Whoops, I meant "land vertically".


> By 1973, it had become “by far and away the single most popular computer game.”

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.

[1] https://7c0h.com/blog/new/moon_landing_in_basic.html


Oy vey, "no chance" is putting it lightly.

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.


> They thought they were "helping" with "obvious" typographical and editorial decisions

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?


> How does that thought process even work?

As it was explained to me, it was territory marking/office politics. Editors back then were very powerful when it came to decisions on content. They did not take kindly to anyone explaining/telling them they had no control over any portion of the content.

> What did they think the code meant?

This gets interesting. They were told it was for the computers, but upon seeing high level language artifacts that looked vaguely like English words, they grabbed their red marking pens and leapt into action, absolutely certain they were in the right as they had always been in the past. This was at the very beginning. Later, it got more nuanced.

> What changes did they make, anyway?

Early incidents had stories of galleys using non-proportional font forced to change to proportional font simply due to aesthetics. Red pens changing the contents of PRINT statements (because it said "print", and that was their domain, right?). Even later with more lessons learned and nuances started to creep in, this was way before programmer fonts made the scene, and the typical goofs one would expect from manual transcription were rampant. The pipelines did not exist yet back then for a long time to take raw source code and dump them into the non-digital typesetting systems at the time, so it was all laboriously transcribed from printouts by non-technical staff.

> Did they learn to not touch math equations before?

Very little cross-pollination of editors experienced with math-heavy technical writing, and those overseeing print products popularizing BASIC programming. BYTE magazine was revolutionary at the time for realizing this, and even they had some gaffs from time to time.


That was an enjoyable read. I, too, when I was a child sometimes thought the same thing about my C64 “magically” being able to load some game-related images with just a few lines of code that are… just somewhere inside it? A super bizarre thought, but as a child you’re still prone to a lot of magical thinking.

> 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.)


Probably copy/paste errors (in editorial) mixed with deadlines mixed with no QA.


  >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.


The nature of the bug is that it has trouble finding when the lander has touched the surface. You need to have an altitude of less than zero for around 0.05 seconds for the game to notice that you've landed. If your thrust during that time is 200 or 199, to have an altitude < 0 for that long, then you need to have a speed greater than 1 MPH when your altitude is zero.

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.


I get what you're saying, but I don't think that contradicts the optimal strategy I outlined?

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.


Yeah, I think we're agreeing. :)

So it turns out, before discovering the bug, I actually wrote code to find the optimal sequence when your choices are restricted to integers. I thought, along the same lines as you, "maybe if you burn 165 or 170 or something in the first non-zero term, then you could burn less on the 14 turn and still land."

And this is how I know it's not possible, at least with integer burn rates. :) I checked all 201^9 combinations, with a few optimizations to cut down the search space.

That's different than what you said, of using floating point for the last burn. But it is in a similar spirit.


  >I thought, along the same lines as you, "maybe if you burn 165 or 170 or something in the first non-zero term, then you could burn less on the 14 turn and still land."
That's not exactly what I was thinking.

Clearly that won't work, because just by changing the least significant digit (ie adding 1e-8 lb/s) in step t=70 seconds, you "blow past" the soft landing window, in part due to the bug.

Evidently the move played at t=70 seconds is, in effect, too 'course-grained' to effectively target the (small) soft landing window. By shifting your "subtract 1e-8 lb/s" move (ie playing 199.99999999 lb/s) later and later in the burn, you effectively make it more and more fine-grained (for a minimum fuel penalty) until you can achieve that soft landing.

Thanks again. I'm not sure who's right, but it's certainly a very stimulating problem!


I think they are saying that you need to switch to 199.999... lbs/s for all the 200 lbs/s burns, not just the last one.

Just trying to clarify where you seem to be speaking past each other, though it seems that this might simply lead to a non-optimal strategy (i.e. taking more time to land than theoretically possible, however minute the difference is).


  >switch to 199.999... lbs/s for all the 200 lbs/s burns, not just the last one
That's not it. See here: https://news.ycombinator.com/item?id=40685081


speaking of speaking past each other

> and then replace one of the subsequent 200 lbs/second inputs with 199.99999999 lbs/second

> replace one

indeed not the last one, but no, not "all"


It's interesting. The naive way to write this would be not use any special formulas, and just recalculate mass and acceleration each frame (based on the new mass). And to calculate intersection with the ground at each frame boundary.

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.


There wasn't any graphical output or any frame rate to speak of in the sense you are thinking. The output would appear printed, like this:

https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...

Only updating the mass/acceleration at ten-second intervals would be wildly incorrect!


Just because your displaying results in 10s increments doesn’t mean anything about the simulation frame rate. You could still simulation 10k frames at 1ms granularity between the results printed each ms. The challenge is computational for a 1960s machine and a closed form solution is sensible here for that reason.


Oh, thanks. There was an arcade game called Lunar Lander and I thought that this was the exact same thing, and I guess I didn't pay much attention to the pictures.


OP here (of this blog post, not the original game). The naive way is what I expected too, and described as the Euler method in the post.

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.


I was confused for a minute because I remember playing Spacewar on a PDP-1 in the 1960s and mis-remembered there also being a lander game. But there wasn't, Storer was the first. There is an interesting history here:

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.

https://en.wikipedia.org/wiki/Gravity_loss


OP here. True, I oversimplified. What I meant was, there are two parts to the dynamics, the rocket equation and gravity. They add linearly, so any extra velocity that comes from gravity needs to be eliminated by increasing the delta V from the rocket equation. The gravity delta V is just acceleration of gravity times time, so you want to minimize the time. Surprisingly (to me), in the rocket equation, it doesn't matter how long it takes, or what sequence of burns you use, or whether you burn at a constant rate all the way through vs short strong bursts, etc. So to land with zero velocity using the least fuel, you just need to land in the shortest amount of time.


I still have a roll of punch tape, I think for a PDP11, that says "Lunar Lander" on it, and I have no idea who to give it to.


Internet Archive or Computer History Museum? Ask @textfiles for recommendations for places that might be interested.


Wow, pretty amazing. I remember playing this game after somebody ported it to Wang 2200 BASIC sometime in the mid 1970s. I didn't figure out how to land it myself, but I remember being shown the technique of coasting for the first several turns before applying maximum thrust. I don't recall the term "suicide burn" though. (Or maybe that term came in later when the Kerbal Space Program became popular.)

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 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 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?


I first played this game on an HP-25 calculator back in 1976, using the same formulas as the article explains.

https://www.hpmuseum.org/software/25moonld.htm


I played it on a hp97/hp67.

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'.


vaguely related 1962 Spacewar video game on a PDP-1 on punchout PAPER TAPE blew my mind

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...


When I made the proposal to restore the CHM's pdp-1, the reason was "Spacewar!"


One of the creators of Myst (Rand Miller) credited the original game with being why he got into game development in the first place [1]

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

[1] https://www.youtube.com/watch?v=EWX5B6cD4_4&t=1099s


Oh, fond memories.

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.


OP here. Cool! I was born in 1969, less than a month before Neil Armstrong walked on the moon, and was only a few months old when this game was written. I too learned BASIC, then spent hours pouring over the book "BASIC Computer Games", before I even had a computer of my own. Fond memories, as you say.


I remember playing a version of this on a TI programmable calculator back in the 80s. There was also a graphical version for an assortment of 8-bit computers where you could navigate over the lunar surface in search of a flat landing area.


I played the ABC-80 version of Lunar Lander way back then. Checking today, it seems to use a simpler Euler integration instead, and a curious value for G (?)


Perhaps someone will fix contemporary game bugs in year 2500 and write a similar article.


That's why old people manage to create such great things. Writing game damn


...what? The game was made by a teenager. The only reason they're now old is because 55 years have passed.


I wonder if this works for braking in automobiles to minimize brake pad wear.


For regenerative braking, a similar question would be how best to break to recover as much energy as possible.


Automobiles are more (wear-)efficient at braking when they use the engine to brake, not the brakes, so that would probably be a better approach to automate


A long time ago, in a book whose title I don’t remember, a character said, “but engine parts are more expensive than brake parts”. That has always stuck with me, even as I glide to a stop with almost no braking.


As an avid engine braker who lives in a hilly area and drives in the foothills/mountains often, I figure that at the relatively inconsequential loads and speeds my passenger vehicles operate under, I'm simply leveraging the engine's already constant state of wear while preserving my brakes for a moment when I may need their optimal stopping performance.


Very true - but I drive cars until they die - and have never had a car issue because of engine braking - it is usually another part of the car that goes before whatever damage I am adding to the engine, becomes an issue. So engine brake away!


True, however that statement sort of makes the assumption that engine braking is the same ablative system as friction braking. with the same wear characteristics.

I have to admit I don't know the exact wear characteristics of an IC engine in breaking operation but I don't think it is any different/more than it's normal running wear.


They are certainly in any way identical, but to engine break, you usually need to switch into a lower gear (or a couple gears lower), which means that the clutch needs to reattach while the engine is rolling at a higher rpm than the gearbox can handle in that gear. Every downshift will do another "reattachment" through the clutch.

Which means that there will be some friction braking before internal engine resistance "takes over". Now, while both brake pads and clutches use "similar" material, it's not the same, and the cost is not the same (clutches are usually more expensive in modern cars).


This isn't the case if the driver (or, car computer, nowadays) rev-matches properly. Which is a skill that all manual drivers should have IMO.


Tractors use jake brakes and they have service lives near a million miles. The best maxim is "proper maintenance is the cheapest part of them all."


Isn't that simply because the engine provides less resistance through the clutch than brakes do? Would clutch really be spent less than brake pads for the same braking power (light press on the brakes)?

FWIW, modern flywheel clutch kits are way more expensive than brake pads, so the cost is not so clear cut anyway.


You aren't really using clutch surfaces to brake though, mostly you are relying on the friction and energy used to compress your intake air and blow it out the exhaust with either minimal or no combustion/fuel input, and if at speed air resistance. And everything else added up helps too like in friction in transmission and differentials and cam and crank bearings which are hopefully minimal, and also pumping coolant and oil and running the alternator, etc. In an automatic some will be lost lost in heating up fluid in the torque converter too.


Agreed, I mostly referred to gear changes (downshifts) used to engine brake as I described in my other comment: it's certainly less friction than on brake pads, but it's slightly more than with usual gear changes (assuming smoother rpm matching). But we are talking minute wear on either, but the price difference is significant, so I just wonder — translated to thousands of km/mi — how does it compare?


I often wonder the same thing about my bicycle.


That theme song. It still rattles in my head.


It's probably why I kept crashing!


Is it really a bug if it hasn't affected the integrity of the game for 55 years? ducks


Agreed. It's a numerical error that only affects accuracy, but not a serious glitch, like the Pac-man Kill Screen Bug, not exploitable (to cheat/get resources/lives, like reaching 990,000 points in Defender), and not an Easter egg.

See e.g. Glitchipedia: https://errors.fandom.com/wiki/Glitchipedia:About


[flagged]


You don't need to put up with cookie banners. Enable the Cookie Notices and Annoyances filters in your uBlock Origin installation, and consider setting up a Kill Sticky bookmarklet[1].

[1] https://www.smokingonabike.com/2024/01/20/take-back-your-web...


Not just you, but there is an option to learn more and then deny all.


I agree with you in abstract, but uMatrix solved this problem for me.

Also, it's funny how people often say "the stupid cookie banners are there because of GDPR", but actually GDPR requires that the Reject button be as large and as easy to click as the Accept button, and somehow most companies do not care about this part.

(Also, GDPR does not require a cookie banner when your website does not place cookies. Seriously, why do you need them for the users who are not going to log in?)


People blame GDPR when they should blame the companies for invasive tracking. It's like making it illegal to serve poison in food, then being annoyed that your restaurants have to get your consent to serve you poison.

> why do you need them for the users who are not going to log in?

because they store cookies in your browser regardless, for tracking and advertising purposes


> GDPR does not require a cookie banner when your website does not place cookies

You can place cookies and not need a cookie banner.

You just can't use consent as a legal basis when you haven't yet asked for consent, that's the only thing all these websites are doing: no legitimate reason for the invasive tracking they want to do and thus they're legally obliged to ask you in a clear way if you will consent to it.

If the data processing were to fall under a reason such as:

- in order to fulfill a contract (such as your visitor asking the website to log them in)

- or a legitimate interest (murky, but aggregated statistics like setting returnVisitor=true should fall under this)

- or one of the other reasons defined in GDPR (I think there are three more besides consent, like public interest, vital interest of the subject, and one more I forgot)

then you don't need to ask for consent to process this data or, specifically in this case, place this cookie.


Surely the game must have hundreds of bugs like any other game.


Why? This is from a time when there weren't any "other games". Heck, there were no computer games, period: there were only applications that could be described as "a sort of game on the computer" but only in the sense that you were asked to perform a task, tell the application what you though the task parameters should be, and then the application told you whether you were right.

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


The game is tiny. It does not even have any graphics. It would be an impressive feat to fit even 10 bugs in there, and still have it seem like a functioning game.


Given the simplistic nature of the game, I'm not convinced.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: