نحوه ایجاد یک هوش مصنوعی بازی: راهنمای مبتدیان

به مطالب جالبی در مورد هوش مصنوعی در بازی ها برخوردم. با توضیح موارد اساسی در مورد هوش مصنوعی با استفاده از مثال های ساده و در داخل ابزارها و روش های مفید زیادی برای توسعه و طراحی راحت آن وجود دارد. نحوه، مکان و زمان استفاده از آنها نیز وجود دارد.

بیشتر نمونه ها با شبه کد نوشته شده اند، بنابراین نیازی به دانش برنامه نویسی پیشرفته نیست. زیر برش 35 برگه متن با عکس و گیف وجود دارد، پس آماده شوید.

UPD. من عذرخواهی می کنم، اما من قبلاً ترجمه خود را از این مقاله در Habré انجام داده ام بیمار صفر. می توانید نسخه او را بخوانید اینجا، اما به دلایلی مقاله از من عبور کرد (من از جستجو استفاده کردم، اما مشکلی پیش آمد). و از آنجایی که من در وبلاگی می نویسم که به توسعه بازی اختصاص دارد، تصمیم گرفتم نسخه ترجمه خود را برای مشترکین بگذارم (برخی از نکات به صورت متفاوتی قالب بندی شده اند، برخی به عمد به توصیه توسعه دهندگان حذف شده اند).

هوش مصنوعی چیست؟

هوش مصنوعی بازی بر روی اعمالی که یک شی باید بر اساس شرایطی که در آن قرار دارد انجام دهد تمرکز می کند. این معمولاً به عنوان مدیریت "عامل هوشمند" شناخته می شود، جایی که یک عامل یک شخصیت بازیکن، یک وسیله نقلیه، یک ربات یا گاهی اوقات چیزی انتزاعی تر است: یک گروه کامل از موجودیت ها یا حتی یک تمدن. در هر مورد، چیزی است که باید محیط خود را ببیند، بر اساس آن تصمیم بگیرد و مطابق با آن عمل کند. این چرخه حس/فکر/عمل نامیده می شود:

• حس: عامل اطلاعاتی در مورد چیزهایی در محیط خود می یابد یا دریافت می کند که ممکن است بر رفتار او تأثیر بگذارد (تهدیدهای نزدیک، اقلام برای جمع آوری، مکان های جالب برای کاوش).
• فکر کنید: مامور تصمیم می گیرد که چگونه واکنش نشان دهد (به این فکر می کند که آیا جمع آوری اقلام به اندازه کافی ایمن است یا اینکه ابتدا باید بجنگد/پنهان شود).
• Act: عامل اقداماتی را برای اجرای تصمیم قبلی انجام می دهد (شروع به حرکت به سمت دشمن یا شیء می کند).
• ...اکنون به دلیل اعمال شخصیت ها وضعیت تغییر کرده است، بنابراین چرخه با داده های جدید تکرار می شود.

هوش مصنوعی تمایل دارد روی بخش Sense حلقه تمرکز کند. به عنوان مثال، اتومبیل های خودران از جاده عکس می گیرند، آنها را با داده های رادار و لیدار ترکیب می کنند و آنها را تفسیر می کنند. این معمولاً توسط یادگیری ماشینی انجام می‌شود، که داده‌های دریافتی را پردازش می‌کند و به آن معنا می‌بخشد، و اطلاعات معنایی مانند «ماشین دیگری در 20 یارد جلوتر از شما وجود دارد» استخراج می‌کند. اینها به اصطلاح مشکلات طبقه بندی هستند.

بازی‌ها برای استخراج اطلاعات به سیستم پیچیده‌ای نیاز ندارند زیرا بیشتر داده‌ها در حال حاضر بخشی جدایی ناپذیر از آن هستند. نیازی به اجرای الگوریتم های تشخیص تصویر برای تعیین اینکه آیا دشمنی در پیش است وجود ندارد - بازی از قبل می داند و اطلاعات را مستقیماً به فرآیند تصمیم گیری می دهد. بنابراین، بخش حس چرخه اغلب بسیار ساده تر از بخش فکر و عمل است.

محدودیت های هوش مصنوعی بازی

هوش مصنوعی تعدادی محدودیت دارد که باید رعایت شود:

• هوش مصنوعی نیازی به آموزش از قبل ندارد، گویی یک الگوریتم یادگیری ماشینی است. نوشتن یک شبکه عصبی در حین توسعه برای نظارت بر ده ها هزار بازیکن و یادگیری بهترین راه برای بازی در برابر آنها، منطقی نیست. چرا؟ چون بازی منتشر نشده و هیچ بازیکنی وجود ندارد.
• بازی باید سرگرم کننده و چالش برانگیز باشد، بنابراین عوامل نباید بهترین رویکرد را در برابر مردم پیدا کنند.
• نمایندگان باید واقع بینانه به نظر برسند تا بازیکنان احساس کنند در مقابل افراد واقعی بازی می کنند. برنامه AlphaGo بهتر از انسان ها عمل کرد، اما مراحل انتخاب شده بسیار دور از درک سنتی بازی بود. اگر بازی حریف انسانی را شبیه سازی می کند، این احساس نباید وجود داشته باشد. الگوریتم باید تغییر کند تا تصمیمات قابل قبولی بگیرد تا تصمیمات ایده آل.
• هوش مصنوعی باید در زمان واقعی کار کند. این بدان معنی است که الگوریتم نمی تواند استفاده از CPU را برای مدت طولانی برای تصمیم گیری در انحصار خود درآورد. حتی 10 میلی ثانیه هم خیلی طولانی است، زیرا اکثر بازی ها فقط به 16 تا 33 میلی ثانیه برای انجام تمام پردازش ها و رفتن به فریم گرافیکی بعدی نیاز دارند.
• در حالت ایده‌آل، حداقل بخشی از سیستم باید مبتنی بر داده باشد، به طوری که غیر کدنویس‌ها می‌توانند تغییرات را انجام دهند و تنظیمات سریع‌تر انجام شود.

بیایید به رویکردهای هوش مصنوعی نگاه کنیم که کل چرخه حس/فکر/عمل را پوشش می‌دهد.

اتخاذ تصمیمات اساسی

بیایید با ساده ترین بازی - Pong شروع کنیم. هدف: دست و پا زدن را طوری حرکت دهید که توپ به جای اینکه از کنار آن عبور کند، از آن پرتاب شود. مثل تنیس است که اگر توپ را نزنید بازنده می شوید. در اینجا هوش مصنوعی کار نسبتاً آسانی دارد - تصمیم گیری در کدام جهت حرکت پلت فرم.

اظهارات مشروط

برای هوش مصنوعی در پونگ، واضح ترین راه حل این است که همیشه سعی کنید سکو را زیر توپ قرار دهید.

یک الگوریتم ساده برای این کار که در شبه کد نوشته شده است:

هر فریم/به‌روزرسانی در حین اجرای بازی:
اگر توپ در سمت چپ پارو باشد:
حرکت پارو به چپ
در غیر این صورت اگر توپ در سمت راست پارو باشد:
دست و پا زدن را به سمت راست حرکت دهید

اگر پلت فرم با سرعت توپ حرکت می کند، این الگوریتم ایده آل برای هوش مصنوعی در Pong است. اگر داده ها و اقدامات احتمالی زیادی برای عامل وجود نداشته باشد، نیازی به پیچیده کردن چیزی نیست.

این رویکرد آنقدر ساده است که کل چرخه حس/فکر/عمل به سختی قابل توجه است. اما آنجاست:

• بخش Sense در دو عبارت if است. بازی می داند توپ کجاست و پلتفرم کجاست، بنابراین هوش مصنوعی به دنبال آن اطلاعات است.
• قسمت Think نیز در دو عبارت if گنجانده شده است. آنها دو راه حل را در بر می گیرند که در این مورد متقابل هستند. در نتیجه، یکی از سه عمل انتخاب می شود - پلت فرم را به سمت چپ حرکت دهید، آن را به سمت راست ببرید، یا اگر قبلاً به درستی قرار گرفته است کاری انجام ندهید.
• بخش Act در دستورات Move Paddle Left و Move Paddle Right یافت می شود. بسته به طراحی بازی، آنها می توانند پلتفرم را به صورت آنی یا با سرعت خاصی حرکت دهند.

چنین رویکردهایی واکنشی نامیده می شوند - مجموعه ای ساده از قوانین (در این مورد اگر عباراتی در کد وجود دارد) وجود دارد که به وضعیت فعلی جهان واکنش نشان می دهد و اقدام می کند.

درخت تصمیم

مثال Pong در واقع معادل یک مفهوم رسمی هوش مصنوعی به نام درخت تصمیم است. الگوریتم از طریق آن می گذرد تا به یک "برگ" برسد - تصمیمی در مورد اینکه چه اقدامی باید انجام شود.

بیایید یک بلوک دیاگرام از درخت تصمیم برای الگوریتم پلت فرم خود بسازیم:

هر قسمت از درخت یک گره نامیده می شود - هوش مصنوعی از نظریه گراف برای توصیف چنین ساختارهایی استفاده می کند. دو نوع گره وجود دارد:

• گره های تصمیم: انتخاب بین دو گزینه بر اساس آزمایش برخی شرایط، که در آن هر جایگزین به عنوان یک گره جداگانه نشان داده می شود.
• گره های پایانی: اقدامی برای انجام که نشان دهنده تصمیم نهایی است.

الگوریتم از اولین گره ("ریشه" درخت) شروع می شود. یا تصمیم می گیرد که به کدام گره فرزند برود، یا عمل ذخیره شده در گره را اجرا می کند و خارج می شود.

