Non-Euclidean Doom: जब pi 3.14159 नहीं होता, तो गेम में क्या होता है (2022) [वीडियो]

 (media.ccc.de)
3 पॉइंट द्वारा GN⁺ 2024-05-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Doom source code में गलत pi value को शुरुआती बिंदु बनाकर यह देखा गया है कि जब गणितीय constants को जानबूझकर और ज्यादा बिगाड़ा जाता है, तो first-person shooter game की rendering और spatial sense कैसे बदलती है
  • गेम graphics सिर्फ pi पर नहीं, बल्कि trigonometry और कई गणितीय तकनीकों पर भी निर्भर करते हैं, इसलिए छोटे गणितीय बदलाव भी दुनिया को देखने और उसमें चलने के तरीके को प्रभावित कर सकते हैं
  • Doom एक classic FPS है जिसका source code 1999 में GPL के तहत जारी किया गया था, इसलिए इसे pi, trigonometric functions और constants बदलने वाले प्रयोगों के लिए इस्तेमाल किया जा सका
  • यह प्रयोग उस समय के hardware पर Doom को अच्छी तरह चलाने के लिए बनाई गई optimization techniques पर भी नज़र डालता है, और गलत गणित वाले version को खुद compile करने की guide भी देता है
  • यह इस बात की पड़ताल करता है कि क्या non-Euclidean geometry गेम के भीतर नए spatial experiences बना सकती है, और गलत pi values इस्तेमाल करने वाले दूसरे games व public source repositories की कड़ियाँ भी देता है

Doom के गणित को जानबूझकर बिगाड़ना

  • pi को आम तौर पर एक निश्चित value वाला constant माना जाता है, लेकिन Doom source code में गलत pi value इस्तेमाल की गई है
  • graphics rendering सिर्फ pi नहीं, बल्कि trigonometry और कई गणितीय तकनीकों पर निर्भर करती है
  • यह प्रयोग देखता है कि Doom source में pi value को और ज्यादा गलत करने पर गेम कैसे बदलता है
  • दूसरे trigonometric functions और constants को भी बदलकर यह देखा जाता है कि परिचित virtual world को समझने और उसमें घूमने का एहसास कैसे डगमगाता है

Doom source और प्रयोग का दायरा

  • Doom एक प्रसिद्ध classic first-person shooter game है
  • Doom source code 1999 में GPL के तहत जारी किया गया था
  • प्रयोग में ये शामिल हैं
    • pi value को और ज्यादा गलत value में बदलना
    • दूसरे trigonometric functions को गलत values में बदलना
    • संबंधित mathematical constants को inaccurate बनाना

Non-Euclidean गेम की संभावनाएँ

  • गणित बदलने पर खिलाड़ी जिस virtual space की संरचना और movement sense को जानता था, वह भी बदल सकती है
  • यह देखा जाता है कि क्या ऐसे बदलाव non-Euclidean geometry पर आधारित दिलचस्प गेम संभावनाओं तक ले जा सकते हैं

Performance optimization और खुद चलाना

  • उस समय के hardware पर Doom को अच्छी तरह चलाने के लिए बनाई गई optimization techniques पर भी संक्षेप में बात की गई है
  • प्रस्तुति के अंत में गलत गणित वाले Doom version को खुद compile करने की guide दी जाती है

संबंधित सामग्री

  • गलत pi values इस्तेमाल करने वाले दूसरे games और public source code repositories के links भी दिए गए हैं
  • प्रस्तुति वीडियो media.ccc.de के MCH2022 content के रूप में उपलब्ध है

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

