शुद्ध WASM में चलने वाला Unity-स्टाइल गेम एडिटर

• Macromedia/Adobe Flash के पुराने अनुभव को फिर से जीवित करने का लक्ष्य रखने वाला हल्का गेम इंजन
• सभी प्लेटफ़ॉर्म पर चलने के लिए डिज़ाइन किया गया, और इसका एकमात्र आउटपुट लक्ष्य शुद्ध WASM है
• आउटपुट में executable या glue code आदि शामिल नहीं होते, और Emscripten का उपयोग नहीं किया गया है
• import और export की सूची PlatformCommunication.hpp में स्पष्ट रूप से परिभाषित है
• ऐसा ढांचा जिसे ब्राउज़र सहित किसी भी प्लेटफ़ॉर्म पर आसानी से लागू किया जा सकता है

---

अवलोकन

• हल्का (light-weight) गेम इंजन, जिसका लक्ष्य पुराने Macromedia/Adobe Flash अनुभव को फिर से बनाना है

आर्किटेक्चर

• इसे किसी भी प्लेटफ़ॉर्म पर चलने के लिए बनाया गया है, और इसका एकमात्र आउटपुट लक्ष्य शुद्ध WASM है
• आउटपुट में executable, glue code आदि शामिल नहीं होते, और Emscripten का उपयोग नहीं करता
• import और export की सूची PlatformCommunication.hpp में साफ़-सुथरे ढंग से परिभाषित है, इसलिए ब्राउज़र सहित किसी भी प्लेटफ़ॉर्म पर इसे आसानी से लागू किया जा सकता है

• Repo : https://github.com/raverie-us/raverie-engine

[GN⁺]

Hacker News टिप्पणियां

• वाह, ये तो Zero Engine बनाने वाले लोग हैं? बहुत पहले DigiPen के समर कैंप में इसे इस्तेमाल किया था, और Zilch में प्रोग्रामिंग करना वाकई मजेदार था
  मैंने Galaga क्लोन खेलने वाला AI भी बनाया था। इस Unity वाली घटना के बाद सोच रहा था कि Zero का क्या हुआ, लेकिन लगता है यह फिर से वापस आएगा, इसलिए सच में उत्साहित हूं

  • बढ़िया! Zilch वह चीज थी जिसे मैं बड़े प्यार से बना रहा था, इसलिए ऐसा सुनकर सच में बहुत खुशी हुई :D

• संदर्भ के लिए एक बात और जोड़ दूं: इंटीग्रेटेड ग्राफिक्स वाले एक पक्के तौर पर लो-एंड लैपटॉप पर यह एक और शानदार स्लाइडशो की तरह चलता है
  पुराने Mate 20 Pro पर भी आजमाया, लेकिन यह “Downloading runtime” पर अटका हुआ दिखा। लगा कि शायद अस्थिर 4G की वजह नहीं है, तो USB से लैपटॉप पर chrome://inspect खोलकर टैब देखा, और Uncaught (in promise) Error: Needs OES_texture_float_linear to function एरर आया। वैसे यह एक दार्शनिक सवाल बन जाता है कि सिर्फ यह बताने के लिए एरर स्क्रीन बनाना वाकई जरूरी है या नहीं कि आप इससे वैसे भी खेल नहीं पाएंगे

  • https://github.com/evanw/OES_texture_float_linear-polyfill
  • कितना लो-एंड? मैं 8 साल पुराने Surface Pro 4 पर Starbucks Wi-Fi के साथ इस्तेमाल कर रहा हूं, फिर भी यह बहुत तेज चलता है

• कॉन्सेप्ट पसंद आया। लेकिन मेरी GPU और ब्राउजर latency की वजह से रो रहे हैं, और यह किसी प्रभावशाली स्लाइडशो जैसा दिख रहा है
  कुछ कोशिशों के बाद आखिरकार शुरुआती गोले को चुन पाया। शुरू में तो यह भी पक्का नहीं था कि loading खत्म हुई है या नहीं। हालांकि मैं Firefox पर 1.8GHz Celeron, इंटीग्रेटेड GPU और 8GB RAM इस्तेमाल कर रहा हूं, इसलिए हाई-एंड से तो काफी दूर है

  • सोच रहा हूं Chrome में यह कुछ बेहतर चलता है या नहीं। लगता है काफी लोग Firefox issues झेल रहे हैं। आगे से Firefox पर भी नियमित रूप से टेस्ट करूंगा
  • अगर आप दोबारा कोशिश कर सकें, तो अभी-अभी एक fix deploy हुआ है जो कुछ machines पर performance को काफी बेहतर करता है
    क्योंकि यह native game engine को WASM में port किया गया है, समस्या framerate limiting code में थी जो browser timing API के साथ ठीक से मेल नहीं खा रहा था: https://raverie-us.github.io/raverie-engine/
  • M2 Pro पर भी मेरा बिल्कुल यही अनुभव था, और मैं भी Firefox पर था
  • वे अभी भी Celeron बनाते हैं?

• “हमारे engine में Spaces नाम का एक unique feature था, जिससे अलग-अलग worlds/levels को instantiate किया जा सकता था” वाला हिस्सा मुझे तो Godot engine के काम जैसा ही दिखता है[1]
  उस engine का भी browser (WASM) target है। [1]: https://godotengine.org/

  • WASM target ही नहीं, इसका web version भी है: https://editor.godotengine.org/
    लगता है project में इसकी priority ज्यादा नहीं है। थोड़ा test किया तो चलता तो दिखा :), लेकिन native execution से धीमा है
  • यह Unity के scenes से कैसे अलग है, यह भी मुझे ज्यादा समझ नहीं आया