مزیت داشتن درخت تصمیم همان کار عبارات if در بخش قبل چیست؟ در اینجا یک سیستم کلی وجود دارد که در آن هر تصمیم فقط یک شرط و دو نتیجه ممکن دارد. این به توسعه‌دهنده اجازه می‌دهد تا هوش مصنوعی را از داده‌هایی که تصمیم‌های یک درخت را نشان می‌دهند، بدون نیاز به کدگذاری سخت آن ایجاد کند. بیایید آن را به شکل جدول ارائه کنیم:

در سمت کد، سیستمی برای خواندن رشته ها دریافت خواهید کرد. برای هر یک از آنها یک گره ایجاد کنید، منطق تصمیم گیری را بر اساس ستون دوم و گره های فرزند را بر اساس ستون های سوم و چهارم به هم متصل کنید. شما هنوز باید شرایط و اقدامات را برنامه ریزی کنید، اما اکنون ساختار بازی پیچیده تر خواهد شد. در اینجا تصمیمات و اقدامات اضافی را اضافه می‌کنید و سپس با ویرایش فایل متنی تعریف درخت، کل هوش مصنوعی را سفارشی می‌کنید. در مرحله بعد، فایل را به طراح بازی منتقل می کنید، که می تواند بدون کامپایل مجدد بازی یا تغییر کد، رفتار را تغییر دهد.

درخت های تصمیم زمانی بسیار مفید هستند که به طور خودکار از مجموعه بزرگی از مثال ها ساخته شوند (مثلاً با استفاده از الگوریتم ID3). این آنها را به ابزاری موثر و با کارایی بالا برای طبقه بندی موقعیت ها بر اساس داده های به دست آمده تبدیل می کند. با این حال، ما فراتر از یک سیستم ساده برای عوامل برای انتخاب اقدامات می‌رویم.

سناریوها

ما یک سیستم درخت تصمیم را تحلیل کردیم که از شرایط و اقدامات از پیش ایجاد شده استفاده می کرد. شخصی که هوش مصنوعی را طراحی می‌کند می‌تواند درخت را هر طور که می‌خواهد سازماندهی کند، اما همچنان باید به کدنویسی که همه آن را برنامه‌ریزی کرده است، تکیه کند. اگر بتوانیم ابزارهایی را در اختیار طراح قرار دهیم تا شرایط یا اقدامات خود را ایجاد کند چه؟

برای اینکه برنامه نویس مجبور نباشد برای شرایط Is Ball Left Of Paddle و Is Ball Right Of Paddle کد بنویسد، می تواند سیستمی ایجاد کند که در آن طراح شرایط را برای بررسی این مقادیر بنویسد. سپس داده های درخت تصمیم به شکل زیر خواهد بود:

این اساساً مانند جدول اول است، اما راه‌حل‌ها در درون خود کد خاص خود را دارند، کمی شبیه بخش شرطی یک دستور if. در سمت کد، این در ستون دوم برای گره های تصمیم خوانده می شود، اما به جای جستجوی یک شرط خاص برای اجرا (Is Ball Left Of Paddle)، عبارت شرطی را ارزیابی می کند و بر اساس آن true یا false را برمی گرداند. این کار با استفاده از زبان برنامه نویسی Lua یا Angelscript انجام می شود. با استفاده از آنها، یک توسعه دهنده می تواند اشیاء را در بازی خود بگیرد (توپ و دست و پا زدن) و متغیرهایی را ایجاد کند که در اسکریپت (ball.position) در دسترس خواهند بود. همچنین زبان برنامه نویسی ساده تر از C++ است. این نیازی به یک مرحله کامل کامپایل ندارد، بنابراین برای تنظیم سریع منطق بازی ایده آل است و به "غیر کدنویس ها" اجازه می دهد تا خود عملکردهای لازم را ایجاد کنند.

در مثال بالا، زبان اسکریپت فقط برای ارزیابی عبارت شرطی استفاده می شود، اما می توان از آن برای اقدامات نیز استفاده کرد. به عنوان مثال، داده Move Paddle Right می تواند به یک دستور اسکریپت تبدیل شود (ball.position.x += 10). به طوری که بدون نیاز به برنامه ریزی Move Paddle Right، اکشن نیز در اسکریپت تعریف شده است.

شما می توانید حتی فراتر رفته و کل درخت تصمیم را در یک زبان برنامه نویسی بنویسید. این کد به شکل عبارات شرطی سخت کد شده خواهد بود، اما آنها در فایل های اسکریپت خارجی قرار می گیرند، یعنی می توان آنها را بدون کامپایل مجدد کل برنامه تغییر داد. شما اغلب می توانید فایل اسکریپت را در طول بازی ویرایش کنید تا به سرعت پاسخ های هوش مصنوعی مختلف را آزمایش کنید.

پاسخ رویداد

مثال های بالا برای پونگ عالی هستند. آنها به طور مداوم چرخه Sense/Think/Act را اجرا می کنند و بر اساس آخرین وضعیت جهان عمل می کنند. اما در بازی های پیچیده تر باید به رویدادهای فردی واکنش نشان دهید و همه چیز را به یکباره ارزیابی نکنید. پنگ در این مورد قبلاً یک مثال بد است. یکی دیگر را انتخاب کنیم.

تیراندازی را تصور کنید که در آن دشمنان تا زمانی که بازیکن را شناسایی نکنند بی حرکت هستند، پس از آن بسته به "تخصص" خود عمل می کنند: کسی می دود تا "عجله کند"، کسی از دور حمله می کند. این هنوز یک سیستم واکنشی اولیه است - "اگر بازیکنی شناسایی شد، کاری انجام دهید" - اما می توان آن را به طور منطقی به یک رویداد Player Seen و یک Reaction تقسیم کرد (یک پاسخ را انتخاب کنید و آن را اجرا کنید).

این ما را به چرخه حس/فکر/عمل برمی گرداند. ما می‌توانیم بخش Sense را کدنویسی کنیم که هر فریم را بررسی کند که آیا هوش مصنوعی پخش‌کننده را می‌بیند یا خیر. اگر نه، هیچ اتفاقی نمی افتد، اما اگر ببیند، رویداد Player Seen ایجاد می شود. کد دارای بخش جداگانه ای است که می گوید "وقتی رویداد Player Seen رخ می دهد، انجام دهید" که در آن پاسخی است که برای پرداختن به بخش های Think and Act نیاز دارید. بنابراین، شما واکنش هایی را به رویداد Player Seen تنظیم خواهید کرد: برای شخصیت "عجله" - ChargeAndAttack، و برای تک تیرانداز - HideAndSnipe. این روابط را می توان در فایل داده برای ویرایش سریع بدون نیاز به کامپایل مجدد ایجاد کرد. زبان اسکریپت در اینجا نیز قابل استفاده است.

گرفتن تصمیمات سخت

اگرچه سیستم‌های واکنش ساده بسیار قدرتمند هستند، اما موقعیت‌های زیادی وجود دارد که کافی نیستند. گاهی اوقات شما نیاز دارید که بر اساس کاری که نماینده در حال حاضر انجام می دهد، تصمیمات متفاوتی بگیرید، اما تصور این به عنوان یک شرط دشوار است. گاهی اوقات شرایط بسیار زیادی وجود دارد که نمی توان آنها را به طور مؤثر در درخت تصمیم یا اسکریپت نشان داد. گاهی اوقات لازم است قبل از تصمیم گیری در مورد مرحله بعدی، از قبل ارزیابی کنید که چگونه وضعیت تغییر خواهد کرد. برای حل این مشکلات به رویکردهای پیچیده تری نیاز است.

ماشین حالت محدود

ماشین حالت محدود یا FSM (ماشین حالت محدود) راهی است برای گفتن اینکه عامل ما در حال حاضر در یکی از چندین حالت ممکن است و می تواند از یک حالت به حالت دیگر منتقل شود. تعداد معینی از چنین ایالت ها وجود دارد - از این رو نام آن. بهترین مثال از زندگی چراغ راهنمایی است. توالی های مختلفی از نورها در مکان های مختلف وجود دارد، اما اصل یکسان است - هر حالت چیزی را نشان می دهد (ایست، راه رفتن، و غیره). یک چراغ راهنمایی در هر زمان معین فقط در یک حالت است و بر اساس قوانین ساده از یکی به دیگری حرکت می کند.

این یک داستان مشابه با NPC ها در بازی ها است. به عنوان مثال، بیایید یک محافظ با حالت های زیر در نظر بگیریم:

• گشت زنی.
• هجوم بردن.
• در حال فرار

و این شرایط برای تغییر حالت آن:

• نگهبان اگر دشمن را ببیند حمله می کند.
• اگر نگهبان حمله کند اما دیگر دشمن را نبیند، برای پاتک برمی گردد.
• اگر نگهبانی حمله کند اما به شدت زخمی شود، فرار می کند.

همچنین می‌توانید if-statements را با متغیر حالت نگهبان و بررسی‌های مختلف بنویسید: آیا دشمنی در این نزدیکی هست، سطح سلامت NPC چقدر است و غیره. اجازه دهید چند حالت دیگر اضافه کنیم:

• بیکاری - بین گشت.
• جستجو - زمانی که دشمن متوجه شده ناپدید شد.
• یافتن کمک - زمانی که یک دشمن شناسایی می شود، اما آنقدر قوی است که نمی تواند به تنهایی بجنگد.

