درون The Space Project؛ معماریِ بازارهای مستقل در محیط‌های مجازی

تصور کنید در یک دنیای دیجیتال، صدها کشتی فضایی بدون هیچ دستورالعمل پیش‌فرض، تجارت می‌کنند، معدن می‌کاوند و در صورت اشتباه در محاسبات، ورشکسته می‌شوند. در ۲۱ ژوئیه ۲۰۲۶، توسعه‌دهنده‌ای به نام کال‌کد (Kalcode) یا دیوید کلاوزن (David Clausen)، پروژه The Space Project را به‌صورت متن‌باز منتشر کرد؛ شبیه‌سازی متمرکز بر عامل (Agent) — شبیه به موجوداتی دیجیتال که هدف دارند و به‌طور مستقل تصمیم می‌گیرند — که با زبان رست (Rust) و موتور بوی (Bevy) توسعه یافته است.

بیشتر شبیه‌سازهای فضایی از اقتصادهای «ساختگی» با قیمت‌های ثابت یا رویدادهای اسکریپت‌شده برای پیشبرد گیم‌پلی استفاده می‌کنند. طبق اعلام توسعه‌دهنده، The Space Project این رویکرد را رد کرده و جهانی ساخته است که در آن عرضه و تقاضا واقعاً قیمت کالاها را تعیین می‌کند. این پروژه در واقع یک اثبات مفهوم فنی است تا نشان دهد زبان‌های برنامه‌نویسی با کارایی بالا چگونه می‌توانند شبیه‌سازی‌های عظیم عامل‌محور (Agentic) را مدیریت کنند. در اینجا هیچ خط داستانی اسکریپت‌شده یا هدف مشخصی برای بازیکن تعریف نشده است؛ کاربر صرفاً یک ناظر یا مدیر با دسترسی کامل (God-mode admin) است که اجرای خودکار یک اقتصاد را تماشا می‌کند.

موتور و معماری

این شبیه‌سازی بر پایه پشته‌ای تخصصی برای مقیاس‌های بسیار بالا طراحی شده است. بر اساس مستندات پروژه در گیت‌هاب، منطق اصلی در کتابخانه sim_core قرار دارد؛ یک کتابخانه خالص، همزمان (Synchronous) و بدون وابستگی به ورودی/خروجی (IO-free) در زبان Rust. این ساختار اجازه می‌دهد شبیه‌سازی بدون سربارهای async یا وابستگی‌های زمان اجرا، با سرعت بالا پیش برود.

برای رندرینگ، کال‌کد هسته اصلی را به‌عنوان یک کتابخانه درون کلاینت Bevy جاسازی کرد. این معماری تضمین می‌کند که شبیه‌سازی و رندرر هر دو از یک سیستم موجودیت-مؤلفه (ECS) مشترک استفاده کنند و نیازی به انتقال داده‌های سنگین (Data Marshalling) بین موتور و بخش بصری نباشد. همان‌طور که در تحلیل‌های پیشین ما درباره بهینه‌سازی موتورهای بازی اشاره کردیم، حذف مرزهای ارتباطی بین منطق و نمایش، کلید دستیابی به نرخ فریم‌های بالا در محیط‌های پیچیده است. پیش از این، یک کلاینت گودو (Godot) برای بررسی تطبیق (Parity Reference) استفاده می‌شد، اما چرخش به سمت Bevy باعث حذف کامل مرزهای سوکتی شد.

جزئیات سیستم‌های پیچیده

این پروژه حس «دنیای زنده» را از طریق چندین سازوکار درهم‌تنیده ایجاد می‌کند:

