Rust के साथ 3 साल गेम डेवलपमेंट करने के बाद उससे दूरी बनाते हुए

 (loglog.games)
29 पॉइंट द्वारा GN⁺ 2024-04-27 | 13 टिप्पणियां | WhatsApp पर शेयर करें
  • इस दावे पर कि Rust का आदी हो जाने पर सारी समस्याएँ गायब हो जाएँगी
    • Rust में सहज हो जाने पर भी बुनियादी समस्याएँ खत्म नहीं होतीं
    • गेम जटिल state machine होते हैं और उनकी requirements लगातार बदलती रहती हैं, इसलिए वे Rust की static और अत्यधिक जाँच करने वाली प्रकृति से मेल नहीं खाते
    • कोड को लगातार refactor करना पड़ना एक self-inflicted समस्या है
  • Borrow checker के कारण होने वाली बड़े पैमाने की refactoring समस्याएँ
    • Rust अन्य भाषाओं की तुलना में ज़्यादा बार refactoring के लिए मजबूर करता है
    • जब गेम requirements बार-बार बदलती हैं, तो borrow checker से जूझना पड़ता है और कोड को दोबारा संरचित करना पड़ता है
    • इस दावे से सहमत होना कठिन है कि refactoring से अच्छा कोड बनता है। अच्छा कोड विचारों को दोहराते हुए और उन्हें आज़माते हुए बनता है
  • Indirection केवल कुछ समस्याएँ हल करता है और विकास उत्पादकता घटाता है
    • Borrow checker की समस्याओं को हल करने के लिए indirection इस्तेमाल करने पर कोड लॉजिक बिखर जाता है और जटिल हो जाता है
    • गेम में जुड़े हुए events, खास timing, और बहुत सारे state management की ज़रूरत होती है, और indirection इसे कठिन बना देता है
    • Rust में साधारण कोड भी indirection के लिए बहुत verbose लिखना पड़ता है
  • ECS(Entity-Component-System) गलत समस्या हल करता है
    • ECS का असली फायदा दरअसल generational arena का फायदा है
    • ECS को dynamic composition, structure of arrays, Rust borrow checker के समाधान, dynamically created generational arenas आदि कई नज़रियों से देखा जाता है
    • लेकिन गेम डेवलपमेंट में ECS सबसे उपयुक्त तरीका है या नहीं, यह संदिग्ध है। performance या composition से अधिक गेम लॉजिक पर ध्यान देना चाहिए
  • Generalized systems मज़ेदार gameplay तक नहीं ले जाते
    • बहुत ज़्यादा generalized systems इस्तेमाल करने पर gameplay नीरस बन जाता है
    • अच्छे गेम में बारीक interactions को सावधानी से डिज़ाइन करना, VFX को synchronize करना, playtest और experiment को दोहराना, और जल्दी रिलीज़ करके feedback लेना महत्वपूर्ण है
    • Rust ऐसे मूल्यों का पीछा करता है जो तेज़ prototyping और iteration के लिए अनुकूल नहीं हैं
  • गेम डेवलपमेंट में महत्वपूर्ण चीज़ तेज़ prototyping और iteration है, लेकिन Rust के मूल्य इसके उलट हैं
    • गेम डेवलपमेंट का केंद्र गेम खुद और player experience है, crash-free code नहीं
    • इंडी गेम्स में गेम कोड की maintainability उतनी महत्वपूर्ण नहीं होती। महत्वपूर्ण है iteration speed
    • Rust समस्याओं से बचने पर इतना केंद्रित है कि वह वास्तव में महत्वपूर्ण चीज़ें ही खो देता है
  • Procedural macros reflection की तुलना में बहुत कमज़ोर हैं
    • गेम डेवलपमेंट में system code, gameplay code, UI, VFX, audio, tools आदि कई क्षेत्रों का कोड लिखना पड़ता है
    • Rust में साधारण "object output" के लिए भी कोड खुद लिखना पड़ता है या procedural macros बनाने पड़ते हैं
    • Procedural macros declarative macros की तुलना में कहीं अधिक सीमित हैं और compile time भी बढ़ा देते हैं
    • C# की reflection बहुत इस्तेमाल-योग्य है और जहाँ performance महत्वपूर्ण नहीं होती, वहाँ तेज़ development संभव बनाती है
  • Hot reloading iteration speed बढ़ाने में महत्वपूर्ण भूमिका निभाता है
    • Hot reloading immediate mode UI/drawing, debugging, और gameplay constants tuning के लिए बहुत उपयोगी है
    • Rust में hot-lib-reloader है, लेकिन वह परफेक्ट नहीं है और planning व foresight माँगता है, जिससे रचनात्मक उपयोग सीमित हो जाता है
    • गेम डेवलपर्स केवल साधारण struct reloading से अधिक उच्च-स्तरीय tooling चाहते हैं
  • Abstraction कोई विकल्प नहीं, बल्कि अनिवार्यता है
    • वास्तविक उदाहरण) UI state के अनुसार अलग व्यवहार चाहिए होने पर Rust में refactoring करनी पड़ती है या clone का अत्यधिक उपयोग करना पड़ता है
    • कई बार business logic नहीं बदलता, बल्कि compiler को संतुष्ट करने के लिए कोड बदलना पड़ता है
    • Rust में "इन fields वाला type" जैसी structural type system नहीं है, इसलिए refactoring के समय कोड की कई जगहें बदलनी पड़ती हैं
  • Rust की GUI स्थिति बेहद खराब है
    • गेम UI में महत्वपूर्ण चीज़ data binding या reactive updates नहीं, बल्कि appearance को customize करना है
    • गेम UI के लिए ज़रूरी है सुंदर GUI, custom sprites, animation, vector shapes, particles, effects, flashes आदि
    • अभी गेम GUI में विशेषज्ञता रखने वाली कोई Rust library नहीं है
  • Orphan rule वैकल्पिक होना चाहिए
    • Orphan rule सुरक्षा के लिए विकास उत्पादकता को बहुत घटा देता है
    • library नहीं, application code में कम-से-कम orphan rule बंद करने का विकल्प होना चाहिए
  • Compile time बेहतर हुआ है, लेकिन proc macros इस्तेमाल करने पर अभी भी धीमा है
    • serde जैसे proc macros compile time को काफी बढ़ा देते हैं
    • 20-30 सेकंड से अधिक लेने वाले incremental build में बारीक tuning करना बहुत कठिन हो जाता है
  • Rust गेम डेवलपमेंट ecosystem कुछ ज़्यादा ही बढ़ा-चढ़ाकर पेश किया गया लगता है
    • वास्तव में गेम बना रहे लोगों की संख्या बहुत ज़्यादा नहीं है
    • कई बार वेबसाइट या README से चमकदार और प्रसिद्ध लगने वाले प्रोजेक्ट वास्तव में वैसा नहीं होते
    • अगर वास्तव में गेम बनाना है, तो godot-rust की सिफारिश की जाती है। pure Rust solution पर अड़ने के बजाय mature engine की मदद लेना बेहतर है
  • गेम single-threaded होते हैं, इसलिए global state असुविधाजनक होने का तर्क गलत है
    • Rust में global state इस्तेमाल करना बहुत असुविधाजनक है (static mut, AtomicRefCell, Rc आदि)
    • लेकिन backend services के विपरीत, गेम में लगभग सब कुछ single-threaded होता है, इसलिए ऐसी असुविधा की ज़रूरत नहीं
    • Bevy द्वारा parallel systems लाना लेखक की नज़र में गलती थी। तेज़ performance के लिए ऐसा किया गया, लेकिन users को लगातार order स्पष्ट करना पड़ता है, जिससे असुविधा ही बढ़ती है
  • Dynamic borrow checking refactoring के बाद अप्रत्याशित crash पैदा कर सकता है
    • hecs को 2 साल इस्तेमाल करते हुए query overlap के कारण crash होने के कई मामले देखे गए
    • RefCell इस्तेमाल करते समय भी दो जगह .borrow_mut() होने पर अप्रत्याशित crash हो सकता है
    • समस्या खराब कोड से ज़्यादा इस बात की है कि Rust अनावश्यक refactoring के लिए मजबूर करता है
    • गेम में RefCell उपयोगी है, लेकिन Rust इसे बहुत कठिन बना देता है
  • Context object की flexibility पर्याप्त नहीं है
    • Rust में global state इस्तेमाल करना कठिन होने के कारण references को context object में इकट्ठा करके पास करने का पैटर्न अपनाया जाता है
    • लेकिन इस दौरान अगर केवल कुछ fields को borrow किया जाए, तो partial borrow के कारण compile error हो जाता है
    • कहा जाता है कि context को तोड़कर structure बदलो, लेकिन जब असल में लक्ष्य गेम लॉजिक बनाना हो, तो compiler को संतुष्ट करने के लिए structure बदलना समय की बर्बादी है