انتخاب برای هر یک از آنها محدود است - به عنوان مثال، نگهبان اگر سلامتی پایینی داشته باشد به دنبال دشمن پنهان نمی رود.

پس از همه، یک لیست بزرگ از "اگر" وجود دارد ، آن ممکن است خیلی دست و پا گیر شود، بنابراین باید روشی را رسمی کنیم که به ما امکان می دهد حالت ها و انتقال بین حالت ها را در ذهن داشته باشیم. برای این کار، همه حالت ها را در نظر می گیریم و در زیر هر حالت، تمام انتقال ها به حالت های دیگر را به همراه شرایط لازم برای آنها در فهرستی یادداشت می کنیم.

این یک جدول انتقال حالت است - راهی جامع برای نشان دادن FSM. بیایید یک نمودار ترسیم کنیم و یک نمای کلی از نحوه تغییر رفتار NPC بدست آوریم.

نمودار ماهیت تصمیم گیری برای این عامل را بر اساس وضعیت فعلی منعکس می کند. علاوه بر این، اگر شرط کنار آن درست باشد، هر فلش یک انتقال بین حالت‌ها را نشان می‌دهد.

هر به روز رسانی وضعیت فعلی عامل را بررسی می کنیم، لیست انتقال ها را بررسی می کنیم و اگر شرایط انتقال برقرار باشد، وضعیت جدید را می پذیرد. به عنوان مثال، هر فریم بررسی می کند که آیا تایمر 10 ثانیه منقضی شده است یا خیر، و اگر چنین است، پس از آن نگهبان از حالت Idling به Patroling می رود. به همین ترتیب، حالت Attacking سلامت عامل را بررسی می کند - اگر پایین باشد، سپس به حالت فرار می رود.

این مدیریت انتقال بین حالت ها است، اما رفتار مرتبط با خود ایالت ها چطور؟ از نظر اجرای رفتار واقعی برای یک حالت خاص، معمولاً دو نوع "قلاب" وجود دارد که در آنها اقداماتی را به FSM اختصاص می دهیم:

• اقداماتی که به صورت دوره ای برای وضعیت فعلی انجام می دهیم.
• اقداماتی که هنگام انتقال از یک حالت به حالت دیگر انجام می دهیم.

نمونه هایی برای نوع اول حالت گشت زنی عامل را در طول مسیر گشت هر فریم حرکت می دهد. حالت حمله تلاش می کند تا هر فریم یا انتقال به حالتی که در آن امکان پذیر باشد، حمله ای را آغاز کند.

برای نوع دوم، انتقال را در نظر بگیرید «اگر دشمن قابل مشاهده است و دشمن بیش از حد قوی است، سپس به حالت Finding Help بروید. نماینده باید انتخاب کند که برای کمک به کجا مراجعه کند و این اطلاعات را ذخیره کند تا وضعیت Finding Help بداند کجا باید برود. پس از یافتن کمک، عامل به حالت حمله برمی گردد. در این مرحله، او می خواهد به متحد در مورد تهدید بگوید، بنابراین ممکن است اقدام NotifyFriendOfThreat رخ دهد.

یک بار دیگر می‌توانیم به این سیستم از دریچه چرخه Sense/Think/Act نگاه کنیم. حس در داده های استفاده شده توسط منطق انتقال تجسم می یابد. فکر کنید - انتقال در هر ایالت موجود است. و Act توسط اقداماتی انجام می شود که به صورت دوره ای در یک حالت یا در انتقال بین حالت ها انجام می شود.

گاهی اوقات رای گیری مداوم شرایط انتقال ممکن است پرهزینه باشد. برای مثال، اگر هر عاملی محاسبات پیچیده‌ای را در هر فریم انجام دهد تا مشخص کند که آیا می‌تواند دشمنان را ببیند یا نه و بفهمد که آیا می‌تواند از حالت Patroling به Attacking عبور کند، این کار زمان زیادی از CPU را می‌گیرد.

تغییرات مهم در وضعیت جهان را می توان به عنوان رویدادهایی در نظر گرفت که به محض وقوع آنها پردازش می شوند. به جای اینکه FSM شرایط انتقال "آیا نماینده من پخش کننده را ببیند؟" را در هر فریم بررسی کند، می توان یک سیستم جداگانه را پیکربندی کرد تا دفعات کمتری را بررسی کند (مثلاً 5 بار در ثانیه). و نتیجه این است که هنگام عبور چک، Player Seen صادر می شود.

این به FSM منتقل می شود، که اکنون باید به شرط دریافت رویداد Player Seen برود و مطابق با آن پاسخ دهد. رفتار حاصل یکسان است به جز یک تاخیر تقریباً نامحسوس قبل از پاسخ. اما عملکرد در نتیجه جداسازی بخش Sense به بخش جداگانه ای از برنامه بهبود یافته است.

ماشین حالت محدود سلسله مراتبی

با این حال، کار با FSM های بزرگ همیشه راحت نیست. اگر می‌خواهیم حالت حمله را گسترش دهیم تا MeleeAttacking و RangedAttacking را از هم جدا کنیم، باید انتقال‌ها را از سایر حالت‌هایی که به حالت Attacking منتهی می‌شوند (حال و آینده) تغییر دهیم.

احتمالاً متوجه شده اید که در مثال ما تعداد زیادی انتقال تکراری وجود دارد. اکثر انتقال ها در حالت Idling با انتقال در حالت Patroling یکسان هستند. خوب است که خودمان را تکرار نکنیم، به خصوص اگر حالت های مشابه بیشتری اضافه کنیم. منطقی است که Idling و Patrolling را تحت عنوان کلی "غیر رزمی" گروه بندی کنیم، جایی که تنها یک مجموعه متداول از انتقال به ایالت های رزمی وجود دارد. اگر این برچسب را به عنوان یک حالت در نظر بگیریم، آنگاه Idling و Patrolling تبدیل به یک حالت فرعی می شوند. نمونه ای از استفاده از یک جدول انتقال جداگانه برای یک زیر دولت جدید غیر جنگی:

حالات اصلی:


وضعیت خارج از رزم:


و به شکل نمودار:

این همان سیستم است، اما با یک حالت غیر جنگی جدید که شامل Idling و Patroling می شود. با هر حالتی که حاوی یک FSM با زیرشاخه‌ها باشد (و این خرده‌حالت‌ها به نوبه خود حاوی FSM‌های خود هستند - و تا زمانی که نیاز دارید ادامه دهید)، یک ماشین حالت محدود سلسله مراتبی یا HFSM (ماشین حالت محدود سلسله مراتبی) دریافت می‌کنیم. با گروه بندی حالت غیر جنگی، ما یک دسته انتقال اضافی را قطع کردیم. ما می توانیم همین کار را برای هر حالت جدید با انتقال مشترک انجام دهیم. به عنوان مثال، اگر در آینده حالت حمله را به ایالت‌های MeleeAttacking و MissileAttacking گسترش دهیم، این دو حالت فرعی خواهند بود که بر اساس فاصله تا دشمن و در دسترس بودن مهمات بین یکدیگر انتقال می‌یابند. در نتیجه، رفتارهای پیچیده و رفتارهای فرعی را می توان با حداقل انتقال تکراری نشان داد.

درخت رفتار

با HFSM، ترکیبات پیچیده ای از رفتارها به روشی ساده ایجاد می شود. با این حال، یک مشکل جزئی وجود دارد که تصمیم گیری در قالب قوانین انتقال ارتباط نزدیکی با وضعیت فعلی دارد. و در بسیاری از بازی ها این دقیقا همان چیزی است که مورد نیاز است. و استفاده دقیق از سلسله مراتب حالت می تواند تعداد تکرارهای انتقال را کاهش دهد. اما گاهی اوقات شما نیاز به قوانینی دارید که بدون توجه به اینکه در چه ایالتی هستید یا تقریباً در هر ایالتی اعمال می شود. به عنوان مثال، اگر سلامت یک مامور به 25٪ کاهش یابد، شما می خواهید که او بدون توجه به اینکه در حال جنگ، بیکار یا صحبت بوده است فرار کند - باید این شرایط را به هر ایالت اضافه کنید. و اگر طراح شما بعداً بخواهد آستانه سلامت پایین را از 25٪ به 10٪ تغییر دهد، این کار باید دوباره انجام شود.

در حالت ایده‌آل، این وضعیت مستلزم سیستمی است که در آن تصمیم‌گیری در مورد «در چه وضعیتی باشد» خارج از خود ایالت‌ها باشد تا تنها در یک مکان تغییراتی ایجاد شود و شرایط انتقال را لمس نکند. درختان رفتار در اینجا ظاهر می شوند.

راه‌های مختلفی برای پیاده‌سازی آن‌ها وجود دارد، اما ماهیت آن تقریباً برای همه یکسان است و شبیه درخت تصمیم است: الگوریتم با یک گره «ریشه» شروع می‌شود و درخت شامل گره‌هایی است که تصمیم‌ها یا اقدامات را نشان می‌دهند. اگرچه چند تفاوت اساسی وجود دارد:

• گره‌ها اکنون یکی از سه مقدار را برمی‌گردانند: موفقیت‌آمیز (اگر کار تکمیل شود)، ناموفق (اگر نمی‌توان آن را شروع کرد)، یا در حال اجرا (اگر هنوز در حال اجرا است و نتیجه نهایی وجود ندارد).
• هیچ گره تصمیم دیگری برای انتخاب بین دو گزینه وجود ندارد. در عوض، آنها گره های Decorator هستند که دارای یک گره فرزند هستند. اگر موفق شوند، تنها گره فرزند خود را اجرا می کنند.
• گره هایی که اقداماتی را انجام می دهند، مقدار Running را برای نمایش اقدامات در حال انجام برمی گردانند.

