WebRTC पर MMO

हर प्रोग्रामर जो अपने स्वयं के MMORPG को बहुत जल्दी लिखता है, एक आम समस्या का सामना करता है । क्लाइंट-सर्वर गेम में नेटवर्क को व्यवस्थित करने का सबसे पैदल रास्ता एक सितारा है, जहां केंद्रीय नोड सर्वर है, और शीट क्लाइंट हैं।



इस तरह के एक संगठन के अपने निर्विवाद फायदे हैं, उदाहरण के लिए, सर्वर पर क्लाइंट के गेम स्टेट्स का सिंक्रनाइज़ेशन, कार्यान्वयन में आसानी और उपयोगकर्ता के लिए लगभग तय देरी। जहां प्लसस होते हैं, आमतौर पर मिनस रहते हैं - यह सर्वर की सीमित बैंडविड्थ है और इसके बजाय बड़े विलंब यदि क्लाइंट आपके सर्वर से दूर है। उनके साथ कैसे व्यवहार करें ब्लॉग पर विस्तृत रूप से लिखा गया है 0fps.net और अपने पसंदीदा "स्टार" में रहकर इन समस्याओं को काफी प्रभावी ढंग से हल करना संभव है - अधिक सर्वर खरीदने के लिए, लेकिन क्या होगा यदि आप एक छात्र हैं जो आप वित्त में सीमित हैं और क्षैतिज / ऊर्ध्वाधर प्रशिक्षण आपके लिए कोई विकल्प नहीं है?

MMORPG के निर्माण से निपटने नहीं है

जैसा कि आप जानते हैं, हर मजाक में एक मजाक होता है - यदि आपके पास गेम-देव कमांड का समर्थन करने के लिए पर्याप्त संसाधन नहीं हैं या आप अकेले गेम पर काम कर रहे हैं, तो अपने लक्ष्यों पर पुनर्विचार करना बेहतर है। जब मैंने ऑक्सिलियम नेटवर्क शूटर (इसमें से केडीपीवी) बनाना शुरू किया, तो मैं समझ गया कि मुझे किसी तरह से स्केलिंग की समस्या को हल करना होगा और कई नेटवर्क गेमों में उपयोग किए जाने वाले स्पष्ट समाधान गेम सत्र या "लड़ाई" की शुरूआत थी - इस मामले में, यह बहुत ही है केवल भौतिक मशीनों के बीच इन लड़ाइयों को वितरित करें और लोड को पकड़ें, लेकिन यह अब एक खुली दुनिया क्लासिक MMORPG नहीं था। इसके बाद तीन त्रुटियां हुईं, जिसके बाद खेल का विकास रुक गया:

पहली गलती यह मानने की थी कि अच्छे सर्वरों को (मेरे लिए) राशि के लिए पाया जा सकता है। नोड.जेएस पर खेल के प्रदर्शन के प्रारंभिक माप से पता चला है कि एक प्रक्रिया 20-25 लोगों के लिए खेल को बढ़ाती है। इसके बाद, सर्वर पर भौतिकी की गणना में देरी के कारण ईवेंटलूप और घातक लैग्स की उप-धारा शुरू होती है। चूंकि 350 पी। प्रति माह मुझे 250 एमबी मेमोरी के साथ एक वीपीएस मिला, फिर खेल के साथ दो से अधिक प्रक्रियाएं शुरू नहीं की जा सकीं (स्टार्टअप में प्रक्रिया ~ 100 एमबी की गई, हाँ, आप नट को कस कर सिकोड़ सकते हैं)। और वो 50 खिलाड़ी। वास्तव में नहीं है कि बड़े पैमाने पर किया था।

दूसरी गलती अकेले खेल का विकास नहीं करना था, लेकिन टीम के साथ (नौ महिलाएं प्रति माह एक बच्चे को जन्म दे सकती हैं, ठीक है?)। MMORPG बनाने के बारे में एक अच्छा लेख है - "हमने तीनों को एक साथ शुरू किया, लेकिन विकास के पहले वर्ष के अंत तक मैं अकेला रह गया।" और इसलिए यह हुआ।

खैर, तीसरी गलती यह मानना ​​था कि आप टीसीपी के साथ जुड़ सकते हैं। हमने WebSockets को एक आधार के रूप में लिया और बाइनरी JSON संपीड़न को इस उम्मीद में जोड़ा कि यह पर्याप्त है। जैसा कि बहुत से लोग जानते हैं, टीसीपी एक प्रोटोकॉल है जिसमें पैकेटों की गारंटीकृत डिलीवरी होती है, जिस क्रम में उन्हें भेजा गया था, इसलिए यदि एक पैकेट खो जाता है, तो खिलाड़ी के लिए इस पैकेट को भेजने तक कुछ समय के लिए फ्रीज हो जाएगा। सबसे बुरी बात यह है कि इसके बाद सभी पैकेट जो इसके पीछे कतार में थे, उन्हें स्क्रॉल किया जाएगा - फिर से, आप बचत में देरी (उन्हें कृत्रिम रूप से जोड़कर) की परिकल्पना कर सकते हैं, लेकिन बैसाखी के लिए गहने की बैसाखी जोड़ना (यूपीडी के बजाय टीसीपी के साथ काम करना) गलत तरीके का एक निश्चित संकेत है।

