گفت‌وگو با هیون‌سونگ کیم، سرپرست بخش تحقیق و یوجئونگ سون، مدیر پروژه در شرکت KRAFTON

در این مقاله می‌خوانیم:

نمایش بیشتر نمایش کمتر

شخصیت‌های غیرقابل‌بازی یا NPCها در بازی‌های ویدیویی معمولاً به مجموعه‌ای از دیالوگ‌های از پیش تعیین‌شده و رفتارهای محدود وابسته هستند. این شخصیت‌ها می‌توانند به بازیکن واکنش نشان دهند، اما در اغلب موارد توانایی درک شرایط متغیر بازی یا همکاری واقعی با او را ندارند. شرکت KRAFTON با معرفی PUBG Ally تلاش کرده است این محدودیت را پشت سر بگذارد و مفهوم تازه‌ای از همراهان هوشمند را وارد دنیای بازی‌های ویدیویی کند.

این شخصیت هوش مصنوعی که برای بازی PUBG: BATTLEGROUNDS توسعه یافته، از فناوری NVIDIA ACE و مجموعه‌ای از مدل‌های هوش مصنوعی بهینه‌شده استفاده می‌کند. PUBG Ally با کمک فناوری تشخیص خودکار گفتار (ASR)، یک مدل زبانی کوچک (SLM) با 2 میلیارد پارامتر و سیستم تبدیل متن به گفتار (TTS)، می‌تواند صحبت‌های بازیکن را درک کند، شرایط مسابقه را تحلیل کند و در لحظه به دستورات و اتفاقات داخل بازی واکنش نشان دهد.

KRAFTON برای توصیف این فناوری از اصطلاح شخصیت قابل‌بازی مشترک (Co-Playable Character یا CPC) استفاده می‌کند؛ مفهومی که قرار است تفاوت اساسی با NPCهای سنتی داشته باشد. Ally تنها یک شخصیت با رفتارهای از پیش برنامه‌ریزی‌شده نیست، بلکه می‌تواند با بازیکن همکاری کند، خود را با شرایط مسابقه تطبیق دهد و حتی اطلاعاتی از تجربه‌های قبلی او را به خاطر بسپارد.

نسخه آزمایشی عمومی این قابلیت از 17 ژوئن در دسترس قرار گرفت و بازیکنان می‌توانستند تا 30 ژوئن آن را در حالت Arcade بازی PUBG: BATTLEGROUNDS تجربه کنند. در ادامه، نگاهی به گفت‌وگوی تیم توسعه KRAFTON درباره معماری فنی، نحوه آموزش، حافظه و آینده این هم‌تیمی هوشمند خواهیم داشت.

هم‌تیمی‌های هوشمند در pubg

تفاوت شخصیت قابل‌بازی مشترک (CPC) با NPCهای سنتی چیست و چرا PUBG را برای توسعه این فناوری انتخاب کردید؟

هدف ما با استفاده از فناوری NVIDIA ACE این بود که شخصیتی بسازیم که بتواند از طریق مکالمه طبیعی، منظور بازیکن را درک کند، شرایط بازی را تشخیص دهد و در لحظه به اتفاقات مسابقه واکنش نشان دهد. ما این مفهوم را شخصیت قابل‌بازی مشترک یا CPC نام‌گذاری کردیم؛ شخصیتی که قرار نیست صرفاً به دستورات مشخصی پاسخ دهد، بلکه باید بتواند در کنار بازیکن بازی کند، با شرایط مختلف سازگار شود و به‌عنوان عضوی از تیم حضور داشته باشد.

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

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

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

معماری فنی PUBG Ally چگونه طراحی شده و اجزای مختلف آن در جریان مسابقه چه وظیفه‌ای دارند؟

در سطح کلی، معماری PUBG Ally دو ورودی اصلی دارد: صدای بازیکن و وضعیت زنده بازی. این اطلاعات پس از پردازش به دو خروجی تبدیل می‌شوند؛ صحبت‌های Ally و اقداماتی که این شخصیت در محیط بازی انجام می‌دهد.

برای اجرای این فرایند، NVIDIA ACE و مدل‌های اختصاصی KRAFTON به‌صورت محلی روی دستگاه بازیکن اجرا می‌شوند. این مجموعه شامل سیستم تشخیص خودکار گفتار NVIDIA (ASR)، مدل زبانی کوچک NVIDIA (SLM) و یک مدل اختصاصی تبدیل متن به گفتار (TTS) است. در کنار این اجزا، لایه مدیریت عامل هوش مصنوعی (Agent Harness) و سیستم یکپارچه‌سازی با موتور بازی نیز قرار دارند.

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

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

