टैंक्स ब्लिट्ज की टीम बैलेन्स कैसे काम करती है

WoT ब्लिट्ज एक मोबाइल टैंक शूटर है जिसमें खिलाड़ी 7 में 7 फॉर्मेट में लड़ते हैं।
एक मैचमेकर, या बैलेंसर, एक ऐसा तंत्र है जो लड़ाई में उतरने के इच्छुक खिलाड़ियों की लाइनअप के आधार पर टीमों की रचना करता है।

मंगनी के लिए टैंकों के निम्नलिखित पैरामीटर महत्वपूर्ण हैं:

• स्तर। स्तर के आधार पर, टैंकों की विभिन्न विशेषताओं में परिवर्तन होता है (उदाहरण के लिए, गति, कवच प्रवेश)। 1 स्तर पर - सबसे कमजोर टैंक, 10 वें पर - सबसे मजबूत।
  
• टाइप करें। WoT ब्लिट्ज में 4 प्रकार के टैंक हैं: प्रकाश, मध्यम, भारी और टैंक विध्वंसक (एंटी-टैंक सेल्फ-प्रोपेल्ड आर्टरी)
  

एक मैचमेकर का सबसे सरल कार्यान्वयन खिलाड़ियों को टीमों में बेतरतीब ढंग से फेंकना है। लेकिन इस मामले में, निचले स्तर के खिलाड़ियों को कम से कम कुछ नुकसान होने का कोई मौका नहीं होगा, और यह खेलने के लिए उदासीन हो जाएगा।

आवश्यकताओं

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

नियमित लड़ाई के लिए लेख लिखने के समय, सूची में निम्नलिखित आइटम शामिल थे:


एक मैचमेकर को विकसित करने के लिए, विशेष रूप से इस तरह के प्रतिबंधों पर विचार करना, एक बहुत ही दिलचस्प काम है। और इसके समाधान के लिए दृष्टिकोण काफी हो सकते हैं।

खिलाड़ियों की एक जोड़ी के रूप में Balancer

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


लड़ाई की शुरुआत

इसलिए, एक और बैलेंसर लिखा गया था, जो निम्नलिखित एल्गोरिथम के अनुसार काम करता था:

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

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

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


मैचमेकर में बग - 9 पर 9 टीम इकट्ठी हुई

सिलेक्टेड एनीलिंग Balancer

अंतिम संस्करण में, हम एक बैलेंसर पर बस गए जो निम्नलिखित एल्गोरिथम के अनुसार काम करता है। "टू बैटल" बटन पर क्लिक करने वाले सभी खिलाड़ी सामान्य कतार में आते हैं। एक अंतहीन लूप बैलेंसर निम्नलिखित करता है:

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

उपयुक्त खिलाड़ियों की सूची से टीमों को बनाने के लिए, एनीलिंग सिमुलेशन विधि का उपयोग किया जाता है। विधि के बारे में यहाँ और अधिक पढ़ें।


एनीलिंग का अनुकरण करके वैश्विक अधिकतम के लिए खोजें

टीमों के गठन के लिए आवेदन के संदर्भ में, एल्गोरिथ्म इस प्रकार है:

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

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

इस तरह के नियमों को जोड़ने का एक अच्छा उदाहरण रेटिंग लड़ाई है। मैचमेकर की रेटिंग की लड़ाई में, एक साथ कई नए नियम सामने आए:

• टीमों को रेटिंग के मामले में संतुलित होना चाहिए (टीमों के बीच खिलाड़ियों की कुल रेटिंग में अंतर किसी दिए गए मूल्य से अधिक नहीं होना चाहिए);
  
• खिलाड़ियों के बीच रेटिंग में अंतर न्यूनतम होना चाहिए (कांस्य लीग के खिलाड़ियों को हीरे से खिलाड़ियों के साथ झगड़े में नहीं आना चाहिए)।
  

डायमंड लीग खिलाड़ी प्रोफ़ाइल उदाहरण

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

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


आरयू सर्वर पर प्रतीक्षा समय और कतार का आकार (सामान्य लड़ाइयों में 5 सेकंड और रेटिंग लड़ाई में 10)

जैसे-जैसे ऑनलाइन विकास बढ़ता गया, वैसे-वैसे बैलेंसर पर भार बढ़ता गया। यह गिरावट, जब आरयू सर्वर पर ऑनलाइन सर्वर 120 हजार तक पहुंच गया (मैड गेम्स इवेंट के दौरान), बैलेंसर सामना करना बंद कर दिया। एक अस्थायी उपाय के रूप में, हमने कुछ नियमों को अक्षम कर दिया, इससे हमें भार कम करने की अनुमति मिली। भविष्य में ऐसी समस्याओं से बचने के लिए, हमने मैचमेकर को वितरित किया।

रेटिंग प्रणाली

डायमंड लीग में सर्वश्रेष्ठ खिलाड़ी, 21 अप्रैल 2019

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

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

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

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

सटीकता की गणना इस प्रकार की गई:

• सभी खिलाड़ियों को एक शुरुआती रेटिंग दी गई थी;
  
• प्रत्येक लड़ाई के परिणामों के आधार पर, इस लड़ाई में भाग लेने वाले खिलाड़ियों की रेटिंग चयनित प्रणाली के अनुसार पुनर्गणना की गई थी;
  
• प्रत्येक लड़ाई से पहले, सिस्टम ने यह अनुमान लगाने की कोशिश की कि कौन सी टीम जीतेगी;
  
• नतीजतन, लड़ाई का प्रतिशत जिसके लिए सिस्टम ने सही भविष्यवाणी दी थी, की गणना की गई थी।
  

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

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



एलो प्रणाली द्वारा सबसे अच्छे परिणाम दिखाए गए, जिसमें आरए प्लेयर रेटिंग है, और आरबी विरोधी टीम की कुल रेटिंग और खिलाड़ी की टीम की कुल रेटिंग के बीच का अंतर है, जिसमें खिलाड़ी खुद अपवाद है।

लॉन्च के बाद हमें जो मुख्य कठिनाइयाँ हुईं:

• खिलाड़ियों के बीच रैंकिंग में बहुत अधिक भिन्नता;
  
• खिलाड़ियों के स्कोर (लीग तक पहुंचने) पर सबसे खराब पूर्वानुमानित गति।
  

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

हमने एक धीमा कारक पेश करके दूसरी समस्या को हल किया (यानी, खिलाड़ी औसत रेटिंग से जितना दूर होता है, उसके लिए नीचे उठना या गिरना उतना ही मुश्किल होता है)।

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

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


विजेता टीम के खिलाड़ी जिन्होंने अच्छा प्रदर्शन किया, उन्हें +40 रेटिंग मिली। और जो सिर्फ +10 खराब है

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

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

निष्कर्ष

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

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

यदि आपके पास वाह ब्लिट्ज में एक बैलेंसर पर कोई प्रश्न / सुझाव है, तो टिप्पणियों में सदस्यता लें (या हमारे मंच पर )।