2 पॉइंट द्वारा GN⁺ 2023-12-22 | 1 टिप्पणियां | WhatsApp पर शेयर करें

Moddio game engine 2

  • Moddio एक multiplayer-first game engine है।
  • इसमें server-authoritative network code, snapshot interpolation, और client-side reconciliation built-in हैं।
  • यह 5 डॉलर प्रति माह वाले VM पर 50 से अधिक concurrent players या 300 से अधिक moving objects को support करता है।

Demo

  • बॉक्स में शामिल: Box2D physics engine, server-authoritative network code, inventory और item system, built-in attributes (HP, energy आदि) और regeneration rates, dialogue system, shop, unit control, client-side predicted projectiles और unit movement, unit AI और A* pathfinding, mobile controls आदि।

Game चलाने का तरीका

  • Node 18 या उससे ऊपर चाहिए।
  • repository सेटअप करने के बाद, /src directory में जाएँ, game-sample.json का नाम बदलकर game.json करें, फिर root directory में लौटकर server चलाएँ।
  • अब आप http://localhost:80 पर game खेल सकते हैं।

शुरुआत से नया game बनाने का तरीका

  • Moddio games, https://www.modd.io पर उपलब्ध Moddio game editor का उपयोग करके बनाए और संपादित किए जाते हैं।
  • game बनाने के बाद, आप local installation में उपयोग के लिए game.json export कर सकते हैं।
  • exported game JSON का नाम बदलकर game.json करें और उसे ./src directory में ले जाएँ।

योगदान कैसे करें

  • Moddio MIT license के तहत पूरी तरह free और open source है।
  • contributor बनने का तरीका जानने के लिए contribution page पर जाएँ।

Credits

  • Isogenic game engine, Phaser, PlanckJS, uWebsocket, Box2D, Kenney assets, Hero Icons आदि का उपयोग किया गया है।

GN⁺ की राय

  • Moddio game engine multiplayer game development के लिए खास तौर पर बनाया गया है और कम लागत पर बहुत से players को support करने वाली मजबूत क्षमताएँ देता है।
  • यह open source है और community contributions के ज़रिए लगातार बेहतर हो रहा है, इसलिए शुरुआती software engineers के लिए भी इसकी पहुँच अच्छी है।
  • game development के लिए ज़रूरी कई features built-in हैं, जिससे developers तेज़ी से prototype बनाकर उनका test कर सकते हैं।

