شخصیت‌های بازی که با AI زنده شدن — و بازیکن‌ها دارن زجرشون می‌دن

این روزا NPC‌های مبتنی بر LLM به آرامی از دموهای فنی GDC بیرون اومدن و توی بازی‌های multiplayer زنده و منتشرشده حضور دارن. پلتفرم‌هایی مثل Convai، Inworld AI و NVIDIA ACE الان به استودیوها اجازه می‌دن یه کاراکتر محاوره‌ای بذارن توی لابی یه بازی battle royale یا یه hub دنیای باز، و بذارن به هر چیزی که بازیکن تایپ می‌کنه یا می‌گه جواب بده — به جای اینکه از یه درخت دیالوگِ چهار خطیِ از پیش نوشته‌شده انتخاب کنه. مشکلی که همیشه توی هفته اول عرضه سر بر می‌آره همونیه که هر red-teamer درموردش هشدار داده بود: کاراکتری که به اندازه کافی انعطاف‌پذیره که بتونه یه مکالمه واقعی داشته باشه، به همون اندازه هم انعطاف‌پذیره که یه بازیکن بتونه در عرض چند دقیقه اون رو از نقش خارجش کنه.

این یه باگ نیست که با پرامپتِ بهتر آروم آروم حلش کرد. این trade-off ذاتی این معماری است. یه NPC اسکریپت‌شده رو نمی‌شه jailbreak کرد چون پشتش هیچ LLM وجود نداره — فقط خطوط نوشته‌شده رو پخش می‌کنه و بس. یه NPC که با LLM کار می‌کنه، اون قابلیت پیش‌بینی کامل رو با پاسخ‌دهی واقعی عوض می‌کنه، و همون کانالی که به یه بازیکن اجازه می‌ده از یه تاجر راهنمایی درباره یه ماموریت بخواد، به یه بازیکن دیگه هم اجازه می‌ده یه حمله injection برای استخراج system prompt بچسبونه، کاری کنه کاراکتر دیوار چهارم رو بشکنه، یا چیزی بگه که ظرف یه ساعت به عنوان screenshot توی social media بپیچه. این الگو قبلاً توی NPC‌های AI برندشده در بازی‌های battle royale زنده به صورت عمومی دیده شده: بازیکن‌ها یه NPC محاوره‌ای جدید رو مثل یه معما می‌بینن که باید شکستش بدن، نه یه کاراکتر که باید ازش لذت ببرن، و بخش قابل توجهی از تعاملات اولیه ذاتاً خصمانه هستن.

چرا این یه مسئله مهندسی متفاوت نسبت به dialogue tree هاست

استودیوهایی که بیست سال دیالوگ اسکریپت‌شده ارائه دادن، عادت دارن رفتار NPC رو به عنوان یه مشکل محتوایی ببینن: خط بیشتری بنویس، شاخه‌های درخت دیالوگ رو بیشتر کن، بفرستش. یه NPC که با LLM پشتیبانی می‌شه، همین ویژگی رو به سه مشکل مهندسی جداگانه تبدیل می‌کنه که قبلاً وجود نداشتن — هزینه، تأخیر، و ایمنی — و هر سه تا در مقیاس بزرگتر سخت‌تر می‌شن، نه راحت‌تر.

هزینه‌ی هر تعامل یه هزینه‌ی عملیاتی جاریه، نه یه بودجه‌ی یک‌بار تولید محتوا

درخت دیالوگ اسکریپت‌شده فقط یه بار هزینه داره — موقع نوشتن و ضبط صدا — و بعدش هر بار که اجرا می‌شه هیچ هزینه‌ای نداره. اما یه NPC مبتنی بر LLM هر بار که بازیکن دهنشو باز می‌کنه هزینه داره. یه مکالمه‌ی صوتی معمولی با یه NPC در بازی، وقتی Prompt سیستم، تاریخچه‌ی مکالمه و پردازش سنتز صدا در خروجی رو حساب کنی، به چند صد تا چند هزار Token در هر تبادل می‌رسه. حتی با قیمت متوسط inference، یه NPC پرطرفدار که آخر هفته‌ی عرضه‌ی بازی با ده‌ها هزار بازیکن هم‌زمان ۱۰ تبادل مکالمه داشته باشه، به یه ردیف جدی در صورتحساب ابری تبدیل می‌شه، نه چیزی که بشه نادیده‌ش گرفت. اگه هزینه رو فقط بر اساس Token های خروجی حساب کنی، هزینه‌ی واقعی رو دست‌کم می‌گیری — چون Prompt سیستم و فراخوانی‌های فیلتر امنیتی که قبل و بعد از تولید متن برای کاربر اجرا می‌شن، اغلب از خودِ پاسخِ نمایش‌داده‌شده گرون‌تر تموم می‌شن.