• सोच रहा हूं कि क्या कोई ऐसा WASM development flow है जो browser के Web API और pure WASM को JS layer के बिना, या कम cost पर, interact करने दे
  कभी-कभी https://github.com/WebAssembly/proposals देखता हूं, लेकिन बहुत confusing लगता है। type imports proposal अभी कई साल दूर लगता है, और लगभग पूरा हो चुका GC proposal GC languages के लिए है, browser↔WASM के लिए नहीं लगता। component model browser use case से दूर लगता है, और JS String Builtins JS strings को तेज करता है, DOM को नहीं। ECMAScript module integration WASM modules को ES modules में बदलता है, लेकिन Web API ES modules नहीं है, इसलिए मदद नहीं करता। Contributors की बातचीत देखने पर कभी-कभी लगता है कि ऐसी functionality देना उनकी priority में भी नहीं है और plan में भी नहीं, और ज्यादातर लोगों के लिए cloud/crypto जैसे uses के लिए WASI और component model ज्यादा important लगते हैं

  • मैं भी यही सच में चाहता हूं। page बस WASM हो, और “browser” WASI की तरह platform imports देने वाला pure wasm browser हो
    हालांकि जैसा आपने कहा, यह उनकी priority नहीं लगता। उम्मीद है कभी न कभी संभव होगा
  • reference types की वजह से technically browser APIs को सीधे call करना पहले से संभव है। क्योंकि WASM JavaScript objects को pass कर और receive कर सकता है
    अगर आप सभी relevant Web APIs import कर लें, तो individual API calls के बीच JS objects को वैसे ही pass कर सकते हैं, इसलिए बीच वाला JS लगभग unnecessary हो सकता है। असल में JS की जरूरत बस शुरुआती WASM module initialize करते समय पड़ती है
  • pure WASM की समस्या यह है कि यह unblockable ads वाले बंद web की ओर ले जा सकता है
  • कम से कम कुछ हद तक मुझे लगता है कि GC proposal उसी दिशा में जा रहा है

• शानदार project है। high-resolution display पर UI को scale करने का कोई तरीका है?
  2:1 display पर fonts में jagged edges दिखते हैं। browser zoom को 50% पर set करने से UI sharp हो जाता है, लेकिन सब कुछ बहुत छोटा हो जाता है और इस्तेमाल करना मुश्किल हो जाता है

  • OP के लिए: इसे fix करने का तरीका है canvas width को window.innerWidth * window.devicePixelRatio, और height को window.innerHeight * window.devicePixelRatio पर set करना
    उसके बाद CSS से canvas को screen पर maximize कर दें
  • समझ नहीं आता कि UI के लिए browser native rendering engine का इस्तेमाल क्यों नहीं किया, कम से कम SVG ही क्यों नहीं
    resources (memory, network, CPU) के लिहाज से यह सस्ता होता, accessibility support आसान होता, और rendering भी आसान होती

• Trevor! DigiPen में grammar के जरिए programming language design पढ़ाने वाला CS elective मुझे बहुत पसंद था
  जिन students को आपने पढ़ाया था, उनमें से काफी अब Minecraft पर काम कर रहे हैं। अभी Minecraft scripting API design करते हुए, मैं तब सीखी basics और DigiPen के समय की बहुत-सी चीजों का इस्तेमाल कर रहा हूं। आपको अब भी शानदार काम करते देखकर अच्छा लगा

  • यह सुनकर बहुत खुशी हुई कि वह काम आया! किसी दिन फिर से teaching करूंगा ;)
    जिस scripting interface पर आप काम कर रहे हैं, उसे जरूर देखना चाहूंगा। मैंने पहले Minecraft mods बहुत बनाए थे, और हमेशा किसी न किसी form की dynamic scripting चाहता था

• सच में शानदार। इस क्षेत्र में pure WASM based product देखकर अच्छा लगा। हालांकि मेरे M1 Mac Pro पर यह काफी हकलाता है

• एक सवाल है: क्या यह NES पर भी चलेगा? refurbished front-loading model है और parts ज्यादातर original हैं, लेकिन मैंने थोड़ी और RAM जोड़ दी है
  ऊपर glue gun से चिपकाई है, और case को लाल रंग से paint करके उस पर कुछ toy soldiers भी लगा दिए हैं

  • WASM > NES converter बनाना सच में मजेदार क्यों लग रहा है…

• सिर्फ default ball scene खोलने पर भी Radeon Pro 560X और लगभग 4K setup में GPU पर बहुत जोर पड़ रहा है
  camera rotate करने भर से framerate बहुत कम हो जाता है। किसी को पता है कि WebGL optimization issue हो सकता है?

  • मेरे Intel HD Graphics 620 पर यह बहुत smooth चलता है। 7th-gen Intel integrated graphics है, यानी पुराना और धीमा ही है, फिर भी default ball scene देखते समय system पर यह बहुत smooth था, देखकर हैरानी हुई। मैं Chrome इस्तेमाल कर रहा हूं
  • अगर आप दोबारा कोशिश कर सकें, तो अभी-अभी एक fix deploy हुआ है जो कुछ machines पर performance को काफी बेहतर करता है
    क्योंकि यह native game engine को WASM में port किया गया है, समस्या framerate limiting code में थी जो browser timing API के साथ ठीक से मेल नहीं खा रहा था: https://raverie-us.github.io/raverie-engine/
  • सुनने में ऐसा भी लग रहा है कि dedicated graphics card इस्तेमाल नहीं हो रहा। बाकी WebGL demos ठीक चल रहे हैं?