एआई एजेंट अपने पर्यावरण के बारे में जानकारी कैसे प्राप्त करते हैं?


9

यह एक तुच्छ प्रश्न हो सकता है, लेकिन मुझे यह समझने में परेशानी हो रही है। आपकी मदद की बहुत सराहना करेंगे।

ऑब्जेक्ट ओरिएंटेड डिज़ाइन का उपयोग करते हुए गेम डेवलपमेंट में, मैं यह समझना चाहता हूं कि एआई-एजेंट अपने कार्यों को करने के लिए गेम की दुनिया से जो जानकारी चाहते हैं, वे कैसे एक्सेस करते हैं।

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

मेरी समस्या यह है कि मुझे यकीन नहीं है कि यह कैसे करना है। एआई एजेंट खेल की दुनिया के बारे में जानकारी की आवश्यकता तक कैसे पहुंच सकता है?

एक संभावित दृष्टिकोण यह है कि एजेंट केवल खेल जगत से सीधे उन सूचनाओं का अनुरोध करते हैं जिनकी उन्हें आवश्यकता है।

गेमवर्ल्ड नामक एक वर्ग है। यह महत्वपूर्ण गेम लॉजिक (गेम लूप, टकराव का पता लगाने, आदि) को संभालता है, और खेल में सभी संस्थाओं के संदर्भ भी रखता है।

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

उदाहरण के लिए, एक एजेंट Seekखिलाड़ी के लिए प्रोग्राम किया जा सकता है जब वह करीब है। ऐसा करने के लिए एजेंट को खिलाड़ी का स्थान प्राप्त करना होता है। तो यह बस सीधे अनुरोध कर सकते हैं GameWorld.instance().getPlayerPosition():।

एक एजेंट भी खेल में सभी संस्थाओं की सूची प्राप्त कर सकता है, और इसकी ज़रूरतों के लिए इसका विश्लेषण कर सकता है (यह पता लगाने के लिए कि कौन सी संस्थाएँ पास हैं, या कुछ और भी हैं): GameWorld.instance().getEntityList()

यह सबसे सरल तरीका है: एजेंट सीधे गेमवर्ल्ड वर्ग से संपर्क करते हैं और उन्हें आवश्यक जानकारी प्राप्त करते हैं। हालाँकि, यह एकमात्र तरीका है जो मुझे पता है। क्या कोई बेहतर है?

एक अनुभवी गेम डेवलपर इसे कैसे डिजाइन करेगा? क्या "सभी संस्थाओं की एक सूची प्राप्त करें और आपको जो कुछ भी चाहिए उसके लिए देखें" एआई एजेंटों को अपने कार्यों को करने के लिए आवश्यक जानकारी तक पहुंचने के लिए कौन से दृष्टिकोण और तंत्र हैं?


यदि आपके पास जीडीसी वॉल्ट की सदस्यता है, तो 2013 में एक उत्कृष्ट बातचीत हुई, जिसे "एआई फॉर द लिविंग, ब्रीथिंग वर्ल्ड ऑफ हिटमैन एबोल्यूशन" कहा गया, जो विस्तार से उनके एआई ज्ञान मॉडल में जाता है।
DMGregory

जवाबों:


5

आप जो वर्णन करते हैं वह दुनिया को क्वेरी करने का एक क्लासिक "पुल" मॉडल है। ज्यादातर समय, यह बहुत अच्छी तरह से काम करता है, विशेष रूप से मूल एआई (जो कि सबसे अधिक है) वाले खेलों के लिए। हालाँकि, कुछ बिंदु हैं जिन पर आपको विचार करना चाहिए कि वे डाउनसाइड हो सकते हैं:

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

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

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

  • अंत में, आप शायद विरासत के बजाय अपनी खोज योग्य वस्तुओं के लिए इंटरफेस या घटकों का उपयोग करना चाहते हैं, जो कहीं और अच्छी तरह से प्रलेखित है। Entitiesजाँच की एक सूची से अधिक instanceOfशायद ही नाजुक कोड के लिए एक नुस्खा है, जिस मिनट को आप StaticObjectऔर दोनों चाहते MovingObjectहैं Healable। (जब तक instanceOfआपकी पसंद की भाषा में इंटरफेस के लिए काम न करें।)


5

एआई महंगा होने के कारण, प्रदर्शन अक्सर वास्तुकला में ड्राइविंग कारक है।

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