Rust के फायदे

  • एक बार compile हो जाए तो आमतौर पर अच्छी तरह काम करता है। खासकर CLI tools, data processing, और algorithms लिखने में उपयोगी है
  • बिना ज़्यादा अतिरिक्त मेहनत के अच्छा performance देता है। C# की तुलना में 1.5~2.5 गुना तेज़ अनुभव हुआ है
  • Enum अच्छी तरह implement किए गए हैं
  • Rust analyzer की वजह से IDE usability काफ़ी बेहतर हुई है
  • Trait system अच्छा है। अगर orphan rule थोड़ा ढीला कर दिया जाए, तो इसका उपयोग और बढ़ सकता है

GN⁺ की राय

  • Rust के बारे में राय कुल मिलाकर नकारात्मक है, लेकिन चूँकि लेखक ने कई प्रयोगों के बाद यह निष्कर्ष निकाला है, इसलिए इसे गंभीरता से लेने की ज़रूरत लगती है। खासकर गेम डेवलपमेंट जैसे डोमेन में practicality और development speed कितनी महत्वपूर्ण है, और Rust अभी इन पहलुओं में कमज़ोर है—यह बात वाजिब लगती है

  • इस बात से सहमति है कि Rust जिस safety की ओर बढ़ता है, वह कभी-कभी development productivity को गंभीर रूप से कम कर सकती है। Rust कोड लिखते समय कई बार लॉजिक से ज़्यादा समय compiler को संतुष्ट करने में निकल जाता है, और लगता है कि यह इस तथ्य से जुड़ा है कि Rust मूल रूप से system programming के लिए विशेषीकृत भाषा है

  • दूसरी ओर, गेम डेवलपमेंट ज़्यादातर single-threaded environment में होता है और वहाँ तेज़ prototyping व iteration महत्वपूर्ण हैं, इसलिए अत्यधिक safety checks उल्टा नुकसानदेह हो सकते हैं। खासकर Rust के शुरुआती दिनों में गेम डेवलपमेंट आज़माकर निराश हुए लोगों के अनुभव बहुत सुने गए थे, और लगता है कि वे बुनियादी समस्याएँ अब भी बहुत नहीं सुधरी हैं

  • बेशक, Bevy जैसे हाल के game engines ने Rust गेम डेवलपमेंट को कुछ हद तक आसान बनाया है, लेकिन अभी भी वे Unity या Godot जैसे mature engines के स्तर से काफ़ी दूर लगते हैं। इस लेख की तरह Rust में सब कुछ pure तरीके से बनाने के बजाय, मौजूदा engines के साथ मिलाकर इस्तेमाल करना अधिक व्यावहारिक विकल्प हो सकता है

  • लेखक द्वारा बताए गए फायदे गेम के बाहर के क्षेत्रों में Rust इस्तेमाल करते समय अधिक स्पष्ट महसूस होते हैं। खासकर system programming या web server development जैसे क्षेत्रों में Rust की safety और उच्च performance बड़ी ताकत हैं, लेकिन गेम डेवलपमेंट में वे फायदे उतने बड़े merit की तरह काम नहीं करते

  • अंततः Rust कोई सर्वगुणसंपन्न भाषा नहीं, बल्कि एक विशेष डोमेन के लिए अधिक उपयुक्त भाषा है, इसलिए यह अपने प्रोजेक्ट की प्रकृति के अनुकूल है या नहीं, इस पर सावधानी से विचार करना चाहिए

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

