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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

खुद का प्रोटोकॉल

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

पहला प्रोग्राम , नेटवर्किंग फॉर गेम प्रोग्रामर्स 2008, दूसरा, बिल्डिंग ए गेम नेटवर्क प्रोटोकॉल 2016 की तुलना में सरल है। मैं आपको एक पुराने के साथ शुरू करने की सलाह देता हूं।

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

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

नेटवर्क लाइब्रेरी

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

• yojimbo ग्लेन फिडलर
• RakNet , जो अब समर्थित नहीं है, लेकिन SLikeNet का कांटा अभी भी सक्रिय है।
• एनेट बहु-उपयोगकर्ता एफपीएस क्यूब के लिए बनाई गई एक लाइब्रेरी है
• वाल्व के GameNetworkingSockets

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

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

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

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

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

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

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

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

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

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

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

क्रमबद्धता

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

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

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

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

• Google FlatBuffers
• सैंडस्टॉर्म कैप'एन प्रोटो
• शेन ग्रांट और Randolph Voorhees द्वारा अनाज

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

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

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

दबाव

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

बिट पैकिंग

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

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

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

नमूना

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

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

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

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

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

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

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

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

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

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

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

एन्क्रिप्शन

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

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

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

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

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

आवेदन तर्क

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

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

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

विलंब चिकनाई तकनीक

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

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

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

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

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

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

छल की रोकथाम

धोखा को रोकने के लिए दो मुख्य तकनीकें हैं।

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

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

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

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

अन्य उपयोगी संसाधन

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

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