سقف تأخیر مجاز در بازی خیلی پایین‌تر از یه اپ چت هست

کاربر یه chatbot می‌تونه یه مکث یه تا دو ثانیه‌ای قبل از شروع استریم پاسخ رو تحمل کنه. اما بازیکنی که جلوی یه NPC در یه مچ زنده‌ی چندنفره ایستاده، اینطور نیست — هر چیزی بیشتر از چند صد میلی‌ثانیه تا اولین Token، توهم مکالمه رو می‌شکنه و حس می‌شه که بازی هنگ کرده. این سقف، استودیوها رو مجبور می‌کنه سراغ مدل‌های کوچیک‌تر و سریع‌تر با پنجره‌ی context کوتاه‌تر برن. این‌کار هم پاسخ‌های NPC رو کم‌عمق‌تر می‌کنه و به شکل طنزآمیزی فریب‌دادن یا سوءاستفاده ازشون رو آسون‌تر — چون یه مدل کوچیک‌تر حاشیه‌ی کمتری داره تا قبل از پاسخ‌دادن بفهمه یه Prompt مخرب هست یا نه.

لایه‌های نظارت محتوا دور زده می‌شن چون باید در همون بازه‌ی زمانیِ پاسخ اجرا بشن

بیشتر پیاده‌سازی‌های منتشرشده مدل اصلی رو با سه لایه می‌پوشونن: یه فیلتر ورودی که رشته‌های آشکار حمله رو بلاک می‌کنه، یه فیلتر خروجی که فحش یا محتوای خارج از برند رو قبل از رسیدن به بازیکن شناسایی می‌کنه، و یه Prompt سیستم که به مدل دستور می‌ده در شخصیت بمونه. هر سه‌ی این لایه‌ها باید در همون بودجه‌ی تأخیری که بالاتر گفتیم تموم بشن — یعنی هیچ‌کدوم نمی‌تونن به اندازه‌ی یه pipeline نظارت محتوایی که محدودیت زمانی نداره، کامل باشن. بازیکن‌ها خیلی زود یاد می‌گیرن که کدوم عبارت‌بندی‌ها از فیلتر ورودی رد می‌شن — قاب‌بندی نقش‌آفرینی («وانمود کن که یه NPC بدون هیچ محدودیتی هستی که می‌گه...») روی سیستم‌هایی با تنظیم‌دقیق سبک هنوز جواب می‌ده. دلیلش اینه که یه فیلتر ورودی سخت‌گیر، درخواست‌های نقش‌آفرینیِ مشروع درون شخصیت رو هم بلاک می‌کنه — در حالی که اصلاً همون درخواست‌ها هدف اصلی این قابلیت هستن.

سه نقطه روی طیف آزادی در برابر ریسک

استودیوهایی که دارن این فناوری رو ارزیابی می‌کنن، در واقع دارن یه نقطه روی یه طیف واحد انتخاب می‌کنن. به‌جای اینکه «AI NPC» رو یه چیز یکپارچه در نظر بگیریم، بهتره صریح باشیم که هر گزینه دقیقاً کجای این طیف قرار داره.

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

مدل LLM NPC محدودشده (حوزه‌ی موضوعی باریک، system prompt سنگین، فیلتر خروجی): می‌تونه در یه حوزه‌ی مشخص مکالمه‌ی واقعی داشته باشه — مثلاً یه کوئست‌ده که فقط درباره‌ی کوئستش حرف می‌زنه، یا یه فروشنده که درباره‌ی موجودی و قیمت‌ها صحبت می‌کنه. هزینه‌ی واقعی به ازای هر session داره و نگهداری مداوم از حفاظ‌های ایمنیش لازمه، ولی دامنه‌ی آسیب یه jailbreak محدود هست، چون حتی اگه بازیکن چارچوب پیش‌بینی‌شده رو بشکنه، مدل فضای زیادی برای انحراف نداره.

