पहले Lunar Lander गेम में 55 साल पुराना बग मिला

 (martincmartin.com)
2 पॉइंट द्वारा GN⁺ 2024-06-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 1969 में हाई-स्कूल छात्र Jim Storer द्वारा बनाए गए पहले Lunar Landing गेम में optimal landing fuel schedule को verify करते समय एक बग सामने आया, जिसमें गेम उस क्षण को जब वास्तव में landing होनी चाहिए थी, flight में होना गलत तरीके से मान रहा था
  • जिस strategy की बात है वह suicide burn है: 70 सेकंड तक engine बंद, फिर 10 सेकंड के लिए 164.31426784 lbs/sec, और उसके बाद maximum 200 lbs/sec पर fuel burn करना; गेम rough landing और बिना landed हुए ऊपर उठने के बीच की smooth landing को miss कर देता है
  • मूल code simple Euler integration नहीं था, बल्कि 10-second turn की motion calculate करने के लिए Tsiolkovsky rocket equation और Taylor series का इस्तेमाल करता था; 1969 के PDP-8 environment में एक हाई-स्कूल छात्र के काम के हिसाब से यह काफी sophisticated था
  • बग का कारण ground contact से पहले trajectory के lowest point को approximate करने वाले formula में square root के अंदर denominator में 2 से divide करना छूट जाना था, जिससे lowest point तक पहुंचने का time लगातार underestimate हुआ
  • छूटा हुआ factor of two ठीक करने और 0.05-second correction हटाने पर suicide burn result 1.66 MPH तक improve होता है, लेकिन 1 MPH से कम की perfect landing के लिए Taylor series के 2-term approximation और landing time recalculation की सीमाएं अब भी बची रहती हैं

1969 का Lunar Landing और optimal landing की खोज

  • Jim Storer ने Neil Armstrong की Moon landing के कुछ महीनों बाद, Massachusetts के Lexington High School के छात्र रहते हुए पहला Lunar Landing गेम लिखा
  • 1973 तक यह गेम इतना व्यापक रूप से फैल गया था कि इसे “by far and away the single most popular computer game” कहा जाने लगा
  • गेम text-based है, और lunar lander की सारी motion केवल vertical direction में होती है
  • player simulation में हर 10 सेकंड पर burn किए जाने वाले fuel की मात्रा तय करता है, और Moon की surface पर जितना हो सके उतनी smooth landing करनी होती है
  • optimal fuel schedule खोजने की प्रक्रिया में, theoretically सबसे अच्छी strategy गेम के अंदर ठीक से काम नहीं कर रही थी
    • असल में lander surface को touch कर रहा था
    • गेम गलत तरीके से मान रहा था कि वह surface को touch नहीं कर रहा
    • अंतिम कारण लगभग 55 साल तक अनदेखा रहा missing divide by two था

Minimum fuel landing और suicide burn

  • minimum fuel से landing करने के लिए जितना संभव हो उतने कम समय में नीचे आना पड़ता है
  • optimal strategy यह है कि शुरुआत में engine बंद रखकर speed बढ़ाई जाए, और आखिरी possible moment पर maximum thrust से decelerate करके surface को touch करते समय speed को 0 के करीब लाया जाए
  • Kerbal Space Program community ऐसी strategy को suicide burn कहती है
    • क्योंकि timing बहुत tight होती है और गलती की गुंजाइश लगभग नहीं होती
  • trial-and-error और manual binary search से मिला schedule इस तरह है
    • 70 सेकंड तक fuel burn नहीं करना
    • अगले 10 सेकंड तक 164.31426784 lbs/sec पर fuel burn करना
    • उसके बाद maximum 200 lbs/sec पर fuel burn करना
  • गेम 1 MPH से कम को perfect landing मानता है
  • इस schedule में 3.5 MPH से अधिक speed पर landing होती है और “could be better” verdict मिलता है
  • लेकिन fuel amount को सिर्फ 0.00000001 lbs/sec और बढ़ाने पर lander surface को touch किए बिना 114 MPH पर ऊपर उठता है
  • यानी rough landing और non-landing ascent के बीच होना चाहिए था जो smooth landing verdict, वह गायब था

