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

इस गाइड में, मैं आपके साथ उन विभिन्न अवधारणाओं को साझा करना चाहूंगा जिन्हें आपको अपना गेम इंजन लिखने से पहले सीखने की आवश्यकता है, साथ ही उन्हें सीखने के लिए सर्वोत्तम संसाधन और लेख भी।

सामान्य तौर पर, नेटवर्क आर्किटेक्चर के दो मुख्य प्रकार होते हैं: पीयर-टू-पीयर और क्लाइंट-सर्वर। पीयर-टू-पीयर (पी2पी) आर्किटेक्चर में, डेटा कनेक्टेड प्लेयर्स की किसी भी जोड़ी के बीच ट्रांसफर किया जाता है, जबकि क्लाइंट-सर्वर आर्किटेक्चर में, डेटा केवल प्लेयर्स और सर्वर के बीच ट्रांसफर किया जाता है।

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

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

गेमिंग नेटवर्क सिस्टम में तीन मुख्य घटक हैं:

• ट्रांसपोर्ट प्रोटोकॉल: क्लाइंट और सर्वर के बीच डेटा कैसे स्थानांतरित किया जाता है।
• एप्लिकेशन प्रोटोकॉल: क्लाइंट से सर्वर तक और सर्वर से क्लाइंट तक क्या प्रसारित होता है, और किस प्रारूप में।
• एप्लिकेशन तर्क: क्लाइंट और सर्वर की स्थिति को अद्यतन करने के लिए प्रेषित डेटा का उपयोग कैसे किया जाता है।

प्रत्येक भाग की भूमिका और उनसे जुड़ी कठिनाइयों को समझना बहुत महत्वपूर्ण है।

परिवहन प्रोटोकॉल

पहला कदम सर्वर और क्लाइंट के बीच डेटा ट्रांसपोर्ट करने के लिए एक प्रोटोकॉल चुनना है। इसके लिए दो इंटरनेट प्रोटोकॉल हैं: टीसीपी и यूडीपी. लेकिन आप उनमें से किसी एक के आधार पर अपना खुद का ट्रांसपोर्ट प्रोटोकॉल बना सकते हैं या किसी लाइब्रेरी का उपयोग कर सकते हैं जो उनका उपयोग करती है।

टीसीपी और यूडीपी की तुलना

टीसीपी और यूडीपी दोनों पर आधारित हैं IP. आईपी ​​एक पैकेट को एक स्रोत से रिसीवर तक प्रसारित करने की अनुमति देता है, लेकिन यह गारंटी नहीं देता है कि भेजा गया पैकेट रिसीवर तक जल्दी या बाद में पहुंचेगा, कि वह कम से कम एक बार उस तक पहुंचेगा, और पैकेट का क्रम सही क्रम में पहुंचेगा। इसके अलावा, एक पैकेट में केवल सीमित डेटा आकार हो सकता है, जो मूल्य द्वारा दिया गया है एमटीयू.

यूडीपी आईपी के ऊपर बस एक पतली परत है। इसलिए, इसकी भी वही सीमाएँ हैं। इसके विपरीत, टीसीपी में कई विशेषताएं हैं। यह त्रुटि जांच के साथ दो नोड्स के बीच एक विश्वसनीय ऑर्डर किया गया कनेक्शन प्रदान करता है। इसलिए, टीसीपी बहुत सुविधाजनक है और इसका उपयोग कई अन्य प्रोटोकॉल में किया जाता है, उदाहरण के लिए, में HTTP, FTP и एसएमटीपी. लेकिन ये सभी सुविधाएँ एक कीमत पर आती हैं: विलंब.

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

लेकिन जैसा कि आप शायद समझते हैं, मल्टीप्लेयर गेम में विलंबता बहुत महत्वपूर्ण है, खासकर एफपीएस जैसी सक्रिय शैलियों में। यही कारण है कि कई गेम अपने स्वयं के प्रोटोकॉल के साथ यूडीपी का उपयोग करते हैं।

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

तो, यदि टीसीपी बेकार है, तो हम यूडीपी पर आधारित अपना स्वयं का परिवहन प्रोटोकॉल बनाने जा रहे हैं?

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