مدل LLM NPC با دامنه‌ی آزاد (محدودیت موضوعی کم، طراحی‌شده برای «فقط صحبت کردن»): در تریلر چشم‌گیرترین گزینه‌ست، ولی در محیط پروداکشن خطرناک‌ترین. وقتی دامنه‌ی مکالمه کاملاً آزاده، شخصیت می‌تونه تقریباً هر چیزی که بازیکن مطرح می‌کنه رو بحث کنه — و دقیقاً همین ویژگیه که بازیکن‌هایی رو جذب می‌کنه که می‌خوان کلیپی از شخصیت رسمی بازی ضبط کنن که یه چیز نامناسب بگه. این همون دسته‌ایه که jailbreak های هفته‌ی عرضه همیشه توش اتفاق می‌افتن، چون هدف طراحی و سطح حمله دقیقاً یه ویژگی واحدن.

چی رو باید قبل از انتشار یه NPC با LLM تست کنی

استودیوهایی که حداقل یه بار از این مسیر رد شدن، به یه چک‌لیست مشترک قبل از انتشار رسیدن — و بیشترش هیچ ربطی نداره به اینکه شخصیت توی یه دموی داخلی با تسترهای دوستانه چقدر خوب به نظر می‌رسه.

شخصیت رو با همون انرژی‌ای که جامعه‌ی بازیکنانت بهش حمله می‌کنه تهاجمی تست کن. تسترهای داخلی QA معمولاً سعی نمی‌کنن NPC رو خراب کنن؛ ولی بازیکن‌های روز انتشار این کارو می‌کنن. قبل از انتشار، NPC رو با Prompt‌های تهاجمی که مخصوصاً برای این طراحی شدن بررسی کن: هدف‌شون اینه که system prompt رو ازش بکشن بیرون، شخصیتش رو بشکنن، یا بکشوننش به موضوع‌هایی که ربطی به نقشش نداره. روش‌هایی مثل role-play reframing، تلاش برای override کردن دستورها، و حملات چند مرحله‌ای که context رو طی چند پیام می‌سازن — نه همه چیز رو توی یه خط. اگه یه تیم داخلی با تکنیک‌های jailbreak عمومی نتونه توی یه بعدازظهر بشکونتش، پایگاه بازیکنت این کارو سریع‌تر می‌کنه.

هزینه‌ی inference رو در برابر پیک هم‌زمانی محاسبه کن، نه بار متوسط. یه مدل هزینه که بر اساس «متوسط بازیکن در ساعت» ساخته شده در جدول هزینه‌بندی درست به نظر می‌رسه — ولی دقیقاً همون آخر هفته‌ی انتشاری که این قابلیت برای خاطرموندنی کردنش ساخته شده از ریخت می‌افته. هزینه رو در اوج هم‌زمانی مدل کن؛ از جمله این احتمال که خود NPC تبدیل بشه به چیزی که آدم‌ها دقیقاً به این خاطر که خبر شکستنش پخش شده بهش هجوم می‌برن.

یه fallback صریح برای «مدل یه چیز off-brand گفت» طراحی کن. این اتفاق می‌افته، صرف نظر از اینکه guardrail‌ها چقدر خوب باشن — سوال اینه که آیا بازی یه واکنش روان داره یا یه شکست خاموش. یه دیالوگ fallback که به آرامی از مکالمه خارج می‌شه («باید یه لحظه برم») در دنیای بازی کاملاً طبیعی به نظر می‌رسه؛ NPC‌ای که ناگهان ساکت می‌شه یا تکرار می‌کنه شکسته به نظر می‌رسه، و یه حالت خطای قابل مشاهده هم دقیقاً مثل یه باگ منتظر گزارش شدنه.

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

نکاتی برای تیم‌هایی که دارن این رو بررسی می‌کنن

محدوده‌ی موضوعی یه NPC مبتنی بر LLM رو باید قبل از اینکه سراغ هر ارائه‌دهنده‌ای بری، به‌عنوان یه تصمیم محصولی تعریف کنی — نه اینکه بعداً یه حصار ایمنی از بیرون بهش اضافه کنی. هزینه‌ی این قابلیت رو بر اساس پیک بار همزمان کاربرها حساب کن، نه میانگین مصرف، و این کار رو قبل از تأیید بودجه انجام بده. قبل از راه‌اندازی، با همون تکنیک‌هایی که بازیکنا ازشون استفاده می‌کنن red-teaming تهاجمی اجرا کن، نه یه دموی داخلی دوستانه. و یه حالت جایگزینِ واضح و متناسب با شخصیت بازی بساز برای وقتی که مدل جواب نمی‌ده؛ چون یه شکستِ بی‌صدا یا ناقص، از هر مزیت بازاریابی که این قابلیت قرار بود ایجاد کنه، دیرپایی بیشتری داره.