55 Jahre alter Bug im ersten Lunar-Lander-Spiel entdeckt
(martincmartin.com)- Bei der Überprüfung des optimalen Treibstoffplans für die Landung im ersten Lunar Landing-Spiel, das 1969 vom High-School-Schüler Jim Storer entwickelt wurde, zeigte sich ein Bug: Das Spiel bewertet den Moment, in dem tatsächlich gelandet werden sollte, fälschlich als noch im Flug befindlich
- Die fragliche Strategie ist ein suicide burn mit 70 Sekunden ausgeschaltetem Triebwerk, dann 10 Sekunden mit 164.31426784 lbs/sec und anschließend mit maximal 200 lbs/sec; das Spiel verpasst dabei eine sanfte Landung zwischen harter Landung und Wiederaufstieg ohne Landung
- Der ursprüngliche Code berechnete die Bewegung eines 10-Sekunden-Zugs nicht mit einfacher Euler-Integration, sondern mit der Ziolkowski-Raketengleichung und Taylor-Reihen und war damit für ein High-School-Projekt auf einem PDP-8 im Jahr 1969 bemerkenswert ausgefeilt
- Die Ursache des Bugs war ein fehlendes Teilen durch 2 im Nenner innerhalb der Quadratwurzel einer Näherungsformel für den Tiefpunkt der Flugbahn vor dem Bodenkontakt, wodurch die Zeit bis zum Tiefpunkt systematisch zu klein geschätzt wurde
- Korrigiert man den fehlenden factor of two und entfernt eine 0,05-Sekunden-Korrektur, verbessert sich das Ergebnis des suicide burn auf 1.66 MPH, doch für eine perfekte Landung unter 1 MPH bleiben die Grenzen der Taylor-Näherung mit zwei Termen und der Neuberechnung des Landungszeitpunkts bestehen
Lunar Landing von 1969 und die Suche nach der optimalen Landung
- Jim Storer schrieb wenige Monate nach Neil Armstrongs Mondlandung als Schüler der Lexington High School in Massachusetts das erste Spiel Lunar Landing
- 1973 war das Spiel so weit verbreitet, dass es als „by far and away the single most popular computer game“ bezeichnet wurde
- Das Spiel ist textbasiert, und die gesamte Bewegung des Mondlanders findet nur in vertikaler Richtung statt
- Die Spieler entscheiden in der Simulation alle 10 Sekunden, wie viel Treibstoff verbrannt werden soll, und müssen möglichst sanft auf der Mondoberfläche landen
- Bei der Suche nach dem optimalen Treibstoffplan funktionierte die theoretisch beste Strategie im Spiel nicht korrekt
- Tatsächlich berührt der Lander dabei die Oberfläche
- Das Spiel bewertet jedoch fälschlich, dass keine Berührung stattgefunden hat
- Die letztliche Ursache war ein fehlendes divide by two, das fast 55 Jahre lang unbemerkt blieb
Minimaler Treibstoffverbrauch und suicide burn
- Um mit minimalem Treibstoff zu landen, muss man in möglichst kurzer Zeit absteigen
- Die optimale Strategie besteht darin, das Triebwerk zunächst auszuschalten, um Geschwindigkeit aufzubauen, und erst im letztmöglichen Moment mit maximalem Schub abzubremsen, sodass die Geschwindigkeit beim Aufsetzen nahe 0 liegt
- Die Kerbal-Space-Program-Community nennt eine solche Strategie suicide burn
- weil das Timing extrem knapp ist und kaum Spielraum für Fehler bleibt
- Durch Trial-and-Error und manuelle Binärsuche wurde folgender Plan gefunden
- 70 Sekunden lang kein Treibstoffverbrauch
- in den nächsten 10 Sekunden 164.31426784 lbs/sec
- danach Treibstoffverbrauch mit dem Maximum von 200 lbs/sec
- Das Spiel betrachtet weniger als 1 MPH als perfekte Landung
- Mit diesem Plan landet man mit mehr als 3.5 MPH und erhält die Bewertung „could be better“
- Verbraucht man jedoch nur 0.00000001 lbs/sec mehr Treibstoff, berührt man die Oberfläche nicht und steigt mit 114 MPH wieder auf
- Das heißt, die Bewertung für eine sanfte Landung, die zwischen harter Landung und Wiederaufstieg ohne Landung liegen müsste, fehlte
Physikberechnung ausgefeilter als erwartet
- Zunächst lag die Vermutung nahe, dass wie in vielen heutigen Spielen Euler-Integration verwendet wurde
- Man berechnet die Kräfte am Anfang eines Zeitintervalls
- bestimmt daraus mit F=ma die Beschleunigung
- und nimmt an, dass diese Beschleunigung im Intervall konstant bleibt
- Der tatsächliche Lunar-Landing-Code war deutlich ausgefeilter
- Jim Storer verwendete die exakte Lösung der Tsiolkovsky rocket equation
- Für die Logarithmusberechnung nutzte er eine Taylor-Reihenentwicklung
- der maximale Argumentwert beträgt 0.1212
- mit 5 Termen wird eine Genauigkeit von mehr als 6 Stellen erreicht
- Durch algebraische Vereinfachungen wurden zudem Rundungsfehler reduziert
- Jim Storer war nach eigener Erinnerung damals bereits mit Konzepten wie Analysis und Taylor-Reihen vertraut, und sein Vater, ein Physiker, half bei der Herleitung der Gleichungen
- Dass suicide burn optimal ist, folgt ebenfalls aus dieser Raketengleichung; dieser Teil war nicht die Ursache des Bugs
Warum die Erkennung des Bodenkontakts schwierig ist
- Die Raketengleichung funktioniert gut, solange der Lander den Boden noch nicht berührt hat
- Kollisionen fester Körper gehören in Physik-Engines zu den schwierigeren Bereichen, und auch Lunar Landing hatte seine größte Hürde bei der Erkennung des Bodenkontakts
- Es reicht nicht, nur Anfang und Ende eines 10-Sekunden-Zugs zu prüfen
- Zu Beginn kann sich der Lander im Sinkflug befinden
- am Ende kann er bereits wieder steigen
- dazwischen kann er unter die Oberfläche gefallen und wieder hochgekommen sein
- In diesem Fall muss das Programm in der Zeit zurückgehen und einen früheren Kontaktzeitpunkt finden
- Ein naheliegender Prüfpunkt ist der Tiefpunkt der Flugbahn, an dem die Geschwindigkeit 0 wird
- In der Raketengleichung lässt sich dieser Tiefpunkt nicht in geschlossener Form mit elementaren mathematischen Funktionen ausdrücken
- in der Fußnote wird erklärt, dass dafür Lambert W nötig wäre
- Mit nur den ersten Termen der Taylor-Reihe des Logarithmus lässt sich jedoch eine Näherung bilden
- Verwendet man nur die ersten beiden Terme, reduziert sich das Problem auf eine quadratische Gleichung
- dafür kann die aus der Schule bekannte quadratic formula verwendet werden
- innerhalb eines 10-Sekunden-Zugs ist eine Genauigkeit von etwa 0.1% zu erwarten
Alternative quadratische Formel und numerische Stabilität
- In Jim Storers Code taucht eine Form auf, bei der die Quadratwurzel nicht im Zähler, sondern im Nenner steht
- Das entspricht nicht der üblichen quadratischen Formel, sondern der alternativen Form der quadratischen Formel, bei der die Wurzel unten steht
- Diese alternative Form hat einen wichtigen numerischen Vorteil
- Auch bei der Bestimmung des tatsächlichen Kontaktzeitpunkts nach erkannter Bodenberührung wird die Taylor-Reihe abgeschnitten und durch eine quadratische Gleichung angenähert
- die Standardform führt bei einem quadratischen Koeffizienten von 0 zu einem Problem durch Division durch 0
- das tritt auf, wenn der Raketenschub die Gravitation exakt ausgleicht
- für Spieler, die nahe an der Oberfläche schweben oder sehr langsam sinken, kann das häufig vorkommen
- Wenn der Schub nahe an der Schwerkraft liegt, entsteht in der Standardform im Zähler catastrophic cancellation, und ein kleiner Nenner verstärkt den Fehler
- Die alternative Form funktioniert auch gut im linearen Sonderfall, wenn der quadratische Term 0 ist
- Dass ein High-School-Schüler 1969 diese Form entweder selbst herleitete oder gelernt hatte, ist angesichts der damaligen Umstände bemerkenswert
Der eigentliche Bug: fehlender factor of two
- Beim direkten Herleiten und Vergleichen ergab sich fast dieselbe Formel wie in Jim Storers Code, nur fehlte im Nenner innerhalb der Quadratwurzel die 2
- Wahrscheinlich entstand diese Auslassung als einfacher Fehler bei der Herleitung der Formel oder beim Eintippen in den Computer
- MACSYMA existierte damals erst seit etwa einem Jahr und stand an High Schools nicht zur Verfügung, sodass die Herleitung auf Papier erfolgen musste
- Durch diesen Bug wurde die Zeit bis zum Tiefpunkt systematisch zu klein geschätzt
- Der Code kompensierte das auf zwei Arten
- durch das Addieren von 0.05 Sekunden
- und durch eine neue Schätzung von einer neueren und näheren Position aus
- In bestimmten suicide-burn-Situationen führte diese Korrektur jedoch dazu, dass der Landungszeitpunkt verpasst wurde
- Die erste Schätzung liegt an einem Zeitpunkt, zu dem sich der Lander oberhalb der Oberfläche noch im Sinkflug befindet
- die zweite Schätzung liegt nach dem Tiefpunkt, wenn der Lander bereits wieder steigt
- die Zeitspanne zwischen beiden Zeitpunkten kann kürzer als 0.05 Sekunden sein
Ergebnisse nach der Korrektur und verbleibende Grenzen
- Fügt man den fehlenden factor of two ein und entfernt die 0.05-Sekunden-Korrektur, verbessert sich das Ergebnis des suicide burn
- Der beste suicide burn nach der Korrektur ergibt eine Landegeschwindigkeit von 1.66 MPH
- damit kommt man ungefähr bis zu drei Vierteln des Weges an eine perfekte Landung unter 1 MPH heran
- Der Grund, warum das Ergebnis weiterhin nicht perfekt ist, liegt darin, dass noch immer nur die ersten beiden Terme der Taylor-Reihe verwendet werden
- Wenn festgestellt wurde, dass der Tiefpunkt unter der Oberfläche liegt, muss anschließend der Zeitpunkt des ersten Bodenkontakts erneut bestimmt werden
- auch dabei wird eine ähnliche Näherung verwendet
- zusätzliche Iterationen könnten helfen
- Nach Behebung des Bugs wird die Zeit nun zu groß geschätzt, sodass man möglicherweise in der Zeit zurückgehen muss
- in diesem Fall müsste eventuell die andere Lösung der quadratischen Gleichung gewählt werden
- Noch einfacher wäre es, nur einen Term der Taylor-Reihe zu verwenden und das Ganze ähnlich wie Newton’s method zu behandeln
- Möglich wäre auch, anzuhalten, sobald der Betrag der Geschwindigkeit unter einen bestimmten Schwellenwert fällt, und dann anhand der Höhe zu entscheiden, ob gelandet wurde
- Solche Änderungen würden den Code aber komplexer machen, und das ursprüngliche Spiel ließ sich bereits gut und mit Spaß spielen
Warum der Bug so lange unentdeckt blieb
- Eine sanfte Landung ist grundsätzlich möglich
- Der 14. Zug endet mit geringer Höhe und geringer Geschwindigkeit
- im 15. Zug wird geringer Schub verwendet
- irgendwann nach 150 Sekunden erfolgt die Landung
- Problematisch ist der theoretische suicide burn mit maximalem Schub, der etwa bei 148 Sekunden endet
- Insgesamt ist dieser Code für ein Werk eines 18-jährigen High-School-Schülers auf einem PDP-8 im Jahr 1969 äußerst beeindruckend
- Damals wurde Informatik an High Schools noch nicht unterrichtet, und Konzepte numerischer Berechnung wie die iterative Verbesserung einer Schätzung mit dem Newton-Verfahren oder Bedenken wegen catastrophic cancellation waren kaum allgemein bekannt
- Dass der Bug fast 55 Jahre lang unbemerkt blieb, liegt daran, dass das Spiel trotz des Fehlers schwierig und unterhaltsam war und sanfte Landungen trotzdem möglich blieben
- Der Versuch, nicht nur zu gewinnen, sondern die optimale Strategie zu finden, führte schließlich dazu, diese kleine Unstimmigkeit zu verstehen
1 Kommentare
Hacker-News-Kommentare
Später stellte er sogar den Quellcode zur Verfügung, was wirklich großartig war.
https://technologizer.com/2009/07/19/lunar-lander/index.html
Meine Lieblingsstelle ist die, in der Storer sagte: „Seit meinem Highschool-Abschluss hatte ich nie wieder an dieses Spiel gedacht. Bis mir vor ein paar Monaten jemand deswegen eine E-Mail schrieb, wusste ich nicht einmal, dass es außer dem, das ich in der Highschool gemacht hatte, noch andere Lunar-Lander-Spiele gab.“
Als ich mich 1989 auf eine Stelle im Zusammenhang mit Lotus Notes bewarb, zeigte ich dem Interviewer Tim Halvorsen das Lander-Spiel, und er sagte: „Cool, probieren wir es unter Windows 3 aus.“
Zunächst dachte ich, es sei schön, Windows 3 schon vor der Veröffentlichung sehen zu können, aber kurz darauf sagte er: „Windows 3 führt alles im Protected Mode aus, wenn also ein Pointer außerhalb des gültigen Bereichs liegt, stirbt es sofort“, und schlug vor, es zu testen.
Während es lief, war ich die ganze Zeit angespannt, aber zum Glück stürzte Lander nicht ab, Tim war zufrieden, und am Ende bekam ich den Job, der meine Karriere komplett veränderte.
Ich finde kein Foto, aber aus meiner Erinnerung sah es ungefähr so ähnlich aus wie diese Maschine:
https://content.invisioncic.com/r322239/monthly_10_2015/post...
Allerdings gab es Gelände und Gruben, und man musste in der beleuchteten Grube landen. Wenn das Raumschiff den mittleren Knopf in der Grube drückte, ging das Licht aus und eine andere Grube leuchtete auf; war das Zielen schlecht, stieß man an den Rand, kippte um und scheiterte.
Wenn ich es mir noch einmal überlege, könnte die Steuerung auch wie bei einem UFO-Catcher gewesen sein: von oben ausrichten und dann „land“ drücken. Es stand früher in der Main Street Arcade von Disneyland.
Ich fand es etwas seltsam, dass im Artikel mehrfach gesagt wurde, das sei „beeindruckend für einen Highschool-Senior im Jahr 1969“. Auf technikorientierte Menschen, die im Weltraumzeitalter aufwuchsen, muss das enorm gewirkt haben, und es erinnert auch an den alten Film October Sky.
Im ursprünglichen Interview heißt es, dass der Spieleentwickler gut in Infinitesimalrechnung war; wenn er also Interesse und Talent für Raumfahrt oder Raketen hatte, wirkt der Versuch, ein Mondlandespiel zu programmieren, ganz natürlich.
[1]: https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
Das Weltraumzeitalter mag inspiriert haben, aber für die breite Öffentlichkeit existierten Computer damals praktisch nicht, und Softwareentwicklung war auch kein weithin bekannter Beruf. Informatikstudiengänge entstanden in den USA erst 1962; dass er 1969 Highschool-Senior war, ist daher durchaus bemerkenswert.
Ich besuchte eine große Highschool in einer ziemlich großen Stadt mit einer großen technischen Universität, aber die größte Hürde war der Zugang zu Computern.
Die Schule hatte ein Teletype-Terminal, das mit einem entfernten Mainframe verbunden war, und meine Freunde und ich fanden ein paar Universitätscomputer, die wir nachts nutzen konnten; die meisten hatten aber nur Kartenleser und Zeilendrucker, überhaupt keine Grafikterminals.
Damals dürfte die Kombination aus Können, Interesse und Zugang ziemlich selten gewesen sein.
https://retro365.blog/2021/12/02/bits-from-my-personal-colle...
Wikipedia zu FOCAL:
https://en.wikipedia.org/wiki/FOCAL_(programming_language)
In der Highschool-Physik kann ein durchschnittlicher Schüler mit einer Eins in Physik von einem Freikörperbild ausgehen und die beiden Kräfte Schwerkraft und Schub behandeln.
Aber die Schwerkraft hängt vom Abstand zum Zentrum ab, also von einem Wert, der sich ständig ändert. Man muss wissen, dass man in 120 Meilen Höhe startet, die Änderung aber nicht groß ist und man sie daher als Konstante approximieren kann.
Auch wie der Schub als Funktion der Verbrennungsrate wirkt, ist knifflig. Wenn man den Treibstoffdurchsatz verdoppelt, verdoppelt sich dann auch die Abgasgeschwindigkeit, oder wie ändern sich P und T im idealen Gasgesetz PV=nRT? Solche Fragen tauchen auf.
Wenn er also seinen Vater, der Physiker war, fragte und die Eigenschaften von Raketentriebwerken sowie die Ziolkowski-Raketengleichung heraussuchte, ist das für einen Highschool-Senior an sich schon beeindruckend.
Um von der Geschwindigkeit zur Position zu kommen, muss man integrieren, und ich weiß nicht, ob ein durchschnittlicher Schüler mit einer Eins in Physik auf die Idee käme, den FLOG()-Aufruf durch eine Taylorreihe zu ersetzen und gliedweise zu integrieren.
Auch Details wie die Frage, wie viele Terme der Taylorreihe man verwenden muss und ob sie konvergiert, sind schwierig. Wenn Jim über diese Feinheiten nachgedacht hat, ist das bemerkenswert; es kann aber auch sein, dass er einfach dachte, fünf Terme sähen nach viel aus.
Selbst wenn die Simulation in Mondnähe funktionierte, war auch die Frage, wie man die Kollision mit dem Boden erkennt. Statt die Nullstelle für die Höhe direkt zu lösen, ist der Ansatz, auf den während der Drehung genau einmal auftretenden Punkt mit Geschwindigkeit 0 zu schauen, ziemlich kreativ
Auch das Umstellen der Raketengleichung, um aus einem gewünschten Delta-v die nötige Treibstoffmenge zu berechnen, kommt mit Schulmathematik und Analysis allein nicht weiter. Tatsächlich braucht man dafür eine neue Funktion wie Lambert W
Am Ende muss man eine Taylor-Reihe als Polynom 5. Grades lösen und daher entscheiden, die Terme 3., 4. und 5. Ordnung wegzulassen, um eine quadratische Gleichung zu erhalten. Dass hier Terme weggelassen wurden, die man bei normalen Dynamikberechnungen nicht weggelassen hatte, zeigt, dass man verstanden hat, für unterschiedliche Situationen unterschiedliche Näherungsgrade zu verwenden – das ist beeindruckend
Außerdem deutet die Tatsache, dass irgendwie eine alternative Form der quadratischen Gleichung verwendet wurde, darauf hin, dass es vielleicht nicht einfach nur abgeschrieben war
Man kam mit hoher Horizontalgeschwindigkeit herein und musste mit den Seitentriebwerken des LEM und dem Haupttriebwerksknopf abbremsen, um vertikal zu landen; war man zu schnell oder ging der Treibstoff aus, entstand ein Krater, und je nach Qualität der Landung wurden eine oder mehrere US-Flaggen aufgestellt
Vor ein paar Jahren warf ich die einzige Kopie des Quellcodes weg, weil ich dachte, er habe keinen Wert und werde nie wiederverwendet; später wurde mir klar, dass es historisch gesehen ein ziemlich frühes Grafikspiel war und sich mit einfacher Emulation hätte wiederbeleben lassen, was ich bereute
Als ich 25 Jahre später wieder hineinschaute, war ich erstaunt, wie absurd viele Bugs sie hatte und wie verheddert die Logik war, etwa „440 IF GOTO 450“
Am Ende habe ich sie als Erwachsener neu geschrieben [1], aber mein kindliches Ich hatte keine Chance. Bis heute frage ich mich, wie innerhalb dieses vergessenen spanischen Verlags aus fast lauffähigem Code etwas wurde, das wie die Endfassung aussah
[1] https://7c0h.com/blog/new/moon_landing_in_basic.html
Solcher BASIC-Code hatte seine Wurzeln in den 1960er- und 1970er-Jahren, und in den gedruckten Magazinen und Codesammlungen jener Zeit hatten Redakteure starke Eingriffsrechte
Das Bewusstsein, dass man Quellcode unverändert bis auf das letzte Zeichen abdrucken muss, war schwach ausgeprägt, sodass Redakteure den Quellcode oft „vorsichtig“ korrigierten, weil sie etwas für einen „offensichtlichen“ Tippfehler oder eine redaktionelle Entscheidung hielten
Erst ab den 1980ern setzte branchenweit eine Verbesserung ein, und die Lektion, dass man Quellcode in Drucksachen nicht anfassen sollte, wurde langsam und schmerzhaft gelernt
Ich frage mich auch, ob diese Entwicklung den Aufstieg von BBS gefördert und die Macht der Printmedien über die Verbreitung von Quellcode geschwächt hat. Wenn die Machthaber der Printmedien offener dafür gewesen wären, dass Außenstehende über Teile „ihrer“ Inhalte absolute Kontrolle haben, hätte die Geschichte vielleicht anders verlaufen können
Als Kind begann ich ohne Hilfe von Erwachsenen mit dem Programmieren, nur mit ein paar Programmierbüchern aus der Schule und der örtlichen Bibliothek; im Rückblick ist es erstaunlich, dass ich trotz der vielen von Hand eingetippten Programme, die ähnlich voller Fehler waren, beim Coden geblieben bin
Zu verhedderter Logik wie „440 IF GOTO 450“ noch eine Ergänzung: Ein Teil des Codes im Buch musste sicher aufgeräumt werden, aber das übliche BASIC auf Heimcomputern jener Zeit arbeitete wahrscheinlich nur mit Zeilennummern und hatte sehr eingeschränkte Verzweigungen
Das verwendete BASIC scheint strukturierte Programmierung zu unterstützen, was auf Heimcomputern damals sehr selten war. Noch 1984 brachte ein C64-Magazin über mindestens drei Ausgaben hinweg eine lange Serie, die den Lesern die Wunder strukturierter Programmierung vorstellte
Wegen der starken Einschränkungen von IF-Anweisungen waren bedingte Verzweigungen im Assembler-Stil mit GOTO sehr verbreitet und praktisch notwendig
Verschachtelte IFs waren unmöglich, und um mehrere IFs zu kombinieren, musste man über die nicht ausgewählten Teile hinweg springen. Commodore/C64 BASIC, faktisch Microsoft BASIC, hatte nicht einmal ELSE, daher wurde ein ELSE-Zweig meist mit negierter Bedingung und Sprung nachgebildet
C64 BASIC hatte das merkwürdige Verhalten, dass auch andere Anweisungen in derselben Zeile zu THEN gehörten. Zum Beispiel gibt
10 IF A=1 THEN PRINT “FOO” : PRINT “BAR”bei A=1 FOO BAR aus, andernfalls gar nichtsDas funktionierte natürlich nur, wenn man alle Anweisungen in die begrenzte eine Zeile bekam. Andere BASIC-Dialekte betrachteten
PRINT “BAR”als außerhalb des ELSE liegend, was syntaktisch sauberer war, je nach den vom Dialekt bereitgestellten Funktionen aber weniger bequem sein konnteDie Bequemlichkeit und Strenge, die wir heute für selbstverständlich halten, gab es nicht. C64 BASIC hatte viele seltsame Eigenschaften, die wie Artefakte der Implementierung wirkten, und fühlte sich deshalb besonders „schmutzig“ an. Zum Beispiel mussten alle Funktionen ein Argument haben, selbst wenn es eigentlich nicht gebraucht wurde; um den freien Speicher auszugeben, schrieb man daher etwas Sinnloses wie
?FRE(123)Je früher man die 199.99999999 „spielt“, desto besser; per vollständiger Suche kann man also die früheste Eingabe wählen, die eine sanfte Landung ergibt
Damit das Spiel die Landung erkennt, muss die Höhe etwa 0,05 Sekunden lang kleiner als 0 sein. Wenn der Schub in dieser Zeit 200 oder 199 beträgt, muss die Geschwindigkeit am Punkt Höhe 0 größer als 1 MPH sein, damit die Höhe so lange negativ bleibt
Selbst wenn man den Bug behebt, approximiert der Code weiterhin nur den Tiefstpunkt. Nach dem Erkennen der Landung muss man auch noch den tatsächlichen Landezeitpunkt berechnen, also den Zeitpunkt, an dem nicht die Geschwindigkeit, sondern die Höhe 0 wird, und auch dafür wird eine Näherung verwendet
Dadurch kann die Zeit etwas danebenliegen. Wenn im letzten Zeitschritt mit 200 oder 199 gebrannt wird, ist die Beschleunigung groß, sodass schon ein sehr kleiner Zeitfehler zu einem großen Geschwindigkeitsfehler führt
Brennt man stattdessen mit etwa 10 lbs/sec, führt selbst eine Abweichung von rund 0,08 Sekunden nicht zu einer großen Geschwindigkeitsänderung
Ich frage mich, ob das bedeutet, dass diese Methode bei niedrigerer Framerate ungenauer wird, oder ob es einfach am Spaß liegt, die echten Gleichungen zu verwenden.
Außerdem frage ich mich, wie stark der Unterschied zwischen den beiden Methoden bei der ursprünglichen Framerate überhaupt spürbar war.
https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
Wenn man Masse und Beschleunigung nur in 10-Sekunden-Abständen aktualisiert, wird es extrem ungenau.
Was die physikalische Genauigkeit betrifft, ändert sich die Masse besonders nahe der Oberfläche bei hoher Treibstoffverbrennungsrate ziemlich stark. Für Schwierigkeit oder Spaß des Spiels und für die Strategie der Spieler dürfte es aber keinen großen Unterschied machen.
Tatsächlich scheint eine der anderen Mondlandesimulationen aus dem Buch BASIC Computer Games genau so einen naiven Ansatz zu verwenden.
Wenn 10 Sekunden zu lang sind, könnte man einen Zug in der Benutzeroberfläche weiterhin bei 10 Sekunden belassen, ihn intern aber feiner aufteilen, etwa in zehn Zeitschritte von je 1 Sekunde.
Das bestehende Spiel macht das an bestimmten Stellen tatsächlich schon so; die Physiksimulation ist daher so ausgelegt, dass sie eine beliebige Zeit S als Eingabe bekommt und nicht immer die vollen 10 Sekunden.
Aber ein Landespiel gab es nicht; Storer war der Erste. Eine interessante Geschichte dazu gibt es hier:
https://www.acriticalhit.com/moonlander-one-giant-leap-for-g...
Selbst wenn man den Effekt nicht berechnet, dass das Fahrzeug durch das Verbrennen von Treibstoff leichter wird, also selbst wenn man das, was die Raketengleichung hier leistet, weglässt, bleibt ein suicide burn optimal.
Der eigentliche Grund ist, dass ein suicide burn Gravitationsverluste minimiert.
https://en.wikipedia.org/wiki/Gravity_loss
Gemeint war, dass die Dynamik aus zwei Teilen besteht, der Raketengleichung und der Gravitation, und dass sich beide linear addieren. Die durch die Gravitation entstandene zusätzliche Geschwindigkeit muss durch mehr Delta-v aus der Raketengleichung abgebaut werden.
Das Gravitations-Delta-v ist Gravitationsbeschleunigung mal Zeit, also muss man die Zeit minimieren.
Überraschenderweise ist es der Raketengleichung egal, wie lange es dauert, welche Brennfolge man verwendet, ob man kontinuierlich mit konstanter Rate brennt oder mit kurzen, starken Schüben.
Um mit minimalem Treibstoff mit Geschwindigkeit 0 zu landen, sollte man also in der kürzestmöglichen Zeit landen.
Ich habe selbst nicht herausgefunden, wie man landet, aber ich erinnere mich, dass mir jemand die Technik zeigte, die ersten paar Züge mit der Trägheit laufen zu lassen und dann maximalen Schub zu geben. An den Begriff „suicide burn“ erinnere ich mich aus der Zeit nicht. Vielleicht kam er erst später auf, nachdem Kerbal Space Program bekannt wurde.
Ich erinnere mich auch, dass Mitte der 1970er im Lawrence Hall of Science in Berkeley dieses Mondlandespiel auf einigen Terminals lief. Ich weiß nicht, auf welchem Computer es ausgeführt wurde.
Den Quellcode dieses Programms habe ich nie gesehen, und ich hatte keine Ahnung, dass die Mathematik so ausgefeilt war. Damals war ich viel zu jung, um sie zu verstehen, und ehrlich gesagt bin ich mir nicht sicher, ob ich sie heute verstehen würde.
Ein „Feature“ des Kioskmodus für Spiele war, dass man ihn mit einem gut getimten Ctrl-C verlassen und andere Spiele spielen konnte.
War das Zufall oder ein Köder für frühe Hacker?