موتور قوانین سرورمحور در برابر توهمات مدل‌های زبانی در مدیریت بازی

تصور کنید در یک بازی نقش‌آفرینی هستید و هوش مصنوعی به شما می‌گوید در حمله شکست خوردید، اما روی صفحه نمایش صراحتاً عبارت «اصابت» (HIT) درج شده است. در دنیای Tales of Munin، ریاضیات همیشه بر متن برتری دارد و این یعنی پایان عصر «داورهای متقلب» در بازی‌های مبتنی بر AI. این بازی یک RPG رومیزی گوتیک است که مشکل «توهمات گیم‌مستر» (hallucinating GM) را با سلب تمام قدرت‌های مکانیکی از داستان‌سرای AI حل کرده است. در این سیستم، نگهبان AI (AI Keeper) نمی‌تواند به تاس‌ها، دفتر حسابات یا برگه شخصیت بازیکن دست بزند و این تضمین می‌کند که هر نتیجه‌ای به طور اثبات‌پذیری منصفانه باشد.

بسیاری از بازی‌های فعلی به مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیارد‌ها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — اجازه می‌دهند تصمیم بگیرند که آیا یک قفل باز می‌شود یا خیر. این آزادی منجر به «تقلب» یا تغییر نتایج توسط مدل برای پیشبرد روایت می‌شود. اما برایان ویلیامز (Bryan Williams) سیستمی را توصیف کرد که در آن AI صرفاً راوی حقایق ریاضی پیش‌تعیین‌شده است. این رویکرد، هوش مصنوعی را از یک خدای قادر مطلق به یک داستان‌سرای محدود تبدیل می‌کند که توسط یک موتور قوانین سخت‌گیرانه محصور شده است.

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

دیوار آتش روایت

طبق مستندات این پروژه، ویلیامز سیستمی را پیاده کرده که او آن را «دیوار آتش روایت با دندان» می‌نامد. تمام پرتاب‌های تاس d20 توسط دستور crypto.getRandomValues در داخل موتور بازی تولید می‌شوند، نه توسط LLM. هوش مصنوعی نتیجه را دریافت می‌کند و موظف است دقیقاً همان را روایت کند؛ او نه می‌تواند تاس را دوباره بریزد و نه نتایج را اختراع کند.

برای جلوگیری از دروغ‌گویی مدل، رابط کاربری یک «رسید» زیر متن روایت چاپ می‌کند. برای مثال، بازیکن متنی درباره ضربه خوردن یک نگهبان می‌خواند و هم‌زمان محاسبات خام را می‌بیند: d20(15)+might(3)+prof(1)=19 vs guard 12. این شفافیت باعث می‌شود بازیکن بداند دقیقاً چه اتفاقی افتاده و AI نتواند نتایج را برای جذاب‌تر کردن داستان تغییر دهد.

جهان به مثابه گراف مرجع

برخلاف اکثر بازی‌های AI که از متون ساده (flat text dump) برای ذخیره لور و داستان استفاده می‌کنند، Tales of Munin از یک Sanity Content Lake (با شناسه پروژه: o5bcgsw6) برای ذخیره جهان به شکل یک گراف مرجع استفاده می‌کند. این ساختار اجازه می‌دهد موتور بازی پرس‌وجوهای دقیقی را با زبان GROQ اجرا کند تا مدل مکان‌ها یا گروه‌های جعلی نسازد.

ساختار فنی این سیستم شامل یک فرانت-اند ساخته شده با Astro، یک موتور مبتنی بر Cloudflare Worker و Durable Object و پایگاه داده Sanity است. برای جلوگیری از ناهماهنگی (drift)، صفحه Astro در زمان ساخت (build time) به کلاینت موتور تبدیل می‌شود، به جای اینکه یک کپی دستی باشد. موتور بازی در آدرس munin.neoaethel.workers.dev دقیقاً همین کلاینت یکسان را ارائه می‌دهد.

طرح‌واره و ساختار داده‌ها

جهان بازی از هشت نوع سند تشکیل شده است: گروه (faction)، منطقه (region)، موجود (creature)، شخصیت غیرقابل‌بازی (npc)، مکان (location)، آیتم (item)، رویداد جهانی (worldEvent) و تاریخچه (chronicle) که دوباره در سیستم ثبت می‌شود. این‌ها به جای پیوندهای ساده، از طریق فیلدهای مرجع به هم متصل شده‌اند:

• طرح‌واره گروه: در فایل studio/schemas/faction.js تعریف شده و شامل هفت فیلد است. فیلدهای کلیدی عبارتند از want (آنچه انگیزه‌ی NPCهاست)، publicFace (آنچه به دنیا نشان می‌دهد) و crack (جایی که فساد و ضعف نمایان می‌شود). فیلد caste (طبقه) گزینه‌ها را به 'lit'، 'graven' یا 'any' محدود می‌کند.
• طرح‌واره موجود: در studio/schemas/creature.js تعریف شده و از مراجع برای متصل کردن موجودات به haunts (مناطقی که در آن گشت می‌زنند) و commandedBy (گروهی که دستورات را صادر می‌کند) استفاده می‌کند. این یعنی پرس‌وجویی مثل «چه کسی فرماندهان سگ‌های مسئول تدارکات است؟» تنها با یک گام در گراف پاسخ داده می‌شود.
• پرس‌وجوی زنده: با زدن دکمه Registry، موتور بازی یک پرس‌وجوی GROQ را اجرا می‌کند که لبه‌های این گراف را طی می‌کند. این پرس‌وجو هدفش _type in ["faction","region","creature","npc","location","item","worldEvent"] است و فیلدهایی مثل provenance (منشأ) برای آیتم‌ها یا residents (ساکنان) برای مکان‌ها را برمی‌گرداند. نسخه خلاصه این پرس‌وجو، فیلدهای _type, name, want, crack, publicFace, kind, caste را به همراه نام‌های ارجاع شده به فرماندهان، مناطق گشت‌زنی، منشأ و ساکنان استخراج می‌کند.
• حقیقت واژه‌به‌واژه: پرسش درباره «The Conservatory» یک رکورد دقیق را برمی‌گرداند: want: "the pen kept in Lit hands — gatekeeping as survival" و crack: "cannot imagine a threat wearing a wizard's authority — precisely the shape the threat takes". این فیلد crack تم اصلی را تعریف می‌کند: نقطه کور هر قدرت، دقیقاً همان شکلی است که باعث نابودی‌اش می‌شود.

جلوگیری از نشت روایت

یکی از پیچیده‌ترین بخش‌ها، سیستم «همزاد» (doppelganger) است. برخی همراهان ممکن است مخفیانه غیرانسان باشند، اما این حقیقت در سمت سرور مهر و موم شده است. احتمال همزاد بودن یک همراه منتشر شده است، اما ماهیت آن پنهان است. موتور بازی، متن تولید شده توسط AI را پیش از نمایش به بازیکن بازرسی می‌کند. اگر مدل تصادفاً حقیقتی را لو دهد (مثلاً بگوید «X هرگز انسان نبوده است»)، آن خط مسدود شده، به عنوان یک «خطای روایت» (stray) ثبت می‌شود و به بازیکن گفته می‌شود که نگهبان (Keeper) دچار لغزش شده است.

این حفاظ حتی به مجموعه داده‌ها نیز گسترش یافته است. کانون پنهان — شامل هویت همزادها، اسرار NPCها و حقیقت «سقوط» (the Fall) — در Content Lake عمومی نیست. این تضمین می‌کند که هیچ بازیکن، داور یا عامل استخراج داده‌ای (scraping agent) نتواند با پرس‌وجوی مجموعه داده، ترس و تعلیق بازی را از بین ببرد. حتی تاریخچه‌هایی که به Lake بازگردانده می‌شوند، از همان ژورنال پاک‌سازی شده‌ای ساخته می‌شوند که بازیکن می‌بیند.

فرآیند توسعه با Vibe Coding

ویلیامز کل پرده اول (Act 0–1) بازی را در کمتر از ۵ روز (حدود ۵۰ ساعت) ساخت. او از یک خط لوله چند-مدلی برای تضمین پایداری استفاده کرد:

1. Claude Code: به عنوان اپراتور اجرایی برای پیاده‌سازی کدها.
2. Codex Session: به عنوان بازبین خصمانه (adversarial reviewer) برای جستجوی باگ‌ها در سورس کد.
3. پنل مدل‌ها: گروهی متشکل از Grok، Gemini و DeepSeek برای شکستن طراحی اقتصاد بازی و موانع پیشرفت پیش از آنکه ساخته شوند.

این فرآیند منجر به ایجاد ۳۲۱۶ ادعای تست (assertion) در ۵۷ مجموعه شد. این سخت‌گیری باعث شناسایی باگ‌های بحرانی شد، از جمله:

• مسیریابی UI: دکمه‌های Arts/Market به دلیل ارسال درخواست‌های GET به یک روتر که فقط POST می‌پذیرفت، خطای 405 می‌دادند. بازبین این مورد را با تست عملی یافت، نه با خواندن کد.
• خطای قابلیت‌ها: شخصیت‌های ساخته شده در طبقه Caste می‌توانستند استعدادها را یاد بگیرند اما نمی‌توانستند از آن‌ها استفاده کنند، زیرا جستجوی قابلیت‌ها از طریق یک ID کلاس منسوخ شده routed می‌شد.
• انحراف وضعیت: اجرای سه بار جادوی «سپر نور» باعث می‌شد دفاع بازیکن به طور دائمی (+4 برای همیشه) افزایش یابد؛ اکنون دفاع به یک وضعیت زنده و مشتق شده تبدیل شده است.
• منطق پیروزی: یک تیک آسیب در زمان (damage-over-time) که آخرین دشمن را می‌کشت، باعث فعال شدن XP یا پیروزی نمی‌شد؛ اکنون یک تابع تسویه (settlement) بعد از هر فاز آسیب اجرا می‌شود.
• راوی شبح: هوش مصنوعی نتایجی (مثل دادن آیتم یا پول) را توصیف می‌کرد که موتور بازی هرگز اجرا نکرده بود. راهکار این بود که افعال اجباری مثل [[marks -16 : given to Bray]] یا [[item spear : garrison issue]] یا [[joins Lund Tanner : agreed on the road]] معرفی شوند. اکنون موتور بازی بر این پیشنهادها حکم می‌دهد و اگر بازیکن پول کافی نداشته باشد، آن‌ها را رد می‌کند. مثلاً اگر AI بخواهد ۲۰ مارک به گدایی بدهد در حالی که کیف بازیکن خالی است، AI مجبور است بگوید: «مارک‌ها تمام شده‌اند. همه‌شان در پیراهن Tansy هستند... گدایی وجود ندارد.»
• شناسه‌های عملیات (Operation IDs): برای جلوگیری از اینکه یک پاسخ گم‌شده یا تلاش مجدد (retry) باعث جابجایی دوبره پول شود، هر اقدام قصد شده اکنون یک Operation ID دارد تا اولین حکم تکرار شود.
• شکاف‌های تست: یک شکست بحرانی رخ داد که در آن ۳۲ تست واحد (unit test) سبز بودند اما سیستم روایت زنده در دسترس نبود. همچنین ۲۱۷ ادعای موتور سبز بودند در حالی که یک باگ تک‌خطی CSS سایت را غیرقابل بازی می‌کرد. تیم اکنون کل صفحه را تست می‌کند، نه فقط موتور را.

مکانیک‌های گیم‌پلی و ساختار

بازیکنان بین دو طبقه انتخاب می‌کنند: Graven (طبقه کارگر، که بدون دلیل اعزام شده‌اند) یا Lit (طبقه تحصیل‌کرده، که همیشه دلیلی برای وجودشان هست). کلاس‌های سنتی وجود ندارد و بازیکن با ویژگی‌های پایه و دو امتیاز شروع می‌کند.

اولین امتیاز، «هنر» (art) بازیکن را تعریف می‌کند که بدن او را تغییر داده و ابزارهای خاصی می‌بخشد. این در UI منعکس می‌شود؛ صرف یک امتیاز، نوار وضعیت را از «انتخاب نشده» (unchosen) به «ماهر» (adept) در آن هنر تغییر می‌دهد.

قوس داستانی پرده اول

پرده اول یک روایت کامل است و نه یک دموی ساده. این پرده یک سفر ساختاریافته را دنبال می‌کند:

• سه روز اول: بازیکن با یک زندگی گذشته تولید شده شروع می‌کند — خانواده‌ای با نام خانوادگی یکسان، یک عشق، یک رقیب و یک یادگاری. اگر Lit باشند، دلیل خاص نوشته شده برای وجودشان به آن‌ها داده می‌شود. آن‌ها سه روز عادی زندگی می‌کنند تا حکم اعزام برسد. بازی یک سوال با پیامدهای مکانیکی می‌پرسد: «قبل از اینکه خط (the Line) تو را ببرد، به دیدن چه کسی می‌روی؟»
• سفر: مسیری به سمت Fort Verdance که از سه بخش نام‌گذاری شده می‌گذرد که خطر و لحن آن‌ها افزایش می‌یابد: Amber Mile (باز و طلایی، عمدتاً مناظر)، The Deepening (جایی که جنگل بسته می‌شود و اولین مبارزات واقعی رخ می‌دهد) و The Hush (سکوتی غیرطبیعی که در آن تهدیدات چهره انسان دارند اما چیزی آن‌ها را کنترل می‌کند). زمین در هر بار اجرا متفاوت تاس می‌خورد و اجساد، اکتشافات و تهدیدات را تغییر می‌دهد.
• قلعه: صعودی در سیاه‌چال برای شکست دادن Necrophage، اهریمنی نقاب‌دار از سایه و پوسیدگی. بازیکنان می‌توانند با شکستن زنجیرهای روح‌های زندانی، آن‌ها را نجات دهند و سربازان هذیان‌گو را با صدا کردن نامشان آرام کنند؛ هر روحی که نجات یابد، مکانیکی باعث تضعیف رئیس نهایی می‌شود. پس از سقوط Necrophage، قلعه پاکسازی شده، «برخاستن» (the Rising) رخ می‌دهد و قلعه به یک مرکز زنده برای سفر تبدیل می‌شود.

