İlk Lunar Lander oyununda 55 yıllık bir hata bulundu
(martincmartin.com)- 1969’da lise öğrencisi Jim Storer’ın yaptığı ilk Lunar Landing oyununda en iyi iniş yakıt takvimi doğrulanırken, oyunun aslında iniş yapılması gereken anı yanlışlıkla uçuş hâli olarak değerlendirdiği bir hata ortaya çıktı
- Söz konusu strateji; motoru 70 saniye kapatıp, 10 saniye boyunca 164.31426784 lbs/sec, ardından da maksimum 200 lbs/sec yakıt yakılan bir suicide burn; oyun sert iniş ile iniş yapmadan yükselme arasındaki yumuşak inişi kaçırıyor
- Özgün kod basit Euler entegrasyonu değil, 10 saniyelik turlardaki hareketi hesaplamak için Tsiolkovsky roket denklemi ve Taylor serisi kullanıyordu; 1969’daki PDP-8 ortamında bir lise öğrencisinin işi olarak oldukça incelikliydi
- Hatanın nedeni, yüzeye temas etmeden önce yörüngenin en düşük noktasını yaklaşık hesaplayan formülde, karekök içindeki paydada 2’ye bölme işleminin eksik olmasıydı; en düşük noktaya ulaşma zamanı tutarlı biçimde düşük tahmin ediliyordu
- Eksik factor of two düzeltilip 0,05 saniyelik düzeltme kaldırıldığında suicide burn sonucu 1,66 MPH’ye kadar iyileşiyor; ancak 1 MPH’nin altındaki kusursuz iniş için Taylor serisinin 2 terimli yaklaşımı ve iniş anını yeniden hesaplama sınırları hâlâ kalıyor
1969 Lunar Landing ve en iyi inişi arama
- Jim Storer, Neil Armstrong’un Ay’a inişinden birkaç ay sonra, Massachusetts’te Lexington High School öğrencisiyken ilk Lunar Landing oyununu yazdı
- 1973’te bu oyun, “by far and away the single most popular computer game” diye anılacak kadar yaygınlaşmıştı
- Oyun metin tabanlıydı ve Ay iniş aracının tüm hareketi yalnızca dikey yönde gerçekleşiyordu
- Oyuncu, simülasyonda her 10 saniyede bir yakılacak yakıt miktarını belirliyor ve Ay yüzeyine olabildiğince yumuşak inmeye çalışıyordu
- En iyi yakıt takvimini bulma sürecinde, teorik olarak en iyi strateji oyunun içinde düzgün çalışmadı
- Gerçekte iniş aracı yüzeye temas ediyordu
- Oyun, yüzeye temas etmediğine yanlış karar veriyordu
- Nihai neden, neredeyse 55 yıl boyunca fark edilmeyen eksik bir divide by two idi
Minimum yakıtla iniş ve suicide burn
- Minimum yakıtla inmek için mümkün olan en kısa sürede aşağı inmek gerekir
- En iyi strateji, başta motoru kapatıp hızı artırmak, son mümkün anda da maksimum itkiyle yavaşlayarak yüzeye temas anında hızı sıfıra yaklaştırmaktır
- Kerbal Space Program topluluğu bu stratejiye suicide burn diyor
- Çünkü zamanlaması son derece sıkıdır ve hataya neredeyse hiç pay bırakmaz
- Deneme-yanılma ve manuel ikili aramayla bulunan takvim şöyleydi
- 70 saniye boyunca yakıt yakmamak
- Sonraki 10 saniye boyunca 164.31426784 lbs/sec hızında yakıt yakmak
- Ardından maksimum değer olan 200 lbs/sec hızında yakıt yakmak
- Oyun 1 MPH’nin altını kusursuz iniş sayıyor
- Bu takvimde iniş 3,5 MPH’nin üzerinde gerçekleşiyor ve “could be better” değerlendirmesi alıyor
- Ancak yakıt miktarı yalnızca 0.00000001 lbs/sec daha artırılırsa yüzeye temas etmeden 114 MPH hızla yükseliyor
- Yani sert iniş ile iniş yapmadan yükselme arasında olması gereken yumuşak iniş sonucu kaybolmuştu
Beklenenden daha incelikli fizik hesaplaması
- Başta, günümüz oyunlarında da yaygın olan Euler entegrasyonu bekleniyordu
- Zaman aralığının başlangıç noktasındaki kuvvet hesaplanır
- F=ma ile ivme bulunur
- İvmenin o zaman aralığı boyunca sabit olduğu varsayılır
- Gerçek Lunar Landing kodu bundan daha incelikliydi
- Jim Storer, Tsiolkovsky rocket equation denkleminin kesin çözümünü kullandı
- Logaritma hesaplarında Taylor serisi açılımı uygulandı
- Argümanın maksimum değeri 0.1212’ydi
- 5 terimle 6 basamaktan fazla doğruluk sağlıyordu
- Cebirsel sadeleştirme, yuvarlama hatalarını da azaltıyordu
- Jim Storer, o dönemde kalkülüs ve Taylor serisi gibi kavramlara aşinaydı; fizikçi olan babasının denklemlerin türetilmesine yardım ettiğini hatırlıyor
- Suicide burn’ün neden en iyi strateji olduğu da bu roket denkleminden çıkıyordu ve hatanın nedeni bu kısım değildi
Yüzey temasını belirlemenin zor olma nedeni
- Roket denklemi, iniş aracı yüzeye temas edene kadar iyi çalışır
- Katı cisimler arasındaki çarpışmalar dinamik motorlarında zor bir alandır; Lunar Landing de en büyük güçlüğü yüzey teması kararında yaşadı
- 10 saniyelik turun yalnızca başlangıcını ve sonunu kontrol etmek yeterli değildir
- Başlangıç anında alçalıyor olabilir
- Bitiş anında yükseliyor olabilir
- Arada yüzeyin altına inip tekrar yukarı çıkmış olabilir
- Bu durumda programın zamanı geri sarıp daha erken temas anını bulması gerekir
- Doğal kontrol noktası, hızın 0 olduğu yörüngenin en düşük noktasıdır
- Roket denkleminde bu en düşük nokta, yalnızca temel matematik fonksiyonlarıyla kapalı biçimde ifade edilemez
- Dipnotta Lambert W gerektiği açıklanıyor
- Logaritmanın Taylor serisinin ilk birkaç terimi kullanılarak yaklaşık hesap yapılabilir
- Yalnızca ilk iki terim kullanılırsa problem ikinci dereceden denkleme indirgenir
- Lise düzeyindeki quadratic formula kullanılabilir
- 10 saniyelik tur aralığında yaklaşık %0,1 içinde doğruluk beklenebilir
Alternatif ikinci dereceden formül ve sayısal kararlılık
- Jim Storer’ın kodunda karekökün payda yerine paydada olduğu bir biçim görülüyor
- Bu, alışıldık ikinci dereceden formül değil; karekökün aşağıda yer aldığı alternatif quadratic formula biçimiyle örtüşüyor
- Bu alternatif biçimin önemli bir sayısal avantajı var
- Yüzey teması algılandıktan sonra gerçek temas zamanını bulurken de Taylor serisi kesilerek ikinci dereceden denklemle yaklaşım yapılıyor
- Genel biçimde, ikinci dereceden terimin katsayısı 0 olduğunda 0’a bölme sorunu ortaya çıkıyor
- Roket itkisi yerçekimini tam olarak dengelediğinde bu durum oluşuyor
- Yüzey yakınında havada asılı kalan veya yavaşça alçalan oyuncularda sık görülebilir
- İtki yerçekimine yakınsa genel biçimde payda catastrophic cancellation oluşur ve küçük payda hatayı büyütür
- Alternatif biçim, ikinci dereceden terimin 0 olduğu doğrusal denklem durumunda da iyi çalışır
- 1969’da bir lise öğrencisinin böyle bir biçimi yeniden türetmiş ya da öğrenmiş olması, dönemin koşulları düşünüldüğünde etkileyici
Asıl hata: eksik factor of two
- Formül doğrudan türetilip karşılaştırıldığında Jim Storer’ın koduyla neredeyse aynıydı; ancak karekök içindeki paydada olması gereken 2 eksikti
- Bu eksiklik, formülü türetme sürecinde ya da bilgisayara girerken yapılmış basit bir hata olabilir
- O dönemde MACSYMA daha yeni bir yıl önce başlamıştı ve lisede kullanılabilecek bir ortam da değildi; bu nedenle türetmenin kâğıt kalemle yapılması gerekiyordu
- Bu hata yüzünden en düşük noktaya kadar olan zaman tutarlı biçimde düşük tahmin ediliyordu
- Kod bunu iki şekilde telafi ediyordu
- 0,05 saniye ekliyordu
- Yeni ve daha yakın bir konumdan yeniden tahmin yapıyordu
- Ancak belirli bir suicide burn durumunda bu düzeltme iniş anının kaçırılmasına yol açtı
- İlk tahmin, iniş aracının yüzeyin üstünde hâlâ alçalmakta olduğu andı
- İkinci tahmin, en düşük noktayı geçip yükselmekte olduğu andı
- Bu iki anın arası 0,05 saniyeden kısa olabilir
Düzeltme sonrası sonuç ve kalan sınırlar
- Eksik factor of two eklenip 0,05 saniyelik düzeltme kaldırılınca suicide burn sonucu iyileşiyor
- Düzeltme sonrası en iyi suicide burn 1,66 MPH iniş hızı gösteriyor
- 1 MPH’nin altındaki kusursuz inişe giden yolun yaklaşık 3/4’üne kadar yaklaşıyor
- Kusursuz olmamasının nedeni, hâlâ Taylor serisinin yalnızca ilk iki teriminin kullanılması
- En düşük noktanın yüzeyin altında olduğuna karar verildikten sonra, yüzeye ilk temas edilen zamanın yeniden bulunması gerekiyor
- Bu süreçte de benzer bir yaklaşım kullanılıyor
- Ek yineleme faydalı olabilir
- Hata düzeltilmiş hâlde zaman fazla tahmin edildiği için zamanı geri almak gerekebilir
- Bu durumda ikinci dereceden denklemin diğer kökünü seçmek gerekebilir
- Daha basit bir yol olarak, Taylor serisinin yalnızca bir terimini kullanıp Newton’s method benzeri bir yöntemle ilerlemek mümkün
- Hız büyüklüğü belirli bir eşiğin altına indiğinde durup o andaki irtifaya göre iniş olup olmadığına karar verme yöntemi de mümkün
- Ancak bu değişiklikler kodu daha karmaşık hâle getirir; özgün oyun zaten yeterince eğlenceli oynanabiliyordu
Hatanın uzun süre kalabilmesinin nedeni
- Yumuşak inişin kendisi mümkün
-
- turu düşük irtifa ve düşük hızla bitirmek
-
- turda düşük itki kullanmak
- 150 saniyeden sonra bir noktada iniş yapmak
-
- Sorunlu olan, yaklaşık 148 saniyede biten teorik maksimum itki suicide burn
- Genel olarak bu kod, 1969’da PDP-8 üzerinde 18 yaşında bir lise öğrencisinin yazdığı bir iş olarak çok etkileyici
- O dönemde liselerde bilgisayar bilimi öğretilmeden önceydi; Newton yöntemiyle tahminleri yinelemeli iyileştirme veya catastrophic cancellation konusunda kaygılanma gibi sayısal hesaplama kavramları da yaygın bilinmiyordu
- Hatanın neredeyse 55 yıl boyunca fark edilmemesinin nedeni, hata olsa bile oyunun zor ve eğlenceli olması, ayrıca yumuşak inişin de mümkün olmasıydı
- Yalnızca kazanmanın ötesine geçip en iyi stratejiyi bulma girişimi, küçük bir tutarsızlığı anlama sürecine dönüştü
1 yorum
Hacker News yorumları
Daha sonra kaynak kodu bile sağlaması gerçekten harikaydı.
https://technologizer.com/2009/07/19/lunar-lander/index.html
En sevdiğim bölüm, Storer'ın “Liseden mezun olduktan sonra o oyunu bir daha hiç düşünmemiştim. Birkaç ay önce biri bana bununla ilgili e-posta gönderene kadar, lisede yaptığım oyun dışında başka Lunar Lander oyunları olduğunu bile hiç bilmiyordum” dediği kısım.
1989'da Lotus Notes ile ilgili bir işe başvurduğumda, mülakatçı Tim Halvorsen'e Lander oyununu göstermiştim; o da “Güzelmiş, bir de Windows 3'te çalıştıralım” dedi.
İlk başta henüz piyasaya çıkmamış Windows 3'ü görebileceğim için iyi olduğunu düşündüm, ama kısa süre sonra “Windows 3 her şeyi korumalı modda çalıştırıyor; bir pointer sınırın dışına çıkarsa hemen çöker” diyerek test etmeyi önerdi.
Çalıştığı süre boyunca içim içimi yedi ama neyse ki Lander çökmedi, Tim de memnun kaldı; sonunda o işi aldım ve kariyerim tamamen değişti.
Fotoğrafını bulamadım ama hatırladığım kadarıyla şu makineye benziyordu:
https://content.invisioncic.com/r322239/monthly_10_2015/post...
Ancak arazisi ve çukurları vardı; ışığı yanan çukura iniş yapmanız gerekiyordu. Uzay aracı çukurun ortasındaki düğmeye bastığında ışık sönüyor ve başka bir çukurun ışığı yanıyordu; nişan kötü olursa kenara çarpıp yana yatıyor ve başarısız oluyordunuz.
Şimdi düşününce kontroller, UFO catcher gibi yukarıdan hizalayıp sonra “land” düğmesine basma şeklinde de olabilir. Eski Disneyland Main Street Arcade'de vardı.
Yazıda “1969'da lise son sınıf öğrencisi için etkileyici” denmesinin birkaç kez tekrarlanması bana biraz tuhaf geldi. Uzay çağında büyüyen teknoloji odaklı insanlar üzerinde muazzam bir etkisi olmuş olmalı; eski October Sky filmini de akla getiriyor.
Orijinal röportajda oyunun geliştiricisinin kalkülüste iyi olduğu söylendiğine göre, uzaya veya roketlere ilgisi ve yeteneği varsa bir Ay'a iniş oyunu programlamayı denemesi doğal görünüyor.
[1]: https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
Uzay çağı ilham vermiş olabilir, ama o dönemde genel halk için bilgisayarlar fiilen yok gibiydi ve yazılım geliştirme de yaygın bilinen bir meslek değildi. ABD'de bilgisayar bilimi bölümlerinin ortaya çıkışı da 1962 olduğuna göre, 1969'da lise son sınıf öğrencisi olması epey dikkat çekici.
Büyük bir mühendislik fakültesinin olduğu oldukça büyük bir şehirde, büyük bir liseye gidiyordum; ama en büyük engel bilgisayara erişimdi.
Okulda uzak bir mainframe'e bağlı bir teletype vardı; arkadaşlarımla geceleri kullanabileceğimiz birkaç üniversite bilgisayarı bulduk ama çoğu yalnızca kart okuyucu ve satır yazıcıdan ibaretti, grafik terminal hiç yoktu.
O dönemde beceri, ilgi ve erişimin aynı anda bulunduğu kombinasyon herhalde oldukça nadirdi.
https://retro365.blog/2021/12/02/bits-from-my-personal-colle...
FOCAL hakkında Wikipedia:
https://en.wikipedia.org/wiki/FOCAL_(programming_language)
Lise fiziğinde serbest cisim diyagramından başlayıp yerçekimi ve itki olmak üzere iki kuvveti ele almaya kadar olan kısmı, fizikten A alan ortalama bir öğrenci de yapabilir.
Ama yerçekimi merkeze olan mesafeye, yani sürekli değişen bir değere bağlıdır. 120 mil yükseklikten başlanıyor ama değişim büyük olmadığı için bunu sabit olarak yaklaşık alabileceğini bilmek gerekir.
İtkinin yanma hızının bir fonksiyonu olarak nasıl çalıştığı da zor bir konu. Yakıt debisini iki katına çıkarınca egzoz gazı hızı da iki katına mı çıkar, ideal gaz yasası PV=nRT'de P ve T nasıl değişir gibi sorular ortaya çıkar.
Bu yüzden fizikçi babasına sorup roket motoru özelliklerini ve Tsiolkovski roket denklemini bulduysa, bu tek başına bir lise son sınıf öğrencisi için etkileyicidir.
Hızdan konuma geçmek için integral almak gerekir; FLOG() çağrısını Taylor serisine dönüştürüp terim terim integral alma fikrinin fizikten A alan ortalama bir öğrencinin aklına gelip gelmeyeceğinden emin değilim.
Taylor serisinin kaç terimini kullanmak gerektiği, yakınsayıp yakınsamadığı gibi ayrıntılar da zordur. Jim bu incelikleri düşündüyse harika; ama sadece 5 terim çok gibi görünüyor diye kullanmış olması da mümkün.
Ay yakınındaki simülasyon tamam dense bile, zemine çarpmanın nasıl algılanacağı da bir sorun. İrtifanın 0 olduğu çözümü doğrudan bulmak yerine, dönüş sırasında tam olarak bir kez ortaya çıkan hızın 0 olduğu noktaya bakma yöntemi oldukça yaratıcı
İstenen delta-V verildiğinde gerekli yakıt miktarını bulmak için roket denklemini tersine çevirmek de lise matematiği ve kalkülüsle aşılamıyor. Gerçekte Lambert W gibi yeni bir fonksiyon gerekiyor
Sonuçta Taylor serisiyle 5. dereceden bir polinomu çözmek gerektiğinden, 3., 4. ve 5. derece terimleri atıp bunu ikinci dereceden denkleme indirme kararını vermek gerekiyor. Normalde dinamik hesaplamalarında atmadığı terimleri burada atabileceğine karar vermesi, farklı durumlarda farklı yaklaşıklaştırma düzeyleri kullanılabileceğini anladığı anlamına geldiği için etkileyici
Ayrıca ikinci dereceden denklemin alternatif biçimini bir şekilde kullanmış olmasına bakılırsa, bu sadece bulup kopyalama düzeyinde olmayabilir
Yatay olarak hızlı girip LEM yan iticileri ve ana motor düğmesiyle yavaşlayarak dikey iniş yapmak gerekiyordu; çok hızlı olursanız veya yakıt biterse bir krater oluşuyor, iniş kalitesine göre bir veya daha fazla Amerikan bayrağı dikiliyordu
Birkaç yıl önce kaynak kodunun değersiz olduğunu ve bir daha kullanılmayacağını düşünüp tek kopyasını attım; sonradan bunun tarihsel olarak oldukça erken bir grafik oyun olduğunu ve basit bir emülasyonla yeniden canlandırılabileceğini fark edip pişman oldum
25 yıl sonra yeniden bakınca, inanılmaz derecede çok hata olduğunu ve mantığın da “440 IF GOTO 450” gibi karmakarışık olduğunu görünce şaşırdım
Sonunda yetişkin olduktan sonra yeniden yazdım [1], ama çocuk halimin başarılı olma ihtimali yoktu. Hâlâ, o unutulmuş İspanyol yayınevinin içinde neredeyse çalışan kodun nasıl olup da son hâline benzer bir şeye dönüştüğünü merak ediyorum
[1] https://7c0h.com/blog/new/moon_landing_in_basic.html
Bu tür BASIC kodlarının kökleri 1960'lara ve 70'lere uzanıyordu; o dönemde kodların yayımlandığı basılı dergilerde ve kod derlemelerinde editörlerin güçlü bir yetkisi vardı
Kaynak kodunun tek bir karakteri bile değiştirilmeden aynen basılması gerektiği bilinci zayıftı; editörler “bariz” yazım hatası ya da editoryal karar sandıkları şeylerle kaynak kodunu “dikkatli” biçimde düzeltirlerdi
Bu ders, 1980'lerden itibaren sektör genelinde iyileşmeler başlayıp basılı materyallerde kaynak koda dokunulmaması gerektiği anlayışı yayılana kadar yavaş ve sancılı biçimde öğrenildi
Bu akımın BBS'lerin yükselişini hızlandırıp hızlandırmadığını ve basılı medyanın kaynak kodu dağıtımı üzerindeki gücünü zayıflatıp zayıflatmadığını da merak ediyorum. Basılı medya sahipleri “kendi” içeriklerinin bir kısmı üzerinde dışarıdakilerin mutlak kontrole sahip olmasına daha açık olsaydı, belki başka bir tarih mümkün olabilirdi
Çocukken yetişkin yardımı olmadan, sadece okul ve yerel kütüphanedeki birkaç programlama kitabına bakarak kod yazmaya başlamıştım; elle girdiğim sayısız program benzer şekilde hatalarla dolu olmasına rağmen kodlamayı bırakmamış olmam şaşırtıcı
“440 IF GOTO 450” gibi karmaşık mantık hakkında biraz ekleme yaparsam: Kitaptaki kodların bir kısmının kesinlikle toparlanması gerekiyor, ama o dönemin ev bilgisayarlarındaki tipik BASIC büyük olasılıkla yalnızca satır numaralarıyla çalışıyor ve dallanma deyimleri de çok sınırlıydı
Kullanılan BASIC yapısal programlamayı destekliyor gibi görünüyor; bu, o dönemin ev bilgisayarlarında çok nadirdi. 1984'te bir C64 dergisi, yapısal programlamanın harikalarını okurlara tanıtan uzun bir diziyi en az 3 sayı boyunca yayımlamıştı
IF deyiminin kısıtları ciddi olduğundan GOTO kullanan assembly tarzı koşullu dallanma çok yaygındı ve fiilen gerekliydi
İç içe IF mümkün değildi; birden çok IF'i birleştirmek için seçilmeyen kısmı atlayarak geçmek gerekiyordu. Commodore/C64 BASIC'te, yani fiilen Microsoft BASIC'te ELSE bile yoktu; bu yüzden genellikle olumsuz koşul ve atlamayla ELSE dalı taklit edilirdi
C64 BASIC'te aynı satırdaki diğer deyimlerin de THEN'e ait sayıldığı tuhaf bir davranış vardı. Örneğin
10 IF A=1 THEN PRINT “FOO” : PRINT “BAR”, A=1 olduğunda FOO BAR yazdırır, değilse hiçbir şey yazdırmazElbette bu ancak sınırlı tek bir satıra tüm deyimleri sığdırabildiğinizde mümkündü. Diğer BASIC lehçeleri
PRINT “BAR”kısmını ELSE dışında görebilirdi; bu sözdizimsel olarak daha temizdi ama lehçenin sunduğu özelliklere bağlı olarak daha az kullanışlı olabilirdiBugün doğal karşıladığımız kolaylıklar ve katılık yoktu. C64 BASIC, uygulamanın yan ürünü gibi duran çok sayıda tuhaf özelliği nedeniyle özellikle “dağınık” hissettiriyordu. Örneğin tüm fonksiyonlar gerçekte gerekli olmasa bile argüman almak zorundaydı; kalan belleği yazdırmak için anlamsız
?FRE(123)gibi bir şey yazmak gerekiyordu199.99999999'u ne kadar erken “oynarsanız” o kadar iyi; bu yüzden kaba kuvvet aramayla yumuşak iniş sağlayan en erken girişi seçmek yeterli
Oyunun inişi algılaması için irtifanın yaklaşık 0,05 saniye boyunca 0'dan küçük olması gerekiyor. O süre boyunca itki 200 ya da 199 ise, irtifanın bu kadar uzun süre negatif kalması için irtifa 0 noktasındaki hızın 1 MPH'den büyük olması gerekir
Hata düzeltilse bile kod hâlâ yalnızca en düşük noktayı yaklaşıklar. İnişi algıladıktan sonra da gerçek iniş zamanını, yani hızın değil irtifanın 0 olduğu anı hesaplamak gerekir ve bu da yaklaşıklaştırma kullanır
Bu yüzden zaman biraz sapabilir. Son zaman adımında 200 veya 199 ile yanma sürüyorsa ivme büyük olduğundan, çok küçük bir zaman hatası bile büyük hız hatasına yol açar
Bunun yerine 10 lbs/sec civarında yanma yaparsanız, 0,08 saniye kadar sapma olsa bile hız değişimi büyük olmaz
Kare hızı düştükçe bu yöntemin doğruluğunun azaldığı mı kastediliyor, yoksa asıl denklemleri kullanmanın verdiği keyif mi, merak ediyorum
Özgün kare hızında iki yöntem arasındaki farkın ne kadar hissedilebilir olduğu da merak konusu
https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
Kütle ve ivmeyi yalnızca 10 saniyelik aralıklarla güncellerseniz, sonuç son derece hatalı olur
Fiziksel doğruluk açısından, özellikle yüzeye yakınken yakıt yakma oranı yüksekse kütle epey değişir. Ama oyunun zorluğu, eğlencesi ya da oyuncu stratejisi açısından büyük fark yaratacağını sanmıyorum
Aslında BASIC computer games kitabındaki diğer Ay’a iniş simülasyonlarından biri böyle saf bir yaklaşım kullanıyor gibi görünüyor
10 saniye çok uzunsa, kullanıcı arayüzünde bir turu yine 10 saniye tutup, içeride her turu 1 saniyelik 10 zaman adımı gibi daha küçük parçalara bölebilirsiniz
Mevcut oyun da bazı yerlerde gerçekten bunu yaptığı için fizik simülasyonu her zaman 10 saniyenin tamamını değil, isteğe bağlı bir S süresini girdi olarak alacak şekilde tasarlanmış
Ama iniş oyunu yokmuş ve ilk olan Storer’ınkiymiş. Bununla ilgili ilginç tarihçe burada
https://www.acriticalhit.com/moonlander-one-giant-leap-for-g...
Yakıt yakıldıkça aracın hafiflemesi etkisini hesaba katmasanız, yani burada roket denkleminin yaptığı işi çıkarsanız bile suicide burn hâlâ en uygun yöntemdir
Asıl neden, suicide burn’ün yerçekimi kaybını en aza indirmesidir
https://en.wikipedia.org/wiki/Gravity_loss
Niyetim, dinamiklerde roket denklemi ve yerçekimi diye iki parça olduğu, bunların da doğrusal olarak toplandığıydı. Yerçekiminin oluşturduğu ek hız, roket denkleminin delta-V’si artırılarak yok edilmeli
Yerçekimi delta-V’si, yerçekimi ivmesi çarpı zaman olduğundan zamanı en aza indirmek gerekir
Şaşırtıcı biçimde roket denkleminde bunun ne kadar sürdüğü, hangi yanma sırasını kullandığınız, sabit hızda sürekli mi yaktığınız yoksa kısa ve güçlü püskürtmelerle mi yaktığınız önemli değildir
Bu yüzden en az yakıtla hızı 0 olan bir iniş yapmak için mümkün olan en kısa sürede inmek gerekir
İnişi nasıl yapacağımı kendim çözememiştim ama ilk birkaç turu ataletle geçip sonra maksimum itki verme tekniğini birinin gösterdiğini hatırlıyorum. O zaman “suicide burn” terimini hatırlamıyorum. Belki Kerbal Space Program popüler olduktan sonra sonradan ortaya çıkmış bir ifade olabilir
1970’lerin ortasında Berkeley’deki Lawrence Hall of Science’ta da birkaç terminalde bu Ay’a iniş oyununun çalıştığını hatırlıyorum. Hangi bilgisayarda çalıştığını bilmiyorum
Bu programın kaynak kodunu hiç görmedim ve matematiğinin bu kadar incelikli olduğunu da hiç bilmiyordum. O zamanlar anlamak için çok küçüktüm; doğrusu şimdi anlayabilir miyim ondan da emin değilim
Oyun kiosk modunun bir “özelliği”, iyi zamanlanmış bir Ctrl-C ile kiosk modundan çıkıp başka oyunlar oynayabilmenizdi
Tesadüf müydü, yoksa erken dönem hacker’lara atılmış bir yem mi?