این مجموعه کوچک از گره ها را می توان برای ایجاد تعداد زیادی رفتار پیچیده ترکیب کرد. بیایید محافظ HFSM را از مثال قبلی به عنوان یک درخت رفتار تصور کنیم:

با این ساختار، هیچ انتقال آشکاری از حالت های Idling/Patrolling به Attacking یا هر حالت دیگری وجود ندارد. اگر دشمن قابل مشاهده باشد و سلامت شخصیت پایین باشد، بدون توجه به اینکه قبلاً کدام گره را اجرا کرده است - پاترولینگ، بیکار، حمله یا هر گره دیگری، اجرا در گره فرار متوقف می شود.

درختان رفتار پیچیده هستند - راه های زیادی برای ترکیب آنها وجود دارد و یافتن ترکیب مناسبی از تزئینات و گره های ترکیبی می تواند چالش برانگیز باشد. همچنین سؤالاتی در مورد هر چند وقت یکبار بررسی درخت وجود دارد - آیا می خواهیم از هر قسمت آن عبور کنیم یا فقط زمانی که یکی از شرایط تغییر کرده است؟ چگونه وضعیت مربوط به گره ها را ذخیره کنیم - چگونه بفهمیم که به مدت 10 ثانیه در حالت بیکار بوده ایم یا چگونه بفهمیم که آخرین بار کدام گره ها اجرا شده اند تا بتوانیم دنباله را به درستی پردازش کنیم؟

به همین دلیل است که پیاده سازی های زیادی وجود دارد. به عنوان مثال، برخی از سیستم ها گره های دکوراتور را با دکوراتورهای درون خطی جایگزین کرده اند. آنها درخت را هنگامی که شرایط دکوراتور تغییر می کند، دوباره ارزیابی می کنند، به گره ها متصل می شوند و به روز رسانی های دوره ای را ارائه می دهند.

سیستم مبتنی بر ابزار

برخی از بازی ها مکانیک های مختلفی دارند. مطلوب است که آنها تمام مزایای قوانین انتقال ساده و کلی را دریافت کنند، اما نه لزوماً در قالب یک درخت کامل رفتار. به جای داشتن مجموعه ای واضح از انتخاب ها یا درختی از اقدامات ممکن، بررسی همه اقدامات و انتخاب مناسب ترین آنها در لحظه آسان تر است.

سیستم مبتنی بر Utility فقط در این مورد کمک خواهد کرد. این سیستمی است که در آن عامل دارای انواع مختلفی از اقدامات است و بر اساس مطلوبیت نسبی هر کدام از آنها را انتخاب می کند. جایی که مطلوبیت معیاری دلخواه است که نشان می دهد چقدر انجام این عمل برای عامل مهم یا مطلوب است.

ابزار محاسبه شده یک عمل بر اساس وضعیت و محیط فعلی، عامل می تواند در هر زمان مناسب ترین حالت دیگر را بررسی و انتخاب کند. این شبیه به FSM است، به جز جایی که انتقال ها با یک تخمین برای هر حالت بالقوه، از جمله وضعیت فعلی تعیین می شوند. لطفاً توجه داشته باشید که ما مفیدترین اقدام را برای ادامه کار انتخاب می‌کنیم (یا اگر قبلاً آن را انجام داده‌ایم می‌مانیم). برای تنوع بیشتر، این می تواند یک انتخاب متعادل اما تصادفی از یک لیست کوچک باشد.

سیستم یک محدوده دلخواه از مقادیر سودمند را اختصاص می دهد - برای مثال، از 0 (کاملاً نامطلوب) تا 100 (کاملاً مطلوب). هر عمل دارای تعدادی پارامتر است که بر محاسبه این مقدار تأثیر می گذارد. بازگشت به مثال نگهبان ما:

انتقال بین اقدامات مبهم است - هر حالتی می تواند از هر حالت دیگری پیروی کند. اولویت های اقدام در مقادیر ابزار برگشتی یافت می شوند. اگر دشمنی قابل مشاهده باشد، و آن دشمن قوی باشد، و سلامت شخصیت پایین باشد، هر دو Fleeing و FindingHelp مقادیر بالای غیر صفر را برمی‌گردانند. در این حالت، FindingHelp همیشه بالاتر خواهد بود. به همین ترتیب، فعالیت های غیر رزمی هرگز بیش از 50 بر نمی گردند، بنابراین همیشه کمتر از فعالیت های رزمی خواهند بود. شما باید این را هنگام ایجاد اقدامات و محاسبه ابزار آنها در نظر بگیرید.

در مثال ما، اقدامات یا یک مقدار ثابت ثابت یا یکی از دو مقدار ثابت را برمی‌گردانند. یک سیستم واقع بینانه تر، تخمینی را از یک محدوده پیوسته از مقادیر برمی گرداند. به عنوان مثال، در صورت پایین بودن سلامت عامل، اکشن Fleeing مقادیر کاربردی بالاتری را برمی‌گرداند و اگر دشمن بیش از حد قوی باشد، اکشن Attacking مقادیر کاربردی کمتری را برمی‌گرداند. به همین دلیل، در هر موقعیتی که عامل احساس کند سلامت کافی برای شکست دادن دشمن را ندارد، اقدام فرار بر حمله ارجحیت دارد. این اجازه می دهد تا اقدامات بر اساس تعدادی از معیارها اولویت بندی شوند و این رویکرد را نسبت به درخت رفتار یا FSM انعطاف پذیرتر و متغیرتر می کند.

هر عمل دارای شرایط زیادی برای محاسبه برنامه است. آنها را می توان به زبان برنامه نویسی یا به عنوان یک سری فرمول های ریاضی نوشت. سیمز، که روال روزانه یک شخصیت را شبیه‌سازی می‌کند، یک لایه محاسبه اضافی اضافه می‌کند - عامل یک سری «انگیزه‌ها» دریافت می‌کند که بر رتبه‌بندی ابزار تأثیر می‌گذارد. اگر شخصیتی گرسنه باشد، با گذشت زمان حتی گرسنه‌تر می‌شود و ارزش کاربردی اکشن EatFood تا زمانی که کاراکتر آن را انجام دهد افزایش می‌یابد و سطح گرسنگی را کاهش می‌دهد و مقدار EatFood را به صفر برمی‌گرداند.

ایده انتخاب اقدامات بر اساس یک سیستم رتبه بندی بسیار ساده است، بنابراین یک سیستم مبتنی بر Utility می تواند به عنوان بخشی از فرآیندهای تصمیم گیری هوش مصنوعی به جای جایگزینی کامل برای آنها استفاده شود. درخت تصمیم ممکن است رتبه‌بندی ابزار دو گره فرزند را بخواهد و گره بالاتر را انتخاب کند. به طور مشابه، یک درخت رفتار می تواند یک گره Utility ترکیبی داشته باشد تا سودمندی اقدامات را ارزیابی کند تا تصمیم بگیرد کدام فرزند را اجرا کند.

حرکت و ناوبری

در نمونه های قبلی یک سکو داشتیم که به چپ یا راست حرکت می کردیم و یک نگهبان که به گشت زنی یا حمله می پرداخت. اما دقیقاً چگونه جابجایی عامل را در یک دوره زمانی مدیریت می کنیم؟ چگونه سرعت را تنظیم کنیم، چگونه از موانع اجتناب کنیم، و چگونه مسیری را برنامه ریزی کنیم که رسیدن به مقصد دشوارتر از حرکت در یک خط مستقیم است؟ بیایید به این نگاه کنیم.

حکومتداری

در مرحله اولیه، فرض می کنیم که هر عامل دارای یک مقدار سرعت است که شامل سرعت حرکت و در چه جهتی است. می توان آن را برحسب متر در ثانیه، کیلومتر در ساعت، پیکسل در ثانیه و غیره اندازه گیری کرد. با یادآوری حلقه Sense/Think/Act، می توانیم تصور کنیم که قسمت Think سرعتی را انتخاب می کند و قسمت Act آن سرعت را برای عامل اعمال می کند. معمولاً بازی‌ها دارای یک سیستم فیزیک هستند که این کار را برای شما انجام می‌دهد، مقدار سرعت هر جسم را یاد می‌گیرد و آن را تنظیم می‌کند. بنابراین، شما می توانید هوش مصنوعی را با یک وظیفه رها کنید - تصمیم بگیرید که عامل باید چه سرعتی داشته باشد. اگر می‌دانید عامل باید کجا باشد، باید آن را با سرعت تعیین‌شده در جهت درست حرکت دهید. یک معادله بسیار پیش پا افتاده:

دلخواه_سفر = موقعیت_ مقصد - موقعیت_عامل

دنیای دو بعدی را تصور کنید. عامل در نقطه (-2،-2)، مقصد جایی در شمال شرقی در نقطه (2، 30)، و مسیر مورد نیاز برای مامور برای رسیدن به آنجا (20، 32) است. فرض کنید این موقعیت ها بر حسب متر اندازه گیری می شوند - اگر سرعت عامل را 22 متر بر ثانیه در نظر بگیریم، بردار جابجایی خود را مقیاس می کنیم و سرعت تقریباً (5، 4.12) را به دست می آوریم. با این پارامترها، عامل تقریباً در 2.83 ثانیه به مقصد می رسد.