उम्मीद से ज्यादा sophisticated physics calculation

  • शुरुआत में आज के games में भी common Euler integration की उम्मीद थी
    • time interval की शुरुआत में force calculate करना
    • F=ma से acceleration निकालना
    • मान लेना कि उस time interval में acceleration constant है
  • असली Lunar Landing code इससे ज्यादा sophisticated था
  • Jim Storer ने Tsiolkovsky rocket equation का exact solution इस्तेमाल किया
  • logarithm calculation के लिए Taylor series expansion लागू किया गया
    • argument का maximum value 0.1212 है
    • 5 terms से 6 digits से ज्यादा accuracy मिलती है
  • algebraic simplification से rounding error भी कम किया गया
  • Jim Storer को याद है कि वे उस समय calculus और Taylor series जैसी concepts से परिचित थे, और उनके physicist पिता ने equations derive करने में मदद की थी
  • suicide burn optimal क्यों होता है, यह भी इसी rocket equation से निकलता है, और यह हिस्सा बग का कारण नहीं था

Ground contact detection मुश्किल क्यों है

  • rocket equation तब तक अच्छा काम करती है जब तक lander ground को touch नहीं करता
  • solid objects के बीच collision dynamics engine में कठिन क्षेत्र है, और Lunar Landing को भी ground contact detection में सबसे बड़ी चुनौती मिली
  • 10-second turn की केवल शुरुआत और अंत check करना काफी नहीं है
    • शुरुआत में lander descending हो सकता है
    • अंत में ascending हो सकता है
    • बीच में वह surface के नीचे जाकर फिर ऊपर आया हो सकता है
  • इस स्थिति में program को time rewind करके earlier contact time खोजना पड़ता है
  • natural check point वह trajectory का lowest point है जहां velocity 0 होती है
  • rocket equation में इस lowest point को केवल basic math functions से closed form में express नहीं किया जा सकता
    • footnote में बताया गया है कि Lambert W की जरूरत पड़ती है
  • logarithm की Taylor series के शुरुआती कुछ terms इस्तेमाल करके approximation किया जा सकता है
    • केवल पहले दो terms इस्तेमाल करने पर problem quadratic equation में सरल हो जाती है
    • हाई-स्कूल level का quadratic formula इस्तेमाल किया जा सकता है
    • 10-second turn range में लगभग 0.1% के भीतर accuracy की उम्मीद की जा सकती है

Alternative quadratic formula और numerical stability

  • Jim Storer के code में ऐसा form आता है जिसमें square root numerator में नहीं बल्कि denominator में है
  • यह सामान्य quadratic formula नहीं, बल्कि square root नीचे आने वाले alternative form of quadratic formula से match करता है
  • इस alternative form के महत्वपूर्ण numerical advantages हैं
    • ground contact detect करने के बाद actual contact time खोजते समय भी Taylor series को काटकर quadratic equation से approximate किया जाता है
    • सामान्य form में quadratic term coefficient 0 होने पर division by zero की समस्या आती है
    • rocket thrust अगर gravity को बिल्कुल balance कर दे तो यह स्थिति बनती है
    • surface के पास hover करने या धीरे-धीरे नीचे आने वाले players के लिए यह common हो सकता है
  • thrust gravity के करीब हो तो सामान्य form में numerator में catastrophic cancellation होता है, और छोटा denominator error को बढ़ाता है
  • alternative form quadratic term 0 होने वाली linear equation की स्थिति में भी ठीक काम करता है
  • 1969 में एक हाई-स्कूल छात्र ने यह form फिर से derive किया या सीखा, यह उस दौर के environment को देखते हुए impressive है

असली बग: missing factor of two

  • formula को खुद derive करके compare करने पर यह Jim Storer के code से लगभग समान था, लेकिन square root के अंदर denominator में होना चाहिए था वह 2 गायब था
  • यह omission formula derive करने की प्रक्रिया में या computer में input करते समय हुई साधारण गलती हो सकती है
  • उस समय MACSYMA शुरू हुए सिर्फ 1 साल हुआ था, और यह हाई-स्कूल में इस्तेमाल करने लायक environment भी नहीं था, इसलिए derivation paper और pencil से करनी पड़ती थी
  • इस बग के कारण lowest point तक का time लगातार underestimate हुआ
  • code इसे दो तरीकों से correct करता है
    • 0.05 सेकंड जोड़ता है
    • नए और ज्यादा नजदीकी position से फिर estimate करता है
  • लेकिन किसी खास suicide burn situation में इसी correction के कारण landing moment miss हो जाता है
    • पहला estimate उस समय का होता है जब lander surface के ऊपर है और अभी descending है
    • दूसरा estimate lowest point पार करके ascending होते समय का होता है
    • इन दोनों moments के बीच का अंतर 0.05 सेकंड से कम हो सकता है