13 टिप्पणियां

 
coremaker 2024-04-29

मेरा मानना है कि rust ऐसी भाषा है जो core level पर integrity वाले code लिख सकने वाले developers की घटती संख्या,
और अलग-अलग developer faults से पैदा होने वाली समस्याओं को हल करने के लिए बनी है।

यह तेज़ी से development करने के लिए नहीं,
बल्कि सटीक तरीके से development करने के लिए ज़्यादा उपयुक्त है,
इसलिए जहाँ user की अतिरिक्त requirements बार-बार आती हों और उन्हें लागू करना ज़रूरी हो, ऐसे projects के लिए यह उपयुक्त नहीं है।

फिर भी, UI library आने की उम्मीद रखने की वजह
शायद यह उम्मीद है कि मज़बूत code के ऊपर चलने वाला छोटा और simple UI भी इसकी उपयोगिता को और बढ़ा देगा।
 
kandk 2024-04-29

मैंने गेम डेवलपमेंट किया नहीं है, इसलिए ठीक से नहीं जानता,
लेकिन लगता है कि शुरू से ही भाषा गलत चुनी गई थी, (अगर development iteration अहम था, तो script-स्तर की भाषा चुननी चाहिए थी..)
या फिर सिस्टम के बारे में गहरी समझ नहीं थी।
मुझे लगता है कि C++ चुना होता तब भी शायद इसी तरह की समस्याएँ आतीं।
 
