एक नए मोबाइल PvP शूटर और गेम सर्वर डिवाइस में क्लाइंट-सर्वर इंटरैक्शन: समस्याएं और समाधान

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




मोबाइल उपकरणों के लिए नए तुल्यकालिक PvP के विकास के दौरान, हमें शैली की विशिष्ट समस्याओं का सामना करना पड़ा:

1. मोबाइल ग्राहकों की कनेक्शन गुणवत्ता खराब है। यह 200-250 एमएस के क्षेत्र में एक अपेक्षाकृत उच्च औसत पिंग है, और पहुंच बिंदुओं के परिवर्तन को ध्यान में रखते हुए पिंग का एक अस्थिर समय वितरण है (हालांकि, लोकप्रिय धारणा के विपरीत, 3 जी + मोबाइल नेटवर्क में पैकेट नुकसान का प्रतिशत काफी कम है - लगभग 1%)।
2. मौजूदा तकनीकी समाधान राक्षसी ढांचे हैं जो डेवलपर्स को तंग ढांचे में चलाते हैं।

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

तुल्यकालिक PvP खेल में ग्राहकों के बीच बातचीत के आयोजन के तंत्र पर विचार करें। उनमें से सबसे लोकप्रिय:

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

यह एक अधिनायकवादी सर्वर लिखने का निर्णय लिया गया था।


सहकर्मी से सहकर्मी (बाएं) और क्लाइंट-सर्वर (दाएं) के साथ नेटवर्किंग

क्लाइंट और सर्वर के बीच डाटा ट्रांसफर

हम फोटॉन सर्वर का उपयोग करते हैं - इसने हमें इस योजना के लिए आवश्यक बुनियादी ढाँचे को जल्दी ही तैनात करने की अनुमति दी, जो पहले से ही वर्षों से चली आ रही योजना के आधार पर (युद्ध रोबोट हम इसका उपयोग करते हैं)।

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

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


फोटॉन सर्वर कंटेनर में मैच धाराओं की सामान्य योजना

प्रत्येक मैच में कई चरण होते हैं:

1. गेम क्लाइंट तथाकथित मैच-मेकिंग सर्विस में कतार में है। जैसे ही कुछ शर्तों को पूरा करने वाले खिलाड़ियों की आवश्यक संख्या इसमें एकत्र की जाती है, वह जीआरपीसी का उपयोग करके गेम सर्वर को इसकी सूचना देता है। इसी समय, गेम बनाने के लिए आवश्यक सभी डेटा संचारित होते हैं।
   
   
   एक मैच बनाने की सामान्य योजना
2. गेम सर्वर पर, मैच की शुरूआत शुरू होती है। सभी मिलान मापदंडों को संसाधित किया जाता है और तैयार किया जाता है, जिसमें मानचित्र डेटा, साथ ही साथ मैच निर्माण सेवा से प्राप्त सभी ग्राहक डेटा शामिल होते हैं। डेटा को संसाधित करने और तैयार करने का तात्पर्य है कि हम सभी आवश्यक डेटा को पार्स करते हैं और इसे एक विशेष उपसमुच्चय में लिखते हैं जिसे हम नियम पुस्तिका कहते हैं। यह मैच के आँकड़ों को संग्रहीत करता है (जो इसके पाठ्यक्रम के दौरान नहीं बदलता है) और कनेक्शन खोने के बाद एक बार या फिर कनेक्ट करते समय गेम सर्वर पर कनेक्शन और प्राधिकरण प्रक्रिया के दौरान सभी ग्राहकों को प्रेषित किया जाएगा। स्टेटिक मैच डेटा में मैप कॉन्फ़िगरेशन (ईसीएस घटकों द्वारा मानचित्र की प्रस्तुति जो उन्हें भौतिक इंजन से जोड़ती है), ग्राहक डेटा (उपनाम, हथियारों का एक सेट जो उनके पास है और लड़ाई के दौरान नहीं बदलते हैं, आदि) को शामिल करता है।
3. एक मैच चल रहा है। ईसीएस सिस्टम जो सर्वर पर गेम बनाते हैं, काम करना शुरू करते हैं। सभी सिस्टम प्रति सेकंड 30 फ्रेम टिक कर रहे हैं।
4. यदि खिलाड़ी एक निश्चित अंतराल के भीतर अपना इनपुट नहीं भेजते हैं तो प्रत्येक फ्रेम खिलाड़ी के इनपुट या प्रतियों को पढ़ता है और कॉपी करता है।
5. फिर, एक ही फ्रेम में, इनपुट ईसीएस सिस्टम में संसाधित किया जाता है, अर्थात्: खिलाड़ी राज्य परिवर्तन; वह दुनिया जिसे वह अपने इनपुट से प्रभावित करता है; और अन्य खिलाड़ियों की स्थिति।
6. फ्रेम के अंत में, परिणामी विश्व स्थिति खिलाड़ी के लिए पैक की जाती है और नेटवर्क पर भेजी जाती है।
7. मैच के अंत में, परिणाम ग्राहकों को और माइक्रो सर्विस को भेजे जाते हैं, जो कि जीआरपीसी का उपयोग करके लड़ाई के लिए पुरस्कारों की प्रक्रिया करता है, साथ ही साथ मैच के लिए विश्लेषक भी।
8. उसके बाद, मैच प्रवाह कम हो जाता है और प्रवाह बंद हो जाता है।