Fix के बाद results और बची हुई limitations

  • missing factor of two जोड़ने और 0.05-second correction हटाने पर suicide burn result improve होता है
  • fix के बाद best suicide burn 1.66 MPH landing speed दिखाता है
    • 1 MPH से कम वाली perfect landing तक लगभग 3/4 distance तक close हो जाता है
  • perfect न होने की वजह यह है कि अब भी Taylor series के सिर्फ पहले दो terms इस्तेमाल हो रहे हैं
  • lowest point surface के नीचे है ऐसा judge करने के बाद, पहली बार surface को touch करने का time फिर से खोजना पड़ता है
    • इस process में भी similar approximation इस्तेमाल होता है
    • additional iteration मदद कर सकती है
  • bug fix होने की स्थिति में time overestimate होता है, इसलिए time को पीछे ले जाना पड़ सकता है
    • इस स्थिति में quadratic equation का दूसरा solution चुनना पड़ सकता है
  • और simple तरीका यह है कि Taylor series का सिर्फ एक term इस्तेमाल करके Newton’s method जैसा process अपनाया जाए
  • velocity magnitude किसी threshold से नीचे आने पर stop करके, उस समय की altitude से landing हुई या नहीं, यह judge करने का तरीका भी संभव है
  • लेकिन ऐसे changes code को ज्यादा complex बनाते हैं, और original game पहले से ही काफी मजेदार तरीके से playable था

बग इतने लंबे समय तक क्यों बचा रह सका

  • smooth landing खुद possible है
    • 14th turn को low altitude और low speed पर खत्म करें
    • 15th turn में low thrust इस्तेमाल करें
    • 150 सेकंड के बाद कहीं landing हो जाए
  • problem लगभग 148 सेकंड पर खत्म होने वाला theoretical maximum-thrust suicide burn है
  • कुल मिलाकर यह code 1969 के PDP-8 पर 18 साल के हाई-स्कूल छात्र द्वारा किया गया काम होने के नाते बहुत impressive है
  • उस समय high schools में computer science पढ़ाया जाने से पहले की बात थी, और Newton method से estimates को iteratively improve करना या catastrophic cancellation की चिंता करना जैसी numerical computation concepts भी व्यापक रूप से ज्ञात नहीं थीं
  • bug लगभग 55 साल तक इसलिए नजर नहीं आया क्योंकि bug होने पर भी game कठिन और मजेदार था, और smooth landing भी संभव थी
  • केवल जीतने से आगे जाकर optimal strategy खोजने की कोशिश ही एक छोटी inconsistency को समझने की प्रक्रिया तक ले गई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-06-15
