मिनी आइ कप 2 या लगभग अगरियो - जीतने के लिए क्या किया जा सकता है

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



कटौती के तहत बहुत सारे जिफ़ और ट्रैफ़िक।

लगातार लोग इसका पता लगा लेंगे, बाकी लोग डरावनी ( संक्षिप्त संकुचित भाग पर टिप्पणियों से) भाग जाएंगे।

जो लोग बहुत पढ़ने के लिए आलसी हैं , वे एल्गोरिथ्म के संक्षिप्त संक्षिप्त विवरण को देखने के लिए लेख के सबसे खराब स्पॉइलर पर जा सकते हैं , और फिर आप शुरुआत से पढ़ना शुरू कर सकते हैं ।

गीथूब पर स्रोत से लिंक करें

उपकरण चयन

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

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

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

शुरुआत

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

और फिर ... मैंने विकल्पों का पता लगाना शुरू किया, इसे कैसे विकसित किया जाए। उस समय विचार:

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

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

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

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


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

एक सिमुलेशन लेखन

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

उस पल में प्रत्येक टिक के लिए रेटिंग फंक्शन मेरे द्वारा खाए गए भोजन के लिए +1 था और दुश्मन द्वारा खाए गए भोजन के लिए -1, साथ ही साथ एक-दूसरे के agarics खाने के लिए थोड़ा बड़ा मूल्य था। अन्य agarics खाने के लिए स्थिरांक में, शुरू में मेरे प्रतिद्वंद्वी, मेरे प्रतिद्वंद्वी (और निश्चित रूप से, प्रतिद्वंद्वी द्वारा मेरी आखिरी अग्रिका खाने के लिए एक बहुत बड़ा जुर्माना) खाने के बीच एक अंतर था, साथ ही एक दूसरे के दो अलग-अलग विरोधियों (कुछ दिनों के बाद अंतिम गुणांक 0 हो गया)। इसके अलावा, सिमुलेशन के सभी पिछले टिक्स के लिए कुल गति, प्रत्येक टिक को 1 + 1e-5 से गुणा किया गया था, जो कि मेरे बॉट को कम से कम थोड़ी देर पहले अधिक उपयोगी कार्य करने के लिए प्रोत्साहित करेगा, और सिमुलेशन के अंत में, अंतिम टिक के लिए गति को बोनस के रूप में जोड़ा गया, बहुत छोटा । आगरिक्स की गति को अनुकरण करने के लिए, अंक को मेरे सभी एग्रिक्स के अंकगणितीय माध्य निर्देशांक से 15 डिग्री के कदम के साथ नक्शे के किनारे पर चुना गया था, और एक बिंदु का चयन किया गया था, जब आंदोलन को अंजाम देने के लिए अनुमान लगाया गया कि फ़ंक्शन सबसे बड़े मूल्य पर ले गया था। और पहले से ही इस तरह के प्रतीत होता है आदिम सिमुलेशन और उस समय एक सरल आकलन के साथ, बॉट ने आत्मविश्वास से शीर्ष 10 में खुद को उलझा दिया।


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

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

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

चलिए आगे बढ़ते हैं

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

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


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

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


प्राप्त किए गए मूल्यांकन फ़ंक्शन को द्रव्यमान के मूल्यांकन में स्थानांतरित करने के प्रयास भी थे, प्रतिद्वंद्वी के खतरे का मूल्यांकन करने के फ़ंक्शन को बदलने का प्रयास ... लेकिन फिर से, भावनाओं में इस तरह के सभी परिवर्तनों ने और भी बदतर बना दिया। केवल एक चीज जो दुश्मन के करीब होने के खतरे का आकलन करने के कार्य के साथ उपयोगी थी, दुश्मन के साथ चौराहे की त्रिज्या की तुलना में बहुत बड़े त्रिज्या के लिए इस अनुमान को विस्तारित करने के साथ-साथ एक और प्रदर्शन अनुकूलन था (वास्तव में, पूरा नक्शा, लेकिन एक द्विघात कमी के साथ, अगर थोड़ा सरल किया जाए - खाने के अधिकतम खतरे के 1/25 के क्षेत्र में प्रतिद्वंद्वी से पांच या अधिक रेडी में उपस्थिति दर्ज करना)। अंतिम परिवर्तन भी इस तथ्य के कारण हुआ कि मेरे अग्रिकों को एक बहुत बड़े दुश्मन से संपर्क करने में बहुत डर लगा, साथ ही साथ उनके बहुत बेहतर आकारों के मामले में प्रतिद्वंद्वी की ओर बढ़ने की अधिक इच्छा थी। इस प्रकार, यह भविष्य के लिए नियोजित कोड के लिए एक सफल और संसाधन-गहन प्रतिस्थापन नहीं निकला, जो कि विभाजन के माध्यम से एक प्रतिद्वंद्वी द्वारा हमले के डर के लिए जिम्मेदार माना जाता था (और बाद में मुझ पर इस तरह के हमले में थोड़ी मदद)।

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

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


इसके अलावा, आंदोलन सिमुलेशन के बिंदुओं को मानचित्र के किनारे पर बिंदुओं में जोड़ा गया था: प्रतिद्वंद्वियों के प्रत्येक अगर में और अंकगणित माध्य के एक त्रिज्या के भीतर हर 45 डिग्री पर मेरे agarics का समन्वय। त्रिज्या मेरे agarics के अंकगणितीय माध्य निर्देशांक से avgDistance के लिए निर्धारित किया गया था।

अंतिम तैयारी

25k टिक्स के लिए खेल के उद्घाटन और फाइनल में पास होने के समय, मेरे पास एक ठोस मार्जिन था, लेकिन मैंने आराम करने की योजना नहीं बनाई थी।

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


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

एक निष्कर्ष के बजाय

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