خروجی صوتی به سیستم TTS فرستاده می‌شود تا به صدای شخصیت Ally تبدیل شود. در مقابل، دستورات مربوط به عملکرد داخل بازی به بخش اجرایی منتقل می‌شوند؛ جایی که یک درخت رفتاری (Behavior Tree) وظیفه اجرای آن‌ها و مدیریت واکنش‌های سریع را بر عهده دارد. این تفکیک اهمیت زیادی دارد، زیرا برخی اقدامات داخل بازی نباید برای تکمیل فرایند استدلال زبانی منتظر بمانند.

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

چرا به‌جای یک مدل زبانی بزرگ (LLM) از مدل زبانی کوچک استفاده کردید؟

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

استفاده محلی از مدل Mistral-NeMo-Minitron-2B که از طریق NVIDIA ACE در دسترس قرار گرفته، نیاز به ارسال اطلاعات به سرور و دریافت پاسخ از آن را حذف کرد. این موضوع علاوه بر کاهش تاخیر، زمان پاسخ‌گویی قابل‌پیش‌بینی‌تری را در جریان مسابقه فراهم کرد. نتایج آزمایش با کاربران نیز نشان داد که بازیکنان به سرعت واکنش و حس حضور Ally اهمیت زیادی می‌دهند. در چنین شرایطی، در دسترس بودن فوری یک هم‌تیمی هوشمند می‌تواند از توانایی انجام استدلال‌های عمومی و پیچیده‌تر اهمیت بیشتری داشته باشد.

اجرای مدل روی دستگاه البته محدودیت‌های سخت‌افزاری مشخصی هم دارد. PUBG یک بازی گرافیکی سنگین است و بخش قابل‌توجهی از حافظه گرافیکی (VRAM) را به خود اختصاص می‌دهد؛ بنابراین، فضای باقی‌مانده برای اجرای یک همراه هوش مصنوعی محدود است.

مدل Mistral-NeMo-Minitron-2B با داشتن 2 میلیارد پارامتر، نقطه شروع مناسبی بود؛ زیرا در کنار ابعاد نسبتاً کوچک، توانایی خوبی در پیروی از دستورالعمل‌ها داشت. تیم توسعه برای اجرای بهتر آن روی سیستم بازیکنان، مدل را با استفاده از فرایند کوانتیزاسیون (Quantization) بهینه کرد. نسخه فشرده‌شده می‌تواند از فضای باقی‌مانده حافظه گرافیکی پس از اجرای PUBG استفاده کند و به همین دلیل، PUBG Ally روی کارت‌های گرافیکی با حداقل 8 گیگابایت حافظه VRAM نیز قابل اجرا است.

در یک بازی بتل رویال، تاخیر اهمیت زیادی دارد. چگونه زمان بین دریافت صدای بازیکن و پاسخ صوتی Ally را کاهش دادید؟

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

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

در سطح معماری نیز نمی‌خواستیم تمام واکنش‌های داخل بازی به پردازش مدل زبانی وابسته باشند. برای حل این مسئله از ساختاری مشابه مفهوم سیستم 1 و سیستم 2 (System 1 / System 2) در تصمیم‌گیری انسان استفاده کردیم؛ ساختاری که در آن واکنش‌های سریع و غریزی از فرایندهای کندتر و تحلیلی جدا می‌شوند.

لایه سیستم 1 که با استفاده از درخت رفتاری (Behavior Tree) پیاده‌سازی شده، مسئولیت واکنش‌های سریع داخل بازی را بر عهده دارد. حرکت، نشانه‌گیری و پاسخ‌های فوری در جریان مبارزه از جمله وظایف این بخش هستند که با نرخ به‌روزرسانی موتور بازی (Game Tick Rate) اجرا می‌شوند.

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

بخش قابل‌توجهی از تلاش مهندسی تیم صرف تعیین مرز میان این دو لایه شد؛ یعنی مشخص کردن اینکه کدام واکنش‌ها باید بلافاصله توسط سیستم 1 اجرا شوند و کدام تصمیم‌ها به مدل زبانی سیستم 2 نیاز دارند. رسیدن به این تفکیک، برای ایجاد تعادل میان سرعت واکنش در مبارزه و انعطاف‌پذیری یک هم‌تیمی هوشمند ضروری بود.

چگونه PUBG Ally را با اصطلاحات، نقشه‌ها، تجهیزات و ویژگی‌های اختصاصی PUBG آشنا کردید؟