Hacker News की राय
  • 2009 में Jim Storer का पता लगाया गया और उनका इंटरव्यू किया गया, जो पहले Lunar Lander गेम के निर्माता थे, और बाद में गेम का इतिहास भी संकलित किया गया।
    बाद में उन्होंने source code भी दे दिया, जो वाकई शानदार था।
    https://technologizer.com/2009/07/19/lunar-lander/index.html
    मेरा पसंदीदा हिस्सा वह है जहाँ Storer कहते हैं, “हाई स्कूल से ग्रेजुएट होने के बाद मैंने उस गेम के बारे में फिर कभी नहीं सोचा। कुछ महीने पहले किसी ने मुझे इस बारे में ईमेल किया, उससे पहले मुझे यह भी बिल्कुल पता नहीं था कि हाई स्कूल में मेरे बनाए गेम के अलावा कोई और Lunar Lander गेम भी है।”
    • इसमें शामिल होना मेरे लिए सम्मान की बात है। Lander(1990) मूल रूप से Windows 2.x के लिए बनाया था।
      1989 में जब मैंने Lotus Notes से जुड़ी नौकरी के लिए आवेदन किया, तो इंटरव्यूअर Tim Halvorsen को Lander गेम दिखाया, और उन्होंने कहा, “यह बढ़िया है, इसे Windows 3 पर चलाकर देखते हैं।”
      पहले तो मुझे लगा कि अभी रिलीज़ भी न हुआ Windows 3 देख पाना ही अच्छी बात है, लेकिन फिर उन्होंने कहा, “Windows 3 सब कुछ protected mode में चलाता है, इसलिए अगर pointer सीमा से बाहर गया तो यह तुरंत क्रैश हो जाएगा,” और इसे टेस्ट करने को कहा।
      जब तक यह चलता रहा, मैं अंदर ही अंदर घबराया रहा, लेकिन सौभाग्य से Lander क्रैश नहीं हुआ, Tim भी संतुष्ट थे, और आखिरकार मुझे वह नौकरी मिल गई, जिससे मेरा करियर पूरी तरह बदल गया।
    • Lunar Lander से पहले mechanical landing game भी थे।
      मुझे उसकी तस्वीर नहीं मिल रही, लेकिन याद के मुताबिक वह इस मशीन जैसा था।
      https://content.invisioncic.com/r322239/monthly_10_2015/post...
      फर्क बस इतना था कि उसमें terrain और गड्ढे थे, और आपको उस गड्ढे में उतरना होता था जिसमें लाइट जल रही हो। जब spacecraft गड्ढे के बीच वाले बटन को दबाता था, तो वह लाइट बंद हो जाती और दूसरे गड्ढे में लाइट जल उठती थी। अगर निशाना खराब हो, तो किनारे से टकराकर झुक जाता और आप असफल हो जाते।
      अब दोबारा सोचता हूँ तो शायद नियंत्रण UFO catcher की तरह था: ऊपर से align करके फिर “land” दबाना। यह पहले Disneyland Main Street Arcade में हुआ करता था।
    • हाई स्कूल में programming सीखते समय जिन शुरुआती गेमों को देखकर वैसा बनाने की कोशिश की थी, उनमें Lunar Lander भी एक था: Java applet में बनाया गया https://github.com/celwell/space-landing
  • सवाल वाली लाइन 08.10 लगती है।
    लेख में बार-बार “1969 में हाई स्कूल के सीनियर छात्र के लिए प्रभावशाली” कहा गया, जो मुझे थोड़ा अजीब लगा। space age में बड़े हुए tech-oriented लोगों पर इसका बहुत गहरा असर रहा होगा, और मुझे पुरानी फिल्म October Sky भी याद आ गई।
    मूल इंटरव्यू में गेम निर्माता ने कहा था कि वह calculus में अच्छे थे, इसलिए अगर उनकी रुचि और प्रतिभा space या rockets में थी, तो moon-landing game प्रोग्राम करने की कोशिश करना स्वाभाविक लगता है।
    [1]: https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
    • 1969 में अमेरिका में कंप्यूटर तक पहुँच रखने वाले हाई स्कूल छात्र शायद केवल कुछ सैकड़ों रहे होंगे, और computer literacy वाले छात्र तो उससे भी कम थे।
      space age ने प्रेरित किया होगा, लेकिन उस समय आम लोगों के लिए कंप्यूटर लगभग अस्तित्वहीन थे, और software development भी कोई व्यापक रूप से पहचाना गया पेशा नहीं था। अमेरिका में computer science major भी 1962 में ही शुरू हुए थे, इसलिए 1969 में हाई स्कूल सीनियर होना अपने आप में काफ़ी उल्लेखनीय बात है।
    • मैं 1969 में हाई स्कूल में था, calculus भी कुछ हद तक जानता था, और programming में बहुत रुचि थी।
      मैं एक बड़े शहर के बड़े हाई स्कूल में पढ़ता था, जहाँ पास में एक बड़ा engineering school भी था, लेकिन सबसे बड़ी रुकावट computer access थी।
      स्कूल में remote mainframe से जुड़ा एक teletype था, और मैंने दोस्तों के साथ कुछ विश्वविद्यालयी कंप्यूटर भी ढूँढ लिए थे जिन्हें रात में इस्तेमाल किया जा सकता था, लेकिन उनमें ज़्यादातर सिर्फ card reader और line printer थे, graphics terminal बिल्कुल नहीं थे।
      उस दौर में skill, interest, और access — इन तीनों का एक साथ मिलना काफ़ी दुर्लभ रहा होगा।
    • मैं जानना चाहता था कि यह किस language में लिखा गया था, और इस गेम पर लिखी एक पोस्ट से पता चला कि वह FOCAL थी।
      https://retro365.blog/2021/12/02/bits-from-my-personal-colle...
      FOCAL पर Wikipedia:
      https://en.wikipedia.org/wiki/FOCAL_(programming_language)
    • मैं ही मूल पोस्ट का लेखक हूँ। मैं समझ सकता हूँ कि “1969 में हाई स्कूल के सीनियर छात्र के लिए प्रभावशाली” जैसी अभिव्यक्ति अजीब लग सकती है, लेकिन इस गेम को बनाने के लिए काफ़ी चीज़ें चाहिए थीं।
      हाई स्कूल physics में free-body diagram से शुरू करके gravity और thrust जैसी दो forces को संभालने तक की बात एक औसत छात्र भी कर सकता है, अगर उसने Physics A पढ़ी हो।
      लेकिन gravity केंद्र से दूरी पर निर्भर करती है, यानी एक ऐसी value पर जो लगातार बदलती रहती है। शुरुआत 120 मील की ऊँचाई से होती है, लेकिन बदलाव बहुत बड़ा नहीं होता, इसलिए इसे constant मानकर approximate किया जा सकता है — यह समझना ज़रूरी था।
      thrust burn rate के function के रूप में कैसे काम करता है, यह भी पेचीदा है। अगर fuel flow को दोगुना करें, तो क्या exhaust gas velocity भी दोगुनी होगी? ideal gas law PV=nRT में P और T कैसे बदलेंगे? ऐसे सवाल उठते हैं।
      इसलिए अगर उसने अपने physicist पिता से पूछा, rocket engine characteristics के बारे में जाना, और Tsiolkovsky rocket equation ढूँढ निकाली, तो यह अपने आप में हाई स्कूल सीनियर के लिए प्रभावशाली है।
      velocity से position पर जाने के लिए integration करना पड़ता है, और यह सोचना कि FLOG() call को Taylor series में बदलकर हर term का अलग integration किया जाए — मुझे नहीं पता कि कोई औसत Physics A छात्र ऐसा सोचता या नहीं।
      कितनी Taylor series terms इस्तेमाल करनी हैं, क्या वह converge करती है, जैसी बारीकियाँ भी मुश्किल हैं। अगर Jim ने सचमुच इन सूक्ष्म बिंदुओं पर विचार किया था, तो यह कमाल है; और यह भी हो सकता है कि उन्होंने बस सोचा हो कि 5 terms काफी ज़्यादा लगती हैं, इसलिए वही लिख दीं।