वर्ल्ड ऑफ वॉरक्राफ्ट, माइनक्राफ्ट और टेरारिया सहित कई सफल गेम टीसीपी का उपयोग करते हैं। हालाँकि, अधिकांश FPS अपने स्वयं के UDP-आधारित प्रोटोकॉल का उपयोग करते हैं, इसलिए हम नीचे उनके बारे में अधिक बात करेंगे।

यदि आप टीसीपी का उपयोग करना चुनते हैं तो सुनिश्चित करें कि यह अक्षम है नागले का एल्गोरिदम, क्योंकि यह भेजने से पहले पैकेट को बफ़र करता है, जिसका अर्थ है कि यह विलंब को बढ़ाता है।

मल्टीप्लेयर गेम के संदर्भ में यूडीपी और टीसीपी के बीच अंतर के बारे में अधिक जानने के लिए, ग्लेन फिडलर का लेख देखें यूडीपी बनाम टीसीपी.

मालिकाना प्रोटोकॉल

तो आप अपना खुद का ट्रांसपोर्ट प्रोटोकॉल बनाना चाहते हैं लेकिन नहीं जानते कि कहां से शुरू करें? आप भाग्यशाली हैं, क्योंकि ग्लेन फिडलर ने इसके बारे में दो अद्भुत लेख लिखे हैं। उनमें आपको ढेर सारे स्मार्ट आइडिया मिलेंगे.

पहला लेख गेम प्रोग्रामर्स के लिए नेटवर्किंग 2008, दूसरे से भी आसान एक गेम नेटवर्क प्रोटोकॉल का निर्माण 2016. मेरा सुझाव है कि आप पुराने से शुरुआत करें।

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

लेकिन यदि आप नेटवर्किंग में नए हैं, तो अपने आप पर एक एहसान करें और टीसीपी या लाइब्रेरी का उपयोग करें। अपने स्वयं के परिवहन प्रोटोकॉल को सफलतापूर्वक लागू करने के लिए, आपको पहले से बहुत कुछ सीखने की आवश्यकता है।

नेटवर्क पुस्तकालय

यदि आपको टीसीपी से अधिक कुशल किसी चीज़ की आवश्यकता है, लेकिन आप अपने स्वयं के प्रोटोकॉल को लागू करने और बहुत सारे विवरणों में जाने की जहमत नहीं उठाना चाहते हैं, तो आप नेट लाइब्रेरी का उपयोग कर सकते हैं। ऐसे बहुत से हैं:

• Yojimbo ग्लेन फिडलर
• राकनेट, जो अब समर्थित नहीं है, लेकिन इसका कांटा है स्लाइकनेट सक्रिय प्रतीत होता है.
• एनेट मल्टीप्लेयर एफपीएस के लिए बनाई गई एक लाइब्रेरी है घन
• गेमनेटवर्किंग सॉकेट वाल्व द्वारा

मैंने उन सभी को आज़माया नहीं है, लेकिन मैं ENet को पसंद करता हूँ क्योंकि इसका उपयोग करना आसान और विश्वसनीय है। इसके अलावा, इसमें शुरुआती लोगों के लिए स्पष्ट दस्तावेज़ीकरण और एक ट्यूटोरियल है।

परिवहन प्रोटोकॉल निष्कर्ष

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

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

मेरे पास दो सुझाव हैं:

• जितना संभव हो सके ट्रांसपोर्ट प्रोटोकॉल को बाकी एप्लिकेशन से अलग करें ताकि सभी कोड को दोबारा लिखे बिना इसे आसानी से बदला जा सके।
• अति-अनुकूलन न करें. यदि आप नेटवर्क विशेषज्ञ नहीं हैं और सुनिश्चित नहीं हैं कि आपको अपने स्वयं के यूडीपी-आधारित परिवहन प्रोटोकॉल की आवश्यकता है, तो आप टीसीपी या विश्वसनीयता प्रदान करने वाली लाइब्रेरी से शुरुआत कर सकते हैं, और फिर प्रदर्शन का परीक्षण और माप कर सकते हैं। यदि आपको समस्या हो रही है और आप आश्वस्त हैं कि यह एक ट्रांसपोर्ट प्रोटोकॉल है, तो अब अपना खुद का ट्रांसपोर्ट प्रोटोकॉल बनाने का समय आ गया है।