شما می توانید مقادیر را در هر زمان دوباره محاسبه کنید. اگر عامل در نیمه راه به سمت هدف بود، حرکت نیمی از طول بود، اما از آنجایی که حداکثر سرعت عامل 5 متر بر ثانیه است (ما در بالا تصمیم گرفتیم)، سرعت یکسان خواهد بود. این همچنین برای اهداف متحرک کار می کند و به عامل اجازه می دهد تا در حین حرکت تغییرات کوچکی ایجاد کند.

اما ما تنوع بیشتری می خواهیم - برای مثال، به آرامی سرعت را برای شبیه سازی یک کاراکتر از حالت ایستاده به دویدن افزایش دهیم. همین کار را می توان در پایان قبل از توقف انجام داد. این ویژگی ها به عنوان رفتارهای فرمان شناخته می شوند که هر کدام نام های خاصی دارند: جستجو، فرار، رسیدن و غیره. ایده این است که نیروهای شتاب را می توان بر اساس مقایسه موقعیت عامل و سرعت فعلی با مقصد در سرعت عامل اعمال کرد. به منظور استفاده از روش های مختلف حرکت به سمت هدف.

هر رفتاری هدف کمی متفاوت دارد. Seek و Arrival راه هایی برای انتقال یک نماینده به مقصد هستند. جلوگیری از موانع و جداسازی حرکت عامل را تنظیم می کند تا از موانع در راه رسیدن به هدف جلوگیری کند. همسویی و انسجام عامل ها را با هم حرکت می دهند. هر تعداد از رفتارهای مختلف فرمان را می توان برای تولید یک بردار مسیر واحد با در نظر گرفتن همه عوامل جمع کرد. عاملی که از رفتارهای ورود، جدایی و اجتناب از مانع استفاده می کند تا از دیوارها و سایر عوامل دور بماند. این رویکرد در مکان های باز و بدون جزئیات غیر ضروری به خوبی کار می کند.

در شرایط سخت تر، افزودن رفتارهای مختلف بدتر عمل می کند - به عنوان مثال، یک عامل می تواند به دلیل تضاد بین ورود و اجتناب از مانع در دیوار گیر کند. بنابراین، باید گزینه‌هایی را در نظر بگیرید که پیچیده‌تر از افزودن همه مقادیر هستند. راه این است: به جای جمع کردن نتایج هر رفتار، می توانید حرکت را در جهات مختلف در نظر بگیرید و بهترین گزینه را انتخاب کنید.

با این حال، در یک محیط پیچیده با بن‌بست‌ها و انتخاب‌هایی در مورد اینکه کدام مسیر را انتخاب کنیم، به چیزی حتی پیشرفته‌تر نیاز خواهیم داشت.

یافتن راهی

رفتارهای فرمان برای حرکت ساده در یک منطقه باز (زمین فوتبال یا میدان) که در آن رسیدن از A به B یک مسیر مستقیم با انحرافات جزئی در اطراف موانع است، عالی است. برای مسیرهای پیچیده، ما به مسیریابی نیاز داریم، که راهی برای کاوش در جهان و تصمیم گیری در مورد مسیر عبور از آن است.

ساده ترین کار این است که یک شبکه برای هر مربع در کنار عامل اعمال کنید و ارزیابی کنید که کدام یک از آنها مجاز به حرکت هستند. اگر یکی از آنها مقصد است، مسیر را از هر مربع به مربع قبلی دنبال کنید تا به ابتدا برسید. این مسیر است. در غیر این صورت، این روند را با سایر مربع های مجاور تکرار کنید تا زمانی که مقصد خود را پیدا کنید یا مربع های شما تمام شود (یعنی مسیر ممکنی وجود ندارد). این همان چیزی است که به طور رسمی به عنوان جستجوی عرض اول یا BFS (الگوریتم جستجوی اول عرض) شناخته می شود. در هر قدم او به همه جهات نگاه می کند (از این رو وسعت، "عرض"). فضای جستجو مانند یک جبهه موج است که حرکت می کند تا زمانی که به مکان مورد نظر برسد - فضای جستجو در هر مرحله گسترش می یابد تا نقطه پایان گنجانده شود، پس از آن می توان آن را به ابتدا ردیابی کرد.

در نتیجه، لیستی از مربع هایی دریافت خواهید کرد که مسیر مورد نظر در طول آنها جمع آوری شده است. این مسیر است (از این رو مسیریابی) - لیستی از مکان هایی که نماینده هنگام دنبال کردن مقصد از آنها بازدید می کند.

با توجه به اینکه موقعیت هر مربع در جهان را می دانیم، می توانیم از رفتارهای فرمان برای حرکت در طول مسیر استفاده کنیم - از گره 1 به گره 2، سپس از گره 2 به گره 3 و غیره. ساده ترین گزینه این است که به سمت مرکز مربع بعدی بروید، اما یک گزینه حتی بهتر این است که در وسط لبه بین مربع فعلی و مربع بعدی توقف کنید. به همین دلیل، عامل قادر خواهد بود در پیچ های تیز گوشه ها را برش دهد.

الگوریتم BFS همچنین دارای معایبی است - به همان اندازه مربع را در جهت "نادرست" و در جهت "درست" بررسی می کند. اینجاست که الگوریتم پیچیده تری به نام A* (A star) وارد عمل می شود. به همین ترتیب کار می‌کند، اما به جای بررسی کورکورانه مربع‌های همسایه (سپس همسایگان همسایه‌ها، سپس همسایگان همسایه‌های همسایه‌ها و غیره)، گره‌ها را در یک لیست جمع‌آوری می‌کند و آنها را مرتب می‌کند تا گره بعدی که بررسی می‌شود همیشه مسیری که به کوتاه ترین مسیر منتهی می شود. گره ها بر اساس یک اکتشافی دسته بندی می شوند که دو چیز را در نظر می گیرد: "هزینه" یک مسیر فرضی به سمت میدان مورد نظر (شامل هر گونه هزینه سفر) و تخمینی از فاصله آن مربع از مقصد (سوگیری از جستجو در میدان). جهت درست).

این مثال نشان می‌دهد که عامل هر بار یک مربع را بررسی می‌کند و هر بار مربع مجاور را که امیدوارکننده‌ترین است انتخاب می‌کند. مسیر حاصل مانند BFS است، اما مربع های کمتری در این فرآیند در نظر گرفته شد - که تأثیر زیادی بر عملکرد بازی دارد.

حرکت بدون شبکه

اما بیشتر بازی‌ها روی یک شبکه قرار نمی‌گیرند، و اغلب انجام این کار بدون قربانی کردن واقع‌گرایی غیرممکن است. مصالحه لازم است. مربع ها چه اندازه ای باید داشته باشند؟ خیلی بزرگ است و نمی توانند راهروها یا پیچ های کوچک را به درستی نشان دهند، خیلی کوچک هستند و مربع های زیادی برای جستجو وجود خواهد داشت که در نهایت زمان زیادی را می طلبد.

اولین چیزی که باید درک کنیم این است که یک مش نموداری از گره های متصل را به ما می دهد. الگوریتم های A* و BFS در واقع روی نمودارها کار می کنند و اصلاً به مش ما اهمیت نمی دهند. ما می‌توانیم گره‌ها را در هر نقطه از دنیای بازی قرار دهیم: تا زمانی که بین هر دو گره متصل، و همچنین بین نقطه شروع و پایان و حداقل یکی از گره‌ها ارتباط وجود داشته باشد، الگوریتم مانند قبل کار خواهد کرد. این اغلب یک سیستم نقطه راه نامیده می شود، زیرا هر گره نشان دهنده موقعیت مهمی در جهان است که می تواند بخشی از هر تعداد مسیر فرضی باشد.

مثال 1: یک گره در هر مربع. جستجو از گره ای که عامل در آن قرار دارد شروع می شود و به گره مربع مورد نظر ختم می شود.

مثال 2: مجموعه ای کوچکتر از گره ها (نقاط راه). جستجو از مربع عامل شروع می شود، از تعداد گره های مورد نیاز عبور می کند و سپس تا مقصد ادامه می یابد.

این یک سیستم کاملا منعطف و قدرتمند است. اما در تصمیم گیری در مورد مکان و نحوه قرار دادن یک ایستگاه بین راهی کمی دقت لازم است، در غیر این صورت ممکن است ماموران به سادگی نزدیکترین نقطه را نبینند و نتوانند مسیر را شروع کنند. اگر بتوانیم به طور خودکار نقاط بین راه را بر اساس هندسه جهان قرار دهیم، آسان تر خواهد بود.

اینجاست که مش ناوبری یا navmesh (مش ناوبری) ظاهر می شود. این معمولاً یک شبکه دوبعدی از مثلث ها است که روی هندسه جهان پوشانده می شود - هر کجا که عامل اجازه راه رفتن داشته باشد. هر یک از مثلث های مش تبدیل به یک گره در نمودار می شود و تا سه مثلث مجاور دارد که به گره های مجاور گراف تبدیل می شوند.

این تصویر نمونه ای از موتور Unity است - هندسه جهان را تجزیه و تحلیل کرد و یک navmesh ایجاد کرد (در تصویر به رنگ آبی روشن). هر چند ضلعی در navmesh ناحیه ای است که یک عامل می تواند در آن بایستد یا از یک چند ضلعی به چند ضلعی دیگر حرکت کند. در این مثال، چند ضلعی ها کوچکتر از طبقاتی هستند که در آن قرار دارند - این به منظور در نظر گرفتن اندازه عامل انجام می شود که فراتر از موقعیت اسمی آن گسترش می یابد.