चाहे चाँद के पास का simulation हो जाए, फिर भी यह समस्या है कि सतह से टक्कर का पता कैसे लगाया जाए। ऊँचाई 0 होने वाले हल को सीधे निकालने के बजाय, rotation के दौरान ठीक एक बार आने वाले velocity 0 बिंदु को देखने का तरीका काफ़ी creative है
मनचाहा delta-V देने पर ज़रूरी ईंधन की मात्रा निकालने के लिए rocket equation को उल्टा करना भी सिर्फ़ हाई-स्कूल गणित और calculus से नहीं हो पाता। वास्तव में Lambert W जैसे नए function की ज़रूरत पड़ती है
आख़िर में Taylor series से 5वीं degree polynomial हल करनी पड़ती है, इसलिए 3री, 4थी, 5वीं degree के पदों को छोड़कर उसे quadratic बनाना पड़ता है। आम dynamics calculations में जिन पदों को नहीं छोड़ा जाता, यहाँ उन्हें छोड़ा जा सकता है—यह समझना कि अलग-अलग स्थितियों में approximation का स्तर अलग हो सकता है, काफ़ी प्रभावशाली है
साथ ही, जिस तरह उसने quadratic equation के alternative form का किसी तरह उपयोग किया, उससे लगता है कि शायद उसने बस कहीं से ढूँढ़कर नकल नहीं की थी

  • इसे पहले Lunar Lander गेम के रूप में जाना जाता है, लेकिन सच में प्रभावशाली हिस्सा इस्तेमाल की गई numerical analysis techniques थीं
  • 1970 के दशक के मध्य में Adage graphics terminal के लिए 2D vector graphics वाला moon landing game बनाया गया था
    क्षैतिज दिशा में तेज़ी से प्रवेश करने के बाद LEM के side thrusters और main engine button से गति कम करके vertical landing करनी होती थी, और बहुत तेज़ होने या ईंधन खत्म होने पर crater बन जाता था; landing quality के अनुसार एक या उससे अधिक अमेरिकी झंडे लगाए जाते थे
    कुछ साल पहले यह सोचकर कि source code की कोई क़ीमत नहीं और इसका फिर उपयोग नहीं होगा, उसकी एकमात्र copy फेंक दी गई थी; बाद में एहसास हुआ कि वह ऐतिहासिक रूप से काफ़ी शुरुआती graphical games में से एक था और एक साधारण emulation से उसे फिर चलाया जा सकता था, इसलिए पछतावा हुआ
    • यहाँ “horizontal landing” नहीं, “vertical landing” कहना था
  • मेरी पहली programming किताब में इस गेम का BASIC version था, लेकिन मैं उसे ठीक से चला नहीं पाया
    25 साल बाद फिर देखा तो हैरानी हुई कि उसमें बेहिसाब bug थे और logic भी “440 IF GOTO 450” की तरह उलझा हुआ था
    आख़िरकार बड़े होने के बाद मैंने इसे फिर से लिखा [1], लेकिन बचपन वाला मैं इसे सफलतापूर्वक चला ही नहीं सकता था। आज भी यह जिज्ञासा है कि उस भुला दिए गए स्पेनी publisher के भीतर लगभग चलने वाला code आख़िर कैसे final version जैसी शक्ल में बदल गया
    [1] https://7c0h.com/blog/new/moon_landing_in_basic.html
    • “संभावना नहीं थी” कहना भी कम होगा
      ऐसे BASIC code की जड़ें 1960–70 के दशक में थीं, और उस समय code छापने वाली printed magazines और code collections में editors के पास बहुत अधिकार होता था
      source code को एक अक्षर भी बदले बिना छापना चाहिए—यह सोच मज़बूत नहीं थी, इसलिए editors अक्सर “स्पष्ट” typo या editorial judgment समझकर source code को “सावधानी से” ठीक कर देते थे
      1980 के दशक से उद्योग-भर में सुधार शुरू होने और यह समझ फैलने तक कि printed material में source code को छेड़ना नहीं चाहिए, यह सबक धीरे-धीरे और कष्टदायक तरीके से सीखा गया
      सोचता हूँ, क्या इसी प्रवृत्ति ने BBS के उभार को बढ़ावा दिया और source code distribution पर print media की पकड़ को कमज़ोर किया। अगर print media के ताकतवर लोग अपने “खुद के” content के एक हिस्से पर outsiders को पूर्ण नियंत्रण देने के लिए ज़्यादा खुले होते, तो शायद इतिहास कुछ और होता
      बचपन में बिना किसी बड़े की मदद के, स्कूल और स्थानीय library की कुछ programming किताबें देखकर coding शुरू की थी; हाथ से टाइप किए गए अनगिनत programs भी इसी तरह errors से भरे होते थे, फिर भी coding से जुड़े रहना अपने आप में अजीब लगता है
    • यह पढ़कर मज़ा आया। बचपन में C64 को गेम से जुड़ी images सिर्फ़ कुछ lines of code से “जादू की तरह” load करते देखकर, मैंने कभी सोचा था कि वे images कहीं उसके अंदर पहले से ही मौजूद हैं
      “440 IF GOTO 450” जैसे उलझे logic के बारे में थोड़ा और जोड़ें तो, किताब के कुछ code को साफ़-सुथरा करने की ज़रूरत ज़रूर थी, लेकिन उस समय home computers के सामान्य BASIC में शायद सिर्फ़ line numbers होते थे और branching भी बहुत सीमित होती थी
      इस्तेमाल किया गया BASIC structured programming को support करता हुआ लगता है, जो उस समय home computers में बहुत दुर्लभ था। 1984 में C64 magazine ने readers को structured programming का कमाल समझाने के लिए कम-से-कम 3 issues तक लंबी series चलाई थी
      IF statement की पाबंदियाँ इतनी कड़ी थीं कि GOTO का इस्तेमाल करने वाली assembly-जैसी conditional branching बहुत आम थी और लगभग आवश्यक भी
      IF nesting संभव नहीं थी, और कई IF को जोड़ने के लिए non-selected हिस्सों को jump करके पार करना पड़ता था। Commodore/C64 BASIC, यानी लगभग Microsoft BASIC में, ELSE भी नहीं था, इसलिए आम तौर पर negated condition और jump से ELSE branch की नकल की जाती थी
      C64 BASIC में एक अजीब behavior था कि उसी line के दूसरे statements भी THEN का हिस्सा बन जाते थे। उदाहरण के लिए 10 IF A=1 THEN PRINT “FOO” : PRINT “BAR” में A=1 होने पर FOO BAR छपता है, नहीं तो कुछ भी नहीं छपता
      बेशक यह तभी संभव था जब सीमित एक line में सारे statements समा जाएँ। दूसरे BASIC dialects PRINT “BAR” को ELSE के बाहर मान सकते थे, जो grammar के हिसाब से ज़्यादा साफ़ है, लेकिन dialect की सुविधाओं पर निर्भर करते हुए कम सुविधाजनक भी हो सकता था
      आज जो सुविधाएँ और सख़्ती हमें स्वाभाविक लगती हैं, वे तब नहीं थीं। C64 BASIC में implementation से उपजी कई विचित्र विशेषताएँ थीं, इसलिए वह खास तौर पर “messy” लगता था। उदाहरण के लिए, हर function को argument चाहिए होता था, चाहे वास्तव में उसकी ज़रूरत न हो; इसलिए बची हुई memory दिखाने के लिए ?FRE(123) जैसा अर्थहीन रूप लिखना पड़ता था
    • शायद यह editing के दौरान copy/paste errors, deadlines, और quality assurance की कमी का मिला-जुला नतीजा था
  • ईंधन-इष्ट smooth landing strategy शायद “suicide burn” के सटीक रूप में फिट नहीं बैठती, इसलिए उसे नज़रअंदाज़ किया गया, लेकिन तरीका शायद यह होगा कि t=70 सेकंड पर 164.31426784 lbs/second डाला जाए और उसके बाद 200 lbs/second के inputs में से किसी एक को 199.99999999 lbs/second में बदल दिया जाए
    199.99999999 को जितनी जल्दी “play” किया जाए उतना बेहतर, इसलिए brute force से smooth landing देने वाला सबसे शुरुआती input चुन लेना चाहिए
    • bug का असली सार यह है कि lander के सतह को छूने के समय को ढूँढ़ना मुश्किल है
      गेम के landing पहचानने के लिए लगभग 0.05 सेकंड तक ऊँचाई 0 से कम रहनी चाहिए। उस दौरान अगर thrust 200 या 199 हो, तो ऊँचाई के इतना देर negative रहने के लिए altitude 0 बिंदु पर velocity 1MPH से ज़्यादा होनी चाहिए
      bug ठीक करने के बाद भी code अब भी सिर्फ़ minimum point का approximation करता है। landing detect करने के बाद भी असली landing time, यानी velocity नहीं बल्कि altitude 0 होने का समय, निकालना पड़ता है और इसमें भी approximation इस्तेमाल होती है
      इसलिए समय थोड़ा चूक सकता है। अगर आख़िरी time step में 200 या 199 पर burn हो रहा हो, तो acceleration बड़ा होने से समय की बहुत छोटी error भी velocity की बड़ी error बन सकती है
      इसके बजाय अगर लगभग 10 lbs/sec पर burn किया जाए, तो 0.08 सेकंड की चूक से velocity में बड़ा बदलाव नहीं आता
  • अगर इसे सीधे-सादे तरीके से लिखा जाता, तो किसी विशेष formula के बिना हर frame में नई mass के आधार पर mass और acceleration फिर से गिने जाते, और हर frame boundary पर जमीन के साथ intersection निकाला जाता

