🕗 💪🏿 ✋🏽 जैसा कि हमने मोबाइल PvP शूटर का नेटवर्क कोड लिखा है: क्लाइंट पर प्लेयर सिंक्रोनाइज़ेशन 👩🏿‍🌾 👸🏾 💄

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

सामान्य तौर पर, पिछले 20 वर्षों में तेजी से मल्टीप्लेयर गेम बनाने के दृष्टिकोण बहुत ज्यादा नहीं बदले हैं। नेटवर्क कोड आर्किटेक्चर में कई तरीकों को प्रतिष्ठित किया जा सकता है:

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

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

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

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

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

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

स्थानीय खिलाड़ी कार्रवाई भविष्यवाणी तंत्र (भविष्यवाणी)

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

क्लाइंट और सर्वर पर चल रही प्रणालियों की सूची का उदाहरण:

फिलहाल, हमारे पास क्लाइंट पर चलने वाली लगभग 30 प्रणालियाँ हैं जो खिलाड़ी की भविष्यवाणी और सर्वर पर चलने वाली लगभग 80 प्रणालियों को प्रदान करती हैं। लेकिन हम नुकसान का सामना करने, क्षमताओं का उपयोग करने या सहयोगियों को ठीक करने जैसी चीजों की भविष्यवाणी नहीं करते हैं। इन यांत्रिकी में दो समस्याएं हैं:

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

ऐसे मैकेनिक के लिए, खिलाड़ी दूसरे तरीकों से छिप जाता है।

उदाहरण: हम शॉट से हिटिंग के प्रभाव को तुरंत आकर्षित करते हैं, और सर्वर से हिट की पुष्टि प्राप्त करने के बाद ही हम दुश्मन के जीवन को अपडेट करते हैं।

परियोजना में नेटवर्क कोड की सामान्य योजना

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

पूरी प्रक्रिया में निम्नलिखित चरण होते हैं: क्लाइंट खिलाड़ी के इनपुट को सर्वर को भेजता है (a) → इस इनपुट को सर्वर पर HRTT + इनपुट बफर साइज (b) के बाद प्रोसेस किया जाता है। → सर्वर क्लाइंट को परिणामी विश्व स्थिति भेजता है () → क्लाइंट के साथ पुष्टिकृत विश्व स्थिति लागू होती है। सर्वर समय RTT + इनपुट बफर आकार + खेल राज्य प्रक्षेप बफर आकार (डी)।

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

अनुमोदन प्रक्रिया में दो भाग होते हैं:

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

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

कोड में, यह कुछ इस तरह दिखता है:

GameState Reconcile(int currentTick, ServerGameStateData serverStateData, GameState currentState, uint playerID) { var serverState = serverStateData.GameState; var serverTick = serverState.Time; var predictedState = _localStateHistory.Get(serverTick); //if predicted state matches server last state use server predicted state with predicted player if (_gameStateComparer.IsSame(predictedState, serverState, playerID)) { _tempState.Copy(serverState); _gameStateCopier.CopyPlayerEntities(currentState, _tempState, playerID); return _localStateHistory.Put(_tempState); // replace predicted state with correct server state } //if predicted state doesn't match server state, reapply local inputs to server state var last = _localStateHistory.Put(serverState); // replace wrong predicted state with correct server state for (var i = serverTick; i < currentTick; i++) { last = _prediction.Predict(last); // resimulate all wrong states } return last; }

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

तुलना विधि:

 public bool IsSame(GameState s1, GameState s2, uint avatarId) { if (s1 == null && s2 != null || s1 != null && s2 == null) return false; if (s1 == null && s2 == null) return false; var entity1 = s1.WorldState[avatarId]; var entity2 = s2.WorldState[avatarId]; if (entity1 == null && entity2 == null) return false; if (entity1 == null || entity2 == null) return false; if (s1.Time != s2.Time) return false; if (s1.WorldState.Transform[avatarId] != s2.WorldState.Transform[avatarId]) return false; foreach (var s1Weapon in s1.WorldState.Weapon) { if (s1Weapon.Value.Owner.Id != avatarId) continue; var s2Weapon = s2.WorldState.Weapon[s1Weapon.Key]; if (s1Weapon.Value != s2Weapon) return false; var s1Ammo = s1.WorldState.WeaponAmmo[s1Weapon.Key]; var s2Ammo = s2.WorldState.WeaponAmmo[s1Weapon.Key]; if (s1Ammo != s2Ammo) return false; var s1Reload = s1.WorldState.WeaponReloading[s1Weapon.Key]; var s2Reload = s2.WorldState.WeaponReloading[s1Weapon.Key]; if (s1Reload != s2Reload) return false; } if (entity1.Aiming != entity2.Aiming) return false; if (entity1.ChangeWeapon != entity2.ChangeWeapon) return false; return true; }

विशिष्ट घटकों के लिए तुलना ऑपरेटरों को पूरी ईसी संरचना के साथ उत्पन्न किया जाता है, विशेष रूप से एक कोड जनरेटर द्वारा लिखा जाता है। एक उदाहरण के लिए, मैं रूपांतरण घटक तुलना ऑपरेटर का उत्पन्न कोड दे दूंगा:

कोड

 public static bool operator ==(Transform a, Transform b) { if ((object)a == null && (object)b == null) return true; if ((object)a == null && (object)b != null) return false; if ((object)a != null && (object)b == null) return false; if (Math.Abs(a.Angle - b.Angle) > 0.01f) return false; if (Math.Abs(a.Position.x - b.Position.x) > 0.01f || Math.Abs(a.Position.y - b.Position.y) > 0.01f) return false; return true; }

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

समन्वय तंत्र की जटिलता यह है कि क्लाइंट और सर्वर राज्यों (मिसप्रिंट) के गलत सिंक्रनाइज़ेशन की स्थिति में, सभी पूर्वानुमानित क्लाइंट राज्यों को बार-बार अनुकरण करना आवश्यक है, जिसके बारे में सर्वर से कोई पुष्टि नहीं होती है, एक फ्रेम में वर्तमान टिक तक। खिलाड़ी के पिंग के आधार पर, यह 5 से 20 सिमुलेशन टिक से हो सकता है। हमें समय सीमा में फिट होने के लिए सिमुलेशन कोड को महत्वपूर्ण रूप से अनुकूलित करना था: 30 एफपीएस।

अनुमोदन प्रक्रिया को पूरा करने के लिए, ग्राहक पर दो प्रकार के डेटा संग्रहीत किए जाने चाहिए:

पूर्वानुमानित खिलाड़ी का इतिहास बताता है।
और इनपुट का इतिहास।

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

लाग समय में कमी

ऊपर दिए गए आरेख से पता चलता है कि खेल में डेटा ट्रांसफर योजना में दो बफ़र हैं:

सर्वर पर इनपुट बफर;
ग्राहक पर दुनिया का एक बफर बताता है।

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

गेम की शुरुआत में, क्लाइंट सर्वर से कई दुनिया के स्टेट्स प्राप्त करने के बाद ही सर्वर से सिंक्रनाइज़ेशन शुरू करता है और गेमस्टेट बफर पूरा हो जाता है। आमतौर पर, इस बफर का आकार 3 टिक (100 एमएस) है।

उसी समय, जब क्लाइंट सर्वर के साथ सिंक्रनाइज़ होता है, तो यह सर्वर पर इनपुट बफर के मूल्य से सर्वर समय से आगे "रन" करता है। यानी क्लाइंट खुद को नियंत्रित करता है कि वह सर्वर से कितना आगे है। इनपुट बफर का शुरुआती आकार भी 3 टिक (100 एमएस) के बराबर है।

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

यह हमें शोभा नहीं देता।

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

इस समस्या का हल इनपुट बफ़र्स और गेमस्टेट्स के गतिशील आकारों का कार्यान्वयन था:

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

गेमस्टेट बफर का आकार बदलने वाला एल्गोरिदम लगभग निम्नलिखित है:

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

सर्वर की क्षतिपूर्ति

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

इस वजह से, स्थिति यह है कि खिलाड़ी स्थानीय रूप से किसी अन्य स्थान पर सर्वर पर स्थित लक्ष्य पर शूट करता है।

अंतराल के लिए क्षतिपूर्ति करने के लिए, हम सर्वर पर रिवाइंड समय का उपयोग करते हैं। ऑपरेशन एल्गोरिथ्म लगभग निम्नलिखित है:

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

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

शॉट सत्यापन प्रणाली के लिए कोड कुछ इस तरह दिखता है:

 public void Execute(GameState gs) { foreach (var shotPair in gs.WorldState.Shot) { var shot = shotPair.Value; var shooter = gs.WorldState[shotPair.Key]; var shooterTransform = shooter.Transform; var weaponStats = gs.WorldState.WeaponStats[shot.WeaponId]; // DeltaTime shouldn't exceed physics history size var shootDeltaTime = (int) (gs.Time - shot.ShotPlayerWorldTime); if (shootDeltaTime > PhysicsWorld.HistoryLength) { continue; } // Get the world at the time of shooting. var oldState = _immutableHistory.Get(shot.ShotPlayerWorldTime); var potentialTarget = oldState.WorldState[shot.Target.Id]; var hitTargetId = _singleShotValidator.ValidateTargetAvailabilityInLine(oldState, potentialTarget, shooter, shootDeltaTime, weaponStats.ShotDistance, shooter.Transform.Angle.GetDirection()); if (hitTargetId != 0) { gs.WorldState.CreateEntity().AddDamage(gs.WorldState[hitTargetId], shooter, weaponStats.ShotDamage); } } }

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

कुछ समस्याओं का हमें सामना करना पड़ा

इस नेटवर्क इंजन के कार्यान्वयन के दौरान, हमें कई समस्याओं का सामना करना पड़ा, जिनमें से कुछ एक अलग लेख के योग्य हैं, लेकिन यहां मैं उनमें से कुछ पर ही स्पर्श करूंगा।

एक भविष्यवाणी प्रणाली और नकल में पूरी दुनिया का अनुकरण

प्रारंभ में, हमारे ECS की सभी प्रणालियों में केवल एक ही विधि थी: शून्य निष्पादित (GameState gs)। इस पद्धति में, सभी खिलाड़ियों से संबंधित घटकों को आमतौर पर संसाधित किया जाता था।

प्रारंभिक कार्यान्वयन में एक गति प्रणाली का एक उदाहरण:

 public sealed class MovementSystem : ISystem { public void Execute(GameState gs) { foreach (var movementPair in gs.WorldState.Movement) { var transform = gs.WorldState.Transform[movementPair.Key]; transform.Position += movementPair.Value.Velocity * GameState.TickDuration; } } }

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

भविष्यवाणी प्रक्रिया इस प्रकार थी:

खेल राज्य की एक प्रति बनाई गई थी।
एक प्रति ईसीएस इनपुट को आपूर्ति की गई थी।
ईसीएस में पूरी दुनिया का अनुकरण था।
स्थानीय खिलाड़ी से संबंधित सभी डेटा को नए प्राप्त गेमस्टेट से कॉपी किया गया था।

भविष्यवाणी की विधि इस प्रकार दिखी:

 void PredictNewState(GameState state) { var newState = _stateHistory.Get(state.Tick+1); var input = _inputHistory.Get(state.Tick); newState.Copy(state); _tempGameState.Copy(state); _ecsExecutor.Execute(_tempGameState, input); _playerEntitiesCopier.Copy(_tempGameState, newState); }

इस कार्यान्वयन में दो समस्याएं थीं:

क्योंकि हम कक्षाओं का उपयोग करते हैं, संरचनाओं का नहीं - नकल हमारे लिए काफी महंगा ऑपरेशन है (आईफोन 5 एस पर लगभग 0.1-0.15 एमएस)।
पूरी दुनिया के सिमुलेशन में बहुत समय लगता है (आईफोन 5 एस पर लगभग 1.5-2 एमएस)।

यदि हम इस बात को ध्यान में रखते हैं कि समन्वय प्रक्रिया के दौरान एक फ्रेम में 5 से 15 दुनिया के राज्यों से पुनर्गणना आवश्यक है, तो इस तरह के कार्यान्वयन के साथ सब कुछ बहुत धीमा था।

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

एक परिवर्तन के बाद एक आंदोलन प्रणाली का एक उदाहरण:

 public sealed class MovementSystem : ISystem { public void Execute(GameState gs) { foreach (var movementPair in gs.WorldState.Movement) { Move(gs.WorldState.Transform[movementPair.Key], movementPair.Value); } } public void ExecutePlayer(GameState gs, uint playerId) { var movement = gs.WorldState.Movement[playerId]; if(movement != null) { Move(gs.WorldState.Transform[playerId], movement); } } private void Move(Transform transform, Movement movement) { transform.Position += movement.Velocity * GameState.TickDuration; } }

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

कोड:

 void PredictNewState(GameState state, uint playerId) { var newState = _stateHistory.Get(state.Tick+1); var input = _inputHistory.Get(state.Tick); newState.Copy(state); _ecsExecutor.Execute(newState, input, playerId); }

एक भविष्यवाणी प्रणाली में संस्थाओं को बनाना और हटाना

हमारी प्रणाली में, सर्वर और क्लाइंट पर संस्थाओं का मिलान पूर्णांक पहचानकर्ता (आईडी) द्वारा होता है। सभी संस्थाओं के लिए, हम पहचानकर्ताओं की एंड-टू-एंड नंबरिंग का उपयोग करते हैं, प्रत्येक नई इकाई का मूल्य id = oldID + 1 है।

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

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

सर्वर पर शॉट्स एक अलग क्रम में बनाए गए थे:

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

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

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

यह भी ध्यान दिया जाना चाहिए कि यह समस्या केवल नई संस्थाओं (नई आईडी के साथ) के निर्माण की चिंता करती है। पहले से निर्मित संस्थाओं पर घटकों को जोड़ना और निकालना समस्याओं के बिना किया जाता है: घटकों में पहचानकर्ता नहीं होते हैं और प्रत्येक इकाई में एक विशिष्ट प्रकार का केवल एक घटक हो सकता है। इसलिए, हम आमतौर पर सर्वर पर इकाइयां बनाते हैं, और भविष्यवाणी प्रणालियों में हम केवल घटकों को जोड़ते / हटाते हैं।

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

क्या पढ़ना है?

फास्ट गेम्स में मल्टीप्लेयर - लेख का अनुवाद फास्ट-पेलड मल्टीप्लेयर (भाग I): परिचय (मेरी राय में, यह गेम में नेटवर्क इंटरेक्शन के बारे में हैबे पर सबसे अच्छा लेख है)।
जीडीसी वॉल्ट ओवरवॉच गेमप्ले आर्किटेक्चर और नेटकोड - ईसीएस और ओवरवॉच में नेटवर्क कोड (दुर्भाग्य से, एक्सेस का भुगतान किया जाता है) पर जीडीसी 17 के साथ एक व्याख्यान।
जीडीसी वॉल्ट: 16 में 8 फ्रेम्स: मॉर्टल कोम्बैट और इनोलिसिस 2 में रोलबैक नेटवर्किंग - यह फाइटिंग गेम्स में कैसे किया जाता है।
स्रोत मल्टीप्लेयर नेटवर्किंग - काउंटर स्ट्राइक में मल्टीप्लेयर कैसे काम करता है।
खेलों पर Gaffer आम तौर पर खेलों में नेटवर्क कोड के बारे में है।
गेम इंजन में यूडीपी ।
जीडीसी तिजोरी: मैंने आपको पहले नेटवर्किंग को शूट किया - हेलो में कैसे मल्टीप्लेयर काम करता है: रीच।

जैसा कि हमने मोबाइल PvP शूटर का नेटवर्क कोड लिखा है: क्लाइंट पर प्लेयर सिंक्रोनाइज़ेशन