• هوش مصنوعی کشتی‌ها (GOAP): هر کشتی از یک برنامه‌ریز پیشرو (Forward Planner) برای رتبه‌بندی اهداف بر اساس وضعیت انتزاعی جهان استفاده می‌کند. اهدافی مانند تجارت، تحویل کالا، سوخت‌گیری، بازسازی تجهیزات (Retrofitting)، استراحت یا اکتشاف در این لیست هستند. سپس یک درخت رفتاری برای اجرای ارزان‌ترین مسیر می‌سازد. کشتی‌ها پویا هستند و اگر در میان پرواز گزینه بهتری پیدا کنند، برنامه خود را مجدداً طراحی می‌کنند.
• اقتصاد و بازارها: هر ایستگاه یک دفتر سفارش (Order-book) برای ۱۳ کالای مختلف دارد. قیمت‌ها بر اساس مدل پوشش (Coverage Model) و با اعمال ضرایب «فوریتِ کمبود» (Shortage-urgency multipliers) محاسبه می‌شوند. کشتی‌ها برای کسب سود، عرضه واقعی کالاها را بین این بازارها جابه‌جا می‌کنند.
• چرخه حیات قراردادها: ۶ نوع قرارداد مختلف وجود دارد: تحویلی (Delivery)، پیک (Courier)، مسافر (Passenger)، سوبسید (Subsidy)، تامین (Supply) و ماموریت خدمه (CrewMission). این قراردادها یک چرخه کامل از «منتشر شده» $ o$ «پذیرفته شده» $ o$ «پرداخت شده» را طی می‌کنند. این سیستم دارای محدودیت‌های مبتنی بر اعتبار (Reputation Gating)، تمدید خودکار و پرداخت‌هایی است که با گذشت زمان و قدیمی شدن قرارداد، افزایش می‌یابند.
• مدیریت تأسیسات: مراکز تولیدی دستورهای تولید (Recipes) را برای ذوب، تصفیه، تولید صنعتی، کشاورزی و معدن اجرا می‌کنند. این مراکز استاتیک نیستند؛ در طول زمان فرسوده می‌شوند، با استفاده از ابزارها خودشان را تعمیر می‌کنند و سطح آن‌ها از ۱ تا ۱۰ ارتقا می‌یابد. اگر مرکزی به‌طور مزمن ورشکسته شود، متروکه می‌شود.
• پویایی جمعیت: جمعیت‌ها غذا و سوخت مصرف کرده و نیروی کار تولید می‌کنند. در شرایط استرس، آن‌ها قراردادهای غذایی و مسافری منتشر می‌کنند. اگر رضایتمندی (Sentiment) سقوط کند، جمعیت‌ها به‌طور فیزیکی به سیستم‌های شادتر مهاجرت می‌کنند.
• شبیه‌سازی خدمه: خدمه دارای معیارهای تجمیعی گرسنگی، خستگی و روحیه هستند. آن‌ها وظایفی مانند هدایت کشتی (Piloting)، مهندسی و تجارت را انجام می‌دهند. این سیستم شامل پیشرفت مهارت، پرداخت دستمزد و یک «گارد محافظ سقوط روحیه» برای جلوگیری از مارپیچ مرگبار روحی است.
• منطق ساخت‌وساز: وقتی کمبودهای مزمن شناسایی شود، سایت‌های ساخت‌وساز ایجاد می‌شوند. این سایت‌ها محموله‌های تحویلی را از مقدار ۰ تا ۱.۰ جمع‌آوری می‌کنند تا در نهایت به یک تأسیسات دائمی تبدیل شوند.

هوش عامل‌های خودگردان

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

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

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

مدل اقتصادی زنده

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

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

عملکرد و مقیاس

در زمان انتشار ژوئیه ۲۰۲۶، این شبیه‌سازی حدود ۴۸۵ عامل فعال را مدیریت می‌کند؛ شامل ۲۸۲ کشتی، ۹۳ تأسیسات، ۲۷ جمعیت، ۸ جناح و ۶۰ جرم آسمانی. موتور در حال حاضر با تاخیر p50 بین ۱۰ تا ۲۰ میلی‌ثانیه تیک می‌زند که بسیار کمتر از بودجه ۱۲۵ میلی‌ثانیه‌ای آن است. برای حفظ این عملکرد، پروژه از Spatial LOD استفاده می‌کند؛ به این معنا که کشتی‌های دورتر، با نرخ‌های مقیاس‌بندی شده تغییر وضعیت می‌کنند و کمتر به‌روزرسانی می‌شوند.

کال‌کد اشاره کرد که این پروژه ابتدا یک پروتوتایپ با Elixir/Phoenix بود. اما زمان‌بندی BEAM در کامپیوترهای گیمینگ ویندوز مشکل داشت و همین باعث بازنویسی کامل آن با Rust شد. معماری فعلی به‌گونه‌ای طراحی شده تا تعداد عامل‌ها را به ۱۰۰,۰۰۰ واحد برساند.

پایداری و حالت بدون رابط (Headless)

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

همچنین یک حالت Headless از طریق axum و tokio وجود دارد که یک سرور HTTP/WebSocket را از طریق کریت کتابخانه sim_server فعال می‌کند. این قابلیت اجازه می‌دهد تست‌های CI و تعاملات اسکریپتی بدون نیاز به اجرای کلاینت سه‌بعدی انجام شود.

پشته فنی و ساختار داخلی

پروژه در قالب ۵ کریت (Crate) در یک محیط Cargo سازمان‌یافته است:

• sim_core: منطق خالص با استفاده از hecs ECS. این بخش قطعی (Deterministic) است و از یک بافر دستور (SimCommand) برای جلوگیری از تداخل‌های نوشتاری در میان مراحل اجرا استفاده می‌کند.
• sim_db: مدیریت پایداری SQLite و مهاجرت‌های داده (Migrations).
• sim_server: فراهم‌کننده بستر HTTP/WebSocket.
• sim_protocol: تعریف انواع داده‌های ارتباطی (Wire Types) برای استفاده در حالت Headless و CI.
• client_bevy: باینری اصلی با استفاده از Bevy 0.18، پنل‌های egui برای بازرس (Inspector) و ذرات GPU با bevy_hanabi.

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

با حذف مرز بین شبیه‌سازی و رندرر، The Space Project ثابت کرد که شبیه‌سازی‌های عامل‌محور با دقت بالا می‌توانند روی سخت‌افزارهای معمولی بدون لگ‌های معمول مدل‌های اقتصادی پیچیده اجرا شوند. این چرخش، درهای جدیدی را برای خلق «دنیاهای زنده» در توسعه بازی‌های مستقل می‌گشاید.

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

گام بعدی شما

• اگر توسعه‌دهنده هستید، مخزن گیت‌هاب پروژه را فورک کنید و فایل CONTRIBUTING.md را برای یافتن مسیرهای توسعه موتور مطالعه کنید.
• معماری ECS در Bevy را بررسی کنید تا