एक फ्रेम के भीतर सर्वर पर क्रियाओं का क्रम

क्लाइंट की ओर से, एक मैच से जुड़ने की प्रक्रिया इस प्रकार है:

1. सबसे पहले, प्रोटॉब के माध्यम से क्रमांकन के साथ वेबसोकेट के माध्यम से मैच बनाने के लिए सेवा में कतार लगाने का अनुरोध किया जाता है।
2. मैच बनाते समय, यह सेवा गेम सर्वर पते के ग्राहक को सूचित करती है और मैच से पहले ग्राहक द्वारा आवश्यक अतिरिक्त पेलोड को स्थानांतरित करती है। अब क्लाइंट गेम सर्वर पर प्राधिकरण प्रक्रिया शुरू करने के लिए तैयार है।
3. क्लाइंट यूडीपी सॉकेट बनाता है और कुछ क्रेडेंशियल्स के साथ मैच से कनेक्ट करने के लिए गेम सर्वर को एक अनुरोध भेजना शुरू करता है। सर्वर पहले से ही इस क्लाइंट का इंतजार कर रहा है। कनेक्ट होने पर, वह उसे गेम शुरू करने और दुनिया को पहली बार प्रदर्शित करने के लिए सभी आवश्यक डेटा देता है। इनमें शामिल हैं: रूलबुक (मैच के लिए स्थैतिक डेटा की एक सूची), साथ ही साथ स्ट्रिंगइन्ग्राफ, जिसे हम गेमप्ले में उपयोग की जाने वाली लाइनों के बारे में डेटा के रूप में संदर्भित करते हैं जो कि मैच के दौरान पूर्णांक द्वारा पहचाने जाएंगे)। ट्रैफिक को बचाने के लिए यह आवश्यक है, क्योंकि हर फ्रेम से गुजरने वाली लाइनें नेटवर्क पर एक महत्वपूर्ण भार बनाती हैं। उदाहरण के लिए, सभी खिलाड़ी के नाम, वर्ग के नाम, हथियार पहचानकर्ता, खाते और इसी तरह, सभी जानकारी StringIntMap को लिखी जाती है, जहां यह सरल पूर्णांक डेटा का उपयोग करके एन्कोड किया गया है।

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

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


मैच बनाने, गेम सर्वर और प्राधिकरण से जुड़ने का अनुरोध

मैच के पहले बाइट्स का सीरियललाइज़ेशन और डीरियलाइज़ेशन, पैकेजिंग और अनपैकिंग

हमारे पास एक मालिकाना बाइनरी डेटा क्रमांकन है, और डेटा ट्रांसफर के लिए हम यूडीपी का उपयोग करते हैं।

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

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

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

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

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

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

संदर्भ-संवेदी नेटवर्क यातायात अनुकूलन। डेल्टा संपीड़न

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

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

deltaGameState = newGameState - prevGameState

लेकिन प्रत्येक ग्राहक के लिए अलग-अलग डेटा भेजा जाता है और केवल एक पैकेट के नुकसान से इस तथ्य को जन्म दिया जा सकता है कि आपको दुनिया की पूर्ण स्थिति को आगे बढ़ाना होगा।

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


परियोजना में क्लाइंट-सर्वर इंटरैक्शन की आवृत्ति का चित्रण

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

public sealed class InputSample { //  ,        public uint WorldTick; // ,      ,     public uint PlayerSimulationTick; //   .  (idle, , ) public MovementMagnitude MovementMagnitude; //  ,   public float MovementAngle; //    public AimMagnitude AimMagnitude; //    public float AimAngle; //   ,       public uint ShotTarget; //    ,        public float AimMagnitudeCompressed; } 

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

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

 if (Math.Abs(s.AimMagnitudeCompressed) < float.Epsilon) { packer.PackByte(0, 1); } else { packer.PackByte(1, 1); float min = 0; float max = 1; float step = 0.001f; //     1000    , //          //     packer.PackUInt32((uint)((s.AimMagnitudeCompressed - min)/step), CalcFloatRangeBits(min, max, step)); } 

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


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

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

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

निष्कर्ष और संदर्भ के बजाय

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

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

उपयोगी लिंक:

• https://gafferongames.com/post/udp_vs_tcp/ टीसीपी और यूडीपी के बीच नेटवर्क गेम के लिए चुनने पर एक शानदार लेख है।
• https://api.unrealengine.com/udk/Three/NetworkingOverview.html - अवास्तविक इंजन में सर्वर मॉडल का विवरण।
• http://ieeexplore.ieee.org/document/5360721 - मोबाइल कनेक्शन के नेटवर्क की गुणवत्ता का अध्ययन।
• http://ithare.com/mmog-rtt-input-lag-and-how-to-mitigate-them/ - तेजी से पुस्तक गेम में नेटवर्क इंटरैक्शन।

परियोजना पर पिछले लेख:

1. "हाउ वी वींग ऑन ए मोबाइल फास्ट पास्ड शूटर: टेक्नोलॉजी एंड अप्चेज़ । "
2. "हमने अपना ECS कैसे और क्यों लिखा है । "
3. "जैसा कि हमने मोबाइल PvP शूटर का नेटवर्क कोड लिखा है: क्लाइंट पर प्लेयर सिंक्रोनाइज़ेशन । "