مجھے گیمز میں مصنوعی ذہانت کے بارے میں کچھ دلچسپ مواد ملا۔ سادہ مثالوں کا استعمال کرتے ہوئے AI کے بارے میں بنیادی چیزوں کی وضاحت کے ساتھ، اور اس کے اندر اس کی آسان ترقی اور ڈیزائن کے لیے بہت سے مفید ٹولز اور طریقے موجود ہیں۔ انہیں کیسے، کہاں اور کب استعمال کرنا ہے یہ بھی موجود ہے۔
زیادہ تر مثالیں pseudocode میں لکھی گئی ہیں، اس لیے کسی جدید پروگرامنگ کے علم کی ضرورت نہیں ہے۔ کٹ کے نیچے تصاویر اور gifs کے ساتھ متن کی 35 شیٹس ہیں، لہذا تیار ہو جائیں۔
یو پی ڈی میں معذرت خواہ ہوں، لیکن میں پہلے ہی Habré پر اس مضمون کا خود ترجمہ کر چکا ہوں۔ . آپ اس کا ورژن پڑھ سکتے ہیں۔ لیکن کسی وجہ سے مضمون میرے پاس سے گزرا (میں نے تلاش کا استعمال کیا، لیکن کچھ غلط ہو گیا)۔ اور چونکہ میں گیم ڈویلپمنٹ کے لیے وقف ایک بلاگ پر لکھ رہا ہوں، اس لیے میں نے اپنے ترجمہ کے ورژن کو سبسکرائبرز کے لیے چھوڑنے کا فیصلہ کیا (کچھ پوائنٹس کو مختلف طریقے سے فارمیٹ کیا گیا ہے، کچھ کو ڈویلپرز کے مشورے پر جان بوجھ کر چھوڑ دیا گیا ہے)۔
Что такое И И
گیم AI اس بات پر توجہ مرکوز کرتا ہے کہ کسی چیز کو ان حالات کی بنیاد پر کیا کرنا چاہئے جن میں وہ واقع ہے۔ اسے عام طور پر "ذہین ایجنٹ" مینجمنٹ کے طور پر کہا جاتا ہے، جہاں ایک ایجنٹ ایک کھلاڑی کا کردار، ایک گاڑی، ایک بوٹ، یا بعض اوقات کچھ اور خلاصہ ہوتا ہے: اداروں کا ایک پورا گروپ یا یہاں تک کہ ایک تہذیب۔ ہر معاملے میں یہ ایک ایسی چیز ہے جس کے لیے اپنے ماحول کو دیکھنا، اس کی بنیاد پر فیصلے کرنا اور ان کے مطابق عمل کرنا چاہیے۔ اسے سینس/تھنک/ایکٹ سائیکل کہتے ہیں:
- احساس: ایجنٹ اپنے ماحول میں ایسی چیزوں کے بارے میں معلومات ڈھونڈتا یا وصول کرتا ہے جو اس کے رویے پر اثر انداز ہو سکتی ہیں (قریبی خطرات، جمع کرنے کے لیے اشیاء، دریافت کرنے کے لیے دلچسپ مقامات)۔
- سوچیں: ایجنٹ فیصلہ کرتا ہے کہ کس طرح رد عمل ظاہر کرنا ہے (اس بات پر غور کریں کہ آیا اشیاء کو جمع کرنا کافی محفوظ ہے یا اسے پہلے لڑنا/چھپانا چاہیے)۔
- ایکٹ: ایجنٹ پچھلے فیصلے کو نافذ کرنے کے لیے اقدامات کرتا ہے (دشمن یا اعتراض کی طرف بڑھنا شروع کرتا ہے)۔
- ...اب کرداروں کے اعمال کی وجہ سے صورتحال بدل گئی ہے، اس لیے سائیکل نئے ڈیٹا کے ساتھ دہرایا جاتا ہے۔
AI لوپ کے احساس والے حصے پر توجہ مرکوز کرتا ہے۔ مثال کے طور پر، خود مختار کاریں سڑک کی تصویریں لیتی ہیں، انہیں ریڈار اور لیڈر ڈیٹا کے ساتھ جوڑتی ہیں، اور ان کی تشریح کرتی ہیں۔ یہ عام طور پر مشین لرننگ کے ذریعے کیا جاتا ہے، جو آنے والے ڈیٹا پر کارروائی کرتا ہے اور اسے معنی دیتا ہے، معنوی معلومات کو نکالتا ہے جیسے کہ "آپ سے 20 گز آگے ایک اور کار ہے۔" یہ نام نہاد درجہ بندی کے مسائل ہیں۔
گیمز کو معلومات نکالنے کے لیے کسی پیچیدہ نظام کی ضرورت نہیں ہے، کیونکہ زیادہ تر ڈیٹا پہلے سے ہی اس کا لازمی حصہ ہے۔ اس بات کا تعین کرنے کے لیے تصویر کی شناخت کے الگورتھم کو چلانے کی ضرورت نہیں ہے کہ آیا آگے کوئی دشمن ہے — گیم پہلے سے ہی جانتی ہے اور معلومات کو براہ راست فیصلہ سازی کے عمل میں فیڈ کرتی ہے۔ لہذا، سائیکل کا احساس حصہ اکثر سوچ اور عمل کے حصے سے زیادہ آسان ہوتا ہے۔
گیم AI کی حدود
AI کی متعدد حدود ہیں جن کا مشاہدہ کرنا ضروری ہے:
- AI کو پہلے سے تربیت دینے کی ضرورت نہیں ہے، گویا یہ ایک مشین لرننگ الگورتھم ہے۔ دسیوں ہزار کھلاڑیوں کی نگرانی کرنے اور ان کے خلاف کھیلنے کا بہترین طریقہ سیکھنے کے لیے ترقی کے دوران اعصابی نیٹ ورک لکھنا کوئی معنی نہیں رکھتا۔ کیوں؟ کیونکہ کھیل جاری نہیں ہوا ہے اور کوئی کھلاڑی نہیں ہیں۔
- گیم تفریحی اور چیلنجنگ ہونی چاہیے، اس لیے ایجنٹوں کو لوگوں کے خلاف بہترین طریقہ نہیں ڈھونڈنا چاہیے۔
- ایجنٹوں کو حقیقت پسندانہ نظر آنے کی ضرورت ہے تاکہ کھلاڑیوں کو محسوس ہو کہ وہ حقیقی لوگوں کے خلاف کھیل رہے ہیں۔ AlphaGo پروگرام نے انسانوں کو پیچھے چھوڑ دیا، لیکن منتخب کیے گئے اقدامات کھیل کی روایتی سمجھ سے بہت دور تھے۔ اگر کھیل انسانی حریف کی تقلید کرتا ہے، تو یہ احساس موجود نہیں ہونا چاہیے۔ الگورتھم کو تبدیل کرنے کی ضرورت ہے تاکہ یہ مثالی فیصلے کرنے کے بجائے قابل فہم فیصلے کرے۔
- AI کو حقیقی وقت میں کام کرنا چاہیے۔ اس کا مطلب ہے کہ الگورتھم فیصلے کرنے کے لیے طویل عرصے تک CPU کے استعمال پر اجارہ داری نہیں رکھ سکتا۔ یہاں تک کہ 10 ملی سیکنڈز بھی بہت طویل ہیں، کیونکہ زیادہ تر گیمز کو تمام پروسیسنگ کرنے اور اگلے گرافکس فریم پر جانے کے لیے صرف 16 سے 33 ملی سیکنڈز کی ضرورت ہوتی ہے۔
- مثالی طور پر، سسٹم کا کم از کم حصہ ڈیٹا پر مبنی ہونا چاہیے، تاکہ نان کوڈر تبدیلیاں کر سکیں اور ایڈجسٹمنٹ زیادہ تیزی سے ہو سکیں۔
آئیے AI نقطہ نظر کو دیکھتے ہیں جو پورے احساس/سوچ/عمل کے چکر کا احاطہ کرتے ہیں۔
بنیادی فیصلے کرنا
آئیے سب سے آسان کھیل - پونگ کے ساتھ شروع کریں۔ مقصد: پیڈل کو حرکت دیں تاکہ گیند اس کے پاس سے گزرنے کے بجائے اس سے اچھالے۔ یہ ٹینس کی طرح ہے، جہاں اگر آپ گیند کو نہیں مارتے ہیں تو آپ ہار جاتے ہیں۔ یہاں AI کے پاس نسبتاً آسان کام ہے - یہ فیصلہ کرنا کہ پلیٹ فارم کو کس سمت منتقل کیا جائے۔
مشروط بیانات
پونگ میں AI کے لیے، سب سے واضح حل یہ ہے کہ پلیٹ فارم کو ہمیشہ گیند کے نیچے رکھنے کی کوشش کی جائے۔
اس کے لیے ایک سادہ الگورتھم، pseudocode میں لکھا گیا:
کھیل کے چلنے کے دوران ہر فریم/اپ ڈیٹ:
اگر گیند پیڈل کے بائیں طرف ہے:
پیڈل بائیں منتقل کریں
دوسری صورت میں اگر گیند پیڈل کے دائیں طرف ہے:
پیڈل کو دائیں منتقل کریں
اگر پلیٹ فارم گیند کی رفتار سے حرکت کرتا ہے، تو یہ پونگ میں AI کے لیے مثالی الگورتھم ہے۔ اگر ایجنٹ کے لیے اتنا زیادہ ڈیٹا اور ممکنہ کارروائیاں نہ ہوں تو کچھ بھی پیچیدہ کرنے کی ضرورت نہیں ہے۔
یہ نقطہ نظر اتنا آسان ہے کہ پورا احساس/سوچ/ایکٹ سائیکل بمشکل ہی قابل توجہ ہے۔ لیکن یہ وہاں ہے:
- سینس کا حصہ دو اگر بیانات میں ہے۔ گیم جانتا ہے کہ گیند کہاں ہے اور پلیٹ فارم کہاں ہے، لہذا AI اس معلومات کے لیے اس کی طرف دیکھتا ہے۔
- Think حصہ بھی دو اگر بیانات میں شامل ہے۔ وہ دو حلوں کو مجسم کرتے ہیں، جو اس معاملے میں باہمی طور پر خصوصی ہیں۔ نتیجے کے طور پر، تین میں سے ایک عمل کا انتخاب کیا جاتا ہے - پلیٹ فارم کو بائیں طرف لے جائیں، اسے دائیں طرف لے جائیں، یا اگر یہ پہلے سے ہی صحیح پوزیشن میں ہے تو کچھ نہ کریں۔
- ایکٹ کا حصہ Move Paddle Left اور Move Paddle Right بیانات میں پایا جاتا ہے۔ گیم ڈیزائن پر منحصر ہے، وہ پلیٹ فارم کو فوری طور پر یا مخصوص رفتار سے منتقل کر سکتے ہیں۔
اس طرح کے نقطہ نظر کو رد عمل کہا جاتا ہے - اصولوں کا ایک سادہ سیٹ ہے (اس صورت میں اگر کوڈ میں بیانات ہیں) جو دنیا کی موجودہ حالت پر رد عمل ظاہر کرتے ہیں اور کارروائی کرتے ہیں۔
فیصلہ کن درخت
پونگ کی مثال دراصل ایک رسمی AI تصور کے مساوی ہے جسے فیصلہ ٹری کہا جاتا ہے۔ الگورتھم ایک "پتے" تک پہنچنے کے لیے اس سے گزرتا ہے - یہ فیصلہ کہ کیا کارروائی کرنی ہے۔
آئیے اپنے پلیٹ فارم کے الگورتھم کے لیے فیصلے کے درخت کا ایک بلاک ڈایاگرام بنائیں:
درخت کے ہر حصے کو نوڈ کہا جاتا ہے - AI اس طرح کے ڈھانچے کو بیان کرنے کے لیے گراف تھیوری کا استعمال کرتا ہے۔ نوڈس کی دو قسمیں ہیں:
- فیصلہ نوڈس: کچھ حالتوں کی جانچ کی بنیاد پر دو متبادل کے درمیان انتخاب کرنا، جہاں ہر متبادل کو علیحدہ نوڈ کے طور پر دکھایا جاتا ہے۔
- اختتامی نوڈس: انجام دینے کی کارروائی جو حتمی فیصلے کی نمائندگی کرتی ہے۔
الگورتھم پہلے نوڈ (درخت کی "جڑ") سے شروع ہوتا ہے۔ یہ یا تو فیصلہ کرتا ہے کہ کس چائلڈ نوڈ پر جانا ہے، یا یہ نوڈ میں محفوظ کارروائی کو انجام دیتا ہے اور باہر نکل جاتا ہے۔
فیصلے کے درخت کو وہی کام کرنے کا کیا فائدہ ہے جیسا کہ پچھلے حصے میں اگر بیانات ہیں؟ یہاں ایک عمومی نظام ہے جہاں ہر فیصلے کی صرف ایک شرط اور دو ممکنہ نتائج ہوتے ہیں۔ یہ ڈویلپر کو کسی درخت میں سخت کوڈ کیے بغیر فیصلوں کی نمائندگی کرنے والے ڈیٹا سے AI بنانے کی اجازت دیتا ہے۔ آئیے اسے ٹیبل کی شکل میں پیش کرتے ہیں:
کوڈ سائیڈ پر آپ کو سٹرنگز پڑھنے کا سسٹم ملے گا۔ ان میں سے ہر ایک کے لیے ایک نوڈ بنائیں، دوسرے کالم کی بنیاد پر فیصلے کی منطق اور تیسرے اور چوتھے کالم کی بنیاد پر چائلڈ نوڈس بنائیں۔ آپ کو ابھی بھی حالات اور اعمال کو پروگرام کرنے کی ضرورت ہے، لیکن اب گیم کا ڈھانچہ زیادہ پیچیدہ ہوگا۔ یہاں آپ اضافی فیصلے اور اعمال شامل کرتے ہیں، اور پھر صرف ٹری ڈیفینیشن ٹیکسٹ فائل میں ترمیم کرکے پورے AI کو اپنی مرضی کے مطابق بنائیں۔ اگلا، آپ فائل کو گیم ڈیزائنر کو منتقل کرتے ہیں، جو گیم کو دوبارہ مرتب کیے یا کوڈ کو تبدیل کیے بغیر رویے کو تبدیل کر سکتا ہے۔
فیصلہ کرنے والے درخت بہت مفید ہوتے ہیں جب وہ مثالوں کے ایک بڑے سیٹ سے خود بخود بنائے جاتے ہیں (مثال کے طور پر، ID3 الگورتھم کا استعمال کرتے ہوئے)۔ یہ انہیں حاصل کردہ ڈیٹا کی بنیاد پر حالات کی درجہ بندی کرنے کے لیے ایک موثر اور اعلیٰ کارکردگی کا آلہ بناتا ہے۔ تاہم، ہم ایجنٹوں کے لیے کارروائیوں کو منتخب کرنے کے لیے ایک سادہ نظام سے آگے بڑھتے ہیں۔
منظر نامے
ہم نے فیصلہ سازی کے نظام کا تجزیہ کیا جس میں پہلے سے تخلیق شدہ حالات اور اعمال کا استعمال کیا گیا تھا۔ AI کو ڈیزائن کرنے والا شخص جس طرح چاہے درخت کو ترتیب دے سکتا ہے، لیکن اسے پھر بھی اس کوڈر پر انحصار کرنا ہوگا جس نے یہ سب پروگرام کیا ہے۔ کیا ہوگا اگر ہم ڈیزائنر کو ان کے اپنے حالات یا اعمال تخلیق کرنے کے اوزار دے سکیں؟
تاکہ پروگرامر کو Is Ball Left Of Paddle اور Is Ball Right Of Paddle کے حالات کے لیے کوڈ نہیں لکھنا پڑے، وہ ایک ایسا نظام بنا سکتا ہے جس میں ڈیزائنر ان اقدار کو چیک کرنے کے لیے حالات لکھے گا۔ پھر فیصلے کے درخت کا ڈیٹا اس طرح نظر آئے گا:
یہ بنیادی طور پر پہلے ٹیبل کی طرح ہی ہے، لیکن اپنے اندر موجود حلوں کا اپنا کوڈ ہوتا ہے، تھوڑا سا if بیان کے مشروط حصے کی طرح ہوتا ہے۔ کوڈ سائیڈ پر، یہ فیصلہ نوڈس کے لیے دوسرے کالم میں پڑھا جائے گا، لیکن عمل کرنے کے لیے ایک مخصوص حالت تلاش کرنے کے بجائے (کیا گیند پیڈل کا بائیں طرف ہے)، یہ مشروط اظہار کا جائزہ لیتا ہے اور اس کے مطابق درست یا غلط لوٹاتا ہے۔ یہ Lua یا Angelscript اسکرپٹ زبان کا استعمال کرتے ہوئے کیا جاتا ہے۔ ان کا استعمال کرتے ہوئے، ایک ڈویلپر اپنے گیم (بال اور پیڈل) میں اشیاء لے سکتا ہے اور متغیرات بنا سکتا ہے جو اسکرپٹ (ball.position) میں دستیاب ہوں گے۔ اس کے علاوہ، سکرپٹ کی زبان C++ سے زیادہ آسان ہے۔ اسے مکمل تالیف کے مرحلے کی ضرورت نہیں ہے، اس لیے یہ گیم منطق کو تیزی سے ایڈجسٹ کرنے کے لیے مثالی ہے اور "نان کوڈرز" کو خود ضروری افعال تخلیق کرنے کی اجازت دیتا ہے۔
اوپر دی گئی مثال میں، اسکرپٹ کی زبان صرف مشروط اظہار کا اندازہ لگانے کے لیے استعمال ہوتی ہے، لیکن اسے اعمال کے لیے بھی استعمال کیا جا سکتا ہے۔ مثال کے طور پر، ڈیٹا Move Paddle Right ایک اسکرپٹ اسٹیٹمنٹ بن سکتا ہے (ball.position.x += 10)۔ تاکہ عمل کو بھی اسکرپٹ میں بیان کیا جائے، بغیر موو پیڈل رائٹ پروگرام کی ضرورت کے۔
آپ اس سے بھی آگے جا سکتے ہیں اور پورے فیصلے کے درخت کو اسکرپٹ کی زبان میں لکھ سکتے ہیں۔ یہ ہارڈ کوڈ کنڈیشنل اسٹیٹمنٹس کی شکل میں کوڈ ہوگا، لیکن وہ بیرونی اسکرپٹ فائلوں میں موجود ہوں گے، یعنی پورے پروگرام کو دوبارہ مرتب کیے بغیر انہیں تبدیل کیا جاسکتا ہے۔ آپ اکثر گیم پلے کے دوران اسکرپٹ فائل میں ترمیم کر سکتے ہیں تاکہ مختلف AI ردعمل کو تیزی سے جانچ سکیں۔
واقعہ کا جواب
اوپر دی گئی مثالیں پونگ کے لیے بہترین ہیں۔ وہ مسلسل سینس/تھنک/ایکٹ سائیکل چلاتے ہیں اور دنیا کی تازہ ترین حالت کی بنیاد پر عمل کرتے ہیں۔ لیکن زیادہ پیچیدہ کھیلوں میں آپ کو انفرادی واقعات پر ردعمل ظاہر کرنے کی ضرورت ہوتی ہے، اور ایک ہی وقت میں ہر چیز کا اندازہ نہیں لگانا پڑتا ہے۔ اس معاملے میں پونگ پہلے ہی ایک بری مثال ہے۔ آئیے ایک اور کا انتخاب کریں۔
ایک شوٹر کا تصور کریں جہاں دشمن اس وقت تک بے حرکت ہوتے ہیں جب تک کہ وہ کھلاڑی کا پتہ نہیں لگا لیتے، جس کے بعد وہ اپنی "تخصص" کے مطابق کام کرتے ہیں: کوئی "جلدی" کرنے کے لیے بھاگے گا، کوئی دور سے حملہ کرے گا۔ یہ اب بھی ایک بنیادی رد عمل کا نظام ہے - "اگر کسی کھلاڑی کو دیکھا گیا ہے تو کچھ کریں" - لیکن اسے منطقی طور پر پلیئر سین ایونٹ اور ایک ردعمل میں تقسیم کیا جا سکتا ہے (جواب منتخب کریں اور اس پر عمل کریں)۔
یہ ہمیں احساس/سوچ/عمل کے چکر میں واپس لاتا ہے۔ ہم ایک سینس پارٹ کوڈ کر سکتے ہیں جو ہر فریم کو چیک کرے گا کہ آیا AI کھلاڑی کو دیکھتا ہے۔ اگر نہیں، تو کچھ نہیں ہوتا، لیکن اگر یہ دیکھتا ہے، تو پلیئر سیئن ایونٹ بن جاتا ہے۔ کوڈ میں ایک الگ سیکشن ہوگا جو کہتا ہے کہ "جب پلیئر سین ایونٹ ہوتا ہے، تو کرو" جہاں آپ کو تھنک اینڈ ایکٹ کے حصوں کو ایڈریس کرنے کی ضرورت ہوتی ہے۔ اس طرح، آپ پلیئر سین ایونٹ پر ردعمل مرتب کریں گے: "جلدی" کردار کے لیے - ChargeAndAttack، اور سنائپر کے لیے - HideAndSnipe۔ ان رشتوں کو دوبارہ مرتب کیے بغیر فوری ترمیم کے لیے ڈیٹا فائل میں بنایا جا سکتا ہے۔ سکرپٹ کی زبان یہاں بھی استعمال کی جا سکتی ہے۔
مشکل فیصلے کرنا
اگرچہ سادہ ردعمل کے نظام بہت طاقتور ہیں، بہت سے حالات ہیں جہاں وہ کافی نہیں ہیں. بعض اوقات آپ کو ایجنٹ کے اس وقت کیا کر رہا ہے اس کی بنیاد پر مختلف فیصلے کرنے کی ضرورت ہوتی ہے، لیکن شرط کے طور پر اس کا تصور کرنا مشکل ہے۔ بعض اوقات فیصلہ ٹری یا اسکرپٹ میں ان کی مؤثر طریقے سے نمائندگی کرنے کے لیے بہت ساری شرائط ہوتی ہیں۔ بعض اوقات آپ کو اگلے مرحلے کا فیصلہ کرنے سے پہلے پہلے سے اندازہ لگانا پڑتا ہے کہ صورتحال کس طرح بدلے گی۔ ان مسائل کو حل کرنے کے لیے مزید نفیس طریقوں کی ضرورت ہے۔
محدود ریاستی مشین
فائنائٹ سٹیٹ مشین یا ایف ایس ایم (فائنیٹ سٹیٹ مشین) یہ کہنے کا ایک طریقہ ہے کہ ہمارا ایجنٹ اس وقت کئی ممکنہ حالتوں میں سے ایک میں ہے، اور یہ کہ یہ ایک حالت سے دوسری حالت میں منتقل ہو سکتا ہے۔ ایسی ریاستوں کی ایک خاص تعداد ہے - اس لیے یہ نام ہے۔ زندگی کی بہترین مثال ٹریفک لائٹ ہے۔ مختلف جگہوں پر روشنیوں کے مختلف سلسلے ہیں، لیکن اصول ایک ہی ہے - ہر ریاست کسی نہ کسی چیز کی نمائندگی کرتی ہے (روکنا، چلنا، وغیرہ)۔ ٹریفک لائٹ کسی بھی وقت صرف ایک حالت میں ہوتی ہے، اور سادہ اصولوں کی بنیاد پر ایک سے دوسری حالت میں جاتی ہے۔
یہ گیمز میں NPCs کے ساتھ بھی ایسی ہی کہانی ہے۔ مثال کے طور پر، آئیے درج ذیل ریاستوں کے ساتھ ایک گارڈ لیتے ہیں:
- گشت۔
- حملہ کرنا۔
- بھاگنا۔
اور اس کی حالت بدلنے کی یہ شرائط:
- اگر محافظ دشمن کو دیکھتا ہے تو حملہ کرتا ہے۔
- اگر محافظ حملہ کرتا ہے لیکن دشمن کو مزید نہیں دیکھتا ہے تو وہ گشت پر واپس آجاتا ہے۔
- اگر کوئی گارڈ حملہ کرتا ہے لیکن وہ بری طرح زخمی ہوتا ہے تو وہ بھاگ جاتا ہے۔
آپ سرپرست ریاست کے متغیر اور مختلف چیک کے ساتھ if-statements بھی لکھ سکتے ہیں: کیا آس پاس کوئی دشمن ہے، NPC کی صحت کی سطح کیا ہے، وغیرہ۔ آئیے چند مزید ریاستوں کو شامل کرتے ہیں:
- سستی - گشت کے درمیان۔
- تلاش کرنا - جب دیکھا دشمن غائب ہو گیا ہے۔
- مدد تلاش کرنا - جب کسی دشمن کو دیکھا جاتا ہے، لیکن وہ تنہا لڑنے کے لیے بہت مضبوط ہوتا ہے۔
ان میں سے ہر ایک کے لیے انتخاب محدود ہے - مثال کے طور پر، اگر محافظ کم صحت مند ہے تو وہ چھپے ہوئے دشمن کی تلاش میں نہیں جائے گا۔
سب کے بعد، "ifs" کی ایک بہت بڑی فہرست ہے ، وہ "بہت بوجھل ہو سکتا ہے، اس لیے ہمیں ایک ایسا طریقہ کار وضع کرنے کی ضرورت ہے جو ہمیں ریاستوں اور ریاستوں کے درمیان منتقلی کو ذہن میں رکھنے کی اجازت دیتا ہے۔ ایسا کرنے کے لیے، ہم تمام ریاستوں کو مدنظر رکھتے ہیں، اور ہر ریاست کے تحت ہم ایک فہرست میں دوسری ریاستوں میں ہونے والی تمام تبدیلیوں کو، ان کے لیے ضروری شرائط کے ساتھ لکھتے ہیں۔
یہ ریاستی منتقلی کی میز ہے - FSM کی نمائندگی کرنے کا ایک جامع طریقہ۔ آئیے ایک خاکہ بنائیں اور اس بات کا مکمل جائزہ لیں کہ NPC کا رویہ کیسے بدلتا ہے۔
خاکہ موجودہ صورتحال کی بنیاد پر اس ایجنٹ کے لیے فیصلہ سازی کے جوہر کی عکاسی کرتا ہے۔ مزید یہ کہ، ہر تیر ریاستوں کے درمیان منتقلی کو ظاہر کرتا ہے اگر اس کے ساتھ والی حالت درست ہے۔
ہر اپ ڈیٹ میں ہم ایجنٹ کی موجودہ حالت کو چیک کرتے ہیں، ٹرانزیشن کی فہرست کو دیکھتے ہیں، اور اگر منتقلی کی شرائط پوری ہوتی ہیں، تو یہ نئی حالت کو قبول کرتا ہے۔ مثال کے طور پر، ہر فریم چیک کرتا ہے کہ آیا 10 سیکنڈ کے ٹائمر کی میعاد ختم ہو گئی ہے، اور اگر ایسا ہے، تو گارڈ آئیڈلنگ سٹیٹ سے پٹرولنگ کی طرف جاتا ہے۔ اسی طرح، حملہ آور ریاست ایجنٹ کی صحت کی جانچ کرتی ہے - اگر یہ کم ہے، تو یہ فرار ہونے والی حالت میں چلا جاتا ہے.
یہ ریاستوں کے درمیان منتقلی کو ہینڈل کر رہا ہے، لیکن خود ریاستوں کے ساتھ منسلک رویے کا کیا ہوگا؟ کسی خاص ریاست کے لیے حقیقی رویے کو نافذ کرنے کے معاملے میں، عام طور پر دو قسم کے "ہک" ہوتے ہیں جہاں ہم FSM کو کارروائیاں تفویض کرتے ہیں:
- وہ اعمال جو ہم وقتاً فوقتاً موجودہ حالت کے لیے انجام دیتے ہیں۔
- ایک ریاست سے دوسری حالت میں منتقلی کے وقت ہم جو اقدامات کرتے ہیں۔
پہلی قسم کی مثالیں۔ گشت کرنے والی ریاست ہر فریم پر گشتی راستے کے ساتھ ایجنٹ کو منتقل کرے گی۔ حملہ کرنے والی ریاست ہر فریم پر حملہ شروع کرنے کی کوشش کرے گی یا ایسی ریاست میں منتقلی کرے گی جہاں یہ ممکن ہو۔
دوسری قسم کے لیے، منتقلی پر غور کریں “اگر دشمن نظر آ رہا ہے اور دشمن بہت مضبوط ہے، تو فائنڈنگ ہیلپ سٹیٹ پر جائیں۔ ایجنٹ کو انتخاب کرنا چاہیے کہ مدد کے لیے کہاں جانا ہے اور اس معلومات کو ذخیرہ کرنا چاہیے تاکہ فائنڈنگ ہیلپ اسٹیٹ کو معلوم ہو کہ کہاں جانا ہے۔ ایک بار مدد مل جانے کے بعد، ایجنٹ حملہ آور حالت میں واپس چلا جاتا ہے۔ اس وقت، وہ اتحادی کو خطرے کے بارے میں بتانا چاہے گا، لہذا NotifyFriendOfThreat کارروائی ہو سکتی ہے۔
ایک بار پھر، ہم اس نظام کو سینس/تھنک/ایکٹ سائیکل کے لینز سے دیکھ سکتے ہیں۔ منتقلی منطق کے ذریعہ استعمال کردہ ڈیٹا میں احساس مجسم ہے۔ سوچیں - ہر ریاست میں منتقلی دستیاب ہے۔ اور ایکٹ ریاست کے اندر یا ریاستوں کے درمیان منتقلی کے وقت وقتاً فوقتاً انجام پانے والے اعمال کے ذریعے انجام دیا جاتا ہے۔
بعض اوقات مسلسل پولنگ کی منتقلی کے حالات مہنگے پڑ سکتے ہیں۔ مثال کے طور پر، اگر ہر ایجنٹ یہ تعین کرنے کے لیے ہر فریم میں پیچیدہ حساب کتاب کرتا ہے کہ آیا وہ دشمنوں کو دیکھ سکتا ہے اور یہ سمجھ سکتا ہے کہ آیا یہ پیٹرولنگ سے اٹیکنگ حالت میں منتقل ہو سکتا ہے، تو اس میں CPU کا کافی وقت لگے گا۔
دنیا کی حالت میں اہم تبدیلیوں کو ایسے واقعات کے طور پر سوچا جا سکتا ہے جن پر عمل درآمد ہوتے ہی رونما ہو گا۔ FSM منتقلی کی حالت کو چیک کرنے کے بجائے "کیا میرا ایجنٹ کھلاڑی کو دیکھ سکتا ہے؟" ہر فریم میں، ایک الگ سسٹم کو کم کثرت سے چیک کرنے کے لیے ترتیب دیا جا سکتا ہے (جیسے 5 بار فی سیکنڈ)۔ اور نتیجہ یہ ہے کہ چیک پاس ہونے پر پلیئر سین جاری کیا جائے۔
یہ ایف ایس ایم کو بھیج دیا جاتا ہے، جسے اب پلیئر سین ایونٹ موصول ہونے والی شرط پر جانا چاہیے اور اس کے مطابق جواب دینا چاہیے۔ جواب دینے سے پہلے تقریبا ناقابل تصور تاخیر کے علاوہ نتیجہ خیز سلوک ایک جیسا ہے۔ لیکن احساس کے حصے کو پروگرام کے الگ حصے میں الگ کرنے کے نتیجے میں کارکردگی میں بہتری آئی ہے۔
درجہ بندی کی محدود ریاستی مشین
تاہم، بڑے FSMs کے ساتھ کام کرنا ہمیشہ آسان نہیں ہوتا ہے۔ اگر ہم حملے کی حالت کو MeleeAttacking اور RangedAttacking کو الگ کرنے کے لیے بڑھانا چاہتے ہیں، تو ہمیں دیگر تمام ریاستوں سے منتقلی کو تبدیل کرنا ہو گا جو حملہ کرنے والی حالت (موجودہ اور مستقبل) کی طرف لے جاتی ہیں۔
آپ نے شاید محسوس کیا ہے کہ ہماری مثال میں بہت ساری ڈپلیکیٹ ٹرانزیشنز ہیں۔ آئیڈلنگ اسٹیٹ میں زیادہ تر ٹرانزیشن پیٹرولنگ اسٹیٹ میں ہونے والی ٹرانزیشنز سے ملتی جلتی ہیں۔ یہ اچھا ہوگا کہ ہم خود کو دہرائیں، خاص طور پر اگر ہم مزید ملتی جلتی ریاستیں شامل کریں۔ یہ "غیر جنگی" کے عمومی لیبل کے تحت گروپ آئیڈلنگ اور پیٹرولنگ کو سمجھ میں آتا ہے، جہاں جنگی ریاستوں میں منتقلی کا صرف ایک مشترکہ مجموعہ ہوتا ہے۔ اگر ہم اس لیبل کو ایک ریاست کے طور پر سوچتے ہیں، تو Idling اور Patrolling سب سٹیٹس بن جاتے ہیں۔ ایک نئے غیر جنگی سب سٹیٹ کے لیے علیحدہ ٹرانزیشن ٹیبل استعمال کرنے کی ایک مثال:
اہم ریاستیں:
جنگی حالت سے باہر:
اور خاکہ کی شکل میں:
یہ وہی نظام ہے، لیکن ایک نئی غیر جنگی ریاست کے ساتھ جس میں آئیڈلنگ اور پیٹرولنگ شامل ہے۔ ہر ریاست کے ساتھ ایک FSM پر مشتمل ذیلی ریاستوں کے ساتھ (اور یہ ذیلی ریاستیں، بدلے میں، ان کے اپنے FSMs پر مشتمل ہوتی ہیں - اور اسی طرح جب تک آپ کی ضرورت ہو)، ہمیں ایک Hierarchical Finite State Machine یا HFSM (حیرارکیکل فائنائٹ سٹیٹ مشین) ملتا ہے۔ غیر جنگی ریاست کا گروپ بنا کر، ہم نے بے کار تبدیلیوں کا ایک گروپ کاٹ دیا۔ ہم مشترکہ منتقلی کے ساتھ کسی بھی نئی ریاستوں کے لیے ایسا ہی کر سکتے ہیں۔ مثال کے طور پر، اگر مستقبل میں ہم حملہ آور ریاست کو MeleeAttacking اور MissileAtacking ریاستوں تک پھیلاتے ہیں، تو وہ ذیلی ریاستیں ہوں گی جو دشمن کے فاصلے اور بارود کی دستیابی کی بنیاد پر ایک دوسرے کے درمیان منتقل ہوتی ہیں۔ نتیجے کے طور پر، پیچیدہ طرز عمل اور ذیلی طرز عمل کو کم از کم نقل کی منتقلی کے ساتھ پیش کیا جا سکتا ہے۔
سلوک کا درخت
HFSM کے ساتھ، طرز عمل کے پیچیدہ امتزاج آسان طریقے سے بنائے جاتے ہیں۔ تاہم، تھوڑی مشکل یہ ہے کہ تبدیلی کے قوانین کی شکل میں فیصلہ کرنا موجودہ حالت سے گہرا تعلق رکھتا ہے۔ اور بہت سے کھیلوں میں یہ بالکل وہی ہے جس کی ضرورت ہے۔ اور ریاستی درجہ بندی کا محتاط استعمال منتقلی کی تکرار کی تعداد کو کم کر سکتا ہے۔ لیکن بعض اوقات آپ کو ایسے اصولوں کی ضرورت ہوتی ہے جو کام کرتے ہوں اس سے کوئی فرق نہیں پڑتا ہے کہ آپ کس حالت میں ہیں، یا جو تقریباً کسی بھی ریاست میں لاگو ہوتے ہیں۔ مثال کے طور پر، اگر کسی ایجنٹ کی صحت 25 فیصد تک گر جاتی ہے، تو آپ چاہیں گے کہ وہ بھاگ جائے، قطع نظر اس کے کہ وہ لڑائی میں تھا، بیکار تھا یا بات کر رہا تھا - آپ کو یہ شرط ہر ریاست میں شامل کرنی ہوگی۔ اور اگر آپ کا ڈیزائنر بعد میں کم صحت کی حد کو 25% سے 10% تک تبدیل کرنا چاہتا ہے، تو اسے دوبارہ کرنا پڑے گا۔
مثالی طور پر، اس صورت حال کے لیے ایک ایسے نظام کی ضرورت ہوتی ہے جس میں "کس حالت میں رہنا ہے" کے بارے میں فیصلے خود ریاستوں سے باہر ہوتے ہیں، تاکہ تبدیلیاں صرف ایک جگہ پر ہوں اور منتقلی کے حالات کو چھونے نہ دیں۔ سلوک کے درخت یہاں نظر آتے ہیں۔
ان کو نافذ کرنے کے کئی طریقے ہیں، لیکن جوہر تقریباً سب کے لیے یکساں ہے اور فیصلہ کرنے والے درخت سے ملتا جلتا ہے: الگورتھم ایک "روٹ" نوڈ سے شروع ہوتا ہے، اور درخت میں ایسے نوڈ ہوتے ہیں جو فیصلوں یا اعمال کی نمائندگی کرتے ہیں۔ اگرچہ کچھ اہم اختلافات ہیں:
- نوڈس اب تین میں سے ایک قدر واپس کرتے ہیں: کامیاب (اگر کام مکمل ہو گیا ہے)، ناکام (اگر اسے شروع نہیں کیا جا سکتا ہے)، یا چل رہا ہے (اگر یہ اب بھی چل رہا ہے اور کوئی حتمی نتیجہ نہیں ہے)۔
- دو متبادل کے درمیان انتخاب کرنے کے لیے مزید فیصلہ کن نوڈس نہیں ہیں۔ اس کے بجائے، وہ ڈیکوریٹر نوڈس ہیں، جن میں ایک چائلڈ نوڈ ہے۔ اگر وہ کامیاب ہو جاتے ہیں، تو وہ اپنے اکلوتے چائلڈ نوڈ پر عمل درآمد کرتے ہیں۔
- نوڈس جو اعمال انجام دیتے ہیں وہ انجام دینے والے اعمال کی نمائندگی کرنے کے لئے ایک رننگ ویلیو واپس کرتے ہیں۔
نوڈس کے اس چھوٹے سے سیٹ کو ایک بڑی تعداد میں پیچیدہ طرز عمل بنانے کے لیے ملایا جا سکتا ہے۔ آئیے گزشتہ مثال سے HFSM گارڈ کو رویے کے درخت کے طور پر تصور کریں:
اس ڈھانچے کے ساتھ آئیڈلنگ/گشت کرنے والی ریاستوں سے اٹیکنگ یا کسی دوسری ریاست میں کوئی واضح منتقلی نہیں ہونی چاہیے۔ اگر کوئی دشمن نظر آ رہا ہے اور کردار کی صحت کم ہے، تو پھانسی فراری نوڈ پر رک جائے گی، قطع نظر اس کے کہ یہ پہلے کس نوڈ پر عمل کر رہا تھا - گشت، سست، حملہ، یا کوئی اور۔
رویے کے درخت پیچیدہ ہیں — ان کو کمپوز کرنے کے بہت سے طریقے ہیں، اور ڈیکوریٹرز اور کمپاؤنڈ نوڈس کا صحیح امتزاج تلاش کرنا مشکل ہو سکتا ہے۔ اس بارے میں بھی سوالات ہیں کہ درخت کو کتنی بار چیک کیا جائے - کیا ہم اس کے ہر حصے سے گزرنا چاہتے ہیں یا صرف اس صورت میں جب ان میں سے کوئی ایک حالت بدل گئی ہو؟ ہم نوڈس سے متعلق اسٹیٹ کو کیسے اسٹور کرتے ہیں - ہمیں کیسے پتہ چلے گا کہ جب ہم 10 سیکنڈ کے لیے آئیڈل رہے ہیں، یا ہمیں کیسے معلوم ہوگا کہ پچھلی بار کون سے نوڈس پر عمل ہو رہا تھا تاکہ ہم ترتیب کو درست طریقے سے پروسیس کر سکیں؟
یہی وجہ ہے کہ بہت سے نفاذ ہیں۔ مثال کے طور پر، کچھ سسٹمز نے ڈیکوریٹر نوڈس کو ان لائن ڈیکوریٹرز سے بدل دیا ہے۔ جب ڈیکوریٹر کے حالات بدلتے ہیں تو وہ درخت کا دوبارہ جائزہ لیتے ہیں، نوڈس میں شامل ہونے میں مدد کرتے ہیں، اور وقتاً فوقتاً اپ ڈیٹ فراہم کرتے ہیں۔
افادیت پر مبنی نظام
کچھ گیمز میں بہت سے مختلف میکانکس ہوتے ہیں۔ یہ ضروری ہے کہ وہ سادہ اور عام منتقلی کے قوانین کے تمام فوائد حاصل کریں، لیکن ضروری نہیں کہ رویے کے مکمل درخت کی شکل میں. انتخاب کے واضح سیٹ یا ممکنہ اقدامات کے درخت کے بجائے، تمام اعمال کا جائزہ لینا اور اس وقت سب سے زیادہ مناسب کا انتخاب کرنا آسان ہے۔
یوٹیلیٹی پر مبنی نظام صرف اس میں مدد کرے گا۔ یہ ایک ایسا نظام ہے جہاں ایجنٹ کے پاس مختلف قسم کے اعمال ہوتے ہیں اور وہ ہر ایک کی متعلقہ افادیت کی بنیاد پر انتخاب کرتا ہے کہ کون سے کام انجام دینے ہیں۔ جہاں افادیت ایک صوابدیدی پیمانہ ہے کہ ایجنٹ کے لیے یہ عمل کرنا کتنا اہم یا مطلوب ہے۔
موجودہ حالت اور ماحول کی بنیاد پر کسی کارروائی کی حسابی افادیت، ایجنٹ کسی بھی وقت سب سے مناسب دوسری ریاست کو چیک کر سکتا ہے اور منتخب کر سکتا ہے۔ یہ FSM سے ملتا جلتا ہے، سوائے اس کے جہاں ٹرانزیشن کا تعین ہر ممکنہ حالت کے تخمینے سے کیا جاتا ہے، بشمول موجودہ حالت۔ براہ کرم نوٹ کریں کہ ہم آگے بڑھنے کے لیے سب سے مفید عمل کا انتخاب کرتے ہیں (یا اگر ہم نے اسے پہلے ہی مکمل کر لیا ہے تو رہیں)۔ مزید تنوع کے لیے، یہ ایک چھوٹی فہرست سے متوازن لیکن بے ترتیب انتخاب ہو سکتا ہے۔
سسٹم یوٹیلیٹی ویلیوز کی ایک صوابدیدی رینج تفویض کرتا ہے - مثال کے طور پر، 0 (مکمل طور پر ناپسندیدہ) سے 100 (مکمل طور پر مطلوبہ)۔ ہر عمل میں متعدد پیرامیٹرز ہوتے ہیں جو اس قدر کے حساب کو متاثر کرتے ہیں۔ ہمارے سرپرست کی مثال پر واپس جانا:
اعمال کے درمیان تبدیلیاں مبہم ہیں - کوئی بھی ریاست کسی دوسرے کی پیروی کر سکتی ہے۔ کارروائی کی ترجیحات لوٹی ہوئی یوٹیلیٹی ویلیوز میں پائی جاتی ہیں۔ اگر کوئی دشمن نظر آ رہا ہے، اور وہ دشمن مضبوط ہے، اور کردار کی صحت کم ہے، تو Fleeing اور FindingHelp دونوں اعلی غیر صفر اقدار واپس کریں گے۔ اس صورت میں، FindingHelp ہمیشہ زیادہ ہو گی۔ اسی طرح، غیر جنگی سرگرمیاں کبھی بھی 50 سے زیادہ واپس نہیں آتیں، اس لیے وہ ہمیشہ جنگی سرگرمیوں سے کم رہیں گی۔ آپ کو اعمال تخلیق کرتے وقت اور ان کی افادیت کا حساب لگاتے وقت اس کو مدنظر رکھنا ہوگا۔
ہماری مثال میں، اعمال یا تو ایک مقررہ مستقل قدر یا دو مقررہ قدروں میں سے ایک واپس کرتے ہیں۔ زیادہ حقیقت پسندانہ نظام اقدار کی مسلسل رینج سے تخمینہ واپس کرے گا۔ مثال کے طور پر، اگر ایجنٹ کی صحت کم ہے تو Fleeing ایکشن اعلی یوٹیلیٹی ویلیو واپس کرتا ہے، اور اگر دشمن بہت زیادہ مضبوط ہو تو Attacking Action کم یوٹیلیٹی ویلیوز واپس کرتا ہے۔ اس کی وجہ سے، فرار کی کارروائی کسی بھی ایسی صورت حال میں حملہ کرنے پر مقدم ہوتی ہے جہاں ایجنٹ کو لگتا ہے کہ اس کے پاس اتنی صحت نہیں ہے کہ وہ دشمن کو شکست دے سکے۔ یہ کسی بھی معیار کی بنیاد پر کارروائیوں کو ترجیح دینے کی اجازت دیتا ہے، اس نقطہ نظر کو رویے کے درخت یا FSM سے زیادہ لچکدار اور متغیر بناتا ہے۔
پروگرام کے حساب کتاب کے لیے ہر عمل میں بہت سی شرائط ہوتی ہیں۔ انہیں رسم الخط کی زبان میں یا ریاضی کے فارمولوں کی ایک سیریز کے طور پر لکھا جا سکتا ہے۔ The Sims، جو ایک کردار کے روزمرہ کے معمولات کی نقالی کرتا ہے، حساب کی ایک اضافی پرت کا اضافہ کرتا ہے - ایجنٹ کو "محرکات" کی ایک سیریز ملتی ہے جو افادیت کی درجہ بندی کو متاثر کرتی ہے۔ اگر کوئی کردار بھوکا ہے، تو وہ وقت کے ساتھ ساتھ اور بھی بھوکا ہو جائے گا، اور EatFood ایکشن کی افادیت کی قیمت اس وقت تک بڑھ جائے گی جب تک کہ کردار اسے انجام نہ دے، بھوک کی سطح کو کم کر کے EatFood کی قیمت صفر پر واپس آ جائے۔
درجہ بندی کے نظام کی بنیاد پر کارروائیوں کو منتخب کرنے کا خیال بہت آسان ہے، اس لیے یوٹیلٹی پر مبنی نظام کو AI فیصلہ سازی کے عمل کے حصے کے طور پر استعمال کیا جا سکتا ہے، نہ کہ ان کے مکمل متبادل کے طور پر۔ فیصلہ ٹری دو چائلڈ نوڈس کی افادیت کی درجہ بندی کا مطالبہ کر سکتا ہے اور اعلی کو منتخب کر سکتا ہے۔ اسی طرح، رویے کے درخت میں ایک جامع یوٹیلیٹی نوڈ ہو سکتا ہے جس سے اعمال کی افادیت کا اندازہ لگایا جا سکتا ہے تاکہ یہ فیصلہ کیا جا سکے کہ کس بچے کو انجام دینا ہے۔
نقل و حرکت اور نیویگیشن
پچھلی مثالوں میں، ہمارے پاس ایک پلیٹ فارم تھا جسے ہم بائیں یا دائیں منتقل کرتے تھے، اور ایک گارڈ جو گشت کرتا تھا یا حملہ کرتا تھا۔ لیکن ہم ایک مدت کے دوران ایجنٹ کی نقل و حرکت کو کس طرح ہینڈل کرتے ہیں؟ ہم رفتار کیسے طے کرتے ہیں، ہم رکاوٹوں سے کیسے بچتے ہیں، اور جب کسی منزل تک پہنچنا سیدھی لائن میں چلنے سے زیادہ مشکل ہوتا ہے تو ہم راستے کی منصوبہ بندی کیسے کرتے ہیں؟ آئیے اس کو دیکھتے ہیں۔
مینجمنٹ
ابتدائی مرحلے پر، ہم فرض کریں گے کہ ہر ایجنٹ کی رفتار کی قدر ہوتی ہے، جس میں یہ شامل ہوتا ہے کہ وہ کتنی تیزی سے اور کس سمت میں چل رہا ہے۔ اسے میٹر فی سیکنڈ، کلومیٹر فی گھنٹہ، پکسلز فی سیکنڈ، وغیرہ میں ناپا جا سکتا ہے۔ Sense/Think/Act Loop کو یاد کرتے ہوئے، ہم تصور کر سکتے ہیں کہ Think حصہ ایک رفتار کا انتخاب کرتا ہے، اور Act کا حصہ اس رفتار کو ایجنٹ پر لاگو کرتا ہے۔ عام طور پر گیمز میں ایک فزکس سسٹم ہوتا ہے جو آپ کے لیے یہ کام کرتا ہے، ہر چیز کی رفتار کی قدر سیکھتا ہے اور اسے ایڈجسٹ کرتا ہے۔ لہذا، آپ AI کو ایک کام کے ساتھ چھوڑ سکتے ہیں - یہ فیصلہ کرنے کے لیے کہ ایجنٹ کی رفتار کیا ہونی چاہیے۔ اگر آپ جانتے ہیں کہ ایجنٹ کہاں ہونا چاہیے، تو آپ کو اسے ایک مقررہ رفتار سے صحیح سمت میں منتقل کرنے کی ضرورت ہے۔ ایک بہت ہی معمولی مساوات:
مطلوبہ_سفر = منزل_پوزیشن – ایجنٹ_پوزیشن
ایک 2D دنیا کا تصور کریں۔ ایجنٹ پوائنٹ (-2,-2) پر ہے، منزل شمال مشرق میں کہیں ہے پوائنٹ (30, 20)، اور ایجنٹ کے وہاں پہنچنے کے لیے مطلوبہ راستہ ہے (32, 22)۔ ہم کہتے ہیں کہ ان پوزیشنز کو میٹر میں ناپا جاتا ہے - اگر ہم ایجنٹ کی رفتار کو 5 میٹر فی سیکنڈ لیتے ہیں، تو ہم اپنے نقل مکانی کے ویکٹر کو پیمانہ کریں گے اور تقریبا (4.12، 2.83) کی رفتار حاصل کریں گے۔ ان پیرامیٹرز کے ساتھ، ایجنٹ تقریباً 8 سیکنڈ میں اپنی منزل پر پہنچ جائے گا۔
آپ کسی بھی وقت اقدار کو دوبارہ گن سکتے ہیں۔ اگر ایجنٹ ہدف کے آدھے راستے پر تھا، تو حرکت نصف لمبائی ہوگی، لیکن چونکہ ایجنٹ کی زیادہ سے زیادہ رفتار 5 m/s ہے (ہم نے اوپر اس کا فیصلہ کیا ہے)، رفتار ایک جیسی ہوگی۔ یہ اہداف کو منتقل کرنے کے لیے بھی کام کرتا ہے، جس سے ایجنٹ کو حرکت کرتے وقت چھوٹی تبدیلیاں کرنے کا موقع ملتا ہے۔
لیکن ہم مزید تغیر چاہتے ہیں - مثال کے طور پر، کھڑے ہونے سے دوڑنے والے کردار کی نقل کرنے کے لیے رفتار کو آہستہ آہستہ بڑھانا۔ رکنے سے پہلے آخر میں بھی ایسا ہی کیا جا سکتا ہے۔ ان خصوصیات کو اسٹیئرنگ رویے کے نام سے جانا جاتا ہے، جن میں سے ہر ایک کے مخصوص نام ہیں: تلاش، بھاگنا، آمد، وغیرہ۔ خیال یہ ہے کہ ایجنٹ کی رفتار پر تیز رفتار قوتوں کا اطلاق کیا جا سکتا ہے، جس کی بنیاد پر ایجنٹ کی پوزیشن اور موجودہ رفتار کا منزل کے ساتھ موازنہ کیا جا سکتا ہے۔ مقصد کی طرف بڑھنے کے مختلف طریقے استعمال کرنے کے لیے۔
ہر رویے کا مقصد تھوڑا مختلف ہوتا ہے۔ تلاش اور آمد ایک ایجنٹ کو منزل تک لے جانے کے طریقے ہیں۔ رکاوٹ سے بچنا اور علیحدگی ایجنٹ کی نقل و حرکت کو ایڈجسٹ کرتے ہیں تاکہ مقصد کے راستے میں رکاوٹوں سے بچا جا سکے۔ صف بندی اور ہم آہنگی ایجنٹوں کو ایک ساتھ چلتے رہتے ہیں۔ تمام عوامل کو مدنظر رکھتے ہوئے مختلف اسٹیئرنگ رویوں کی کسی بھی تعداد کا خلاصہ ایک واحد راستہ ویکٹر پیدا کرنے کے لیے کیا جا سکتا ہے۔ ایک ایجنٹ جو دیواروں اور دیگر ایجنٹوں سے دور رہنے کے لیے آمد، علیحدگی، اور رکاوٹ سے بچنے کے طرز عمل کا استعمال کرتا ہے۔ یہ نقطہ نظر غیر ضروری تفصیلات کے بغیر کھلی جگہوں پر اچھی طرح سے کام کرتا ہے۔
زیادہ مشکل حالات میں، مختلف رویوں کا اضافہ بدتر کام کرتا ہے - مثال کے طور پر، ایک ایجنٹ آمد اور رکاوٹ سے بچنے کے درمیان تنازعہ کی وجہ سے دیوار میں پھنس سکتا ہے۔ لہذا، آپ کو ان اختیارات پر غور کرنے کی ضرورت ہے جو صرف تمام اقدار کو شامل کرنے سے زیادہ پیچیدہ ہیں۔ طریقہ یہ ہے: ہر رویے کے نتائج کو شامل کرنے کے بجائے، آپ مختلف سمتوں میں حرکت پر غور کر سکتے ہیں اور بہترین آپشن کا انتخاب کر سکتے ہیں۔
تاہم، ایک پیچیدہ ماحول میں جس کے ختم ہونے اور راستے کے بارے میں انتخاب کے ساتھ، ہمیں اس سے بھی زیادہ جدید چیز کی ضرورت ہوگی۔
راستہ تلاش کرنا۔
اسٹیئرنگ رویے کھلے علاقے (فٹ بال کے میدان یا میدان) میں سادہ نقل و حرکت کے لیے بہترین ہیں جہاں A سے B تک جانا ایک سیدھا راستہ ہے جس میں رکاوٹوں کے گرد صرف معمولی راستے ہیں۔ پیچیدہ راستوں کے لیے، ہمیں پاتھ فائنڈنگ کی ضرورت ہے، جو دنیا کو تلاش کرنے اور اس کے ذریعے کسی راستے کا فیصلہ کرنے کا ایک طریقہ ہے۔
سب سے آسان یہ ہے کہ ایجنٹ کے ساتھ والے ہر اسکوائر پر ایک گرڈ لگائیں اور اندازہ کریں کہ ان میں سے کس کو حرکت کرنے کی اجازت ہے۔ اگر ان میں سے کوئی ایک منزل ہے، تو ہر چوک سے پچھلے والے راستے تک اس وقت تک چلیں جب تک کہ آپ شروع میں نہ پہنچ جائیں۔ یہ راستہ ہے۔ بصورت دیگر، اس عمل کو قریبی دوسرے چوکوں کے ساتھ اس وقت تک دہرائیں جب تک کہ آپ کو اپنی منزل نہ مل جائے یا آپ چوکوں سے باہر ہو جائیں (یعنی کوئی ممکنہ راستہ نہیں ہے)۔ یہ وہی ہے جو رسمی طور پر چوڑائی-پہلی تلاش یا BFS (چوڑائی پہلی تلاش الگورتھم) کے طور پر جانا جاتا ہے. ہر قدم پر وہ تمام سمتوں میں دیکھتا ہے (لہذا چوڑائی، "چوڑائی")۔ تلاش کی جگہ ایک ویو فرنٹ کی طرح ہوتی ہے جو اس وقت تک حرکت کرتی ہے جب تک کہ وہ مطلوبہ مقام تک نہ پہنچ جائے - تلاش کی جگہ ہر قدم پر پھیلتی ہے جب تک کہ اختتامی نقطہ شامل نہ ہو جائے، جس کے بعد اسے شروع تک پہنچایا جا سکتا ہے۔
نتیجے کے طور پر، آپ کو چوکوں کی ایک فہرست ملے گی جس کے ساتھ مطلوبہ راستہ مرتب کیا گیا ہے۔ یہ راستہ ہے (لہذا، پاتھ فائنڈنگ) - ان جگہوں کی فہرست جہاں ایجنٹ منزل کی پیروی کرتے ہوئے جائے گا۔
یہ دیکھتے ہوئے کہ ہم دنیا کے ہر مربع کی پوزیشن کو جانتے ہیں، ہم راستے پر چلنے کے لیے اسٹیئرنگ رویے کا استعمال کر سکتے ہیں - نوڈ 1 سے نوڈ 2 تک، پھر نوڈ 2 سے نوڈ 3 تک، وغیرہ۔ سب سے آسان آپشن یہ ہے کہ اگلے اسکوائر کے بیچ کی طرف جائیں، لیکن اس سے بھی بہتر آپشن یہ ہے کہ موجودہ اسکوائر اور اگلے والے کے درمیان کنارے کے بیچ میں رک جائے۔ اس کی وجہ سے، ایجنٹ تیز موڑ پر کونوں کو کاٹنے کے قابل ہو جائے گا.
BFS الگورتھم کے بھی نقصانات ہیں - یہ "غلط" سمت میں جتنے مربعوں کو "صحیح" سمت میں تلاش کرتا ہے۔ یہ وہ جگہ ہے جہاں A* (A star) نامی ایک زیادہ پیچیدہ الگورتھم کام میں آتا ہے۔ یہ اسی طرح کام کرتا ہے، لیکن آنکھ بند کرکے پڑوسی چوکوں (پھر پڑوسیوں کے پڑوسی، پھر پڑوسیوں کے پڑوسیوں کے پڑوسی، اور اسی طرح) کی جانچ کرنے کے بجائے، یہ نوڈس کو ایک فہرست میں جمع کرتا ہے اور ان کو ترتیب دیتا ہے تاکہ اگلے نوڈ کی جانچ پڑتال کی جائے ایک جو مختصر ترین راستے کی طرف جاتا ہے۔ نوڈس کو ایک ہیورسٹک کی بنیاد پر ترتیب دیا جاتا ہے جس میں دو چیزوں کو مدنظر رکھا جاتا ہے — مطلوبہ اسکوائر تک فرضی راستے کی "لاگت" (بشمول سفری اخراجات) اور اس بات کا اندازہ کہ وہ مربع منزل سے کتنا دور ہے (اس میں تلاش کا تعصب درست سمت).
یہ مثال ظاہر کرتی ہے کہ ایجنٹ ایک وقت میں ایک مربع کو تلاش کرتا ہے، ہر بار ملحقہ کو منتخب کرتا ہے جو سب سے زیادہ امید افزا ہو۔ نتیجے کا راستہ BFS جیسا ہی ہے، لیکن اس عمل میں کم چوکوں پر غور کیا گیا - جس کا گیم کی کارکردگی پر بڑا اثر پڑتا ہے۔
گرڈ کے بغیر نقل و حرکت
لیکن زیادہ تر کھیل گرڈ پر نہیں رکھے جاتے ہیں، اور حقیقت پسندی کی قربانی کے بغیر ایسا کرنا اکثر ناممکن ہوتا ہے۔ سمجھوتوں کی ضرورت ہے۔ چوکوں کا سائز کیا ہونا چاہئے؟ بہت بڑا ہے اور وہ چھوٹی راہداریوں یا موڑ کی صحیح طریقے سے نمائندگی نہیں کر پائیں گے، بہت چھوٹے اور تلاش کرنے کے لیے بہت زیادہ چوکیاں ہوں گی، جس میں بالآخر کافی وقت لگے گا۔
سمجھنے کی پہلی چیز یہ ہے کہ ایک میش ہمیں منسلک نوڈس کا گراف فراہم کرتا ہے۔ A* اور BFS الگورتھم دراصل گرافس پر کام کرتے ہیں اور ہمارے میش کی بالکل بھی پرواہ نہیں کرتے ہیں۔ ہم کھیل کی دنیا میں کہیں بھی نوڈس رکھ سکتے ہیں: جب تک کہ کسی بھی دو منسلک نوڈس کے ساتھ ساتھ آغاز اور اختتامی پوائنٹس اور کم از کم ایک نوڈس کے درمیان رابطہ موجود ہے، الگورتھم پہلے کی طرح کام کرے گا۔ اسے اکثر وے پوائنٹ سسٹم کہا جاتا ہے، کیونکہ ہر نوڈ دنیا میں ایک اہم مقام کی نمائندگی کرتا ہے جو کسی بھی فرضی راستوں کا حصہ ہو سکتا ہے۔
مثال 1: ہر مربع میں ایک گرہ۔ تلاش نوڈ سے شروع ہوتی ہے جہاں ایجنٹ واقع ہے اور مطلوبہ مربع کے نوڈ پر ختم ہوتا ہے۔
مثال 2: نوڈس کا ایک چھوٹا سیٹ (وی پوائنٹس)۔ تلاش ایجنٹ کے مربع سے شروع ہوتی ہے، مطلوبہ تعداد میں نوڈس سے گزرتی ہے، اور پھر منزل تک جاتی ہے۔
یہ مکمل طور پر لچکدار اور طاقتور نظام ہے۔ لیکن یہ فیصلہ کرنے میں کچھ احتیاط کی ضرورت ہے کہ راستہ کہاں اور کیسے رکھنا ہے، بصورت دیگر ایجنٹوں کو قریب ترین نقطہ نظر نہیں آسکتا ہے اور وہ راستہ شروع کرنے کے قابل نہیں ہوں گے۔ یہ آسان ہو گا اگر ہم خود بخود دنیا کی جیومیٹری کی بنیاد پر وے پوائنٹس رکھ سکیں۔
یہ وہ جگہ ہے جہاں نیویگیشن میش یا نیومیش (نیویگیشن میش) ظاہر ہوتا ہے۔ یہ عام طور پر مثلث کا ایک 2D میش ہے جو دنیا کی جیومیٹری پر چڑھا ہوا ہے - جہاں بھی ایجنٹ کو چلنے کی اجازت ہے۔ میش میں موجود ہر مثلث گراف میں ایک نوڈ بن جاتا ہے، اور اس میں تین ملحقہ تکون ہوتے ہیں جو گراف میں ملحقہ نوڈ بن جاتے ہیں۔
یہ تصویر یونٹی انجن کی ایک مثال ہے - اس نے دنیا میں جیومیٹری کا تجزیہ کیا اور ایک نیومیش بنایا (اسکرین شاٹ میں ہلکے نیلے رنگ میں)۔ نیومیش میں ہر کثیرالاضلاع ایک ایسا علاقہ ہے جہاں ایک ایجنٹ کھڑا ہو سکتا ہے یا ایک کثیرالاضلاع سے دوسرے کثیرالاضلاع میں جا سکتا ہے۔ اس مثال میں، کثیر الاضلاع ان منزلوں سے چھوٹے ہیں جن پر وہ واقع ہیں - یہ ایجنٹ کے سائز کو مدنظر رکھنے کے لیے کیا جاتا ہے، جو اس کی معمولی پوزیشن سے آگے بڑھے گا۔
ہم دوبارہ A* الگورتھم کا استعمال کرتے ہوئے اس میش کے ذریعے راستہ تلاش کر سکتے ہیں۔ یہ ہمیں دنیا میں تقریباً ایک مکمل راستہ فراہم کرے گا، جو تمام جیومیٹری کو مدنظر رکھتا ہے اور اسے غیر ضروری نوڈس اور وے پوائنٹس بنانے کی ضرورت نہیں ہے۔
پاتھ فائنڈنگ ایک ایسا موضوع ہے جس کے لیے مضمون کا ایک حصہ کافی نہیں ہے۔ اگر آپ اس کا مزید تفصیل سے مطالعہ کرنا چاہتے ہیں، تو اس سے مدد ملے گی۔ .
منصوبہ بندی
ہم نے پاتھ فائنڈنگ کے ساتھ سیکھا ہے کہ بعض اوقات صرف ایک سمت چننا اور آگے بڑھنا کافی نہیں ہوتا ہے - ہمیں اپنی مطلوبہ منزل تک پہنچنے کے لیے راستہ چننا پڑتا ہے اور کچھ موڑ لینا پڑتا ہے۔ ہم اس خیال کو عام کر سکتے ہیں: کسی مقصد کا حصول صرف اگلا مرحلہ نہیں ہے، بلکہ ایک پورا سلسلہ ہے، بعض اوقات آپ کو یہ جاننے کے لیے کئی قدم آگے دیکھنے کی ضرورت ہوتی ہے کہ پہلا کیا ہونا چاہیے۔ اسے پلاننگ کہتے ہیں۔ پاتھ فائنڈنگ کو منصوبہ بندی کی متعدد توسیعات میں سے ایک سمجھا جا سکتا ہے۔ ہمارے سینس/تھنک/ایکٹ سائیکل کے لحاظ سے، یہ وہ جگہ ہے جہاں تھنک حصہ مستقبل کے لیے ایکٹ کے متعدد حصوں کی منصوبہ بندی کرتا ہے۔
آئیے بورڈ گیم میجک: دی گیدرنگ کی مثال دیکھتے ہیں۔ ہم اپنے ہاتھوں میں کارڈ کے درج ذیل سیٹ کے ساتھ پہلے جاتے ہیں:
- دلدل - 1 کالا من (لینڈ کارڈ) دیتا ہے۔
- جنگل - 1 سبز مانا (لینڈ کارڈ) دیتا ہے۔
- مفرور وزرڈ - طلب کرنے کے لیے 1 نیلا مانا درکار ہے۔
- ایلویش صوفیانہ - طلب کرنے کے لیے 1 سبز مانے کی ضرورت ہے۔
ہم اسے آسان بنانے کے لیے باقی تین کارڈز کو نظر انداز کر دیتے ہیں۔ قوانین کے مطابق، ایک کھلاڑی کو فی موڑ پر 1 لینڈ کارڈ کھیلنے کی اجازت ہے، وہ اس کارڈ سے من نکالنے کے لیے اس کارڈ کو "تھپ" کر سکتا ہے، اور پھر من کی مقدار کے مطابق منتر (بشمول مخلوق کو طلب کر کے) کاسٹ کر سکتا ہے۔ اس صورت حال میں، انسانی کھلاڑی جنگل کھیلنا جانتا ہے، 1 سبز مانا کو تھپتھپائیں، اور پھر ایلویش صوفیانہ کو طلب کریں۔ لیکن گیم AI اس کا پتہ کیسے لگا سکتا ہے؟
آسان منصوبہ بندی
معمولی نقطہ نظر یہ ہے کہ ہر ایک عمل کو باری باری آزمائیں جب تک کہ کوئی مناسب کام باقی نہ رہے۔ کارڈز کو دیکھ کر، AI دیکھتا ہے کہ دلدل کیا کھیل سکتا ہے۔ اور وہ کھیلتا ہے۔ کیا اس موڑ پر کوئی اور کارروائیاں باقی ہیں؟ یہ ایلویش صوفیانہ یا مفرور جادوگر کو طلب نہیں کر سکتا، کیونکہ انہیں بلانے کے لیے بالترتیب سبز اور نیلے من کی ضرورت ہوتی ہے، جبکہ دلدل صرف سیاہ من فراہم کرتا ہے۔ اور وہ اب فارسٹ نہیں کھیل سکے گا، کیونکہ وہ پہلے ہی سومپ کھیل چکا ہے۔ اس طرح، گیم AI نے قواعد کی پیروی کی، لیکن اس نے خراب کارکردگی کا مظاہرہ کیا۔ بہتر کیا جا سکتا ہے۔
منصوبہ بندی سے ان اعمال کی فہرست مل سکتی ہے جو کھیل کو مطلوبہ حالت میں لے آئیں۔ جس طرح راستے پر ہر چوک کے پڑوسی ہوتے ہیں (پاتھ فائنڈنگ میں)، اسی طرح پلان میں ہر عمل کے پڑوسی یا جانشین ہوتے ہیں۔ ہم مطلوبہ حالت تک پہنچنے تک ان اعمال اور اس کے بعد کے اعمال کو تلاش کر سکتے ہیں۔
ہماری مثال میں، مطلوبہ نتیجہ ہے "اگر ممکن ہو تو کسی مخلوق کو طلب کریں۔" موڑ کے آغاز میں، ہم صرف دو ممکنہ کارروائیوں کو دیکھتے ہیں جن کی گیم کے قواعد کے ذریعے اجازت دی گئی ہے:
1. دلدل کھیلیں (نتیجہ: کھیل میں دلدل)
2. جنگل کھیلیں (نتیجہ: کھیل میں جنگل)
کھیل کے اصولوں پر منحصر ہر ایک کارروائی مزید کارروائیوں کا باعث بن سکتی ہے اور دوسروں کو بند کر سکتی ہے۔ تصور کریں کہ ہم نے Swamp کھیلا ہے - یہ اگلے مرحلے کے طور پر Swamp کو ہٹا دے گا (ہم اسے پہلے ہی کھیل چکے ہیں)، اور یہ جنگل کو بھی ہٹا دے گا (کیونکہ قواعد کے مطابق آپ فی موڑ پر ایک لینڈ کارڈ کھیل سکتے ہیں)۔ اس کے بعد، AI اگلے مرحلے کے طور پر 1 بلیک من حاصل کرنا شامل کرتا ہے کیونکہ اس کے علاوہ کوئی آپشن نہیں ہے۔ اگر وہ آگے بڑھ کر Tap the Swamp کا انتخاب کرتا ہے، تو اسے 1 یونٹ کالا مانا ملے گا اور وہ اس کے ساتھ کچھ نہیں کر سکے گا۔
1. دلدل کھیلیں (نتیجہ: کھیل میں دلدل)
1.1 "تھپتھپائیں" دلدل (نتیجہ: دلدل "ٹیپ"، سیاہ مانا کی +1 اکائی)
کوئی کارروائی دستیاب نہیں - END
2. جنگل کھیلیں (نتیجہ: کھیل میں جنگل)
اعمال کی فہرست مختصر تھی، ہم اختتام کو پہنچ گئے۔ ہم اگلے مرحلے کے لیے اس عمل کو دہراتے ہیں۔ ہم جنگل کھیلتے ہیں، ایکشن کھولتے ہیں "1 گرین مانا حاصل کریں"، جس کے نتیجے میں تیسری کارروائی کھل جائے گی - ایلویش صوفیانہ کو طلب کریں۔
1. دلدل کھیلیں (نتیجہ: کھیل میں دلدل)
1.1 "تھپتھپائیں" دلدل (نتیجہ: دلدل "ٹیپ"، سیاہ مانا کی +1 اکائی)
کوئی کارروائی دستیاب نہیں - END
2. جنگل کھیلیں (نتیجہ: کھیل میں جنگل)
2.1 "ٹیپ" جنگل (نتیجہ: جنگل "ٹیپ" ہے، سبز مانا کی +1 اکائی)
2.1.1 ایلویش صوفیانہ کو طلب کریں (نتیجہ: کھیل میں ایلویش صوفیانہ، -1 سبز مانا)
کوئی کارروائی دستیاب نہیں - END
آخر میں، ہم نے تمام ممکنہ اقدامات کی کھوج کی اور ایک ایسا منصوبہ پایا جو ایک مخلوق کو طلب کرتا ہے۔
یہ ایک بہت آسان مثال ہے۔ یہ مشورہ دیا جاتا ہے کہ بہترین ممکنہ منصوبہ منتخب کریں، بجائے اس کے کہ کوئی ایسا منصوبہ جو کچھ معیارات پر پورا اترتا ہو۔ عام طور پر ممکنہ منصوبوں کا اندازہ ان کے نفاذ کے نتائج یا مجموعی فائدہ کی بنیاد پر ممکن ہے۔ آپ لینڈ کارڈ کھیلنے کے لیے اپنے آپ کو 1 پوائنٹ اور کسی مخلوق کو بلانے کے لیے 3 پوائنٹ حاصل کر سکتے ہیں۔ دلدل کھیلنا ایک 1 نکاتی منصوبہ ہوگا۔ اور Forest → Tap the Forest → summon Elvish Mystic کھیلتے ہوئے فوری طور پر 4 پوائنٹس دے گا۔
جادو: اجتماع میں منصوبہ بندی اس طرح کام کرتی ہے، لیکن یہی منطق دوسرے حالات میں بھی لاگو ہوتی ہے۔ مثال کے طور پر، شطرنج میں بشپ کے لیے جگہ بنانے کے لیے ایک پیادے کو منتقل کرنا۔ یا اس طرح XCOM میں محفوظ طریقے سے شوٹنگ کرنے کے لیے دیوار کے پیچھے ڈھانپیں۔ عام طور پر، آپ کو خیال آتا ہے.
بہتر منصوبہ بندی
کبھی کبھی ہر ممکنہ آپشن پر غور کرنے کے لیے بہت زیادہ ممکنہ اقدامات ہوتے ہیں۔ جادو کے ساتھ مثال کی طرف لوٹنا: دی گیدرنگ: آئیے کہتے ہیں کہ گیم اور آپ کے ہاتھ میں کئی زمینی اور مخلوق کارڈز ہیں - چالوں کے ممکنہ امتزاج کی تعداد درجنوں میں ہوسکتی ہے۔ مسئلے کے کئی حل ہیں۔
پہلا طریقہ پیچھے کی طرف چیننگ ہے۔ تمام امتزاجات کو آزمانے کے بجائے بہتر ہے کہ حتمی نتیجہ سے آغاز کریں اور براہ راست راستہ تلاش کرنے کی کوشش کریں۔ درخت کی جڑ سے ایک مخصوص پتے تک جانے کے بجائے، ہم الٹی سمت میں جاتے ہیں - پتے سے جڑ تک۔ یہ طریقہ آسان اور تیز تر ہے۔
اگر دشمن کی صحت 1 ہے، تو آپ "ڈیل 1 یا زیادہ نقصان" کا منصوبہ تلاش کر سکتے ہیں۔ اسے حاصل کرنے کے لیے، کئی شرائط کو پورا کرنا ضروری ہے:
1. نقصان جادو کی وجہ سے ہو سکتا ہے - یہ ہاتھ میں ہونا ضروری ہے.
2. جادو کرنے کے لیے، آپ کو من کی ضرورت ہے۔
3. مانا حاصل کرنے کے لیے، آپ کو لینڈ کارڈ کھیلنے کی ضرورت ہے۔
4. لینڈ کارڈ کھیلنے کے لیے، آپ کے ہاتھ میں ہونا ضروری ہے۔
دوسرا طریقہ سب سے پہلے تلاش کرنا ہے۔ تمام راستے آزمانے کے بجائے، ہم سب سے موزوں راستے کا انتخاب کرتے ہیں۔ زیادہ تر اکثر، یہ طریقہ تلاش کے غیر ضروری اخراجات کے بغیر بہترین منصوبہ فراہم کرتا ہے۔ A* بہترین پہلی تلاش کی ایک شکل ہے - شروع سے ہی سب سے زیادہ امید افزا راستوں کا جائزہ لے کر، یہ دوسرے اختیارات کو چیک کیے بغیر پہلے ہی بہترین راستہ تلاش کر سکتا ہے۔
ایک دلچسپ اور تیزی سے مقبول سب سے پہلے تلاش کا اختیار مونٹی کارلو ٹری سرچ ہے۔ ہر بعد کی کارروائی کا انتخاب کرتے وقت یہ اندازہ لگانے کے بجائے کہ کون سے منصوبے دوسروں سے بہتر ہیں، الگورتھم ہر قدم پر بے ترتیب جانشینوں کا انتخاب کرتا ہے جب تک کہ یہ اختتام تک نہ پہنچ جائے (جب اس منصوبے کے نتیجے میں فتح یا شکست ہوتی ہے)۔ حتمی نتیجہ پھر پچھلے اختیارات کے وزن کو بڑھانے یا کم کرنے کے لیے استعمال کیا جاتا ہے۔ اس عمل کو لگاتار کئی بار دہرانے سے، الگورتھم اس بات کا ایک اچھا اندازہ لگاتا ہے کہ اگلا بہترین اقدام کیا ہے، چاہے صورتحال بدل جائے (اگر دشمن کھلاڑی کے ساتھ مداخلت کرنے کے لیے کارروائی کرتا ہے)۔
گیمز میں منصوبہ بندی کے بارے میں کوئی کہانی گول اورینٹڈ ایکشن پلاننگ یا GOAP (گول پر مبنی ایکشن پلاننگ) کے بغیر مکمل نہیں ہوگی۔ یہ ایک وسیع پیمانے پر استعمال اور زیر بحث طریقہ ہے، لیکن چند امتیازی تفصیلات کے علاوہ، یہ بنیادی طور پر پیچھے کی زنجیر کا طریقہ ہے جس کے بارے میں ہم نے پہلے بات کی تھی۔ اگر مقصد "کھلاڑی کو تباہ کرنا" تھا اور کھلاڑی کور کے پیچھے ہے، تو منصوبہ یہ ہو سکتا ہے: گرینیڈ سے تباہ کریں → اسے حاصل کریں → پھینک دیں۔
عام طور پر کئی مقاصد ہوتے ہیں، ہر ایک کی اپنی ترجیح ہوتی ہے۔ اگر سب سے زیادہ ترجیحی مقصد کو مکمل نہیں کیا جا سکتا ہے (کارروائیوں کا کوئی مجموعہ "کھلاڑی کو مارنے" کا منصوبہ نہیں بناتا ہے کیونکہ کھلاڑی نظر نہیں آتا ہے)، AI کم ترجیحی مقاصد پر واپس آ جائے گا۔
تربیت اور موافقت
ہم پہلے ہی کہہ چکے ہیں کہ گیم AI عام طور پر مشین لرننگ کا استعمال نہیں کرتا ہے کیونکہ یہ حقیقی وقت میں ایجنٹوں کے انتظام کے لیے موزوں نہیں ہے۔ لیکن اس کا مطلب یہ نہیں ہے کہ آپ اس علاقے سے کچھ ادھار نہیں لے سکتے۔ ہم شوٹر میں ایک مخالف چاہتے ہیں جس سے ہم کچھ سیکھ سکیں۔ مثال کے طور پر، نقشے پر بہترین پوزیشنوں کے بارے میں معلوم کریں۔ یا لڑائی کے کھیل میں ایک مخالف جو کھلاڑی کی اکثر استعمال ہونے والی کومبو چالوں کو روکتا ہے، اسے دوسروں کو استعمال کرنے کی ترغیب دیتا ہے۔ تو ایسے حالات میں مشین لرننگ کافی کارآمد ثابت ہو سکتی ہے۔
اعداد و شمار اور امکانات
پیچیدہ مثالوں میں جانے سے پہلے، آئیے دیکھتے ہیں کہ چند سادہ پیمائشیں لے کر اور فیصلے کرنے کے لیے ان کا استعمال کرکے ہم کس حد تک جا سکتے ہیں۔ مثال کے طور پر، حقیقی وقت کی حکمت عملی - ہم یہ کیسے طے کریں گے کہ آیا کوئی کھلاڑی کھیل کے پہلے چند منٹوں میں حملہ کر سکتا ہے اور اس کے خلاف کیا دفاع تیار کرنا ہے؟ ہم یہ سمجھنے کے لیے کھلاڑی کے ماضی کے تجربات کا مطالعہ کر سکتے ہیں کہ مستقبل میں کیا ردعمل ہو سکتا ہے۔ شروع کرنے کے لیے، ہمارے پاس ایسا خام ڈیٹا نہیں ہے، لیکن ہم اسے اکٹھا کر سکتے ہیں - جب بھی AI کسی انسان کے خلاف کھیلتا ہے، یہ پہلے حملے کا وقت ریکارڈ کر سکتا ہے۔ کچھ سیشنز کے بعد، ہمیں اس وقت کا اوسط ملے گا جو کھلاڑی کو مستقبل میں حملہ کرنے میں لگے گا۔
اوسط اقدار کے ساتھ بھی ایک مسئلہ ہے: اگر کوئی کھلاڑی 20 بار جلدی کرتا ہے اور 20 بار آہستہ کھیلتا ہے، تو مطلوبہ اقدار درمیان میں کہیں ہوں گی، اور اس سے ہمیں کچھ بھی مفید نہیں ملے گا۔ ایک حل ان پٹ ڈیٹا کو محدود کرنا ہے - آخری 20 ٹکڑوں کو مدنظر رکھا جا سکتا ہے۔
اسی طرح کا نقطہ نظر استعمال کیا جاتا ہے جب یہ تصور کرتے ہوئے کہ کھلاڑی کی ماضی کی ترجیحات مستقبل میں ایک جیسی ہوں گی۔ اگر کوئی کھلاڑی ہم پر پانچ بار فائر بال سے حملہ کرتا ہے، دو بار آسمانی بجلی سے اور ایک بار ہنگامہ آرائی کرتا ہے، تو ظاہر ہے کہ وہ فائر بال کو ترجیح دیتا ہے۔ آئیے ایکسٹرپولیٹ کرتے ہیں اور مختلف ہتھیاروں کے استعمال کا امکان دیکھتے ہیں: فائر بال = 62,5٪، بجلی = 25٪ اور ہنگامہ = 12,5٪۔ ہمارے گیم AI کو خود کو آگ سے بچانے کے لیے تیاری کرنے کی ضرورت ہے۔
ایک اور دلچسپ طریقہ یہ ہے کہ بڑی مقدار میں ان پٹ ڈیٹا کا مطالعہ کرنے اور صورتحال کی درجہ بندی کرنے کے لیے Naive Bayes Classifier کا استعمال کیا جائے تاکہ AI مطلوبہ طریقے سے ردعمل ظاہر کرے۔ Bayesian کلاسیفائر ای میل سپیم فلٹرز میں اپنے استعمال کے لیے مشہور ہیں۔ وہاں وہ الفاظ کی جانچ کرتے ہیں، ان کا موازنہ کرتے ہیں کہ وہ الفاظ پہلے کہاں ظاہر ہوئے ہیں (اسپام میں یا نہیں)، اور آنے والی ای میلز کے بارے میں نتیجہ اخذ کرتے ہیں۔ ہم کم ان پٹ کے ساتھ بھی وہی کام کر سکتے ہیں۔ ان تمام مفید معلومات کی بنیاد پر جو AI دیکھتا ہے (جیسے کہ دشمن کے کون سے یونٹ بنائے گئے ہیں، یا وہ کون سے ہجے استعمال کرتے ہیں، یا انہوں نے کون سی ٹیکنالوجیز پر تحقیق کی ہے) اور حتمی نتیجہ (جنگ یا امن، جلدی یا دفاع وغیرہ)۔ - ہم مطلوبہ AI رویے کا انتخاب کریں گے۔
یہ تمام تربیتی طریقے کافی ہیں، لیکن جانچ کے اعداد و شمار کی بنیاد پر ان کا استعمال کرنے کا مشورہ دیا جاتا ہے۔ AI ان مختلف حکمت عملیوں کو اپنانا سیکھے گا جو آپ کے پلے ٹیسٹرز استعمال کرتے ہیں۔ AI جو ریلیز کے بعد پلیئر کے مطابق ہوتا ہے بہت زیادہ پیش گوئی یا شکست دینا بہت مشکل ہو سکتا ہے۔
قدر پر مبنی موافقت
ہماری گیم کی دنیا کے مواد اور قواعد کو دیکھتے ہوئے، ہم صرف ان پٹ ڈیٹا کو استعمال کرنے کے بجائے، فیصلہ سازی پر اثر انداز ہونے والی اقدار کے سیٹ کو تبدیل کر سکتے ہیں۔ ہم یہ کرتے ہیں:
- AI کو کھیل کے دوران دنیا کی حالت اور اہم واقعات پر ڈیٹا اکٹھا کرنے دیں (جیسا کہ اوپر)۔
- آئیے اس ڈیٹا کی بنیاد پر چند اہم اقدار کو تبدیل کرتے ہیں۔
- ہم اپنے فیصلوں کو ان اقدار پر عملدرآمد یا ان کا جائزہ لینے کی بنیاد پر نافذ کرتے ہیں۔
مثال کے طور پر، ایک ایجنٹ کے پاس فرسٹ پرسن شوٹر میپ میں سے انتخاب کرنے کے لیے کئی کمرے ہوتے ہیں۔ ہر کمرے کی اپنی قدر ہوتی ہے، جو اس بات کا تعین کرتی ہے کہ اس کا دورہ کتنا ضروری ہے۔ AI تصادفی طور پر قیمت کی بنیاد پر منتخب کرتا ہے کہ کس کمرے میں جانا ہے۔ ایجنٹ پھر یاد کرتا ہے کہ وہ کس کمرے میں مارا گیا تھا اور اس کی قیمت کم کرتا ہے (اس بات کا امکان کہ وہ وہاں واپس آجائے گا)۔ اسی طرح ریورس صورت حال کے لئے - اگر ایجنٹ بہت سے مخالفین کو تباہ کر دیتا ہے، تو کمرے کی قیمت بڑھ جاتی ہے.
مارکوف ماڈل
کیا ہوگا اگر ہم جمع کردہ ڈیٹا کو پیشن گوئی کرنے کے لیے استعمال کریں؟ اگر ہمیں ہر وہ کمرہ یاد ہے جس میں ہم کھلاڑی کو ایک خاص مدت کے لیے دیکھتے ہیں، تو ہم اندازہ لگائیں گے کہ کھلاڑی کس کمرے میں جا سکتا ہے۔ کمروں (اقداروں) میں کھلاڑی کی نقل و حرکت کا سراغ لگا کر اور ریکارڈ کر کے، ہم ان کی پیش گوئی کر سکتے ہیں۔
آئیے تین کمرے لیں: سرخ، سبز اور نیلے رنگ۔ اور وہ مشاہدات جو ہم نے گیم سیشن دیکھتے ہوئے ریکارڈ کیے:
ہر کمرے میں مشاہدات کی تعداد تقریباً برابر ہے - ہم ابھی تک نہیں جانتے کہ گھات لگانے کے لیے کہاں سے اچھی جگہ بنائی جائے۔ اعداد و شمار جمع کرنا کھلاڑیوں کے دوبارہ پیدا ہونے سے بھی پیچیدہ ہوتا ہے، جو پورے نقشے میں یکساں طور پر ظاہر ہوتے ہیں۔ لیکن نقشے پر ظاہر ہونے کے بعد وہ جس اگلے کمرے میں داخل ہوتے ہیں اس کا ڈیٹا پہلے سے ہی کارآمد ہے۔
یہ دیکھا جا سکتا ہے کہ گرین روم کھلاڑیوں کے لیے موزوں ہے - زیادہ تر لوگ ریڈ روم سے اس میں چلے جاتے ہیں، جن میں سے 50% مزید وہیں رہتے ہیں۔ اس کے برعکس، نیلا کمرہ مقبول نہیں ہے؛ تقریباً کوئی بھی اس کے پاس نہیں جاتا، اور اگر وہ کرتے ہیں، تو وہ زیادہ دیر نہیں ٹھہرتے۔
لیکن ڈیٹا ہمیں کچھ اور اہم بتاتا ہے - جب کوئی کھلاڑی نیلے رنگ کے کمرے میں ہوتا ہے، تو اگلا کمرہ جس میں ہم اسے دیکھیں گے وہ سبز نہیں بلکہ سرخ ہوگا۔ اگرچہ گرین روم سرخ کمرے سے زیادہ مقبول ہے، اگر کھلاڑی نیلے کمرے میں ہو تو صورتحال بدل جاتی ہے۔ اگلی حالت (یعنی جس کمرے میں کھلاڑی جائے گا) پچھلی حالت پر منحصر ہے (یعنی کھلاڑی اس وقت جس کمرے میں ہے)۔ چونکہ ہم انحصار کو تلاش کرتے ہیں، ہم اس سے کہیں زیادہ درست پیشین گوئیاں کریں گے کہ اگر ہم مشاہدات کو آزادانہ طور پر شمار کرتے ہیں۔
ماضی کی ریاست کے اعداد و شمار کی بنیاد پر مستقبل کی ریاست کی پیشین گوئی کرنا مارکوف ماڈل کہلاتا ہے، اور ایسی مثالیں (کمروں کے ساتھ) مارکوف چینز کہلاتی ہیں۔ چونکہ پیٹرن یکے بعد دیگرے ریاستوں کے درمیان تبدیلیوں کے امکان کی نمائندگی کرتے ہیں، اس لیے وہ بصری طور پر FSMs کے طور پر دکھائے جاتے ہیں جس میں ہر منتقلی کے ارد گرد امکان ہوتا ہے۔ پہلے، ہم نے FSM کا استعمال اس طرز عمل کی حالت کی نمائندگی کے لیے کیا تھا جس میں ایک ایجنٹ تھا، لیکن یہ تصور کسی بھی ریاست تک پھیلا ہوا ہے، چاہے وہ ایجنٹ سے وابستہ ہو یا نہ ہو۔ اس صورت میں، ریاستیں اس کمرے کی نمائندگی کرتی ہیں جس پر ایجنٹ کا قبضہ ہے:
یہ ریاستی تبدیلیوں کے نسبتا امکان کی نمائندگی کرنے کا ایک آسان طریقہ ہے، جس سے AI کو اگلی حالت کی پیشین گوئی کرنے کی کچھ صلاحیت ملتی ہے۔ آپ کئی قدم آگے کی توقع کر سکتے ہیں۔
اگر کوئی کھلاڑی گرین روم میں ہے تو اس بات کا 50% امکان ہے کہ اگلی بار جب اسے دیکھا جائے گا تو وہ وہیں رہے گا۔ لیکن اس کے بعد بھی وہ وہاں موجود ہونے کے کیا امکانات ہیں؟ نہ صرف یہ ایک موقع ہے کہ کھلاڑی دو مشاہدات کے بعد گرین روم میں رہا، بلکہ یہ بھی امکان ہے کہ وہ چلا گیا اور واپس آگیا۔ نئے ڈیٹا کو مدنظر رکھتے ہوئے نیا ٹیبل یہ ہے:
یہ ظاہر کرتا ہے کہ کھلاڑی کو دو مشاہدات کے بعد گرین روم میں دیکھنے کا امکان 51% - 21% کے برابر ہوگا کہ وہ سرخ کمرے سے ہوگا، ان میں سے 5% کہ کھلاڑی ان کے درمیان نیلے کمرے میں جائے گا، اور 25% کہ کھلاڑی گرین روم نہیں چھوڑے گا۔
ٹیبل صرف ایک بصری ٹول ہے - طریقہ کار کے لیے صرف ہر قدم پر امکانات کو ضرب کرنے کی ضرورت ہوتی ہے۔ اس کا مطلب ہے کہ آپ ایک انتباہ کے ساتھ مستقبل میں بہت دور تک دیکھ سکتے ہیں: ہم فرض کرتے ہیں کہ کمرے میں داخل ہونے کا امکان مکمل طور پر موجودہ کمرے پر منحصر ہے۔ اسے مارکوف پراپرٹی کہا جاتا ہے - مستقبل کی حالت صرف حال پر منحصر ہے۔ لیکن یہ سو فیصد درست نہیں ہے۔ کھلاڑی دوسرے عوامل کی بنیاد پر فیصلے بدل سکتے ہیں: صحت کی سطح یا گولہ بارود کی مقدار۔ چونکہ ہم ان اقدار کو ریکارڈ نہیں کرتے ہیں، اس لیے ہماری پیشین گوئیاں کم درست ہوں گی۔
این گرام
فائٹنگ گیم کی مثال اور کھلاڑی کی کومبو چالوں کی پیشین گوئی کے بارے میں کیا خیال ہے؟ ایسا ہی! لیکن ایک ریاست یا واقعہ کے بجائے، ہم ان تمام ترتیبوں کا جائزہ لیں گے جو ایک کومبو سٹرائیک بناتے ہیں۔
ایسا کرنے کا ایک طریقہ یہ ہے کہ ہر ان پٹ (جیسے کِک، پنچ یا بلاک) کو بفر میں اسٹور کریں اور پورے بفر کو بطور ایونٹ لکھیں۔ لہذا کھلاڑی سپر ڈیتھ فسٹ اٹیک کو استعمال کرنے کے لیے کِک، کِک، پنچ کو بار بار دباتا ہے، اے آئی سسٹم تمام ان پٹس کو بفر میں اسٹور کرتا ہے اور ہر قدم میں استعمال ہونے والے آخری تین کو یاد رکھتا ہے۔
(بولڈ میں لکیریں اس وقت ہوتی ہیں جب کھلاڑی SuperDeathFist حملہ شروع کرتا ہے۔)
AI تمام اختیارات دیکھے گا جب کھلاڑی کِک کا انتخاب کرے گا، اس کے بعد ایک اور کِک آئے گا، اور پھر دیکھیں گے کہ اگلا ان پٹ ہمیشہ Punch ہوتا ہے۔ یہ ایجنٹ کو SuperDeathFist کے کومبو اقدام کی پیشین گوئی کرنے اور اگر ممکن ہو تو اسے بلاک کرنے کی اجازت دے گا۔
واقعات کے ان سلسلے کو N-grams کہا جاتا ہے، جہاں N ذخیرہ شدہ عناصر کی تعداد ہے۔ پچھلی مثال میں یہ 3-گرام (ٹریگرام) تھا، جس کا مطلب ہے: پہلی دو اندراجات تیسرے کی پیشین گوئی کرنے کے لیے استعمال ہوتی ہیں۔ اس کے مطابق، 5 گرام میں، پہلی چار اندراجات پانچویں اور اسی طرح کی پیشین گوئی کرتی ہیں۔
ڈیزائنر کو N-گرام کا سائز احتیاط سے منتخب کرنے کی ضرورت ہے۔ ایک چھوٹے N کو کم میموری کی ضرورت ہوتی ہے لیکن اس میں کم تاریخ بھی ذخیرہ ہوتی ہے۔ مثال کے طور پر، ایک 2 گرام (بگگرام) کِک، کِک یا کِک، پنچ کو ریکارڈ کرے گا، لیکن کِک، کِک، پنچ کو اسٹور نہیں کر سکے گا، اس لیے AI SuperDeathFist کومبو کا جواب نہیں دے گا۔
دوسری طرف، بڑی تعداد میں زیادہ میموری کی ضرورت ہوتی ہے اور AI کو تربیت دینا زیادہ مشکل ہو گا کیونکہ بہت سے ممکنہ آپشنز ہوں گے۔ اگر آپ کے پاس کِک، پنچ یا بلاک کے تین ممکنہ ان پٹ تھے، اور ہم نے 10 گرام استعمال کیا، تو یہ تقریباً 60 ہزار مختلف آپشنز ہوں گے۔
بگگرام ماڈل ایک سادہ مارکوف چین ہے - ہر ماضی کی ریاست/موجودہ حالت کا جوڑا ایک بڑا گرام ہے، اور آپ پہلی کی بنیاد پر دوسری حالت کی پیشین گوئی کر سکتے ہیں۔ 3-گرام اور بڑے N-grams کو مارکوف چینز کے طور پر بھی سوچا جا سکتا ہے، جہاں تمام عناصر (سوائے N-gram میں آخری عنصر) مل کر پہلی حالت بناتے ہیں اور آخری عنصر دوسری۔ فائٹنگ گیم کی مثال کِک اینڈ کِک سٹیٹ سے کِک اینڈ پنچ سٹیٹ میں منتقلی کا موقع دکھاتی ہے۔ متعدد ان پٹ ہسٹری کے اندراجات کو ایک اکائی کے طور پر دیکھ کر، ہم بنیادی طور پر ان پٹ کی ترتیب کو پوری ریاست کے حصے میں تبدیل کر رہے ہیں۔ اس سے ہمیں مارکوف کی خاصیت ملتی ہے، جو ہمیں اگلے ان پٹ کی پیشن گوئی کرنے اور اندازہ لگانے کے لیے مارکوف چینز کا استعمال کرنے کی اجازت دیتی ہے کہ آگے کیا کامبو اقدام ہوگا۔
حاصل يہ ہوا
ہم نے مصنوعی ذہانت کی ترقی میں سب سے عام ٹولز اور طریقوں کے بارے میں بات کی۔ ہم نے ان حالات کو بھی دیکھا جن میں انہیں استعمال کرنے کی ضرورت ہے اور وہ کہاں خاص طور پر مفید ہیں۔
گیم AI کی بنیادی باتوں کو سمجھنے کے لیے یہ کافی ہونا چاہیے۔ لیکن، یقینا، یہ تمام طریقے نہیں ہیں. کم مقبول، لیکن کم مؤثر نہیں شامل ہیں:
- اصلاحی الگورتھم بشمول پہاڑی چڑھنے، تدریجی نزول اور جینیاتی الگورتھم
- مخالف تلاش/شیڈیولنگ الگورتھم (منی میکس اور الفا بیٹا کی کٹائی)
- درجہ بندی کے طریقے (پرسیپٹرون، نیورل نیٹ ورکس اور سپورٹ ویکٹر مشینیں)
- پروسیسنگ ایجنٹوں کے خیال اور میموری کے نظام
- AI تک تعمیراتی نقطہ نظر (ہائبرڈ سسٹمز، سب سیٹ آرکیٹیکچرز اور AI سسٹم کو اوورلی کرنے کے دوسرے طریقے)
- حرکت پذیری کے اوزار (منصوبہ بندی اور تحریک کوآرڈینیشن)
- کارکردگی کے عوامل (تفصیل کی سطح، کسی بھی وقت، اور ٹائم سلائسنگ الگورتھم)
موضوع پر آن لائن وسائل:
1. GameDev.net کے پاس ہے۔ اور .
2. گیم AI کی ترقی سے متعلق موضوعات کی ایک وسیع رینج پر بہت سی پیشکشیں اور مضامین شامل ہیں۔
3. اس میں GDC AI سمٹ کے عنوانات شامل ہیں، جن میں سے بہت سے مفت میں دستیاب ہیں۔
4. مفید مواد ویب سائٹ پر بھی پایا جا سکتا ہے۔ .
5. Tommy Thompson، AI محقق اور گیم ڈویلپر، YouTube پر ویڈیوز بناتے ہیں۔ تجارتی گیمز میں AI کی وضاحت اور مطالعہ کے ساتھ۔
موضوع پر کتابیں:
1. گیم AI پرو بک سیریز مختصر مضامین کا مجموعہ ہے جو وضاحت کرتی ہے کہ مخصوص خصوصیات کو کیسے نافذ کیا جائے یا مخصوص مسائل کو کیسے حل کیا جائے۔
2. AI گیم پروگرامنگ وزڈم سیریز گیم AI پرو سیریز کی پیشرو ہے۔ اس میں پرانے طریقے ہیں، لیکن تقریباً سبھی آج بھی متعلقہ ہیں۔
3. ہر ایک کے لیے بنیادی متن میں سے ایک ہے جو مصنوعی ذہانت کے عمومی شعبے کو سمجھنا چاہتا ہے۔ یہ گیم ڈویلپمنٹ کے بارے میں کوئی کتاب نہیں ہے - یہ AI کی بنیادی باتیں سکھاتی ہے۔
ماخذ: www.habr.com