(प्रत्येक उदाहरण एक एकल, वैश्विक तर्क अद्यतन मानता है।)

  • एक * सबसे छोटा रास्ताप्रत्येक AI पथ-निर्धारण उद्देश्यों के लिए मानचित्र की स्थिति की गणना करता है। A * के लिए आवश्यक है कि प्रत्येक AI पहले से ही पूरे (स्थानीय) वातावरण को जानता हो, जिसमें उसे pathfind करना होगा, इसलिए हमें इसे मानचित्र बाधाओं और स्थान (अक्सर एक 2D बूलियन सरणी) के बारे में जानकारी सौंपनी होगी। ए * दिज्क्स्ट्रा के एल्गोरिथ्म का एक विशेष रूप है, एक छोटा रास्ता खुला ग्राफ खोज एल्गोरिदम; इस तरह के दृष्टिकोण पथ का प्रतिनिधित्व करने वाली सूची लौटाते हैं, और प्रत्येक चरण पर, एआई इस सूची में अगले नोड का चयन करने के लिए कदम रखता है, जब तक कि यह अपने लक्ष्य तक नहीं पहुंचता है या पुनर्गणना आवश्यक है (उदाहरण के लिए नक्शा बाधा परिवर्तन के कारण)। इस ज्ञान के बिना, कोई यथार्थवादी सबसे छोटा रास्ता नहीं मिल सकता है। A * यही कारण है कि RTS खेलों में AI हमेशा जानते हैं कि बिंदु A से बिंदु B तक कैसे पहुँचें - यदि कोई पथ मौजूद है। यह प्रत्येक व्यक्ति एआई के लिए सबसे छोटा रास्ता पुनर्गणना करेगा, क्योंकि पथ वैधता उन AI की स्थिति पर आधारित है जो पहले स्थानांतरित हो चुके हैं (और संभवतः कुछ पथ अवरुद्ध हो गए हैं)। पुनरावृत्ति के दौरान ए * द्वारा सेल मूल्यों की गणना करने वाली पुनरावृति प्रक्रिया गणितीय अभिसरण में से एक है। कोई कह सकता है कि अंतिम परिणाम दृष्टि की भावना के साथ मिश्रित गंध की भावना जैसा दिखता है, लेकिन सभी में यह हमारी मानसिकता से कुछ हद तक अलग है।

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

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

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

वास्तुकला अंक

यह स्पष्ट हो जाता है कि हम AI के लिए सिर्फ एक सही डेटा एक्सेस पैटर्न नहीं मान सकते हैं; चुनाव इस बात पर निर्भर करता है कि आप क्या हासिल करना चाहते हैं। GameWorldसीधे कक्षा तक पहुँचना पूरी तरह से मानक है: यह आपको दुनिया की जानकारी प्रदान करता है। अनिवार्य रूप से यह आपका डेटा मॉडल है, और यही डेटा मॉडल के लिए है। इसके लिए सिंगलटन ठीक है।

"सभी संस्थाओं की एक सूची प्राप्त करें और आपको जो कुछ भी चाहिए उसकी तलाश करें"

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


जवाब के लिए धन्यवाद। जब से मैं खेल देव के लिए एक शुरुआत कर रहा हूं, मुझे लगता है कि मैं सरल से चिपके रहूंगा "गेम वर्ल्ड से एक सूची प्राप्त करें" अब के लिए दृष्टिकोण :) एक प्रश्न: मेरे प्रश्न में मैंने GameWorldकक्षा को उस वर्ग के रूप में वर्णित किया है जिसमें संदर्भ हैं सभी गेम इकाइयाँ, और इसमें अधिकांश महत्वपूर्ण 'इंजन' तर्क भी शामिल हैं: मुख्य गेम लूप, टकराव का पता लगाना, आदि। यह मूल रूप से खेल का 'मुख्य वर्ग' है। मेरा सवाल है: क्या यह खेल में आम है? एक 'मुख्य वर्ग' है? या क्या मुझे इसे छोटी कक्षाओं में अलग करना चाहिए और एक 'एंटिटी डेटाबेस' ऑब्जेक्ट के रूप में एक वर्ग हो सकता है?
अवीव कोहन

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

2

मूल रूप से मेरे पास जानकारी को क्वेरी करने के 2 तरीके होंगे।

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

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

    Transform* targetTransform = nullptr;
    EnemyAIState  AIState = EnemyAIState::Idle;
    void OnTriggerEnter(GameObject* go)
    {
       if(go->hasTag(TAG_PLAYER))
       {
       //Cache important information that will be needed during pursuit
       targetTransform = go->getComponent<Transform>();
       AIState = EnemyAIState::Pursue;
       }
    }
    
    void Update()
    {
       switch(AIState)
       {
          case EnemyAIState::Pursue:
           //Find position to move to
           Vector3 nextNode = PathSystem::Seek(
                              transform->position,targetTransform->position);
           /*Update the position towards the target by whatever speed the unit moves
             Depending on how robust your path system is you might want to raycast
             against obstacles it can't take into account or might clip the path.*/
            transform->Move((nextNode - transform->position).unitVector()*speed*Time::deltaTime());
            break;
        }
     }
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.