मेगापैक: फैक्टोरियो ने 200-प्लेयर मल्टीप्लेयर समस्या को कैसे हल किया

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हमने सभी अपडेट एज मामलों और देरी कतार समर्थन को ठीक करके इस समस्या का समाधान किया है। हालांकि इसमें काफी समय लगा, लेकिन त्वरित हैक्स पर भरोसा करने के बजाय अंत में इसे ठीक करना उचित था।

स्रोत: www.habr.com