Bevy 0.12 - Rust से बना डेटा-ड्रिवन गेम इंजन

• Renderer अब वैकल्पिक Deferred Rendering को सपोर्ट करता है, और material के हिसाब से forward या deferred path चुना जा सकता है, साथ ही DefaultOpaqueRendererMethod से global default सेट किया जा सकता है
• मौजूदा Bevy app या plugin के लिए migration प्रक्रिया को 0.11 to 0.12 Migration Guide के जरिए जरूर जांचना चाहिए
• Bevy Asset V2 asset preprocessing, .meta file-आधारित settings, कई AssetSource, recursive dependency load events, asynchronous asset I/O, और बेहतर handles को सपोर्ट करता है
• Asset preprocessing को AssetPlugin { mode: AssetMode::Processed } और bevy/asset_processor Cargo feature से enable किया जाता है, लेकिन अभी अधिकांश use case के लिए इसकी सिफारिश नहीं की जाती
• Android पर app suspend होने पर अब crash नहीं होता, resume होने तक system execution रुक जाता है, और ApplicationLifetime::Suspended तथा ApplicationLifetime::Resumed events मिलते हैं
• StandardMaterial में specular_transmission, diffuse_transmission, thickness, ior, attenuation_color, attenuation_distance जोड़े गए हैं, जिससे glass, water, plastic, leaf और paper जैसे transmissive material को व्यक्त किया जा सकता है
• glTF loader KHR_materials_transmission, KHR_materials_ior, KHR_materials_volume, KHR_materials_emissive_strength extensions को सपोर्ट करता है, और TEXCOORD1 या UV1 दूसरा UV map इम्पोर्ट कर सकता है
• Draw command का स्वचालित batching/instancing अब संभव है, और एक जैसे material व mesh वाले entities को फिलहाल batch किया जा सकता है, जबकि NoAutomaticBatching component से उन्हें बाहर रखा जा सकता है
• Shadows में PCF Shadow Filtering जोड़ा गया है, जिससे DirectionalLight और SpotLight में अधिक मुलायम shadows मिलती हैं, और default तरीका ShadowMapFilter::Castano13 है
• ECS में one-shot systems जोड़े गए हैं, जिनमें system को register करने के बाद SystemId से जरूरत पड़ने पर चलाया जा सकता है, लेकिन exclusive system, system piping के लिए system, खुद को कॉल करना, और parallel evaluation सपोर्ट नहीं हैं
• FixedTime हटा दिया गया है, और Time अब FixedUpdate में भी संदर्भ के अनुरूप मान लौटाता है, जिससे FixedUpdate के अत्यधिक जमा होने से app के रुक जाने वाली “death spiral” स्थिति को रोका जा सकता है
• AnimationPlayer में set_elapsed को seek_to से, और stop_repeating को set_repeat(RepeatAnimation::Never) से बदला गया है, जबकि elapsed अब animation speed से प्रभावित हुए बिना वास्तविक elapsed time लौटाता है
• Bevy shader import अब Rust-स्टाइल syntax में बदल गया है, जो #import bevy_pbr::forward_io::VertexOutput, braces के साथ multiple import, partial path import, और fully qualified path को सपोर्ट करता है
• UI में UiMaterial के जरिए custom material shader को UI node पर इस्तेमाल किया जा सकता है, और Outline component ऐसे node outline को सपोर्ट करता है जो layout space नहीं घेरता
• accessibility integration में ManageAccessibilityUpdates resource जोड़ा गया है, जिसका मान false होने पर engine के accessibility tree का automatic update रोका जा सकता है

[GN⁺]

Hacker News की राय