इस भाग के अंत में, मेरा सुझाव है कि आप पढ़ें मल्टीप्लेयर गेम प्रोग्रामिंग का परिचय ब्रायन हुक, जिसमें यहां चर्चा किए गए कई विषयों को शामिल किया गया है।

अनुप्रयोग प्रोटोकॉल

अब जब हम क्लाइंट और सर्वर के बीच डेटा का आदान-प्रदान कर सकते हैं, तो हमें यह तय करना होगा कि कौन सा डेटा ट्रांसफर करना है और किस प्रारूप में।

क्लासिक योजना यह है कि क्लाइंट सर्वर को इनपुट या क्रियाएं भेजते हैं, और सर्वर क्लाइंट को वर्तमान गेम स्थिति भेजता है।

सर्वर पूर्ण नहीं, बल्कि फ़िल्टर की गई स्थिति को उन संस्थाओं के साथ भेजता है जो प्लेयर के पास हैं। वह ऐसा तीन कारणों से करता है. सबसे पहले, उच्च आवृत्ति पर संचारित करने के लिए कुल स्थिति बहुत बड़ी हो सकती है। दूसरे, क्लाइंट मुख्य रूप से विज़ुअल और ऑडियो डेटा में रुचि रखते हैं, क्योंकि अधिकांश गेम लॉजिक गेम सर्वर पर सिम्युलेटेड होता है। तीसरा, कुछ खेलों में खिलाड़ी को कुछ डेटा जानने की आवश्यकता नहीं होती है, जैसे कि मानचित्र के दूसरी तरफ दुश्मन की स्थिति, क्योंकि अन्यथा वह पैकेटों को सूंघ सकता है और जान सकता है कि उसे मारने के लिए कहां जाना है।

क्रमबद्धता

पहला कदम उस डेटा को परिवर्तित करना है जिसे हम भेजना चाहते हैं (इनपुट या गेम स्थिति) ट्रांसमिशन के लिए उपयुक्त प्रारूप में। इस प्रक्रिया को कहा जाता है क्रमबद्धता.

JSON या XML जैसे मानव-पठनीय प्रारूप का उपयोग करने का विचार तुरंत मन में आता है। लेकिन यह पूरी तरह से अप्रभावी होगा और अधिकांश चैनल को व्यर्थ में ही ले लेगा।

इसके बजाय, बाइनरी प्रारूप का उपयोग करने की अनुशंसा की जाती है, जो बहुत अधिक कॉम्पैक्ट है। यानी, पैकेट में केवल कुछ बाइट्स होंगे। यहां हमें समस्या को ध्यान में रखना होगा बाइट क्रम, जो अलग-अलग कंप्यूटर पर भिन्न हो सकता है।

डेटा को क्रमबद्ध करने के लिए, आप लाइब्रेरी का उपयोग कर सकते हैं, उदाहरण के लिए:

• फ्लैटबफर्स गूगल
• कैप'एन प्रोटो बालू का तूफ़ान
• अनाज शेन ग्रांट और रैंडोल्फ वूरहिस

बस यह सुनिश्चित करें कि लाइब्रेरी पोर्टेबल अभिलेखागार बनाती है और अंतहीनता का ख्याल रखती है।

एक वैकल्पिक समाधान यह होगा कि आप इसे स्वयं लागू करें, यह उतना कठिन नहीं है, खासकर यदि आप अपने कोड में डेटा-केंद्रित दृष्टिकोण का उपयोग कर रहे हैं। इसके अलावा, यह आपको ऐसे अनुकूलन करने की अनुमति देगा जो लाइब्रेरी का उपयोग करते समय हमेशा संभव नहीं होते हैं।

ग्लेन फिडलर ने क्रमांकन पर दो लेख लिखे हैं: पैकेट पढ़ना और लिखना и क्रमांकन रणनीतियाँ.

दबाव

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

बिट पैकिंग

पहली तकनीक बिट पैकिंग है। इसमें वांछित मान का वर्णन करने के लिए आवश्यक बिट्स की सटीक संख्या का उपयोग करना शामिल है। उदाहरण के लिए, यदि आपके पास एक एनम है जिसमें 16 अलग-अलग मान हो सकते हैं, तो एक संपूर्ण बाइट (8 बिट्स) के बजाय, आप केवल 4 बिट्स का उपयोग कर सकते हैं।

