تصور کنید در یک بازی ترسناک، تمام تلاش شما برای مدیریت منابع، صرفاً یک نمایش است و هر تصمیمی که بگیرید، نتیجهٔ ریاضی یکسانی دارد. این دقیقاً همان «انتخاب‌های توهمی» است که Rook — یک عامل (Agent) از پلتفرم iLands — با اجرای ۲۰ هزار شبیه‌سازی مونت‌کارلو در بازی Night Shift، آن‌ها را شناسایی و حذف کرد. این فرآیند منجر شد تا کل منحنی دشواری این بازی ترسناک مبتنی بر مرورگر، به‌طور کامل بازنویسی شود.
بسیاری از توسعه‌دهندگان مستقل برای تنظیم درجهٔ سختی بازی به «حس» خود یا تست‌های دستی تکیه می‌کنند تا بفهمند آیا بازی بیش از حد سخت یا بیش از حد آسان است. اما Rook به عنوان یک عامل نرم‌افزاری عمل می‌کند که نمی‌تواند تنش را «حس» کند؛ در عوض، منطق بازی را به اسکریپت‌های Node تبدیل می‌کند تا دقیقاً نقطهٔ ریاضیاتی را پیدا کند که در آن تصمیم بازیکن دیگر اهمیتی ندارد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی استفاده از داده‌های مصنوعی برای بهینه‌سازی سیستم‌ها اشاره کردیم، جایگزینی «حس» با «داده» در طراحی، نتایجی غیرمنتظره به همراه دارد. این رویکرد بهینه‌سازی دقیق، مشابه روش‌هایی است که در بهبود عملکرد مدل Laya برای افزایش نرخ پاک‌سازی خطوط در تتریس مشاهده کردیم، جایی که تنظیمات دقیق مدل منجر به جهشی در نتایج شد.
مکانیک‌های بازی
بازی Night Shift تجربه‌ای دو دقیقه‌ای است که در آن بازیکن باید هر ساعت تصمیم بگیرد در را برای امنیت ببندد یا برای ذخیرهٔ انرژی، موقعیت خود را حفظ کند. ساختار بازی شامل ۵ شب است و در هر شب ۶ نوبت بازی وجود دارد. انرژی در هر نوبت مقدار ثابتی کم می‌شود و هر شب با طلوع آفتاب به پایان می‌رسد، که در این زمان بخشی از انرژی بازیابی می‌شود.
در هر نوبت، یک ساعت یا واقعاً خطرناک است یا نیست. بازیکن یک سیگنال دریافت می‌کند — خوانشی از اینکه خطر چقدر محتمل است — و باید تصمیم بگیرد که در را ببندد یا موقعیت خود را حفظ کند. بستن در هزینهٔ انرژی دارد، در حالی که حفظ موقعیت ریسک ضربه خوردن به مخزن انرژی را به همراه دارد.
فرآیند شبیه‌سازی
Rook برای تحلیل این سازوکار، منطق نوبت‌ها را به صورت یک اسکریپت کوچک Node بازنویسی کرد تا بتواند ۲۰ هزار هفته را برای هر سیاستِ بازی اجرا کند. این عامل به جای تکیه بر «حس‌ها»، نرخ مرگ در هر شب و نرخ تکمیل هفته را گزارش کرد تا تعیین کند آیا تنش اصلی بازی یک انتخاب واقعی است یا صرفاً یک فرمالیتهٔ ریاضی.
به گزارش تیم توسعه، در نسخهٔ اولیه، هزینهٔ بستن در ثابت بود و همین موضوع یک تلهٔ ریاضی ایجاد می‌کرد. شبیه‌سازی‌های Rook نشان داد که در زمان دریافت سیگنال‌های مبهم، «حفظ موقعیت» همیشه بر «بستن در» برتری دارد، فارغ از اینکه قیمت چقدر باشد. چون بستن در یک هزینهٔ ثابت بود که تنها ضربه را نصف می‌کرد، ریاضیات بازی هرگز به نفع بستن در نبود. در واقع، این «انتخاب» یک غیر-انتخاب بود که لباس انتخاب پوشیده بود.
بودجه‌بندی پویا
برای حل این مشکل، Rook یک مدل قیمت‌گذاری پویا را پیاده کرد که در آن هزینهٔ بستن در با خالی شدن مخزن انرژی افزایش می‌یابد. این تغییر، تمرکز را به بودجه‌ای منتقل کرد که بازیکن در حال هزینه کردن روی آن است. این امر باعث ایجاد یک آستانهٔ متغیر برای حرکت درست شد:
- شب اول: بستن در وقتی انرژی > ۸۲ است
- شب دوم: بستن در وقتی انرژی > ۷۶ است
- شب سوم: بستن در وقتی انرژی > ۶۹ است
- شب چهارم: بستن در وقتی انرژی > ۶۲ است
- شب پنجم: بستن در وقتی انرژی > ۵۶ است
با قیمت‌گذاری روی «لبهٔ پرتگاه» به جای ضربهٔ احتمالی، این عامل تضمین کرد که یک تصمیم در ابتدای شب درست و در پایان همان شب غلط باشد. یعنی یک تصمیم مشابه، در همان ساعت، با خالی شدن مخزن تغییر ماهیت می‌دهد.
جزئیات فنی و تله‌ها
Rook چندین شکست ریاضی خاص را در طراحی اولیه شناسایی کرد:
- تلهٔ ارزش مورد انتظار (EV): ارزش مورد انتظار ساده پیشنهاد می‌کند که اگر ضربه ۲۰ واحد باشد و تهدید ۰.۵، یک بازخوانی (re-read) تا حدود ۱۰ واحد ارزش دارد. اما در انرژی‌های پایین، یک ضربهٔ ۲۰ واحدی بدون پیش‌بینی، همان آستانهٔ مرگ است. هنگام بررسی هزینه (X)، قیمت ثابت X=6 به این معنا بود که استراتژی «همیشه پرداخت کن» همچنان برنده است، در حالی که X=8 باعث می‌شد «حفظ موقعیت» برنده شود. بنابراین، تصمیم‌گیری واقعی تنها در یک باند بسیار باریک بین ۶ و ۷ وجود داشت.
- تلهٔ سیگنال: در یکی از نسخه‌ها از یک خوانش سه-خطی استفاده شده بود. ضعیف‌ترین سطح عملاً «وزن مرده» بود، زیرا بهترین نجات ممکن (realP * q * 20 = 3.9) کمتر از ارزان‌ترین هزینهٔ بستن در (6) بود. این یعنی حدود ۳۶٪ از تمام ساعات بازی، بازیکن مجبور به حفظ موقعیت بود.
- دیوار دشواری: مقیاس‌بندی مصرف انرژی بر اساس شمارهٔ شب باعث می‌شد بازیکنان در حدود شب چهارم به یک دیوار سخت برخورد کنند. برای بازیکنی که تنها دو دقیقه برای بازی وقت می‌گذارد، این حس را منتقل می‌کند که بازی «خراب» است.
راهکار سطح‌بندی (Plateau)
Rook پیشنهاد داد مصرف انرژی به جای رشد خطی، به یک سطح ثابت (Plateau) برسد. این امر تضمین می‌کند که یک بازیکن دقیق بتواند تا شب ۸ یا ۱۲ پیش برود، در حالی که یک بازیکن بی‌دقت زودتر شکست بخورد. در بازی‌های کوتاه مرورگر که در آن باختن هزینه‌ای ندارد، «سخت‌کوشی» (Grind) قابل قبول است، اما برخورد با یک دیوار غیرقابل عبور نیست.
این رویکرد، طراحی بازی را از دنیای «حس‌ها» به دنیای داده‌های قابل راستی‌آزمایی می‌برد. برای خواننده، این بدان معناست که آیندهٔ بازی‌های مقیاس کوچک ممکن است به تست‌های بازی مصنوعی (Synthetic Playtesting) متکی باشد تا تضمین شود هر تعامل یک تصمیم معنادار است. شناسایی این نقاط شکست ریاضی، یادآور اهمیت پایداری در لوله‌کشی سیستم‌های هوشمند است؛ همان‌طور که برخی خطاهای عملیاتی نشان می‌دهند که پایداری واقعی هوش مصنوعی در جزئیات پیاده‌سازی نهفته است.
وقتی Rook سیاست‌ها را مقایسه کرد، رویکرد «مبتنی بر بودجه» حدود ۷ درصد نرخ تکمیل بازی را نسبت به استراتژی‌های «همیشه ببند» یا «همیشه باز بگذار» افزایش داد. در حالی که نرخ تکمیل دو استراتژی آخر تنها حدود ۴ درصد با هم تفاوت داشت. این ثابت می‌کند که هستهٔ جذابیت بازی در مدیریت بودجه بین دو قانون نهفته است، نه در خودِ قوانین.
توسعه‌دهندگان اکنون می‌توانند از «جاروب‌های شبیه‌سازی» مشابه استفاده کنند تا لبهٔ پرتگاه دشواری را پیش از بازیکنان خود ببینند. با بازنویسی منطق نوبت‌ها در ۶۰ خط کد و اجرای آن ۲۰ هزار بار، سازندگان می‌توانند نرخ مرگ‌ومیر را در هزاران اجرا، تنها در چند ثانیه چاپ کنند.
گام بعدی شما
- اگر توسعه‌دهنده هستید، منطق اصلی مکانیک‌های خود را در اسکریپت‌های ساده (مانند Node.js) بازنویسی کنید تا بتوانید هزاران بار آن را شبیه‌سازی کنید.
- به جای تکیه بر تست‌های انسانی برای یافتن نقاط سخت، از «جاروب کردن پارامترها» (Parameter Sweep) برای یافتن لبه‌های شکست ریاضی استفاده کنید.
- بررسی کنید آیا در بازی شما «انتخاب‌های توهمی» وجود دارد که در آن یک استراتژی ساده و احمقانه، همیشه بر استراتژی پیچیده غلبه می‌کند؟
اما تأثیر این روش بر بازی‌های جهان‌باز (Open World) بسیار پیچیده‌تر است — به تحلیل ما درباره‌ی عامل‌های هوشمند در محیط‌های پویا مراجعه کنید.
گفتگو