• Unity या Godot जैसे पारंपरिक engines की तुलना में Bevy में गेम बनाने का तरीका पूरी तरह अलग है
  UI या scripting के बिना सब कुछ Rust code से संभलता है, इसलिए यह libGDX या Cocos2D-x के ज़्यादा करीब है। हालांकि ECS और Rust इस्तेमाल होने की वजह से coding का तरीका भी काफी बदल जाता है, तो यह असल में अपनी ही अलग दुनिया में होने जैसा लगता है
  मैं Bevy से सफल हुए indie games देखना चाहूँगा, लेकिन संभव है कि ज़्यादातर game developers उन पारंपरिक tools को ज्यादा पसंद करें जिन्हें वे पहले से सीख चुके हैं और जिनका इस्तेमाल उनके आसपास भी होता है। जो लोग game बनाना चाहते हैं और Rust भी पसंद करते हैं, उनका overlap बहुत बड़ा नहीं है; और उनमें भी कई लोग किसी experimental नए engine को सीखने में काफी समय और मेहनत लगाने के बजाय भरोसेमंद और भरपूर resources वाले tools चुनेंगे
  निजी तौर पर मुझे लगता है कि Bevy को Bevy और Rust पर आधारित IDE और scripting language की जरूरत है। नए project में काफी मेहनत लगाने की बाधा तो खत्म नहीं होगी, लेकिन जिन नए users को Rust का अनुभव नहीं है और code की दीवार से शुरुआत करना भारी लगता है, उनके लिए यह बहुत ज्यादा अपनाने लायक हो सकता है। यह Unity या Godot की तरह canvas पर कुछ घंटों में बहुत basic prototype बनाने वाले तरीके से अलग है
  मुझे पता है कि developers scripting language के खिलाफ हैं, लेकिन hot reload और ज्यादा गहरी debugging की जरूरत है, और मुझे लगता है कि सिर्फ Rust से यह प्रभावी ढंग से करना मुश्किल है। कई game developers Rust और borrow checker से overwhelmed भी हो सकते हैं। हालांकि अभी इसे खुद implement करने के लिए समय, संसाधन और इच्छा नहीं है

  • Bevy की संरचना ऐसी है कि borrow checker से सीधे टकराने की नौबत ज्यादा नहीं आती। components और resources आम तौर पर owned types इस्तेमाल करते हैं, और Query और Ref के जरिए उन्हें बिना ज्यादा चिंता के handle किया जा सकता है
    मैंने Bevy को थोड़ा इस्तेमाल किया और repository देखी, तो lifetime annotations 0 थीं
  • game development में सबसे ज्यादा समय अक्सर asset management में जाता है, और उसके बाद programming आती है। Bevy जैसे engines bug fixing का समय घटाने की कोशिश करते हैं, लेकिन अगर asset pipeline कमज़ोर हो तो वह बचत assets की तरफ खो जाती है
    scripting language थोड़ी मदद कर सकती है, लेकिन अभी Bevy इस्तेमाल करने वाले लोग काफी technical मिजाज के हैं और अक्सर full-time designers नहीं होते, इसलिए बहुत तीखी demand नहीं दिखती
    Rust community का game development पर असर देखने की उम्मीद है और कभी contribute करना चाहूँगा, लेकिन फिलहाल बताए गए कारणों से C++/C# pipeline बनाए रखने का इरादा है। Rust को साथ-साथ ठीक से सीखूँगा, और tools mature होने पर आगे के projects में सोच सकता हूँ
    hot reload अक्सर तब का अस्थायी उपाय होता है जब compile time संभालना मुश्किल होने लगे। अगर average 4 सेकंड और full recompile करीब 20 सेकंड है, तो full compile से बचने के तरीकों पर बहुत संसाधन लगाने की जरूरत कम हो जाती है
    हालांकि मैंने सुना है कि Rust में कुल मिलाकर compile times लंबे होते हैं, इसलिए scripting या hot reload की जरूरत उम्मीद से जल्दी आ सकती है। फिर भी अभी चल रहे indie projects शायद उस दीवार तक नहीं पहुँचेंगे
  • IDE काफी पहले से plan में था, और मेरी जानकारी में इस release के बाद यह top priority है
    Bevy के creator Cart का मानना है कि Bevy को Rust-first होना चाहिए, और निजी तौर पर मैं भी सहमत हूँ। इसका यह मतलब नहीं कि कई scripting languages के लिए plugins नहीं बनाए जा सकते; असल में कुछ पहले से मौजूद हैं