cosine20 2024-04-29

हाँ। खैर, अगर C++ चुना होता, तो Unreal का विकल्प मौजूद था...
 
cosine20 2024-04-29

आजकल के दौर में लगता है कि Rust, C++ जैसी native भाषाएँ गेम क्लाइंट डेवलपमेंट की तुलना में गेम इंजन जैसे middleware डेवलपमेंट के लिए ज़्यादा उपयुक्त हैं।
ठीक वैसे ही जैसे native भाषाओं में full-stack web development के उदाहरण लगभग नहीं के बराबर हैं।
 
kandk 2024-04-29

यह भाषा शुरू से ही उसी उद्देश्य के लिए आई थी। C++ के विकल्प के तौर पर।
लगता है कि यह लेख भाषा की आलोचना करने वाला लेख बन गया है।
 
cosine20 2024-04-29

सही है। क्या यह मूल रूप से Firefox के आंतरिक इंजन को बेहतर बनाने के लिए शुरू किया गया था?
लेख की सामग्री से ऐसा लगता है जैसे Rust को किसी रामबाण इलाज की तरह देखा गया, और फिर उसे ऐसे क्षेत्र में इस्तेमाल करके डेवलपमेंट किया गया जहाँ वह अच्छी तरह फिट नहीं बैठता, इसलिए काफ़ी परेशानियाँ झेलनी पड़ीं, हाहा
 
mammal 2024-04-29

100% सहमत हूँ। गेम लॉजिक के लिए बेहतर productivity वाली भाषा इस use case के लिए ज़्यादा उपयुक्त लगती है।
 
edunga1 2024-04-28

मैं अभी Rust शुरू करने के चरण में हूँ, इसलिए इससे थोड़ी सहानुभूति महसूस होती है.
Borrowing में बदलाव की वजह से कोड में बहुत ज़्यादा बदलाव करने पड़ते हैं, और यह काफ़ी तकलीफ़देह लगता है.
implicit expressions वाले Python और JavaScript के विपरीत, Rust ज़्यादा explicit होने की तरफ़ झुकता है, इसलिए कभी-कभी verbose code बन जाता है, और प्रोग्रामर को बहुत सारे चुनाव करने पड़ते हैं, जिससे थकान भी होती है.
फिर भी, इसमें ऐसे concepts हैं जो दूसरी भाषाओं में नहीं मिलते, और वही इसे नया और मज़ेदार बनाते हैं.

अगर Rust Analyzer या GitHub Copilot नहीं होते, तो शायद मैं इसे बहुत पहले छोड़ देता.
 
botplaysdice 2024-04-28

वाकई, game development काफ़ी hardcore है...
 
steamb23 2024-04-28

Rust में core से लेकर front तक सब कुछ लिखने के बजाय
अगर Unity या किसी दूसरे game engine की तरह core को Rust में लिखा जाए और उसे किसी ज़्यादा productive language के साथ जोड़कर इस्तेमाल किया जाए, तो कैसा रहेगा?
 
bus710 2024-04-28

शायद ऐसा होना लाज़िमी है, क्योंकि यह चीज़ों को काफ़ी सख्ती से एक ढांचे में बांध देता है।
 
2024-04-27
[यह टिप्पणी छिपाई गई है.]
 
GN⁺ 2024-04-27
Hacker News टिप्पणी