क्या इसका मतलब है कि frame rate कम होने पर इस तरीके की accuracy घटती है, या फिर असली equation इस्तेमाल करने का मज़ा ही वजह है, यह जानने की जिज्ञासा है
यह भी जानना है कि मूल frame rate पर दोनों तरीकों का फ़र्क कितना महसूस होता था

  • वैसी graphics output या frame rate जैसी हम आज सोचते हैं, तब थी ही नहीं। output शायद इस तरह print होकर निकलती थी
    https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
    अगर mass और acceleration को सिर्फ 10 सेकंड के अंतराल पर update किया जाए, तो यह बहुत ज़्यादा inaccurate हो जाता है
  • मैं मूल पोस्ट का लेखक हूँ। मैंने भी उसी naïve तरीके की उम्मीद की थी, और लेख में उसे Euler method से समझाया था
    physical accuracy के लिहाज़ से, खासकर सतह के पास जब fuel burn rate ऊँची हो, तब mass काफ़ी बदलता है। लेकिन game difficulty, मज़े, या player strategy के हिसाब से शायद बड़ा फ़र्क नहीं पड़ेगा
    दरअसल BASIC computer games किताब में मौजूद दूसरे moon landing simulations में से एक ऐसा naïve approach इस्तेमाल करता दिखता है
    अगर 10 सेकंड बहुत लंबा लगे, तो user interface का एक turn 10 सेकंड ही रखा जा सकता है, और अंदरूनी तौर पर हर turn को 1-1 सेकंड के 10 time steps में बाँटा जा सकता है
    मौजूदा game भी कुछ हिस्सों में वास्तव में ऐसा ही करता है, इसलिए physics simulation हमेशा पूरे 10 सेकंड नहीं बल्कि मनमाना समय S input के रूप में लेता है
  • 1960s में PDP-1 पर Spacewar खेलने की याद की वजह से मैं थोड़ी देर के लिए भ्रमित हो गया था, और मुझे ग़लत याद था कि landing game भी था
    लेकिन landing game नहीं था, और Storer ही पहले थे। इससे जुड़ी दिलचस्प history यहाँ है
    https://www.acriticalhit.com/moonlander-one-giant-leap-for-g...
  • “rocket equation की वजह से suicide burn optimal होता है” यह बात सख़्ती से कहें तो सही नहीं है
    fuel जलने से craft के हल्का होने वाले असर की गणना न भी करें, यानी यहाँ rocket equation जो काम करती है उसे हटा दें, तब भी suicide burn optimal ही रहता है
    असली वजह यह है कि suicide burn gravity loss को न्यूनतम करता है
    https://en.wikipedia.org/wiki/Gravity_loss
    • मैं मूल पोस्ट का लेखक हूँ। सही है, मैंने इसे सरल करके कहा था
      मेरा आशय यह था कि dynamics में rocket equation और gravity, ये दो हिस्से हैं, और दोनों रैखिक रूप से जुड़ते हैं। gravity से पैदा हुई अतिरिक्त velocity को rocket equation के delta-V को बढ़ाकर हटाना पड़ता है
      gravity delta-V, gravitational acceleration गुणा time होता है, इसलिए time को न्यूनतम करना पड़ता है
      हैरानी की बात यह है कि rocket equation में यह मायने नहीं रखता कि कितना समय लगा, burn किस क्रम में किया गया, या लगातार स्थिर दर से जलाया गया या छोटे और तेज़ bursts में
      इसलिए न्यूनतम fuel में velocity 0 के साथ landing करनी हो, तो जितना संभव हो उतने कम समय में landing करनी चाहिए
  • मेरे पास अभी भी एक punched tape roll है जो शायद PDP-11 के लिए है, और उस पर “Lunar Lander” लिखा है, लेकिन समझ नहीं आ रहा कि इसे किसे दूँ
    • Internet Archive या Computer History Museum अच्छे विकल्प लगते हैं। जिन जगहों को इसमें दिलचस्पी हो सकती है, उनके सुझाव के लिए @textfiles से पूछ सकते हैं
  • काफ़ी चौंकाने वाला है। मुझे याद है कि 1970s के मध्य में किसी ने इसे Wang 2200 BASIC में port किया था और मैंने यह game खेला था
    मैं खुद landing का तरीका नहीं समझ पाया था, लेकिन याद है किसी ने दिखाया था कि पहले कुछ turns तक inertia पर चलो और फिर maximum thrust लगाने की तरकीब अपनाओ। तब “suicide burn” शब्द सुना हो, ऐसा याद नहीं। शायद यह शब्द Kerbal Space Program के मशहूर होने के बाद बाद में प्रचलित हुआ होगा
    1970s के मध्य में Berkeley के Lawrence Hall of Science में भी मुझे याद है कि कुछ terminals पर यह moon landing game चल रहा था। यह किस computer पर चल रहा था, पता नहीं
    मैंने इस program का source code कभी नहीं देखा था, और मुझे बिल्कुल अंदाज़ा नहीं था कि इसका math इतना sophisticated है। तब मैं इतना छोटा था कि समझ नहीं पाता, और सच कहूँ तो पता नहीं आज भी समझ पाऊँगा या नहीं
    • मुझे याद है कि 1973 की शुरुआत में Lawrence में शायद ADM-3 terminal पर Lunar Lander खेला जा सकता था। वहाँ आम तौर पर किशोर लड़कों की भीड़ लगी रहती थी
      game kiosk mode की एक “feature” यह थी कि सही timing के साथ Ctrl-C दबाकर kiosk mode से बाहर निकला जा सकता था और दूसरे games खेले जा सकते थे
      यह महज़ संयोग था, या शुरुआती hackers के लिए जानबूझकर छोड़ा गया लालच?