मेगापॅक: फॅक्टोरिओने 200-प्लेअर मल्टीप्लेअर समस्या कशी सोडवली

या वर्षीच्या मे महिन्यात मी खेळाडू म्हणून भाग घेतला MMO इव्हेंट KatherineOfSky. माझ्या लक्षात आले की जेव्हा खेळाडूंची संख्या एका विशिष्ट संख्येपर्यंत पोहोचते तेव्हा दर काही मिनिटांनी त्यांच्यापैकी काही “पडतात”. सुदैवाने तुमच्यासाठी (परंतु माझ्यासाठी नाही), मी डिस्कनेक्ट झालेल्या खेळाडूंपैकी एक होतो प्रत्येक वेळी, अगदी चांगल्या कनेक्शनसह. मी हे वैयक्तिक आव्हान म्हणून घेतले आणि समस्येची कारणे शोधण्यास सुरुवात केली. तीन आठवड्यांच्या डीबगिंग, चाचणी आणि निराकरणानंतर, दोष शेवटी निश्चित केला गेला, परंतु प्रवास इतका सोपा नव्हता.

मल्टीप्लेअर गेममधील समस्यांचा मागोवा घेणे खूप कठीण आहे. ते सहसा अतिशय विशिष्ट नेटवर्क पॅरामीटर्स आणि अतिशय विशिष्ट गेम परिस्थितींमध्ये (या प्रकरणात, 200 पेक्षा जास्त खेळाडू असतात). आणि जेव्हा समस्या पुनरुत्पादित केली जाऊ शकते, तरीही ती योग्यरित्या डीबग केली जाऊ शकत नाही कारण ब्रेकपॉइंट्स टाकल्याने गेम थांबतो, टाइमर गोंधळतो आणि सहसा कनेक्शन कालबाह्य होते. पण चिकाटी धन्यवाद आणि एक आश्चर्यकारक साधन म्हणतात बोजड मी काय चालले आहे ते शोधण्यात व्यवस्थापित केले.

थोडक्यात, लेटन्सी स्टेट सिम्युलेशनच्या बग आणि अपूर्ण अंमलबजावणीमुळे, क्लायंटला कधीकधी अशा परिस्थितीत सापडेल जिथे त्याला एका घड्याळाच्या चक्रात सुमारे 400 गेम घटकांच्या प्लेअरच्या इनपुट निवड क्रियांचा समावेश असलेले नेटवर्क पॅकेट पाठवावे लागते ( आम्ही याला "मेगा-पॅकेट" म्हणतो). नंतर सर्व्हरने या सर्व इनपुट क्रिया योग्यरित्या प्राप्त केल्या पाहिजेत, परंतु त्या इतर सर्व क्लायंटना पाठवाव्यात. आपल्याकडे 200 क्लायंट असल्यास, ही त्वरीत समस्या बनते. सर्व्हरची लिंक त्वरीत बंद होते, ज्यामुळे पॅकेटचे नुकसान होते आणि पुन्हा विनंती केलेल्या पॅकेट्सचा कॅस्केड होतो. इनपुट अॅक्शनला उशीर केल्याने आणखी क्लायंट मेगापॅकेट्स पाठवतात, ज्यामुळे हिमस्खलन आणखी मोठे होते. भाग्यवान क्लायंट पुनर्प्राप्त करण्यात व्यवस्थापित करतात; इतर सर्व खाली पडतात.


समस्या अगदी मूलभूत होती आणि ती दूर करण्यासाठी मला 2 आठवडे लागले. हे खूपच तांत्रिक आहे, म्हणून मी खाली रसाळ तांत्रिक तपशील स्पष्ट करेन. परंतु प्रथम, आपल्याला हे माहित असणे आवश्यक आहे की आवृत्ती 0.17.54 पासून, 4 जून रोजी, तात्पुरत्या कनेक्शन समस्यांमुळे, मल्टीप्लेअर अधिक स्थिर झाले आहे, आणि विलंब लपवणे खूपच कमी बग्गी (कमी मंदी आणि टेलिपोर्टिंग) झाले आहे. मी कॉम्बॅट लॅग लपवण्याचा मार्ग देखील बदलला आहे आणि मला आशा आहे की यामुळे ते थोडे नितळ होईल.

मल्टीप्लेअर मेगा पॅक - तांत्रिक तपशील

सोप्या भाषेत सांगायचे तर, गेममधील मल्टीप्लेअर असे कार्य करते: सर्व क्लायंट गेमच्या स्थितीचे अनुकरण करतात, फक्त प्लेअर इनपुट प्राप्त करतात आणि पाठवतात (ज्याला "इनपुट क्रिया" म्हणतात, इनपुट क्रिया). सर्व्हरचे मुख्य कार्य हस्तांतरित करणे आहे इनपुट क्रिया आणि सर्व क्लायंट एकाच घड्याळ चक्रात समान क्रिया करतात हे नियंत्रित करा. आपण पोस्टमध्ये याबद्दल अधिक वाचू शकता FFF-149.