1 टिप्पणियां

 
GN⁺ 2024-05-18
Hacker News की राय

  • क्लासिक Duke Nukem 3D में भी ऐसा एक उदाहरण था। Richard “Levelord” Gray का बनाया हुआ ‘Lunatic Fringe’ लेवल
    https://dukenukem.fandom.com/wiki/Lunatic_Fringe
    इस लेवल में बाहरी तरफ एक गोलाकार कॉरिडोर था, जिसकी संरचना ऐसी थी कि वह आपस में क्रॉस किए बिना पूरे दो चक्कर लगाता था, और इसने उस समय के क्रांतिकारी Build engine की room-connection आधारित area-separation क्षमता का उपयोग किया था। वही फीचर ‘room over room’ तकनीक में भी इस्तेमाल हुआ था
    मल्टीप्लेयर में यह मजेदार था और optical illusion भी काफी अच्छी तरह बना रहता था। अगर मुझे ठीक याद है, तो केंद्रीय कमरे में 4 दरवाजे थे, लेकिन बाहर का एक चक्कर लगाने पर उनमें से केवल 2 ही सामने आते थे
    engine के साथ प्रयोग करते हुए, मैंने कभी इसी तकनीक से “3 घरों और 3 utilities को बिना लाइनों के क्रॉस किए जोड़ने” वाली पहेली हल करने वाला एक toy level भी बनाया था

    • समझ नहीं आ रहा कि Duke Nukem किस मायने में “इसका उदाहरण” है। Duke वाला अंदरूनी तौर पर consistent program behavior है, जबकि यह source code में arbitrary बदलाव से पैदा हुई random error के ज्यादा करीब है
      Duke गैर-यूक्लिडीय geometry जैसी चीज हो सकता है, लेकिन Doom में pi बदलना geometry से खास संबंधित नहीं है और “garbage in, garbage out” जैसा ज्यादा लगता है
    • “उस समय की क्रांतिकारी ‘room over room’ तकनीक” की बात हो, तो 1994 में Bungie का Marathon भी यह पहले से कर सकता था और deathmatch map 5-D Space[1] में दिखाया था
      overlapping sectors में टूटने वाली चीज असल में लगभग सिर्फ Doom ही था
      [1] https://www.lhowon.org/level/marathon/30
    • बहुत पहले मैंने ऐसी सुविधा वाला एक छोटा engine बनाया था। उस समय मुझे Build engine के बारे में नहीं पता था, और मैंने world को convex sectors में बांटकर BSP tree follow करने के बजाय arbitrary links, यानी portals, allow किए थे। Rendering आगे से पीछे की ओर होती थी और portal boundary पर clip करती थी
      अगर आप convex shape के अंदर rasterize कर सकते हैं, तो sector-portal world को भी rasterize कर सकते हैं: किसी खास face को portal के रूप में mark करें, फिर उस face के दिखने की जगह को clipping area या stencil buffer के रूप में set करें, और portal data में मौजूद सही transformation और दूसरी तरफ के sector ID का उपयोग करके पीछे वाले sector को render करें
      portal से होकर गुजरने वाली collision handling, portal के पार rendering से कहीं ज्यादा मुश्किल है
    • बाद के Build games में implemented room over room के लिए आम तौर पर sectors का इस तरह overlap करना जरूरी नहीं होता। यह तैरने योग्य पानी implement करने के तरीके का extension है, जिसमें engine floor या ceiling की जगह किसी दूसरे sector को render करता है
      Lunatic Fringe, Build में impossible geometry को सीधे दिखाने का उदाहरण है, लेकिन Duke3D maps में intersecting geometry इससे भी बहुत ज्यादा है। Doom में ऐसी structure से BSP tree नहीं बनाया जा सकता, और player या monster भी सिर्फ X/Y coordinates ही track करते हैं, इसलिए स्वाभाविक रूप से यह असंभव है
    • Tea For God नाम का एक रोचक VR game है। वास्तविक play space के अंदर जब भी आप किसी मोड़ से गुजरते हैं या lift लेते हैं, यह चतुराई से नए corridors और rooms बना देता है, जिससे बिना उसी कमरे से बाहर निकले भी ऐसा illusion होता है कि आप किसी विशाल जगह में हैं। यह joystick या teleportation के बिना implement किया गया है

  • संयोग से मैं Poul Anderson की classic Operation Chaos पढ़ रहा था
    https://en.wikipedia.org/wiki/Operation_Chaos_(novel)
    इसकी setting एक parallel world है जहां magic सचमुच मौजूद है और science के साथ तेजी से विकसित हो रहा है। उदाहरण के लिए, Edwin Land polarization का उपयोग करके बिना चांदनी के werewolf को transform करने वाला device invent करता है
    मुख्य पात्रों का बच्चा अपहरण होकर नरक में ले जाया जाता है, और उन्हें पता चलता है कि सेना ने 20 साल पहले नरक की जांच करने की कोशिश की थी, लेकिन सभी पागल हो गए थे। विरोधी एक clue छोड़ता है कि नरक की spacetime geometry हमारी geometry से अलग है, इसलिए वे बच्चे के पहुंचने के क्षण पर वापस जाकर उसे ला सकते हैं
    वैज्ञानिक सिर्फ उसी clue से समझ जाते हैं कि नरक की geometry non-Euclidean geometry है, और सुरक्षित रूप से अंदर जाने, टिके रहने और वापस आने के मंत्र calculate कर लेते हैं। रास्ता खोजने के लिए वे 19वीं सदी के दो geometers, जिनमें से एक saint है, की मदद के लिए प्रार्थना करते हैं

    • हमारे world की spacetime geometry भी Euclidean नहीं है, और यहां तक कि Riemannian geometry भी नहीं है। Operation Chaos scientific होने से ज्यादा chaotic लगती है
      Poul Anderson की जो रचनाएं मैंने पढ़ी हैं, जैसे बेहतरीन High Crusade, उनमें भी वह scientific veneer की ज्यादा परवाह किए बिना rough तरीके से आगे बढ़ना पसंद करते हैं
      non-Euclidean geometry पर आधारित दूसरी रचना के रूप में Christopher Priest की Inverted World मेरी अच्छी यादों में है
    • यह घिसा-पिटा सुनाई दे सकता है, और शायद सचमुच हो भी, लेकिन आजकल इतनी creative fiction क्यों कम आती है, यह समझ नहीं आता
    • Jack Vance की शानदार short story collection Tales of the Dying Earth भी देखने लायक है। इसमें magic/science और demonic dimensions साथ आते हैं
    • Operation Chaos मुझे पसंद थी, लेकिन बहुत बाद में आया sequel निराशाजनक था

  • John Carmack ने शायद pi का 10वां दशमलव अंक गलत याद कर लिया हो, लेकिन अच्छा होगा कि सभी अपने codebase में 84,600 खोजकर देखें कि कहीं किसी ने एक दिन के seconds की संख्या में typo तो नहीं कर दिया
    यह हैरानी की बात है कि काफी आम है, और इससे यह सीख मिलती है कि constants को program में सीधे type करना चाहिए या programming language की standard library में पहले से मौजूद value का इस्तेमाल करना चाहिए

    • सच में ऐसा था। MySQL या Textmate जैसे बड़े projects के codebase में भी यह गलती हो सकती है, ऐसा दिखता है
      https://github.com/search?type=code&auto_enroll=true&q=84600
      https://github.com/mysql/mysql-server/blob/824e2b4064053f7da...
      https://github.com/textmate/textmate/blob/346b52b108b387462d...
    • हर 15 मिनट में चलने वाला token refresh code क्यों नहीं चल रहा, इसे debug करने में शर्मनाक रूप से बहुत ज्यादा समय लगा। आखिर में सभी variable values print करने के बाद ही पता चला कि 15 मिनट को 15 * 60 * 60 define किया था
    • ठीक-ठीक कहें तो यह “ज्यादातर दिनों” में seconds की संख्या है

  • असल में graphics और movement अजीब होने लगते हैं और आखिरकार game खेलने लायक नहीं रहता। इसे non-Euclidean Doom कहने के बजाय “universal constants से छेड़छाड़ का नतीजा” कहना ज्यादा सही लगता है
    असली non-Euclidean Doom ऐसा दिखेगा, ऐसी उम्मीद थी: https://youtu.be/kEB11PQ9Eo8?si=0HNlpGFBii2AIK1n

    • थोड़ा nitpick करें तो, वह video भी non-Euclidean शब्द का गलत इस्तेमाल कर रहा है। HyperRogue वाले लोगों ने actual non-Euclidean geometry दिखाने वाले कुछ videos बनाए हैं
      https://youtu.be/yqUv2JO2BCs?si=AutaqS5unvT7cDjw
      Doom video में आगे बढ़ते समय objects का side में फिसलते हुए लगना जैसे अजीब geometry effects देखें, तो इस Doom को non-Euclidean कहना कुछ हद तक ठीक भी लगता है
    • यह भी non-Euclidean का मतलब नहीं है। यह बस portals वाली एक सामान्य 3D world है। उस दौर के first-person shooter engines आम तौर पर rooms को doorways, यानी portals, से जोड़कर occlusion culling के लिए इस्तेमाल करते थे
      सामान्य geometry दिखा सकते थे, लेकिन geometry का किसी भी तरह से consistent होना जरूरी नहीं था, और rooms के बीच arbitrary connections भी allowed थे। बाल की खाल निकालने की कोशिश नहीं है, लेकिन यह एक आम गलतफहमी है
      असली non-Euclidean चीजों के लिए ZenoRogue का काम recommend करूंगा। जैसे Nil geometry का इस्तेमाल करने वाला एक simple game[1], non-Euclidean world roguelike की एक विशाल boss fight[2], और overall geometry weirdness[3] वगैरह हैं। उनके काम में से कुछ भी देख लें
      [1] https://m.youtube.com/watch?v=gejRg_q70EA&pp=ygUJemVub3JvZ3V...
      [2] https://m.youtube.com/watch?v=jcnXI8IArRI&pp=ygUJemVub3JvZ3V...
      [3] https://m.youtube.com/watch?v=yqUv2JO2BCs&pp=ygUJemVub3JvZ3V...
    • हैरानी है कि अभी तक Antichamber का जिक्र नहीं आया। यह एक शानदार game था जिसने इसी तरह के concept से actual puzzles बनाए थे
      सोचता हूं, अब काफी समय बीत चुका है, तो इसे फिर से खेलना मजेदार हो सकता है
    • यह portals जैसा दिखता है। उस समय के first-person shooter games मूल रूप से rooms को doorways, यानी portals, से जोड़कर occlusion culling करते थे
      सामान्य geometry दिखाने में दिक्कत नहीं थी, लेकिन geometry का जरूरी तौर पर sensible होना शर्त नहीं था, और rooms को आपस में मनमाने ढंग से जोड़ा जा सकता था
    • मैंने भी ठीक ऐसी ही चीज की उम्मीद की थी। यहां कुछ और नए ideas के साथ एक और non-Euclidean implementation है
      https://www.youtube.com/watch?v=tl40xidKF-4

  • Doom simulation नहीं है, इसलिए एक constant बदलना किसी चीज का अच्छा example नहीं बनता
    यह बस कुछ routines को खराब करने जैसा है, और इसी वजह से ज्यादातर बदलावों का नतीजा game के unplayable हो जाने में निकलता है

    • समझ नहीं आता इसमें interesting क्या है। किसी constant को गलत number से बदलेंगे तो जाहिर है अजीब behavior या errors आएंगे। और क्या होगा? वह अजीब behavior भी कुछ खास नहीं लगता; पता नहीं मैं क्या miss कर रहा हूं

  • अपने पसंदीदा console emulator का source code लेकर उसमें arbitrary floating-point errors डाल दें या कुछ branch instructions का meaning उलट दें। game जितना पुराना होगा, उसके फिर भी चलते रहने की संभावना उतनी ज्यादा होगी, और उसके खराब hallucination trip जैसा दिखने की संभावना भी उतनी ही बढ़ेगी

    • बहुत पहले N64 emulator के लिए ऐसा करने वाला एक tool था। इस्तेमाल किया तो कुछ समय तक मजेदार लगा, लेकिन उम्मीद के मुताबिक अक्सर crash होता था
      मशहूर images और video files के कुछ हिस्सों को corrupt करके कुछ नया बनाने वाले glitch art projects भी थे। दोनों को फिर से ढूंढना चाहता हूं, लेकिन मिल नहीं रहे

  • Marathon 1 (1994) ने non-Euclidean space को सपोर्ट किया था, लेकिन इसका इस्तेमाल बहुत कम हुआ। पूरे गेम में कई levels हैं जिनमें maps होते हैं, और खेलते-खेलते सिर्फ एक-दो levels में ही असंभव space सामने आता है—गेम यह चेतावनी या जानकारी नहीं देता कि ऐसी चीज संभव है
    इसलिए शायद यह गेम में मिले सबसे अच्छे Easter egg locations में से एक रहा होगा
    इसका demo video भी मिला: https://www.reddit.com/r/Marathon/comments/vclu55/probably_n...

  • आखिरी सवाल है: “ऐसा pi का अधिकतम मान कितना है जिसके साथ गेम playable रहे और crash न हो।” pi के 4 होने पर segmentation error आने की वजह शायद यह है कि lookup table access के कुछ हिस्से table के end से आगे चले जाते हैं; अगर ऐसा है, तो playable maximum value संभवतः pi से बस थोड़ा-सा ही बड़ी होगी

  • काश यह video game mechanics और यह कि Pi बदलने से इस तरह की दिक्कतें क्यों हुईं, इन पर और गहराई से बात करता

  • जिन ray-traced Doom का संदर्भ दिया गया है, उसमें यह experiment और दिलचस्प होगा या नहीं—यह जानने की उत्सुकता है। rasterization technique में constants hack करने का नतीजा लगभग उम्मीद के मुताबिक ही था। लेकिन ray tracing में शायद और दिलचस्प नतीजे आ सकते हैं