• मैं Bevy का creator और project lead हूँ। कुछ भी पूछ सकते हैं

  • हम अपनी company के size के हिसाब से काफी बड़ा WASM app Bevy से बना रहे हैं, और engine इस्तेमाल करने का अनुभव बहुत अच्छा रहा
    Bevy और community शानदार हैं। हमें कुछ tickets पर काम चाहिए था, और core contributors में से एक को ढूँढकर sponsor करना और request को अंत तक आगे बढ़वाना बहुत आसान था। उदाहरण के लिए morph target ऐसा ही था
    Carter सच में कुछ महत्वपूर्ण बना रहे हैं, और उसके पीछे शानदार momentum है। Bevy में web deployment बहुत आसान है, और ज्यादा लोगों को इसे देखना चाहिए। community भी अच्छी है और मदद पाना आसान है
  • documentation सीमित होने से शुरुआत करने में हिचक होती है। Bevy book कुछ ही मिनटों में पूरी पढ़ी जा सकती है, और अटकने पर refer करने के लिए सामग्री जल्दी खत्म हो जाती है
    documentation कब बेहतर होगी? release notes देखते हुए, ideally हर feature के लिए कई pages की documentation हो तो अच्छा होगा। समझता हूँ कि काम बहुत है, और पूरी documentation शायद stabilization के बाद ही संभव हो
  • hobby game developer के तौर पर अगर नया project शुरू करूँ, तो शायद Bevy चुनूँगा। यह Love और Godot के बीच का अच्छा संतुलन लगता है; Love से ज्यादा robust है, लेकिन Godot जितना beginner-oriented नहीं लगता
    Bevy कितना opinionated engine है? जानना चाहूँगा कि क्या कभी features और developer accessibility के बीच समझौता करना पड़ा है
    अभी Bevy के लिए सबसे ideal project किस तरह का होगा?
  • Rust और Bevy से game लिखने पर दूसरी languages की तुलना में क्या फायदे और नुकसान हैं, यह जानना चाहूँगा। खासकर performance, safety, development speed के लिहाज से सुनना चाहूँगा
  • dynamic systems और first-class Bevy scripting संभव बनाने वाली features कब देखने को मिलेंगी?
    scripting plugins कुछ हैं और अभी लगता है कि focus मुख्य रूप से rhai पर है, लेकिन proper Bevy support की कमी से चीजें अटकी हुई लगती हैं
    Bevy का मौजूदा focus चाहे Rust-only games हो या नहीं, scripting की demand है, और पहले से ऐसे लोग हैं जो third-party solutions खोजने में लगे हैं। अभी official Bevy scripting की उम्मीद नहीं है, लेकिन third-party crates काम कर सकें, इसके लिए बुनियादी आधार Bevy को अपनाना चाहिए

• लेख में कहा गया है कि deferred rendering MSAA support नहीं करता, लेकिन यह बात सिर्फ naive implementation के लिए सही है
  उदाहरण के लिए pre-pass में complex pixels का stencil mask बनाया जा सकता है, और hierarchical early stencil rejection का इस्तेमाल करके complex pixels पर per-sample pass और बाकी pixels पर per-pixel pass चलाया जा सकता है। SIMD lane utilization perfect नहीं होगा
  इसके अलावा complex pixel mask को process करने वाला pass रखकर (x, y, sample) coordinate buffer इकट्ठा किया जाए, तो बाद में एक single hybrid per-pixel/per-sample compute shader pass में perfect SIMD lane utilization भी संभव है

  • दिलचस्प है। पहले मैंने इस बारे में सोचा था, लेकिन मान लिया था कि यह बहुत धीमा होगा। जानना चाहूँगा कि क्या आपको कोई ऐसा released title पता है जिसमें यह technique इस्तेमाल हुई हो