सर्व्हरने कोणत्या क्रिया करायच्या याबद्दल निर्णय घेणे आवश्यक असल्याने, खेळाडूच्या क्रिया या मार्गावर अंदाजे हलतात: खेळाडू क्रिया -> गेम क्लायंट -> नेटवर्क -> सर्व्हर -> नेटवर्क -> गेम क्लायंट. याचा अर्थ असा की प्रत्येक खेळाडूची क्रिया संपूर्ण नेटवर्कवर फेरी मारल्यानंतरच केली जाते. यामुळे, गेम खूपच मंद वाटेल, म्हणून गेममध्ये मल्टीप्लेअरचा परिचय झाल्यानंतर लगेचच, विलंब लपविण्यासाठी एक यंत्रणा सुरू करण्यात आली. विलंब लपवणे इतर खेळाडूंच्या क्रिया आणि सर्व्हरचे निर्णय विचारात न घेता प्लेअर इनपुटचे अनुकरण करते.

फॅक्टोरिओमध्ये खेळाची स्थिती आहे खेळ राज्य कार्ड, खेळाडू, संस्था आणि इतर सर्व गोष्टींची संपूर्ण स्थिती आहे. सर्व्हरकडून प्राप्त झालेल्या क्रियांच्या आधारे सर्व क्लायंटमध्ये ते निश्चितपणे अनुकरण केले जाते. गेम स्टेट पवित्र आहे, आणि जर ते सर्व्हर किंवा इतर कोणत्याही क्लायंटपेक्षा वेगळे होऊ लागले, तर डिसिंक होते.

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

या उद्देशासाठी, आम्ही तयार केलेल्या प्रत साठवतो इनपुट क्रिया विलंब रांगेत.

म्हणजेच, क्लायंटच्या बाजूने प्रक्रियेच्या शेवटी चित्र असे काहीतरी दिसते:

1. आम्ही अर्ज करतो इनपुट क्रिया सर्व खेळाडूंना खेळ राज्य सर्व्हरकडून या इनपुट क्रिया ज्या प्रकारे प्राप्त झाल्या.
2. आम्ही विलंब रांगेतून सर्वकाही काढून टाकतो इनपुट क्रिया, जे, सर्व्हरनुसार, आधीच लागू केले गेले आहे खेळ राज्य.
3. हटवा विलंब स्थिती आणि ते रीसेट करा जेणेकरून ते अगदी सारखे दिसेल खेळ राज्य.
4. आम्ही विलंब रांगेपासून सर्व क्रिया लागू करतो विलंब स्थिती.
5. डेटावर आधारित खेळ राज्य и विलंब स्थिती आम्ही खेळाडूला गेम प्रस्तुत करतो.

हे सर्व प्रत्येक मापात पुनरावृत्ती होते.

खूप कठीण? आराम करू नका, हे सर्व नाही. अविश्वसनीय इंटरनेट कनेक्शनची भरपाई करण्यासाठी, आम्ही दोन यंत्रणा तयार केल्या आहेत:

• चुकलेल्या टिक्स: जेव्हा सर्व्हर ठरवतो इनपुट क्रिया खेळाच्या बीटवर अंमलात आणला जाईल, नंतर तो प्राप्त झाला नाही तर इनपुट क्रिया काही खेळाडू (उदाहरणार्थ, वाढलेल्या विलंबामुळे), तो प्रतीक्षा करणार नाही, परंतु या क्लायंटला सूचित करेल “मी तुमचा विचार केला नाही इनपुट क्रिया, मी त्यांना पुढील बारमध्ये जोडण्याचा प्रयत्न करेन. हे केले जाते जेणेकरून एका प्लेअरच्या कनेक्शन (किंवा संगणक) समस्यांमुळे, नकाशा अद्यतन प्रत्येकासाठी मंद होत नाही. हे लक्षात घेण्यासारखे आहे इनपुट क्रिया दुर्लक्षित नाहीत, परंतु फक्त बाजूला ठेवले आहेत.
• पूर्ण राउंड-ट्रिप लेटन्सी: सर्व्हर प्रत्येक क्लायंटसाठी क्लायंट आणि सर्व्हरमधील राउंड-ट्रिप लेटन्सी काय आहे याचा अंदाज लावण्याचा प्रयत्न करतो. प्रत्येक 5 सेकंदाला, ते आवश्यक असल्यास क्लायंटसोबत नवीन विलंबतेची वाटाघाटी करते (भूतकाळात कनेक्शन कसे वागले आहे यावर आधारित), आणि त्यानुसार राउंड-ट्रिप लेटन्सी वाढवते किंवा कमी करते.

त्यांच्या स्वत: च्या वर, या यंत्रणा अगदी सोप्या आहेत, परंतु जेव्हा ते एकत्र वापरले जातात (जे सहसा कनेक्शनच्या समस्यांसह होते), कोडचे तर्क व्यवस्थापित करणे कठीण होते आणि बर्‍याच एज केसेससह. याव्यतिरिक्त, जेव्हा ही यंत्रणा कार्यान्वित होते, तेव्हा सर्व्हर आणि विलंब रांगेने योग्यरित्या विशेष अंमलबजावणी करणे आवश्यक आहे इनपुट क्रिया म्हणतात StopMovementInTheNextTick. याबद्दल धन्यवाद, कनेक्शनमध्ये समस्या असल्यास, वर्ण स्वतःहून चालणार नाही (उदाहरणार्थ, ट्रेनच्या समोर).