تداوم و حافظه

این چرخه دوطرفه است؛ Content Lake تمام بازی‌های انجام شده را به یاد می‌آورد. پس از هر اتفاق مهم، Worker تاریخچه میز بازی را به عنوان یک سند ذخیره می‌کند، اما این کار خارج از مسیر اصلی (hot path) انجام می‌شود تا نوبت‌های بازی منتظر آن نمانند. این اسناد ثبت می‌کنند که بازیکن به چه کسی تبدیل شد، هنر او چه بود، سطحش چقدر بود و ستون فقرات داستان ژورنال چه بود.

در زمان نگارش این متن، ۱۹۴ تاریخچه در مجموعه داده‌ها وجود دارد. این باعث می‌شود شعار «جهان چیزی است که به یاد آورده شده» به یک پرس‌وجوی واقعی GROQ تبدیل شود. این حافظه مکانیکی است؛ NPCها سوابق وزنی از سکه‌ها، کمک‌ها یا ضرباتی که با بازیکن رد و بدل کرده‌اند را نگه می‌دارند و در دیدارهای بعدی بازخوانی می‌کنند. فهرست تهدیدات روبرو شده و نقشه‌های به‌دست‌آمده به عنوان حقایق شناخته شده به نگهبان (Keeper) داده می‌شود تا با پیشرفت داستان، جهان عمیق‌تر شود.

تحلیل: تغییر به سمت AI دترمینستیک (قطعی)

برای صنعت سرگرمی، Tales of Munin نشان‌دهنده تغییری از بازی‌های «مولد» (generative) به ارکستراسیون AI «دترمینستیک» است. با تبدیل LLM به یک «پوست» به جای «مغز»، ویلیامز غیرقابل‌پیش‌بینی بودن را که باعث می‌شود بازی‌های AI توخالی یا غیرمنصفانه به نظر برسند، حذف می‌کند.

این معماری ثابت می‌کند که موثرترین راه برای استفاده از LLM در یک سیستم پیچیده، سلب اختیار آن بر وضعیت (state) سیستم است. وقتی AI مجبور است خادم یک دفتر حسابات سخت‌افزاری (hard-coded ledger) باشد، تجربه حاصل بیشتر شبیه به یک RPG سنتی و کمتر شبیه به یک توهم مشترک است.

برای توسعه‌دهندگان، درس روشن است: سرعت «Vibe-coding» هوش مصنوعی تنها زمانی ایمن است که با یک مجموعه تست خصمانه همراه باشد که بتواند انحرافات منطقی ظریفی را که LLMها ناگزیر ایجاد می‌کنند، شناسایی کند. آن ۳۲۱۶ ادعای تست بود که سرعت را ایمن کرد و تضمین نمود که یک آخر هفته توسعه بتواند یک پرده کامل را در لایه داده‌ها ببندد.

اگر می‌خواهید محدودیت‌های داستان‌سرا را تست کنید، می‌توانید نسخه فعلی را در https://munin-web.neoaethel.workers.dev بازی کنید و سعی کنید AI را فریب دهید تا آیتم‌ها یا پولی را که به دست نیاورده‌اید به شما بدهد — موتور بازی به سادگی درخواست را رد خواهد کرد.

گام بعدی شما

• اگر توسعه‌دهنده بازی هستید، مدل «جداسازی لایه منطق از لایه روایت» را برای حذف توهمات مدل در پروژه‌های خود پیاده کنید.
• برای تجربه این سیستم، به آدرس https://munin-web.neoaethel.workers.dev بروید و سعی کنید هوش مصنوعی را برای دریافت آیتم‌های رایگان فریب دهید تا قدرت موتور سرور را ببینید.
• بررسی کنید که چگونه استفاده از گراف‌های دانش (Knowledge Graphs) به جای متون ساده، دقت روایت‌های AI را افزایش می‌دهد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.