• मैं कुछ समय से Bevy से गेम बना रहा हूं। कोड भी देख सकते हैं और सवाल भी पूछ सकते हैं
  https://ant.care/
  https://github.com/MeoMix/symbiants
  अब तक की मुश्किलें ये रही हैं कि UI सिस्टम widgets आराम से बनाने के लिए बहुत ज्यादा verbose है, इसलिए मैंने egui पर स्विच किया, लेकिन लगता है कि एक साल के अंदर native Bevy पर लौट जाऊंगा। egui में भी बड़ी सीमाएं हैं
  parent/child relation के लिए support बहुत ज्यादा नहीं है, और ECS की संरचना कुछ हद तक इससे बचने वाली है। sprite पर label लगाना, फिर sprite को move/rotate करते हुए label को सिर्फ position follow करवाना और rotation follow न करवाना उम्मीद से ज्यादा कठिन था
  sessions के बीच entity persistence default रूप से supported नहीं है। Entity client-side uniqueness के लिए है, और saved parent/child relation को आसानी से recreate करना भी अपने-आप नहीं होता
  अभी WASM parallelism support नहीं है, लेकिन Bevy architecture में बहुत-सी design choices ऐसी हैं जो system order को flexible रखती हैं ताकि task parallelization से performance gain मिल सके
  spatial queries ECS के goals से टकराती हुई लगती हैं। type के आधार पर, यानी entity के पास Position है या नहीं, इससे खोजने के बजाय जब Position value से खोजना चाहें, तो query engine के साथ sync रखने वाले कई auxiliary caches बन जाते हैं
  commands से world बदलने पर performance के लिए batch processing हो सके, इसलिए बदलाव defer होते हैं; लेकिन deferred behavior ज्यादा हो तो world को actively बदलने वाला system बनाना मुश्किल हो जाता है। इसलिए apply_deferred को बार-बार call करना पड़ता है, और race conditions सुलझाने के लिए custom commands इस्तेमाल करने पड़ते हैं
  Android पर WASM, खासकर Pixel 6 और Chrome combination, फिलहाल काम नहीं करता, लेकिन यह lower dependency issue है, इसलिए Bevy 13 में ठीक होने की उम्मीद है
  अच्छी बात यह है कि Rust engine और Rust game का combination काम करने में बहुत अच्छा है, और Rust+WASM में भी शायद ही कभी लगता है कि technology अड़चन बन रही है। जब दिमाग ECS तरीके से सोचना शुरू कर देता है, तो वापस जाना मुश्किल होता है और यह बेहद flexible है। शायद थोड़ा जरूरत से ज्यादा flexible भी
  community active है, इसलिए समस्याओं पर बात करने के लिए लोग मिलना आसान है, और documentation ज्यादा नहीं है, लेकिन examples बहुत हैं। भविष्य को लेकर optimism भी बड़ा है; development speed तेज है और हर release में प्रमुख चिंताओं पर काफी progress होती है

  • संदर्भ के लिए, ant.care iPhone पर काम नहीं करता। Safari और Firefox दोनों में test किया, लेकिन website थोड़ी देर बाद infinite loop में reload होने लगती है

• release notes शानदार हैं
  अनुभवी game/engine developers के लिए कुछ हिस्से बहुत basic लग सकते हैं, लेकिन उस दुनिया में हमेशा रहने वाला व्यक्ति न होने के नाते, बदलावों की व्याख्या और topic explanation के बीच balance बहुत अच्छा लगा