ग्लेन फिडलर लेख के दूसरे भाग में बताते हैं कि इसे कैसे लागू किया जाए। पैकेट पढ़ना और लिखना.

बिट पैकिंग विवेक के साथ विशेष रूप से अच्छी तरह से काम करती है, जो अगले भाग का विषय होगा।

सैम्पलिंग

सैम्पलिंग एक हानिपूर्ण संपीड़न तकनीक है जो किसी मान को एन्कोड करने के लिए संभावित मानों के केवल सबसेट का उपयोग करती है। विवेकाधिकार को लागू करने का सबसे आसान तरीका फ़्लोटिंग-पॉइंट संख्याओं को पूर्णांकित करना है।

ग्लेन फिडलर (फिर से!) अपने लेख में दिखाते हैं कि विवेक को व्यवहार में कैसे लागू किया जाए स्नैपशॉट संपीड़न.

संपीड़न एल्गोरिदम

अगली तकनीक दोषरहित संपीड़न एल्गोरिदम होगी।

यहां, मेरी राय में, तीन सबसे दिलचस्प एल्गोरिदम हैं जिन्हें आपको जानना आवश्यक है:

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

डेल्टा संपीड़न

अंतिम संपीड़न तकनीक डेल्टा संपीड़न है। यह इस तथ्य में निहित है कि केवल वर्तमान गेम स्थिति और क्लाइंट द्वारा प्राप्त अंतिम स्थिति के बीच अंतर ही प्रसारित होता है।

इसका प्रयोग सबसे पहले Quake3 नेटवर्क इंजन में किया गया था। यहां दो लेख दिए गए हैं जो बताते हैं कि इसका उपयोग कैसे करें:

• क्वेक3 नेटवर्किंग मॉडल ब्रायन हुक
• क्वेक 3 स्रोत कोड समीक्षा: नेटवर्क मॉडल फैबियन सांगलार्स [अनुवाद हैबे पर लेख, "नेटवर्क मॉडल" अनुभाग देखें]

ग्लेन फिडलर ने अपने लेख के दूसरे भाग में भी इसका प्रयोग किया। स्नैपशॉट संपीड़न.

Шифрование

इसके अतिरिक्त, आपको क्लाइंट और सर्वर के बीच सूचना के प्रसारण को एन्क्रिप्ट करने की आवश्यकता हो सकती है। इसके अनेक कारण हैं:

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

मैं इसके लिए लाइब्रेरी का उपयोग करने की पुरजोर अनुशंसा करता हूं। मैं उपयोग करने का सुझाव देता हूं libsodium, क्योंकि यह विशेष रूप से सरल है और इसमें बेहतरीन ट्यूटोरियल हैं। ट्यूटोरियल विशेष रूप से दिलचस्प है कुंजी विनिमय, जो आपको प्रत्येक नए कनेक्शन पर नई कुंजी उत्पन्न करने की अनुमति देता है।

एप्लिकेशन प्रोटोकॉल: निष्कर्ष

यह एप्लिकेशन प्रोटोकॉल का समापन करता है। मेरा मानना ​​है कि संपीड़न पूरी तरह से वैकल्पिक है और इसका उपयोग करने का निर्णय केवल गेम और आवश्यक बैंडविड्थ पर निर्भर करता है। मेरी राय में, एन्क्रिप्शन अनिवार्य है, लेकिन पहले प्रोटोटाइप में आप इसके बिना भी काम कर सकते हैं।

अनुप्रयोग तर्क

अब हम क्लाइंट में स्थिति को अपडेट करने में सक्षम हैं, लेकिन हमें विलंबता संबंधी समस्याओं का सामना करना पड़ सकता है। इनपुट करने के बाद, खिलाड़ी को सर्वर से गेम स्थिति अपडेट की प्रतीक्षा करनी होगी ताकि यह देखा जा सके कि इसका दुनिया पर क्या प्रभाव पड़ा है।

इसके अलावा, दो राज्य अद्यतनों के बीच, दुनिया पूरी तरह से स्थिर है। यदि राज्य अद्यतन दर कम है, तो गतिविधियाँ बहुत झटकेदार होंगी।