می‌توانیم با استفاده از الگوریتم A* مسیری را از طریق این مش جستجو کنیم. این به ما یک مسیر تقریباً عالی در جهان می دهد که تمام هندسه را در نظر می گیرد و نیازی به گره های غیر ضروری و ایجاد ایستگاه های بین راه ندارد.

مسیریابی موضوعی بسیار گسترده است که یک بخش از مقاله برای آن کافی نیست. اگر می خواهید آن را با جزئیات بیشتری مطالعه کنید، این کمک خواهد کرد وب سایت آمیت پاتل.

برنامه ریزی

ما با مسیریابی یاد گرفته‌ایم که گاهی اوقات فقط انتخاب یک جهت و حرکت کافی نیست - ما باید مسیری را انتخاب کنیم و چند پیچ ​​انجام دهیم تا به مقصد مورد نظر خود برسیم. ما می‌توانیم این ایده را تعمیم دهیم: دستیابی به یک هدف فقط مرحله بعدی نیست، بلکه یک توالی کامل است که در آن گاهی اوقات لازم است چندین مرحله را به جلو نگاه کنید تا بفهمید اولین مرحله چیست. به این می گویند برنامه ریزی. مسیریابی را می توان به عنوان یکی از چندین پسوند برنامه ریزی در نظر گرفت. از نظر چرخه Sense/Think/Act ما، اینجا جایی است که بخش Think چندین بخش Act را برای آینده برنامه ریزی می کند.

بیایید به مثال بازی رومیزی Magic: The Gathering نگاه کنیم. ابتدا با مجموعه کارت های زیر در دست می رویم:

• Swamp - 1 مانا سیاه (کارت زمین) می دهد.
• جنگل - 1 مانا سبز (کارت زمین) می دهد.
• جادوگر فراری - برای احضار به 1 مانا آبی نیاز دارد.
• Elvish Mystic - برای احضار به 1 مانا سبز نیاز دارد.

ما سه کارت باقیمانده را نادیده می گیریم تا کار را آسان تر کنیم. طبق قوانین، بازیکن مجاز است در هر نوبت 1 کارت زمین بازی کند، می تواند روی این کارت ضربه بزند تا مانا را از آن استخراج کند و سپس با توجه به مقدار مانا، طلسم هایی (از جمله احضار یک موجود) انجام دهد. در این شرایط، بازیکن انسان می‌داند که Forest را بازی کند، روی ۱ مانای سبز ضربه بزنید و سپس Elvish Mystic را احضار کنید. اما هوش مصنوعی بازی چگونه می تواند این را بفهمد؟

برنامه ریزی آسان

رویکرد بی اهمیت این است که هر عمل را به نوبه خود امتحان کنید تا زمانی که هیچ اقدام مناسبی باقی نماند. با نگاه کردن به کارت‌ها، هوش مصنوعی متوجه می‌شود که Swamp چه چیزی می‌تواند بازی کند. و او آن را بازی می کند. آیا اقدامات دیگری از این نوبت باقی مانده است؟ نمی تواند Elvish Mystic یا Fugitive Wizard را احضار کند، زیرا آنها به ترتیب به مانای سبز و آبی نیاز دارند تا آنها را احضار کنند، در حالی که Swamp فقط مانا سیاه را ارائه می دهد. و او دیگر نمی تواند Forest را بازی کند، زیرا قبلاً Swamp را بازی کرده است. بنابراین، هوش مصنوعی بازی از قوانین پیروی کرد، اما آن را ضعیف انجام داد. قابل بهبود است.

برنامه ریزی می تواند لیستی از اقداماتی را پیدا کند که بازی را به حالت مطلوب می رساند. همانطور که هر مربع در یک مسیر دارای همسایگانی (در مسیریابی) بود، هر اقدامی در یک طرح نیز همسایگان یا جانشینانی دارد. تا رسیدن به حالت مطلوب می توانیم به دنبال این اعمال و اقدامات بعدی باشیم.

در مثال ما، نتیجه مطلوب «احضار یک موجود در صورت امکان» است. در ابتدای چرخش، ما فقط دو عمل ممکن را می بینیم که توسط قوانین بازی مجاز است:

1. بازی Swamp (نتیجه: Swamp در بازی)
2. بازی Forest (نتیجه: جنگل در بازی)

هر اقدامی که انجام می‌شود می‌تواند به اقدامات بعدی منجر شود و باز هم بسته به قوانین بازی، اقدامات دیگری را ببندد. تصور کنید ما Swamp بازی کردیم - این کار Swamp را به عنوان مرحله بعدی حذف می کند (ما قبلاً آن را بازی کردیم) و همچنین Forest را حذف می کند (زیرا طبق قوانین می توانید در هر نوبت یک کارت زمین بازی کنید). پس از این، هوش مصنوعی دریافت 1 مانا سیاه را به عنوان مرحله بعدی اضافه می کند زیرا هیچ گزینه دیگری وجود ندارد. اگر او پیش برود و Tap the Swamp را انتخاب کند، 1 واحد مانا سیاه دریافت می کند و نمی تواند کاری با آن انجام دهد.

1. بازی Swamp (نتیجه: Swamp در بازی)
1.1 "Tap" Swamp (نتیجه: Swamp "tapped"، +1 واحد مانا سیاه)
هیچ اقدامی در دسترس نیست - END
2. بازی Forest (نتیجه: جنگل در بازی)

لیست اقدامات کوتاه بود، به بن بست رسیدیم. ما این روند را برای مرحله بعدی تکرار می کنیم. ما Forest را بازی می کنیم، اکشن "دریافت 1 مانا سبز" را باز می کنیم، که به نوبه خود اکشن سوم را باز می کند - Elvish Mystic را احضار می کند.

1. بازی Swamp (نتیجه: Swamp در بازی)
1.1 "Tap" Swamp (نتیجه: Swamp "tapped"، +1 واحد مانا سیاه)
هیچ اقدامی در دسترس نیست - END
2. بازی Forest (نتیجه: جنگل در بازی)
2.1 "Tap" Forest (نتیجه: جنگل "تاپ" شده است، +1 واحد مانا سبز)
2.1.1 احضار الویش میستیک (نتیجه: الویش میستیک در بازی، -1 مانا سبز)
هیچ اقدامی در دسترس نیست - END

در نهایت، ما تمام اقدامات ممکن را بررسی کردیم و نقشه ای پیدا کردیم که یک موجود را احضار می کند.

این یک مثال بسیار ساده است. بهتر است به جای هر طرحی که برخی معیارها را برآورده می کند، بهترین طرح ممکن را انتخاب کنید. به طور کلی می توان برنامه های بالقوه را بر اساس نتیجه یا منافع کلی اجرای آنها ارزیابی کرد. شما می توانید برای بازی یک کارت زمین 1 امتیاز و برای احضار یک موجود 3 امتیاز کسب کنید. بازی Swamp یک طرح 1 امتیازی خواهد بود. و بازی Forest → Tap the Forest → احضار Elvish Mystic بلافاصله 4 امتیاز می دهد.

برنامه ریزی در Magic: The Gathering اینگونه عمل می کند، اما همین منطق در موقعیت های دیگر نیز صدق می کند. به عنوان مثال، حرکت دادن یک پیاده برای ایجاد فضا برای اسقف برای حرکت در شطرنج. یا پشت دیواری بپوشید تا با خیال راحت در XCOM مانند این عکس بگیرید. به طور کلی، شما ایده را دریافت می کنید.

برنامه ریزی بهبود یافته

گاهی اوقات اقدامات بالقوه زیادی برای بررسی هر گزینه ممکن وجود دارد. بازگشت به مثال با Magic: The Gathering: بیایید بگوییم که در بازی و در دست شما چندین کارت زمین و موجود وجود دارد - تعداد ترکیب های ممکن حرکت می تواند ده ها باشد. چندین راه حل برای مشکل وجود دارد.

روش اول زنجیر زدن به عقب است. به جای امتحان همه ترکیب ها، بهتر است از نتیجه نهایی شروع کنید و سعی کنید یک مسیر مستقیم پیدا کنید. به جای رفتن از ریشه درخت به یک برگ خاص، در جهت مخالف حرکت می کنیم - از برگ به ریشه. این روش آسانتر و سریعتر است.

اگر دشمن 1 سلامتی داشته باشد، می توانید طرح "مواجهه با 1 یا بیشتر آسیب" را پیدا کنید. برای رسیدن به این هدف، یکسری شرایط باید رعایت شود:

1. آسیب می تواند توسط یک طلسم ایجاد شود - باید در دست باشد.
2. برای طلسم کردن، به مانا نیاز دارید.
3. برای به دست آوردن مانا، باید یک کارت زمین بازی کنید.
4. برای بازی کارت زمین، باید آن را در دست داشته باشید.

راه دیگر، جستجوی اول بهترین است. به جای اینکه همه راه ها را امتحان کنیم، مناسب ترین راه را انتخاب می کنیم. اغلب، این روش بدون هزینه های جستجوی غیر ضروری، طرح بهینه را ارائه می دهد. A* شکلی از بهترین جستجوی اول است - با بررسی امیدوارکننده ترین مسیرها از ابتدا، می تواند بهترین مسیر را بدون بررسی گزینه های دیگر پیدا کند.