• मैंने एक joke देखा था कि Rust में लिखे गए games 5 हैं, लेकिन game engines 50 हैं
  क्या सच में Bevy में लिखे games की list है?

  • काफी सारे हैं
    Tiny Glade (https://pouncelight.games/tiny-glade) बहुत popular है और social media पर भी काफी दिखता है। यह Bevy ECS / Bevy App और custom renderer इस्तेमाल करता है। https://store.steampowered.com/app/2198150/Tiny_Glade/
    tunnet (https://puzzled-squid.itch.io/tunnet), Noumenal (https://noumenal.app/), Foresight Mining (https://www.foresightmining.com/) भी हैं। Foresight Mining mining “CAD” software है और कई Bevy developers को employ करता है
    Axie Infinity: Homeland (https://app.axieinfinity.com/games/homeland-alpha/) Bevy ECS और Unity इस्तेमाल करता है। Shifting Chamber (https://maciekglowka.itch.io/shifting-chamber), Hytopia (https://hytopia.com/) भी हैं
    Titleless Comfy City Builder (https://twitter.com/i_am_feenster/status/1710714877231186323), Molecoole (https://store.steampowered.com/app/1792170/Molecoole/), Titleless industrial revolution builder (https://twitter.com/ElmoSampedro/status/1684920884811698176) भी हैं
    Jarl Game (https://twitter.com/jarl_game) Dwarf Fortress जैसा game है, जिसमें शानदार dynamic lighting है
    itch.io के “bevy” tag में सैकड़ों games हैं: https://itch.io/games/tag-bevy
    Bevy Discord के #showcase channel में भी काफी activity है

• हर framework शुरुआत में दावा करता है कि वह किसी ज़्यादा पारंपरिक चीज़ को सरल, साफ़ और तेज़ तरीके से लागू करेगा, लेकिन उसमें चमकदार features कम होते हैं
  फिर features की बराबरी करते-करते वह भी उतना ही जटिल monster बन जाता है, और यह cycle दोहराती रहती है

  • Software project lifecycle को बड़े स्तर पर देखें तो यह बात सही है, लेकिन software की simplicity या ease of use पर किए गए किसी भी दावे पर इसे वैसे ही लागू किया जा सकता है, इसलिए यह कोई खास उपयोगी आलोचना नहीं लगती
    निष्कर्ष ऐसा सुनाई देता है जैसे “features जोड़ने वाला हर आसान software बर्बाद होने के लिए बना है”, जो थोड़ा dramatic है
    Bevy की architecture या features जोड़ने के तरीके को लेकर आपके कोई ठोस विचार या चिंताएँ हैं क्या, यह जानना चाहूँगा। हम ऐसी नियति से बचने की पूरी कोशिश कर रहे हैं
  • मैं असहमत तो नहीं हूँ, लेकिन Bevy में एक ताकत है जो ज़्यादातर frameworks में नहीं होती: modularity। यह सिर्फ़ concept नहीं, बल्कि असल में अच्छी तरह काम करने वाली साबित हुई modularity है
    Tiny Glade bevy_ecs इस्तेमाल करता है, लेकिन Bevy के rendering crates बिल्कुल इस्तेमाल नहीं करता। निजी तौर पर भी मेरे कुछ PRs हैं जिनमें वैकल्पिक rendering paths लागू करने का काम है, जैसे ray tracing या GPU-driven meshlet + visibility buffer rendering, और Bevy internals में लगभग कोई बदलाव नहीं होता
    User के नज़रिए से भी बहुत कुछ नहीं बदलता। app में FeatureFooPlugin जोड़ें और FooComponent जैसी चीज़ इस्तेमाल करें, तो यह काम करता है
    अलग-अलग crates या plugins bloated हो सकते हैं, लेकिन पूरा Bevy ठीक रहेगा। user ऐसे plugins को ignore करके अपने लिए बेहतर suited कोई और चीज़ इस्तेमाल कर सकते हैं
    साथ ही, यह एक game engine है। परिभाषा के हिसाब से यह bloated और जटिल monster होता है, और किसी game में उपयोगी हो सकता है इसलिए हर तरह के features अपने अंदर ले लेता है। मुख्य बात यह है कि feature bloat usability को कैसे प्रभावित करता है। अगर 1000 features हों लेकिन उनमें से ज़्यादातर से interact करने की ज़रूरत न पड़े, तो यह बिल्कुल ठीक है
  • मेरे हिसाब से असली मुद्दा यह है कि project API को सरल, साफ़ और तेज़ बनाए रखने के लिए अतीत से नाता तोड़ने को तैयार है या नहीं
    यह सही है कि नए projects के लिए यह आसान होता है, जिन्हें backward compatibility की चिंता नहीं करनी पड़ती। मैंने Bevy में जो देखा है, उसमें user experience अच्छा रखने और API surface घटाने की culture काफी मजबूत है। शायद यह Rust packaging की वजह से भी हो सकता है, लेकिन इसके लिए पुराने तरीकों से टूटने में यह काफी सक्रिय है, जो मुझे अच्छी बात लगती है
    cargo की अच्छी बात यह है कि अगर आप Bevy पर depend करने का फैसला करते हैं, तो future version टूट भी जाए तो आपको moving target का पीछा करने की ज़रूरत नहीं। आप बस अपने version पर रह सकते हैं। फिर भी latest पर migrate करना आसान हो, इसके लिए guides भी मिलती हैं। कम से कम Bevy को थोड़ा इस्तेमाल करने का मेरा अनुभव ऐसा ही रहा है

• 0.10 से 0.11 पर upgrade करते समय app में काफी बदलाव चाहिए थे, लेकिन इस बार सीधे compile हो गया

• Bevy खासकर बड़े projects में मेरे पसंदीदा game engines में से एक है। Asset V2 preprocessing और .meta files बहुत उपयोगी लगती हैं
  future releases में lightmap support का भी इंतज़ार है

• Web examples देखते हुए UI section देखा, और लगता है सब कुछ canvas के अंदर ही handle होता है
  क्या UI को इसकी जगह DOM से बनाकर WASM से जोड़ा जा सकता है?

  • यह संभव है, और मैंने असल में ऐसे cases देखे हैं। UI और Bevy के बीच information भेजने-लेने का तरीका बनाना पड़ेगा
    Rust, यानी WASM side पर web_sys जैसे तरीके हैं, और JavaScript side पर WASM functions call करने के तरीके भी हैं, इसलिए options काफी हैं