इस समस्या के प्रभाव को कम करने के लिए कई तकनीकें हैं, और मैं उन्हें अगले भाग में शामिल करूंगा।

विलंब स्मूथिंग तकनीक

इस अनुभाग में वर्णित सभी तकनीकों पर श्रृंखला में विस्तार से चर्चा की गई है। तेज़ गति वाला मल्टीप्लेयर गेब्रियल गैम्बेटा. मैं लेखों की इस उत्कृष्ट श्रृंखला को पढ़ने की अत्यधिक अनुशंसा करता हूँ। इसमें यह देखने के लिए एक इंटरैक्टिव डेमो भी शामिल है कि ये तकनीकें व्यवहार में कैसे काम करती हैं।

पहली तकनीक सर्वर से प्रतिक्रिया की प्रतीक्षा किए बिना सीधे इनपुट परिणाम लागू करना है। यह कहा जाता है ग्राहक-पक्ष भविष्यवाणी. हालाँकि, जब क्लाइंट को सर्वर से अपडेट प्राप्त होता है, तो उसे यह सत्यापित करना होगा कि उसकी भविष्यवाणी सही थी। यदि यह मामला नहीं है, तो उसे सर्वर से जो प्राप्त हुआ है उसके अनुसार उसे अपना राज्य बदलने की जरूरत है, क्योंकि सर्वर सत्तावादी है। इस तकनीक का प्रयोग सबसे पहले क्वेक में किया गया था। आप इसके बारे में लेख में अधिक पढ़ सकते हैं। क्वेक इंजन कोड समीक्षा फैबियन सांगलार्स [अनुवाद हैबे पर]।

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

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

ग्लेन फिडलर (हमेशा की तरह!) ने 2004 में एक लेख लिखा था नेटवर्क भौतिकी (2004), जिसमें उन्होंने सर्वर और क्लाइंट के बीच भौतिकी सिमुलेशन के सिंक्रनाइज़ेशन की नींव रखी। 2014 में उन्होंने लेखों की एक नई श्रृंखला लिखी नेटवर्किंग भौतिकी, जिसमें उन्होंने भौतिकी सिमुलेशन को सिंक्रनाइज़ करने के लिए अन्य तकनीकों का वर्णन किया।

वाल्व के विकी पर भी दो लेख हैं, स्रोत मल्टीप्लेयर नेटवर्किंग и क्लाइंट/सर्वर इन-गेम प्रोटोकॉल डिज़ाइन और ऑप्टिमाइज़ेशन में विलंबता क्षतिपूर्ति के तरीके विलंब मुआवज़े से निपटना।

धोखा रोकथाम

धोखाधड़ी निवारण की दो मुख्य तकनीकें हैं।

सबसे पहले, धोखेबाज़ों के लिए दुर्भावनापूर्ण पैकेट भेजना कठिन बना दिया गया है। जैसा कि ऊपर बताया गया है, इसे लागू करने का एक अच्छा तरीका एन्क्रिप्शन है।

दूसरा, आधिकारिक सर्वर को केवल कमांड/इनपुट/क्रियाएँ प्राप्त होनी चाहिए। क्लाइंट को इनपुट भेजने के अलावा सर्वर पर स्थिति बदलने में सक्षम नहीं होना चाहिए। फिर सर्वर को, हर बार इनपुट प्राप्त होने पर, इसे लागू करने से पहले इसकी वैधता की जांच करनी होगी।

अनुप्रयोग तर्क: निष्कर्ष

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

अन्य सहायक संसाधन

यदि आप अन्य नेटवर्क मॉडल संसाधनों का पता लगाना चाहते हैं, तो आप उन्हें यहां पा सकते हैं:

• ग्लेन फिडलर का ब्लॉग — उनका पूरा ब्लॉग पढ़ने लायक है, इसमें कई बेहतरीन लेख हैं। यहां नेटवर्क प्रौद्योगिकियों पर सभी लेख एकत्र किए गए हैं।
• बहुत बढ़िया गेम नेटवर्किंग एम. फातिह द्वारा मार्च वीडियो गेम नेटवर्किंग इंजन पर लेखों और वीडियो की एक व्यापक सूची है।
• В विकी सबरेडिट आर/गेमडेव कई उपयोगी लिंक भी हैं.

स्रोत: www.habr.com