یکی از بهترین گزینه های جستجوی جالب و به طور فزاینده ای محبوب، جستجوی درخت مونت کارلو است. الگوریتم به جای حدس زدن اینکه کدام برنامه‌ها در هنگام انتخاب هر اقدام بعدی بهتر از سایرین هستند، در هر مرحله جانشین‌های تصادفی را انتخاب می‌کند تا زمانی که به پایان برسد (زمانی که طرح منجر به پیروزی یا شکست شود). سپس از نتیجه نهایی برای افزایش یا کاهش وزن گزینه های قبلی استفاده می شود. با تکرار این فرآیند چندین بار پشت سر هم، الگوریتم تخمین خوبی از بهترین حرکت بعدی می دهد، حتی اگر وضعیت تغییر کند (اگر دشمن اقدامی برای تداخل با بازیکن انجام دهد).

هیچ داستانی در مورد برنامه ریزی در بازی ها بدون برنامه ریزی اقدام هدفمند یا GOAP (برنامه ریزی اقدام هدف گرا) کامل نخواهد بود. این روشی است که به طور گسترده مورد استفاده و بحث قرار گرفته است، اما به غیر از چند جزئیات متمایز، اساساً روش زنجیره‌ای به عقب است که قبلاً در مورد آن صحبت کردیم. اگر هدف "از بین بردن بازیکن" بود و بازیکن پشت سر است، نقشه می تواند این باشد: نابود کردن با نارنجک → بدست آوردن → پرتاب آن.

معمولاً چندین هدف وجود دارد که هر کدام اولویت خاص خود را دارند. اگر هدف بالاترین اولویت را نتوان تکمیل کرد (هیچ ترکیبی از اقدامات باعث ایجاد طرح "کشتن بازیکن" نمی شود زیرا بازیکن قابل مشاهده نیست)، هوش مصنوعی به اهداف با اولویت پایین تر بازمی گردد.

آموزش و سازگاری

قبلاً گفتیم که هوش مصنوعی بازی معمولاً از یادگیری ماشینی استفاده نمی کند زیرا برای مدیریت عوامل در زمان واقعی مناسب نیست. اما این بدان معنا نیست که شما نمی توانید چیزی از این منطقه قرض بگیرید. ما حریفی در تیرانداز می خواهیم که بتوانیم از او چیزی یاد بگیریم. به عنوان مثال، از بهترین موقعیت ها در نقشه مطلع شوید. یا حریفی در یک بازی مبارزه ای که حرکات ترکیبی پرکاربرد بازیکن را مسدود می کند و او را تشویق می کند تا از دیگران استفاده کند. بنابراین یادگیری ماشینی می تواند در چنین شرایطی کاملاً مفید باشد.

آمار و احتمالات

قبل از اینکه به مثال های پیچیده بپردازیم، بیایید ببینیم با انجام چند اندازه گیری ساده و استفاده از آنها برای تصمیم گیری تا کجا می توانیم پیش برویم. به عنوان مثال، استراتژی زمان واقعی - چگونه تعیین کنیم که آیا یک بازیکن می تواند در چند دقیقه اول بازی حمله کند و چه دفاعی در برابر آن آماده شود؟ ما می‌توانیم تجربیات گذشته یک بازیکن را مطالعه کنیم تا بفهمیم واکنش‌های آینده ممکن است چه باشد. برای شروع، ما چنین داده های خامی نداریم، اما می توانیم آن ها را جمع آوری کنیم - هر بار که هوش مصنوعی علیه یک انسان بازی می کند، می تواند زمان اولین حمله را ثبت کند. پس از چند جلسه، میانگین زمان حمله بازیکن در آینده را به دست خواهیم آورد.

همچنین یک مشکل با مقادیر متوسط ​​وجود دارد: اگر بازیکنی 20 بار عجله کرد و 20 بار آهسته بازی کرد، مقادیر مورد نیاز جایی در وسط خواهند بود و این هیچ چیز مفیدی به ما نمی دهد. یک راه حل محدود کردن داده های ورودی است - می توان 20 قطعه آخر را در نظر گرفت.

رویکرد مشابهی برای تخمین احتمال برخی اقدامات با این فرض که ترجیحات گذشته بازیکن در آینده یکسان خواهد بود استفاده می شود. اگر بازیکنی پنج بار با گلوله آتشین، دو بار با رعد و برق و یک بار با غوغا به ما حمله کند، بدیهی است که توپ آتشین را ترجیح می دهد. بیایید برون یابی کنیم و احتمال استفاده از سلاح های مختلف را ببینیم: فایربال=62,5%، رعد و برق=25% و غوغا=12,5%. هوش مصنوعی بازی ما باید برای محافظت از خود در برابر آتش آماده شود.

روش جالب دیگر استفاده از طبقه‌بندی کننده Naive Bayes برای مطالعه مقادیر زیادی از داده‌های ورودی و طبقه‌بندی وضعیت است تا هوش مصنوعی به روش مورد نظر واکنش نشان دهد. طبقه بندی کننده های بیزی بیشتر به دلیل استفاده در فیلترهای اسپم ایمیل شناخته شده اند. در آنجا آنها کلمات را بررسی می کنند، آنها را با جایی که قبلاً آن کلمات ظاهر شده است (در هرزنامه یا نه) مقایسه می کنند و در مورد ایمیل های دریافتی نتیجه گیری می کنند. حتی با ورودی های کمتر می توانیم همین کار را انجام دهیم. بر اساس تمام اطلاعات مفیدی که هوش مصنوعی می بیند (مانند واحدهای دشمن ایجاد شده، یا از چه جادوهایی استفاده می کنند، یا در مورد چه فناوری هایی تحقیق کرده اند)، و نتیجه نهایی (جنگ یا صلح، عجله یا دفاع و غیره) - ما رفتار هوش مصنوعی مورد نظر را انتخاب خواهیم کرد.

همه این روش های آموزشی کافی هستند، اما توصیه می شود از آنها بر اساس داده های آزمایش استفاده کنید. هوش مصنوعی یاد می گیرد که با استراتژی های مختلفی که بازیکنان آزمایش کننده شما استفاده کرده اند سازگار شود. هوش مصنوعی که پس از انتشار با بازیکن سازگار می شود، ممکن است بسیار قابل پیش بینی یا شکست دادن آن بسیار دشوار باشد.

سازگاری مبتنی بر ارزش

با توجه به محتوای دنیای بازی ما و قوانین، می‌توانیم مجموعه مقادیری را که بر تصمیم‌گیری تأثیر می‌گذارند، به جای استفاده از داده‌های ورودی تغییر دهیم. ما این کار را انجام می دهیم:

• به هوش مصنوعی اجازه دهید اطلاعاتی در مورد وضعیت جهان و رویدادهای کلیدی در طول بازی جمع آوری کند (مانند بالا).
• بیایید چند مقدار مهم را بر اساس این داده ها تغییر دهیم.
• ما تصمیمات خود را بر اساس پردازش یا ارزیابی این ارزش ها اجرا می کنیم.

به عنوان مثال، یک نماینده چندین اتاق برای انتخاب در نقشه تیراندازی اول شخص دارد. هر اتاق ارزش خاص خود را دارد که میزان مطلوبیت بازدید را تعیین می کند. هوش مصنوعی بر اساس مقدار به طور تصادفی انتخاب می کند که به کدام اتاق برود. سپس مامور به یاد می آورد که در کدام اتاق کشته شده است و از ارزش آن می کاهد (احتمال بازگشت او به آنجا). به طور مشابه برای وضعیت معکوس - اگر عامل بسیاری از مخالفان را از بین ببرد، ارزش اتاق افزایش می یابد.

مدل مارکوف

اگر از داده های جمع آوری شده برای پیش بینی استفاده کنیم چه؟ اگر هر اتاقی را که بازیکنی را در آن می بینیم برای مدت معینی به خاطر بیاوریم، پیش بینی می کنیم که بازیکن ممکن است به کدام اتاق برود. با ردیابی و ضبط حرکات بازیکن در اتاق ها (مقادیر)، می توانیم آنها را پیش بینی کنیم.

بیایید سه اتاق را انتخاب کنیم: قرمز، سبز و آبی. و همچنین مشاهداتی که هنگام تماشای جلسه بازی ثبت کردیم:

تعداد مشاهدات در هر اتاق تقریباً برابر است - ما هنوز نمی دانیم کجا مکان مناسبی برای کمین بسازیم. جمع‌آوری آمار نیز با بازپرداخت بازیکنانی که به طور مساوی در سراسر نقشه ظاهر می‌شوند، پیچیده است. اما داده‌های مربوط به اتاق بعدی که پس از ظاهر شدن روی نقشه وارد می‌شوند، از قبل مفید هستند.

می توان دید که اتاق سبز برای بازیکنان مناسب است - بیشتر افراد از اتاق قرمز به آن جا می روند که 50٪ از آنها بیشتر در آنجا باقی می مانند. اتاق آبی، برعکس، محبوب نیست؛ تقریباً هیچ کس به آن نمی رود، و اگر هم برود، مدت زیادی نمی ماند.

اما داده ها چیز مهم تری را به ما می گوید - وقتی بازیکنی در اتاق آبی است، اتاق بعدی که او را در آن می بینیم قرمز خواهد بود نه سبز. حتی اگر اتاق سبز از اتاق قرمز محبوب تر است، اگر بازیکن در اتاق آبی باشد وضعیت تغییر می کند. حالت بعدی (یعنی اتاقی که بازیکن به آن خواهد رفت) به حالت قبلی (یعنی اتاقی که بازیکن در حال حاضر در آن است) بستگی دارد. از آنجایی که ما وابستگی‌ها را بررسی می‌کنیم، پیش‌بینی‌های دقیق‌تری نسبت به زمانی که مشاهدات را مستقل بشماریم، انجام خواهیم داد.