आता आम्‍हाला तुम्‍हाला स्‍पष्‍ट करण्‍याची आवश्‍यकता आहे की घटक निवड कशी कार्य करते. प्रसारित प्रकारांपैकी एक इनपुट क्रिया घटक निवड स्थितीत बदल आहे. खेळाडू कोणत्या घटकावर फिरत आहे हे प्रत्येकाला सांगते. तुम्ही कल्पना करू शकता की, क्लायंटद्वारे पाठवलेल्या सर्वात सामान्य इनपुट क्रियांपैकी ही एक आहे, म्हणून बँडविड्थ जतन करण्यासाठी, आम्ही शक्य तितक्या कमी जागा घेण्यासाठी ते ऑप्टिमाइझ केले आहे. त्याचे कार्य करण्याचा मार्ग असा आहे की प्रत्येक घटक निवडला गेल्याने, परिपूर्ण, उच्च-परिशुद्धता नकाशा निर्देशांक संचयित करण्याऐवजी, गेम मागील निवडीतील कमी-परिशुद्धता सापेक्ष ऑफसेट संचयित करतो. हे चांगले कार्य करते कारण माऊसची निवड मागील निवडीच्या अगदी जवळ असते. हे दोन महत्त्वपूर्ण आवश्यकता वाढवते: इनपुट क्रिया ते कधीही वगळले जाऊ नयेत आणि योग्य क्रमाने पूर्ण केले पाहिजेत. साठी या आवश्यकता पूर्ण केल्या जातात खेळ राज्य. पण कार्य पासून विलंब स्थिती खेळाडूसाठी "पुरेसे चांगले दिसत" मध्ये, ते विलंब स्थितीत समाधानी नाहीत. विलंब स्थिती विचारात घेत नाही अनेक धार प्रकरणे, घड्याळाची चक्रे वगळणे आणि राउंड-ट्रिप ट्रान्समिशन विलंब बदलण्याशी संबंधित.

हे कुठे चालले आहे याचा अंदाज तुम्ही आधीच लावू शकता. आम्ही शेवटी मेगाबंडल समस्येची कारणे पाहण्यास सुरुवात करत आहोत. समस्येचे मूळ हे आहे की अस्तित्व निवड तर्कावर अवलंबून आहे विलंब स्थिती, आणि या स्थितीत नेहमीच योग्य माहिती नसते. म्हणून, मेगापॅकेट असे काहीतरी व्युत्पन्न केले जाते:

1. खेळाडूला कनेक्शन समस्या आहेत.
2. घड्याळाची चक्रे वगळण्यासाठी आणि राउंड-ट्रिप ट्रान्समिशनच्या विलंबाचे नियमन करण्याच्या यंत्रणा कार्यात येतात.
3. विलंब राज्य रांगेत या यंत्रणा विचारात घेत नाहीत. यामुळे काही क्रिया वेळेपूर्वी काढल्या जातात किंवा चुकीच्या क्रमाने केल्या जातात, परिणामी चुकीच्या विलंब स्थिती.
4. प्लेअरला कनेक्शनची समस्या आहे आणि, सर्व्हरशी संपर्क साधण्यासाठी, 400 पर्यंत सायकलचे अनुकरण करते.
5. प्रत्येक टिकवर, एक नवीन क्रिया, घटक निवड बदलणे, व्युत्पन्न केले जाते आणि सर्व्हरला पाठवण्यासाठी तयार केले जाते.
6. क्लायंट सर्व्हरवर 400+ घटक निवड बदलांची मेगा-बॅच पाठवतो (आणि इतर क्रियांसह: शूटिंग स्थिती, चालण्याच्या स्थिती इ. देखील या समस्येने ग्रस्त).
7. सर्व्हरला 400 इनपुट क्रिया प्राप्त होतात. कोणत्याही इनपुट क्रिया वगळण्याची परवानगी नसल्यामुळे, ते सर्व क्लायंटना त्या क्रिया करण्यासाठी आदेश देते आणि त्यांना संपूर्ण नेटवर्कवर पाठवते.

गंमत अशी आहे की बँडविड्थ वाचवण्यासाठी डिझाइन केलेली यंत्रणा प्रचंड नेटवर्क पॅकेट्स तयार करते.

अपडेट आणि बॅकलॉग क्यू सपोर्टच्या सर्व एज केसेसचे निराकरण करून आम्ही या समस्येचे निराकरण केले. जरी यास बराच वेळ लागला तरी, शेवटी द्रुत हॅकवर अवलंबून राहण्याऐवजी ते योग्यरित्या मिळवणे योग्य होते.

स्त्रोत: www.habr.com