ما برای این کار از دو مرحله استفاده کردیم. در قدم اول، به‌جای اینکه از مدل بخواهیم تمام سناریوهای احتمالی PUBG را مدیریت کند، محدوده فعالیت آن را مشخص کردیم. Ally در ابتدا تنها به یک نقشه، یعنی Sanhok، و یک حالت بازی به نام AI Duo محدود شد. همچنین، مجموعه مشخصی از تجهیزات و آیتم‌ها برای آن تعریف کردیم تا معلوم باشد این شخصیت چه وسایلی را می‌تواند استفاده کند، کدام تجهیزات را صرفاً تشخیص می‌دهد و چه آیتم‌هایی اساساً در محدوده فعالیت آن قرار ندارند.

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

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

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

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

این ابزارهای مشاهده شامل اطلاعات مربوط به وضعیت خود Ally، شرایط هم‌تیمی، تجهیزات اطراف و موقعیت‌های درگیری هستند. هر ابزار، بخشی از داده‌های معتبر موتور بازی را در قالب متن ساده در اختیار مدل قرار می‌دهد. برای مثال، سیستم می‌تواند اطلاعاتی مانند «سلاح M416 با 24 گلوله از 30 گلوله در خشاب، 78 درصد سلامتی و حضور در محدوده امن» را به مدل منتقل کند.

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

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

پشتیبانی PUBG Ally از زبان‌های مختلف چه چالش‌هایی ایجاد کرد؟

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

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

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

حافظه بلندمدت چه قابلیت‌هایی به PUBG Ally اضافه می‌کند و این سیستم چگونه پیاده‌سازی شده است؟

حافظه Ally ساختار مشخصی دارد و در دو بازه زمانی متفاوت عمل می‌کند. بخش اول، حافظه بلندمدت (Long-Term Memory) است که اطلاعات را میان مسابقات مختلف حفظ می‌کند. این بخش شامل مشخصات بازیکن مانند نام، سلاح‌های موردعلاقه، مکان‌های ترجیحی برای فرود و اطلاعات شخصی‌ای است که او در جریان مکالمه با Ally به اشتراک گذاشته است.

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

در مقابل، حافظه کوتاه‌مدت (Short-Term Memory) به اتفاقات همان مسابقه اختصاص دارد. صحبت‌های اخیر بازیکن و رویدادهایی که به‌تازگی در بازی رخ داده‌اند، در این بخش نگهداری می‌شوند تا Ally بتواند شرایط فعلی را درک کند و پاسخ‌های مرتبط‌تری ارائه دهد.

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

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

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

فرایند آزمایش و بهینه‌سازی PUBG Ally چگونه انجام شد؟

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

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

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

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

نظرات بازیکنان فقط به شناسایی مشکلات محدود نبودند؛ بلکه به ما نشان دادند کاربران از چه رفتارهایی لذت می‌برند، چه ویژگی‌هایی را نمی‌پسندند و از یک هم‌تیمی هوشمند چه انتظاراتی دارند. این اطلاعات به ما کمک کرد معیارهای ارزیابی را دقیق‌تر کنیم و مراحل بعدی بهینه‌سازی را بر اساس تجربه واقعی بازیکنان پیش ببریم.

چه توصیه‌ای برای استودیوهایی دارید که قصد دارند با NVIDIA ACE اولین همراه یا هم‌تیمی هوش مصنوعی خود را بسازند؟

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

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

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

آینده شخصیت‌های قابل‌بازی مشترک (CPC) به کدام سمت می‌رود؟

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

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

آزمایش عمومی در حالت Arcade اولین فرصت واقعی ما برای بررسی این موضوع است که بازیکنان به کدام‌یک از این قابلیت‌ها علاقه نشان می‌دهند. قصد داریم از همین تجربه برای تعیین مسیر توسعه‌های بعدی استفاده کنیم.

شروع کار با NVIDIA ACE

ما از همکاری با KRAFTON برای توسعه PUBG Ally و ورود مفهوم شخصیت‌های قابل‌بازی مشترک به مرحله آزمایش عمومی هیجان‌زده هستیم. توسعه‌دهندگانی که قصد دارند شخصیت‌های بازی مبتنی بر هوش مصنوعی بسازند، می‌توانند کار خود را با NVIDIA ACE آغاز کنند.

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

منبع مقاله:

NVIDIA Developer – Q&A: How KRAFTON Built PUBG Ally, a Co-Playable Character Powered by NVIDIA ACE