1 टिप्पणियां

 
GN⁺ 2023-12-22
Hacker News की राय
  • Android ऐप के साइन-अप स्क्रीन पर Google username और password को ऐप के अंदर वेब फॉर्म जैसा दिखने वाली जगह में डालने को कहा जाता है, और यूज़र के पास यह जानने का कोई तरीका नहीं कि ऐप password झांक तो नहीं रहा
    आम तौर पर लगता है कि ऐप login screen पर भेजकर फिर वापस आने वाला flow इस्तेमाल करते हैं, इसलिए उत्सुकता है कि वह pattern implement करना मुश्किल है क्या। यह cross-platform support की वजह से होने वाली समस्या है क्या, यह भी जानना चाहूंगा

    • सिद्धांत रूप में यह बहुत मुश्किल काम नहीं है। कार manufacturers के साथ काम करते हुए यूज़र को OEM account से login कराना पड़ता है, और theory में सब compliant होता है, लेकिन असल में बहुत-सी चीज़ें काम नहीं करतीं और उन्हें ठीक करने में भी लंबा समय लगता है
      हालांकि ऊपर बताया गया तरीका सच में कभी नहीं होना चाहिए, और मुझे लगा था Google ने इसे पहले ही ban कर दिया है
    • इसे OAuth 2.0 कहते हैं, और Okta जैसी चीज़ इस्तेमाल करें तो implement करना आसान है
  • यूज़र्स से कोई game engine अपनवाना कभी आसान नहीं होता, और खासकर अगर वह closed source हो तो और मुश्किल होता है
    साइट पर मौजूद games gallery देखें तो लगता है अब तक काफी अच्छा किया है, लेकिन उत्सुकता है कि ये कुछ दोस्तों ने बनाए हैं या काफी active community है

    • अच्छे features, सीखने में आसानी, और कम entry barrier का combination काफी आगे जा सकता है
      ऐसे structure की कल्पना करें जिसमें casually कुछ दिन या कुछ घंटे लगाने पर भी meaningful result निकल आए। Flash को याद कर सकते हैं
    • active community है और रोज़ 150–300 नए games बना रही है
      game developers और players दोनों के लिए entry barrier कम होना निश्चित रूप से मदद करता है। download या signup की ज़रूरत नहीं
  • सिर्फ title देखकर मुझे अंदाज़ा नहीं था कि यह modd.io होगा। यह IO games बनाने में इस्तेमाल होने वाला popular framework/platform है

    • मैं काफी games खेलता हूं और पहले बेच भी चुका हूं, लेकिन यह term कभी नहीं सुना। IO game क्या होता है?
  • Brains server में से एक पर जाकर देखना चाहता था कि करीब 50 players का experience कैसा है। WebSocket से जैसी उम्मीद होती है, movement थोड़ा झटकेदार था, और क्योंकि मैं भी कुछ वैसा बना रहा हूं, network compression को लेकर भी उत्सुक था
    सिर्फ LZ-string compression काफी है या नहीं, मुझे ठीक से नहीं पता। 50 players पर यह लगभग 20KB प्रति सेकंड इस्तेमाल करता है, जबकि Warzone 150 players पर सिर्फ करीब 48KB प्रति सेकंड इस्तेमाल करता है। अगर unlimited data नहीं है तो cloud bandwidth cost काफी हो सकती है
    compressed byte buffer का 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼 जैसा दिखना भी दिलचस्प था। पता नहीं LZ-string compression का result आम तौर पर ऐसा ही होता है या नहीं, लेकिन यह काफी अनजान-सा दिखता है
    बहरहाल, potential cost घटाने के लिए networking side में सुधार की काफी गुंजाइश है। पूरा project बहुत impressive और अच्छी तरह बनाया गया काम है

    • हमारे WebSocket में movement काफी tight है: https://gooberdash.winterpixel.io/
      core चीज़ client-side prediction और rollback networking algorithm है। हमारा game state 30Hz पर करीब 1KB है, इसलिए आम तौर पर single packet में फिट हो जाता है, और इस वजह से WebSocket भी बहुत बुरा नहीं है। हां, unreliable protocol बेहतर तो होगा ही
    • “WebSocket से जैसी उम्मीद होती है, movement थोड़ा झटकेदार था” वाले हिस्से को थोड़ा और समझा सकते हैं? मैंने कुछ “IO games” खेले हैं और कभी-कभी बहुत high latency वाले players को छोड़कर वे काफी smooth दिखे
      कुछ महीने पहले WebSockets को थोड़ा test किया था, और मेरी समझ के मुताबिक games जैसी latency-sensitive communication में TCP इस्तेमाल करने के काफी नुकसान हैं। TCP header UDP से 2 गुना से भी बड़ा होता है, extra control packets होते हैं, और old data retransmit होने के दौरान new data भेजना delay हो जाता है। WebSockets भी TCP के ऊपर चलते हैं, इसलिए उनमें भी वही कमियां हैं
      फिर भी लोग कहते हैं कि TCP WebSocket messages की delivery guarantee करता है, लेकिन मैं packet loss reproduce कर पाया था। आखिरकार नुकसान वैसे ही रहते हैं, और अगर सच में guaranteed delivery चाहिए तो उसके ऊपर खुद कुछ बनाना पड़ेगा; ऐसे में शायद शुरुआत से ही UDP के ऊपर सिर्फ ज़रूरी messages के लिए वैसा बना सकते थे
      networking के बारे में मैंने थोड़ा छेड़छाड़ करने के अलावा ज्ञान और अनुभव बहुत कम है, इसलिए उसी हिसाब से पढ़ें
    • CJK characters printable Unicode characters का बहुत बड़ा हिस्सा हैं। [1] दो सबसे बड़े blocks में U+3400~U+4DBF, U+4E00~U+9FFF शामिल हैं
      वह string \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c के रूप में decode होती है
      [1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs
  • game को कभी पूरा न कर पाने का पक्का तरीका है engine लिखने से शुरुआत करना
    अपनी technology बनाना बिल्कुल संभव है, लेकिन हर step पर वह technology general-purpose game platform नहीं, बल्कि आपके अपने project के हिसाब से tuned होनी चाहिए

    • मुझे blog शुरू करना चाहिए!
      यहां “blog शुरू करना” का मतलब है बिल्कुल scratch से नया blog engine बनाना
    • क्या आप थोड़ा और समझा सकते हैं कि modd.io के किस हिस्से की बात कर रहे हैं? क्या मतलब है कि यह game बनाने की कोशिश में fail होने का result है?
    • engine इस्तेमाल करने वाले ज्यादातर लोग शायद शुरुआत से game बनाना चाहते ही नहीं; असल में वे engine बनाना चाहते हैं
  • Node.js आधारित multiplayer backend में मैंने देखा है कि connections की संख्या बढ़ने पर वे आखिरकार रेंगने जितने धीमे हो जाते हैं। जानना चाहूंगा कि आपने इस समस्या को कैसे हल किया
    ऐसे मामलों में Go जैसा विकल्प बेहतर नहीं होगा?

    • मुझे ठीक से समझ नहीं आ रहा कि ऐसा क्यों होगा। connections के लिहाज़ से, Node के event loop की वजह से HTTP request/response वाले input/output blocking की समस्या नहीं होनी चाहिए
      backend शायद frontend के लिए physics calculations जैसे भारी काम भी नहीं कर रहा होगा
    • uWebSockets(https://github.com/uNetworking/uWebSockets) इस्तेमाल करता हूँ। यह C में लिखा है, लेकिन NodeJS में इस्तेमाल करने के लिए interface मौजूद है
      आसान tests में इसका performance दूसरे लोकप्रिय websocket libraries से कहीं बेहतर था, जो जल्दी धीमी पड़ जाती थीं
    • ज़्यादातर IO games में bottleneck input/output ही होगा। genre का नाम top-level domain से आया है, लेकिन यह wordplay जैसा भी लगता है
      इसलिए Node एक अच्छा चुनाव लगता है
    • Scalability, खासकर बहुत ज़्यादा connections होने पर, सचमुच विचार करने वाली बात हो सकती है। हमारे मामले में हमने backend को optimize करके काफी बड़ी संख्या में concurrent connections को efficiently handle करने लायक बनाया
      हर game अधिकतम 64 players तक सीमित है, लेकिन 100 से ज़्यादा connections तक test करने पर performance issue नहीं दिखा। हर game अलग-थलग container में चलता है
  • नया engine बनाने की motivation जानना चाहूंगा
    README देखने पर weapon system (melee/projectile), shop, client-side prediction projectile और unit movement जैसी काफी specific चीज़ें built-in हैं
    जानना चाहूंगा कि इन्हें engine में ही क्यों bake किया गया, copy किए जा सकने वाले plugins क्यों नहीं बनाया गया। बेशक कई games को इन features की ज़रूरत नहीं होती—तो क्या यह game engine है? या FPS/RPG/किसी और specific genre के लिए engine है?
    technology से मुझे कोई दिक्कत नहीं, लेकिन फिर भी “क्यों?” वाला सवाल रहता है। यह किसलिए है? Three.js और अपने server की जगह इसे क्यों इस्तेमाल करें?

    • सवाल के लिए धन्यवाद। हमने जानबूझकर engine को दूसरे modular alternatives की तुलना में ज़्यादा opinionated structure वाला बनाने का फैसला किया। वजह यह है कि हम 2D multiplayer games को बेहद तेज़ी से develop करना चाहते हैं
      उदाहरण के लिए, हमने 2 घंटे में एक simple MMORPG बनाया: https://www.youtube.com/watch?v=GZVsxkALR5U
      मुझे लगता है कि ease of use और customization level के बीच उल्टा संबंध होता है। Multiplayer games बनाना मुश्किल माना जाता है, और casual game developers के बीच की खाई कम करने के लिए हमने पहले वाले को चुना
    • “यह किसलिए है?”
      लगता है यह आपके लिए नहीं है, बल्कि उन लोगों के लिए है जो ऐसे specific games बनाना चाहते हैं। हर engine का general-purpose होना ज़रूरी नहीं
  • मेरे कुछ hobby projects थे जिनके लिए यह काफी fit लगता। coding कर सकता हूँ, लेकिन hobby project करते समय कभी-कभी उतना focus नहीं करना चाहता, इसलिए low-code और interactive editor hobby developers के लिए अच्छे लगते हैं
    निजी तौर पर मुझे सबसे ज़्यादा उत्साह maps और world generation को लेकर है। game को JSON में export करना, programmatically modify करना और फिर वापस import करना सबसे अच्छा तरीका लगता है—क्या यह सही है, जानना चाहूंगा
    हालांकि यह थोड़ा भारी भी लगता है। बिना modify किया tutorial world ही JSON की 3500 lines है, इसलिए समझने के लिए बहुत कुछ है
    पहला तरीका जो दिमाग में आया, वह है जानबूझकर editing करके देखना कि JSON कैसे बदलता है। कोई अच्छा JSON diff viewer भी ढूंढना होगा। इससे जिन हिस्सों को छूना है, उन्हें ढूंढने में मदद मिल सकती है। assets और map tiles शायद interactive editor में ही इकट्ठा करूंगा
    जानना चाहूंगा कि यह approach reasonable है या नहीं, और क्या कोई helpful tools हैं

    • JSON को सीधे edit करने की सलाह नहीं दूंगा। यह काफी पढ़ने में कठिन और bloated है। modd.io में maps को सीधे modify करने के लिए actions मौजूद हैं
      हमारी community के एक creator ChatGPT से dynamically maps generate कर रहे हैं। वे hide-and-seek game बना रहे हैं, जिसमें वे 2D map JSON generate करने के लिए prompt भेजते हैं और हर नए round की शुरुआत पर उस map को load करते हैं। अभी public नहीं किया है, इसलिए game share करना मुश्किल है
      साथ ही community के एक member हमारे game JSON के लिए interpreter बना रहे हैं। उदाहरण: https://pypi.org/project/pymodd/
  • ऐसे और open-source projects सामने आते देखना अच्छा लग रहा है। हैरानी है कि GitHub stars 100 भी नहीं हैं

    • गलत न समझें, मैं सच में जिज्ञासा से पूछ रहा हूँ। GitHub stars 100 से कम होना हैरान करने वाला क्यों है?
    • शायद इसलिए कि अभी-अभी public किया गया है