پیش‌بینی وضعیت آینده بر اساس داده‌های یک حالت گذشته، مدل مارکوف نامیده می‌شود و چنین نمونه‌هایی (با اتاق‌ها) زنجیره مارکوف نامیده می‌شوند. از آنجایی که الگوها احتمال تغییرات بین حالت‌های متوالی را نشان می‌دهند، به صورت بصری به‌عنوان FSM با احتمالی در اطراف هر انتقال نمایش داده می‌شوند. قبلاً از FSM برای نشان دادن حالت رفتاری که یک عامل در آن قرار داشت استفاده می کردیم، اما این مفهوم به هر حالتی تسری می یابد، خواه با عامل مرتبط باشد یا نباشد. در این مورد، حالت ها اتاقی را که عامل اشغال می کند نشان می دهد:

این یک راه ساده برای نمایش احتمال نسبی تغییرات حالت است که به هوش مصنوعی توانایی پیش بینی وضعیت بعدی را می دهد. می توانید چندین مرحله را پیش بینی کنید.

اگر بازیکنی در اتاق سبز باشد، 50 درصد احتمال دارد که دفعه بعد که مشاهده شود در آنجا بماند. اما چه شانسی وجود دارد که او حتی پس از آن همچنان آنجا باشد؟ نه تنها این احتمال وجود دارد که بازیکن پس از دو مشاهده در اتاق سبز باقی بماند، بلکه احتمال رفتن و بازگشت او نیز وجود دارد. در اینجا جدول جدید با در نظر گرفتن داده های جدید آمده است:

این نشان می دهد که شانس دیدن بازیکن در اتاق سبز پس از دو مشاهده برابر با 51٪ - 21٪ خواهد بود که او از اتاق قرمز خواهد بود، 5٪ از آنها که بازیکن از اتاق آبی بین آنها بازدید می کند و 25% که بازیکن نمی خواهد اتاق سبز را ترک کند.

جدول به سادگی یک ابزار بصری است - این روش فقط به ضرب احتمالات در هر مرحله نیاز دارد. این بدان معنی است که شما می توانید با یک نکته به آینده دور نگاه کنید: ما فرض می کنیم که شانس ورود به یک اتاق کاملاً به اتاق فعلی بستگی دارد. این ویژگی مارکوف نامیده می شود - وضعیت آینده فقط به زمان حال بستگی دارد. اما این صد در صد دقیق نیست. بازیکنان می توانند تصمیمات خود را بسته به عوامل دیگر تغییر دهند: سطح سلامتی یا مقدار مهمات. از آنجایی که ما این مقادیر را ثبت نمی کنیم، پیش بینی های ما دقت کمتری خواهد داشت.

N-گرم

در مورد مثال یک بازی مبارزه ای و پیش بینی حرکات ترکیبی بازیکن چطور؟ همان! اما به جای یک حالت یا رویداد، کل دنباله هایی که یک ضربه ترکیبی را تشکیل می دهند را بررسی می کنیم.

یکی از راه های انجام این کار این است که هر ورودی (مانند Kick، Punch یا Block) را در یک بافر ذخیره کنید و کل بافر را به عنوان یک رویداد بنویسید. بنابراین بازیکن بارها و بارها Kick، Kick، Punch را فشار می دهد تا از حمله SuperDeathFist استفاده کند، سیستم هوش مصنوعی تمام ورودی ها را در یک بافر ذخیره می کند و سه ورودی آخر استفاده شده در هر مرحله را به خاطر می آورد.

(خطوط پررنگ زمانی است که بازیکن حمله SuperDeathFist را انجام می دهد.)

هوش مصنوعی زمانی که بازیکن Kick را انتخاب می کند و سپس Kick دیگری را انتخاب می کند، همه گزینه ها را می بیند و سپس متوجه می شود که ورودی بعدی همیشه Punch است. این به عامل اجازه می دهد تا حرکت ترکیبی SuperDeathFist را پیش بینی کند و در صورت امکان آن را مسدود کند.

این توالی رویدادها N-gram نامیده می شوند که N تعداد عناصر ذخیره شده است. در مثال قبلی 3 گرم (تریگرام) بود، به این معنی که: دو ورودی اول برای پیش بینی سوم استفاده می شود. بر این اساس، در یک 5 گرمی، چهار ورودی اول پنجمی را پیش‌بینی می‌کنند و به همین ترتیب.

طراح باید اندازه N گرم را با دقت انتخاب کند. یک N کوچکتر به حافظه کمتری نیاز دارد اما تاریخچه کمتری را نیز ذخیره می کند. به عنوان مثال، یک 2 گرمی (بیگرام) Kick، Kick یا Kick، Punch را ضبط می کند، اما نمی تواند Kick، Kick، Punch را ذخیره کند، بنابراین هوش مصنوعی به ترکیب SuperDeathFist پاسخ نمی دهد.

از سوی دیگر، اعداد بزرگتر به حافظه بیشتری نیاز دارند و آموزش هوش مصنوعی دشوارتر خواهد بود زیرا گزینه های ممکن بسیار بیشتری وجود خواهد داشت. اگر سه ورودی احتمالی Kick، Punch یا Block داشتید و ما از 10 گرم استفاده می کردیم، حدود 60 هزار گزینه مختلف می شد.

مدل بیگرام یک زنجیره مارکوف ساده است - هر جفت حالت گذشته/حالت فعلی یک بیگرام است و شما می توانید حالت دوم را بر اساس حالت اول پیش بینی کنید. N-گرم های 3 گرمی و بزرگتر را می توان به عنوان زنجیره های مارکوف نیز در نظر گرفت، جایی که همه عناصر (به جز آخرین عنصر در N-گرم) با هم حالت اول و آخرین عنصر حالت دوم را تشکیل می دهند. مثال بازی مبارزه شانس انتقال از حالت Kick and Kick به حالت Kick and Punch را نشان می دهد. با در نظر گرفتن چندین ورودی تاریخچه ورودی به عنوان یک واحد واحد، اساساً دنباله ورودی را به بخشی از کل حالت تبدیل می کنیم. این ویژگی مارکوف را به ما می دهد که به ما امکان می دهد از زنجیره های مارکوف برای پیش بینی ورودی بعدی و حدس زدن حرکت ترکیبی بعدی استفاده کنیم.

نتیجه

در مورد رایج ترین ابزارها و رویکردها در توسعه هوش مصنوعی صحبت کردیم. ما همچنین موقعیت هایی را که در آنها باید مورد استفاده قرار گیرند و در کجا مفید هستند بررسی کردیم.

این باید برای درک اصول اولیه هوش مصنوعی بازی کافی باشد. اما، البته، اینها همه روش ها نیستند. کمتر محبوب، اما نه کمتر موثر عبارتند از:

• الگوریتم های بهینه سازی شامل تپه نوردی، شیب فرود و الگوریتم های ژنتیک
• الگوریتم‌های جستجو/زمان‌بندی متخاصم (هرس حداقل و آلفا بتا)
• روش های طبقه بندی (پرسپترون ها، شبکه های عصبی و ماشین های بردار پشتیبان)
• سیستم هایی برای پردازش ادراک و حافظه عوامل
• رویکردهای معماری به هوش مصنوعی (سیستم های ترکیبی، معماری های زیرمجموعه و سایر روش های همپوشانی سیستم های هوش مصنوعی)
• ابزارهای انیمیشن (برنامه ریزی و هماهنگی حرکت)
• عوامل عملکرد (سطح جزئیات، هر زمان و الگوریتم های زمان بندی)

منابع اینترنتی با موضوع:

1. GameDev.net دارد بخش با مقالات و آموزش های هوش مصنوعیو فروم.
2. AiGameDev.com شامل ارائه ها و مقالات بسیاری در مورد طیف گسترده ای از موضوعات مرتبط با توسعه هوش مصنوعی بازی است.
3. خرک GDC شامل موضوعاتی از اجلاس GDC AI Summit است که بسیاری از آنها به صورت رایگان در دسترس هستند.
4. مطالب مفیدی نیز در وب سایت یافت می شود انجمن برنامه نویسان بازی هوش مصنوعی.
5. تامی تامپسون، محقق و سازنده بازی های هوش مصنوعی، در یوتیوب ویدیو می سازد هوش مصنوعی و بازی ها با توضیح و بررسی هوش مصنوعی در بازی های تجاری.

کتاب هایی با موضوع:

1. سری کتاب Game AI Pro مجموعه ای از مقالات کوتاه است که نحوه پیاده سازی ویژگی های خاص یا نحوه حل مشکلات خاص را توضیح می دهد.

بازی AI Pro: جمع آوری حکمت متخصصان هوش مصنوعی بازی
بازی AI Pro 2: جمع آوری خرد حرفه ای های هوش مصنوعی بازی
بازی AI Pro 3: جمع آوری خرد حرفه ای های هوش مصنوعی بازی

2. سری AI Game Programming Wisdom سلف سری Game AI Pro است. این شامل روش های قدیمی تر است، اما تقریباً همه آنها حتی امروز نیز مرتبط هستند.

برنامه نویسی بازی هوش مصنوعی Wisdom 1
برنامه نویسی بازی هوش مصنوعی Wisdom 2
برنامه نویسی بازی هوش مصنوعی Wisdom 3
برنامه نویسی بازی هوش مصنوعی Wisdom 4

3. هوش مصنوعی: رویکردی مدرن یکی از متون اساسی برای همه کسانی است که می خواهند حوزه کلی هوش مصنوعی را درک کنند. این کتاب در مورد توسعه بازی نیست - اصول اولیه هوش مصنوعی را آموزش می دهد.

منبع: www.habr.com