मेटावर्स क्लाइंट डेवलपमेंट के अनुभव साझा करते हुए Rust की समस्याओं को सामने रखा गया है

  • Rust के साथ बड़े पैमाने के 3D गेम डेवलपमेंट के उदाहरण लगभग नहीं हैं
  • refactoring और प्रोग्राम के अलग-अलग हिस्सों को जोड़ने का काम कष्टदायक है
  • rendering लगभग पर्याप्त है, लेकिन stack पूरा नहीं है और भरोसेमंद भी नहीं है
  • 2D GUI सिस्टम कमजोर है और हर dialog box के लिए बहुत ज़्यादा code चाहिए
  • async सिस्टम का अनावश्यक क्षेत्रों तक फैल जाना एक वास्तविक समस्या है

20 साल के अनुभव वाले गेम डेवलपर के रूप में लेखक का मानना है कि Rust गेम डेवलपमेंट के लिए उपयुक्त नहीं है

  • gameplay code लचीला होना चाहिए और दिलचस्प गेम बनाने के लिए edge case बहुत होने चाहिए
  • compile time महत्वपूर्ण है और structure में बदलाव बार-बार करने पड़ते हैं
  • ECS कुछ सिस्टम में उपयोगी है, लेकिन gameplay या UI code में इसका उपयोग करना कठिन है

Rust गेम डेवलपमेंट ecosystem बहुत हद तक hype पर निर्भर है

  • Rust के साथ गेम डेवलपमेंट की कोशिश की, लेकिन तुरंत ही अनुभव बेहद खराब रहा
  • धीमा compile time, बहुत बड़े package download, और खुद Rust की कठिनाई जैसी समस्याएं
  • यह कहा जाता है कि दूसरे tools Rust जितने safe नहीं हैं, लेकिन गेम्स में memory safety शायद ही कभी बड़ा मुद्दा रही है

लेखक ने Bevy, Unity और Godot के गेम डेवलपमेंट अनुभव की तुलना की

  • आज के समय में Rust के साथ गेम डेवलपमेंट चुनना समझना कठिन है
  • अगर हर चीज़ को ECS में ठूंसा जाए, तो यह मजेदार gameplay डेवलपमेंट में बाधा बनता है
  • आधुनिक PC की performance को देखते हुए multithreading optimization को लेकर अत्यधिक चिंता की ज़रूरत नहीं है

Nim भाषा Rust की तुलना में गेम डेवलपमेंट के लिए अधिक उपयुक्त हो सकती है

  • यह डेवलपर के रास्ते में बाधा नहीं बनती और hot reloading को support करती है

Rust एक ऐसी हठधर्मी भाषा लगती है जो प्रोग्रामिंग का एक खास तरीका थोपती है

  • यह memory safety को हर चीज़ से ऊपर रखती है, लेकिन गेम डेवलपमेंट में इसकी उपयोगिता उतनी अधिक नहीं है
  • गेम डेवलपमेंट के लिए आदर्श भाषा ऐसी होनी चाहिए जो उच्च productivity दे, पर्याप्त performance रखे, और जोखिम लेने वाले कुशल programmers के लिए बनी हो

Allen Blomquist का tooling demo दिखाता है कि डेवलपमेंट feedback loop कितना महत्वपूर्ण है

  • Rust मनचाहा कार्य-परिवेश नहीं दे सका, इसलिए फिर से Unity पर लौट गए

Rust की बुनियादी समस्या यह है कि उसने object-oriented शैली को छोड़कर functional programming को प्राथमिकता दी है

  • सबसे निचले core स्तर पर यह मददगार हो सकता है, लेकिन ऊपरी स्तरों पर उपयुक्त नहीं है

गेम डेवलपमेंट के लिए Rust सबसे खराब विकल्प है

  • correctness, safety और perfect code पर Rust का ज़ोर गेम डेवलपमेंट की प्रकृति से मेल नहीं खाता
  • गेम्स की उम्र छोटी होती है और डेवलपमेंट cycle भी छोटी होती है, इसलिए code quality उतनी निर्णायक नहीं होती
  • गेम engine डेवलपमेंट में यह मदद कर सकता है, लेकिन इसे उच्च लचीलेपन वाली scripting language के साथ इस्तेमाल करना चाहिए

D भाषा में coding करते हुए यह महसूस हुआ कि C की तुलना में data layout बदलना कहीं अधिक आसान है

  • reference type और value type के बीच बदलाव C में कठिन है, लेकिन D में आसान है