मेगापैक: फैक्टरियो डेवलपर्स 200 खिलाड़ी मल्टीप्लेयर के साथ समस्या को हल करने में कैसे कामयाब रहे

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

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

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


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

मल्टी-यूजर मेगापैक - तकनीकी विवरण

सरल शब्दों में, खेल में मल्टीप्लेयर निम्नानुसार काम करता है: सभी ग्राहक गेम की स्थिति का अनुकरण करते हैं, केवल खिलाड़ी का इनपुट (जिसे "इनपुट एक्शन", इनपुट एक्शन कहा जाता है) प्राप्त करना और भेजना। सर्वर का मुख्य कार्य इनपुट क्रियाओं को संचारित करना और नियंत्रित करना है जो सभी ग्राहक एक ही चक्र में एक ही क्रिया करते हैं। इस बारे में और अधिक पढ़ें FFF-149 पोस्ट में।

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


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

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

ऐसा करने के लिए, हम विलंबित कतार में बनाई गई इनपुट क्रियाओं की एक प्रति संग्रहीत करते हैं।


अर्थात्, क्लाइंट की ओर से प्रक्रिया के अंत में, चित्र कुछ इस तरह दिखता है:

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

यह सब हर उपाय में दोहराया जाता है।

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

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

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

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

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

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

विडंबना यह है कि चैनल बैंडविड्थ को बचाने के लिए डिज़ाइन किए गए एक तंत्र ने परिणामस्वरूप विशाल नेटवर्क पैकेट बनाए।

हमने विलंब की कतार को अद्यतन करने और समर्थन करने के सभी बॉर्डरलाइन मामलों को सही करके इस समस्या को हल किया। हालांकि इसमें काफी समय लगा, अंत में यह सब कुछ सही ढंग से लागू करने और तेज हैक पर भरोसा न करने लायक था।