टॉवर रक्षा खेलों को विकसित करने के लिए एआई और उपयोगिताओं का उपयोग करना

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

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



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

शुरू करने के लिए, हम यह निर्धारित करेंगे कि एआई को टॉवर रक्षा (टीडी) गेम में क्यों आवश्यकता हो सकती है।

सबसे पहले, बॉट को स्तरों के सतही मूल्यांकन के लिए आवश्यक था, खासकर ज्यामिति की जांच के लिए। चूँकि हमारे पास गेम (फ्री डेवलपमेंट) में एक फ्री फील्ड है, बॉट की मदद से हम जल्दी से जाँच सकते हैं कि अलग-अलग बिल्डिंग ऑप्शंस के साथ दुश्मन के पाथ ग्राफ में कितना बदलाव आता है।

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

अगर हम बॉट के सिद्धांत के बारे में बात करते हैं, तो इसमें निम्नलिखित एल्गोरिथ्म थे (पैराग्राफ में बॉट के विकास, इसके विभिन्न पुनरावृत्तियों को भी दिखाया गया है):

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



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

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

1. जाँच करें कि बेस टावरों द्वारा स्तर को विशेष रूप से कितनी आसानी से पारित किया जाता है।
2. ज्यामिति की जांच करें, चाहे तरंगों में से एक पर विकास में असंतुलन हो - वास्तव में, यह जाँच की गई थी कि टावर रखने के लिए कितने सुविधाजनक बिंदु स्तर पर थे, क्या खिलाड़ी के पास अभी भी टॉवर निर्माण स्थलों का विकल्प कम से कम मध्य स्तर तक था।
3. जांचें कि क्या स्तर आम तौर पर पहली लहरों में पहुंच जाता है, बॉट के लिए धन्यवाद, शुरुआती फंडों के पर्याप्त संतुलन की गणना करना संभव था।

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

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

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

रिकॉर्डिंग और लॉग देखना

प्रत्येक खेल सत्र में, निम्नलिखित क्रियाएं दर्ज की गईं:

1. खेल सत्र की शुरुआत / अंत,
2. चालू / बंद विराम,
3. खेल की गति बदलें,
4. प्रारंभिक कॉल तरंगें,
5. AB के निर्देशांक में टॉवर X स्थापित करना,
6. जगह X में टॉवर को अपग्रेड करें,
7. जगह एक्स में टॉवर की बिक्री,
8. नियंत्रण के लिए - एक कप जीवन का नुकसान,
9. नियंत्रण के लिए - जीत / हार का स्तर,
10. नियंत्रण के लिए - लहर में आखिरी रेंगने की हत्या का तथ्य (रेंगना के निर्देशांक लिखे गए हैं)।

लॉग उदाहरण है

level3.lvl start; 03/22/2012 19:39:12;
level3.lvl; 6.41; निर्माण; active_tower; 5.1; 250;
level3.lvl; 10.25; निर्माण; active_tower; 9.1; 190;
level3.lvl; 12.16; उन्नयन; 5.1; 130;
level3.lvl; 13.86; उन्नयन; 9.1; 80;
level3.lvl; 35.68; killlast; wave1; 7.0; 6;
level3.lvl; 60.76; killlast; wave2; 7.0; 10;
level3.lvl; 85.97; निर्माण; splash_tower; 11.0; 190;
level3.lvl; 88.44; lifelose; wave3; 56;
level3.lvl; 88.98; lifelose; wave3; 56;
level3.lvl; 99.08; killlast; wave3; 7.0; 6;

खेल का समय प्रत्येक घटना के लिए लिखा जाता है, समय खेल की गति पर निर्भर नहीं करता है, अर्थात यह वास्तविक से भिन्न हो सकता है।

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

रिकॉर्डिंग गेम का समय आपको यह गणना करने की अनुमति देता है कि खिलाड़ी कितनी जल्दी एक "अड़चन" (दुश्मनों की एक नई लहर) की उपस्थिति पर प्रतिक्रिया करता है।

रीप्ले फ़ाइलें स्वचालित रूप से फोन फ़ाइल सिस्टम में दर्ज की गईं, फिर उन्हें हटा दिया गया और गेम के डेस्कटॉप संस्करण में खेला गया। गेम यूनिटी में लिखा गया है, इसलिए एडिटर में गेम को उसी तरह लॉन्च किया जा सकता है, जिस तरह मोबाइल डिवाइस पर किया जाता है। बेशक, हमने रिप्ले खेलते समय इसका फायदा उठाया।

इसके अलावा, खिलाड़ी के कार्यों के अनुसार, आप देख सकते हैं कि खेल में "सैगिंग" एक्शन घटक क्या है।



यह "मैप" आपको कई अलग-अलग रिप्ले के विश्लेषण का सहारा लिए बिना स्तर की कमजोरियों की पहचान करने की अनुमति देता है, और दृश्य प्रदर्शन आपको गेम स्तर पर लॉग डेटा को बेहतर "ओवरले" करने की अनुमति देता है।

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