वे क्या चाहते थे और लगभग क्या हुआ (बाएं से दाएं):



लेकिन अतीत के बारे में पर्याप्त - क्या बदल गया है और रेक कहां स्थानांतरित हो गए हैं, जिसे आप फिर से कदम रखना चाहते हैं?

WebRTC और STCP

एक डेवलपर के रूप में अपनी गलतियों पर पुनर्विचार करने के बाद, मैंने एक बार फिर प्रौद्योगिकियों के क्षेत्र में कंघी करने का फैसला किया, जिसका उपयोग ब्राउज़र में MMORPG बनाने के लिए किया जा सकता है। मेरे लिए अभी भी ब्राउज़रों के भीतर रहना महत्वपूर्ण है, क्योंकि इससे कुछ भी स्थापित किए बिना प्रयोगों को चलाना बहुत आसान हो जाता है (विशेषकर चूंकि अवास्तविक इंजन 4 पहले से ही ब्राउज़र रूप में बाहर निकलने की तैयारी कर रहा है )।

जैसा कि यह पता चला, विकास के दौरान दुनिया अभी भी खड़ी नहीं हुई और वेबआरटीसी एक नया गर्म विषय बन गया - हर किसी ने स्काइप बनाना शुरू कर दिया और अपने हत्यारों को चैट करना शुरू कर दिया, लेकिन वास्तव में जिस चीज ने ध्यान आकर्षित किया वह एसटीसीपी प्रोटोकॉल में अविश्वसनीय और अव्यवस्थित वस्तुओं का इस्तेमाल किया गया - जिसका मतलब है कि समस्या नंबर तीन को हल कर दिया गया है। ! लेकिन सीमाओं के बिना नहीं।

WebRTC को काम करने के लिए, आपको एक तथाकथित सिग्नल सर्वर की आवश्यकता होती है, जो STUN सर्वर से संदेश भेजकर STCP के माध्यम से दो ब्राउज़रों के शुरुआती कनेक्शन के लिए जिम्मेदार होगा। यह NAT को बायपास करने के लिए किया गया था, और आप इस बारे में अधिक लेख "वेबरटीसी पर हमने कैसे सेवा की" और "रियलआर में वेबआरटीसी: एसटीयूएन, टीआरएन और सिग्नलिंग" पढ़ सकते हैं। अपने लिए अंतिम लेख से, मैंने सीखा कि यदि आप पैसे के लिए वेबआरटीसी सेवा प्रदान करते हैं, तो आप नरक में हैं (आपको सभी नेटवर्क से 100% काम हासिल करने की आवश्यकता है)। यह अच्छा है कि यह हमारा मामला नहीं है।

अब हमारे क्लाइंट-सर्वर गेम की वास्तुकला इस तरह दिख सकती है:



जैसा कि आप देख सकते हैं, सर्वर से क्लाइंट के लिए सभी भारी इंटरैक्शन को स्थानांतरित कर दिया गया है। यह दृष्टिकोण लुभावना है, लेकिन यह हल करने के लिए काफी गैर-तुच्छ कार्यों का परिचय देता है:

1. क्या यह पूरी तरह से जुड़े ग्राफ का उपयोग करने के लिए इष्टतम है?
2. पूरे नेटवर्क के लिए खेल की स्थिति को कैसे सिंक्रनाइज़ करें
3. बेईमान खिलाड़ियों का क्या किया जाए

यदि अंतिम दो प्रश्नों का उत्तर उस गेम मॉडल के भाग पर निर्भर करता है जिसे आप विकसित कर रहे हैं, तो पहले प्रश्न का उत्तर सामान्य मामले में दिया जा सकता है। फिर भी, हंटरकोर्ट के बारे में पढ़ना दिलचस्प है - एक परियोजना जो गेम को सिंक्रनाइज़ करने के लिए बिटकॉइन के एनालॉग का उपयोग करती है, हालांकि यह गतिशील मॉडल के लिए उपयुक्त नहीं है और सभी लेनदेन के पूर्ण सिंक्रनाइज़ेशन की आवश्यकता होती है (यदि मैं सही ढंग से समझता हूं कि बिटकॉइन कैसे काम करते हैं)। इन बिंदुओं पर बाकी चर्चा मैं अगले लेख के लिए छोड़ूंगा।

पूर्ण ग्राफ (साथ ही सर्वर के तनाव परीक्षण) के बारे में परिकल्पना का परीक्षण करने के लिए, हमें एक छोटे डेमो गेम की आवश्यकता है जो ग्राहकों के बीच विलंबता को मापने में सक्षम होगा। यदि यह पता चला है कि प्रत्यक्ष कनेक्शन हमेशा किसी अन्य क्लाइंट के माध्यम से एक संदेश भेजने की तुलना में तेज़ होता है - तो एक पूर्ण ग्राफ़, इसलिए एक पूर्ण ग्राफ़ (जिसमें मुझे संदेह है)।

MMO - माउस मल्टीप्लेयर ऑनलाइन

डेमो : mmo.jit.su (प्रयोग समाप्त हो गया है, परिणाम लेख के नीचे तय किया गया है)

लगभग एक साल पहले, दुनिया ने भीड़-खट्टा संगीत वीडियो देखा। यदि आप इसे याद करते हैं, तो यह बाधित होने और देखने का समय है (और इसके लिए कुछ है)। विचार सरल है - हम वीडियो के दौरान कर्सर आंदोलनों को रिकॉर्ड करते हैं और इसे पहले से ही संचित वाले में जोड़ते हैं। नतीजतन, हमें कर्सर से एक बहुत ही मनोरंजक वीडियो अनुक्रम मिलता है (शुरुआत में मुझे ऐसा लगता था कि सिंक्रनाइज़ेशन वास्तविक समय में हो रहा है, लेकिन नहीं)। इस क्लिप को फिर से देखने के बाद - मुझे एक डेमो गेम के लिए एक विचार मिला - हम कर्सर को स्थानांतरित करेंगे।

कार्यान्वयन के लिए, हमें सिग्नल सर्वर के साथ काम करने और ग्राहकों के बीच संबंध बनाने की सुविधा के लिए कुछ चाहिए। एक अच्छा विकल्प Peer.js है - जो एक तैयार सिग्नल सर्वर प्रदान करता है (हालांकि पुनर्स्थापना पर आधारित) और यहां तक ​​कि एक सार्वजनिक सिग्नल सर्वर भी होस्ट करता है।

सभी क्लाइंट साइड कोड जावास्क्रिप्ट की 100 लाइनों में फिट होते हैं , सर्वर साइड Node.JS और उससे भी कम - 55। मैं उन्हें लेख में लाने की बात नहीं देखता, क्योंकि वे सार्वजनिक डोमेन में हैं और लिखने के लिए काफी सरल हैं। कोड स्वयं एमआईटी लाइसेंस के तहत उपलब्ध है और मुझे आशा है कि यह शुरुआती लोगों को अपने ब्रेक-योग्य-खिलौना बनाने में मदद करता है।

परिणाम क्या है?

खेल से कुछ आंकड़े एकत्र करने के बाद, मैं अपने प्रश्न का उत्तर देने का वचन देता हूं। हालांकि अंतर्ज्ञान कहता है कि चूंकि हम एक पारंपरिक नेटवर्क बुनियादी ढांचे पर भरोसा करते हैं जो पैकेट भेजने के लिए इष्टतम रास्ता चुनना चाहते हैं, इसलिए यह पता चल सकता है कि यह पथ एक नया कनेक्शन (और नेटवर्क बड़ा) बनाने की तुलना में गेम क्लाइंट के बीच संदेश भेजने के साथ मेल खाता है। इस बारे में अधिक निश्चितता)। इसलिए, प्रसारण डुप्लिकेट पैकेट होगा, लेकिन आंकड़े दिखाएंगे।

परिणाम

जाहिर है, कुछ गलत हो गया। हमारे पास कई सहकर्मी-से-सहकर्मी खिलाड़ी (बाएं-नीचे) हैं, साथ ही साथ बड़ी संख्या में प्रतिभागियों के साथ कई जुड़े घटक हैं। सबसे बड़ा घटक निचले दाईं ओर स्थित है और यह स्पष्ट रूप से एक पूर्ण ग्राफ़ नहीं है।

ऐसा क्यों हुआ? Peer.js में पहचानकर्ताओं के वितरण को लागू करने में विषमताएं हो सकती हैं, क्योंकि Math.random का उपयोग वहाँ किया जाता है - हालांकि यह 2300 नोड्स के लिए संभावना नहीं है । सबसे अधिक संभावना है कि ये WebRTC प्रोटोकॉल की विशेषताएं हैं - यह स्पष्ट है कि आप अनंत संख्या में कनेक्शन नहीं ले सकते ।

प्रयोग के दौरान यह देखा गया (शायद केवल मेरे लिए) एक ही समय में 5-10 कर्सर चल रहे थे, जो एक बड़े नेटवर्क को सिंक्रनाइज़ करने के लिए पूर्ण ग्राफ़ का उपयोग करने की क्षमता को काट देता है। प्रसारण के माध्यम से यह कैसे करें - यह एक अलग लेख के लिए सामग्री है (यदि लेखों की एक श्रृंखला नहीं है)। भाग लेने के लिए आप सभी को धन्यवाद!