تصور کنید یک توسعه‌دهنده تنها، بدون نوشتن دستی تک‌تک خطوط کد، جهانی با ۱۹۰ هزار منظومه ستاره‌ای و یک میلیون سیاره خلق کند. یاروسلاو، معمار مهندسی عامل‌محور در شرکت SoftServe، این دستاورد را با استفاده از ارکستراسیون پیشرفته‌ای از عامل‌های هوش مصنوعی در پروژه GalaxyAtlas به دست آورد. این پروژه هم به عنوان یک شبیه‌ساز اکتشافات فضایی و هم به عنوان آزمایشگاهی برای مهندسی به کمک هوش مصنوعی عمل می‌کند.
این تجربه در زمانی رخ می‌دهد که بسیاری از برنامه‌نویسان با پدیده «آشغال‌های هوش مصنوعی» (AI Slop) دست‌وپنجه نرم می‌کنند؛ یعنی تمایل مدل‌های بزرگ به تولید حجم انبوهی از کد که در نهایت با سیستم اصلی سازگار نیست و در یک سیستم پایدار ادغام نمی‌شود. در حالی که پرامپت‌نویسی ساده برای ساخت نمونه‌های اولیه کافی است، اما مقیاس‌پذیری پروژه‌ای با مکانیک‌های وابسته به هم — مثل فیزیک مداری و فرود بر سیارات — معمولاً به نظارت معماری سخت‌گیرانه و کنترل نسخه‌های دستی نیاز دارد. این رویکرد بهینه‌سازی در طراحی، مشابه کاربردهای تخصصی دیگر در معماری است، جایی که ابزارهایی مانند Blueprints AI نقشه‌های ساختمانی را در چند دقیقه تولید می‌کنند تا فرآیندهای پیچیده طراحی را تسریع بخشند.
به گزارش وب‌سایت dev.to در تاریخ ۱۶ اکتبر ۲۰۲۶، یاروسلاو این مسیر را از اوایل سپتامبر ۲۰۲۶ و با استفاده از مدل GPT-6 Astra آغاز کرد. او به‌سرعت دریافت که بدون معیارهای سخت‌گیرانه، عامل‌های خودگردان می‌توانند بودجه‌های کلانی را در چرخه‌های بی‌پایان و بی‌حاصلِ «بهبود» بسوزانند. در یک آزمایش خاص روی شبیه‌سازی خودگردان، تکرار مداوم چرخه تولید، تست و اصلاح باعث شد محدودیت‌های اعتباری او به‌سرعت تمام شود. او یک درس دردناک آموخت: بدون معیارهای بسیار شفاف، یک عامل می‌تواند بودجه‌ای قابل توجه را صرف بهبودهای بی‌پایان کند.
برای حل این مشکل، او از رویکرد تک‌چت فاصله گرفت و به سراغ یک معماری ماژولار «مهارت‌محور» رفت. او ابتدا از GPT Sites برای اعتبارسنجی سریع ایده‌ها استفاده کرد تا نیاز به تنظیم دستی فرآیند انتشار نباشد. این مرحله اجازه داد تا اطلسی مبتنی بر مرورگر با داده‌های بیش از ۱۰۹ هزار ستاره واقعی از کاتالوگ HYG و یک مدل تولیدی (Procedural) از کهکشان ساخته شود. این نمونه‌سازی سریع ثابت کرد که مفهوم پروژه می‌تواند به بخش‌های پرواز، سطوح سیارات، بیوم‌های مختلف و مکانیک‌های کامل گیم‌پلی گسترش یابد.
معماری یک کهکشان مجازی
پروژه GalaxyAtlas یک میلیون مدل سه‌بعدی را روی سرور ذخیره نمی‌کند؛ زیرا ذخیره‌سازی، انتقال و رندر کردن چنین حجم عظیمی از اطلاعات به‌طور همزمان به‌شدت گران است. در عوض، این سیستم بر تولید رویه‌ای (Procedural Generation) تکیه دارد، جایی که ویژگی‌های سیاره‌ای در لحظه و بر اساس پارامترها و قوانین بازسازی می‌شوند. این روش باعث می‌شود تجربه کاربری در مرورگر وب و بدون نیاز به کلاینت بازی اختصاصی، سبک باقی بماند.
برای واقع‌گرایانه کردن شبیه‌سازی، پروژه در ابتدا از HYG Database v4.1 استفاده کرد که شامل داده‌های ۱۰۹,۴۰۱ ستاره واقعی بود. این امر اجازه داد تا اشیاء از یک کاتالوگ ستاره‌ای واقعی با مختصات و ویژگی‌های خاص خودشان نمایش داده شوند. با این حال، چون راه شیری واقعی صدها میلیارد ستاره دارد، یک کاتالوگ تنها برای ایجاد یک کهکشان متقاعدکننده از نظر بصری کافی نبود.
برای پر کردن این شکاف‌ها، یاروسلاو یک مدل ریاضی برای ساختار کهکشانی پیاده کرد:
- شعاع دیسک: تقریباً ۱۵.۳ کیلوبارسِک.
- زاویه گام بازوهای مارپیچی: ۱۳ درجه.
- جهت‌گیری میله مرکزی: ۲۷ درجه.
او برای نمایش چرخش، از مدلی ساده‌شده استفاده کرد که در آن سرعت به فاصله از مرکز بستگی دارد. این یک شبیه‌سازی کامل N-body نیست که تعاملات گرانشی میان صدها هزار جرم را محاسبه کند، بلکه یک مدل رویه‌ای کنترل‌شده از نظر ریاضی است تا از محاسبات سنگین فیزیکی اجتناب شود.
مکانیک‌های گیم‌پلی و اکتشاف
با وجود مقیاس عظیم، تجربه برای تعامل عمیق طراحی شده است. پروژه دارای یک انتقال بدون درز (Seamless) از نقشه کهکشانی به سطح سیاره است. کاربران می‌توانند یک ستاره را انتخاب کنند، وارد منظومه سیاره‌ای آن شوند، یک سفینه فضایی را هدایت کنند و روی یک جهان فرود آیند.
پس از فرود، شبیه‌سازی یک محیط دقیق را تولید می‌کند که شامل موارد زیر است:
- گیاهان و موجودات: فلور و فونای تولیدشده رویه‌ای که بسته به هر جهان متفاوت است.
- پدیده‌های جوی: اثرات اتمسفری پویا که بر تجربه بصری تأثیر می‌گذارند.
- سفارشی‌سازی: توانایی کاربران برای افزودن، ویرایش و شخصی‌سازی سیارات.
- مأموریت اصلی: یک چرخه گیم‌پلی مرکزی متمرکز بر جست‌وجوی یک اثر باستانی.
جزئیات رندرینگ و عملکرد
برای حفظ کارایی، سیستم از «تولید تنبل» (Lazy Generation) و سطوح جزئیات (LOD) استفاده می‌کند. موتور گرافیکی تنها زمانی زمین‌های با چندضلعی بالا و اثرات جوی را رندر می‌کند که کاربر واقعاً روی سیاره فرود بیاید. این کار مانع از کرش کردن GPU تحت فشار صدها هزار شیء فعال می‌شود. یاروسلاو اشاره کرد که اگر صدها هزار ستاره روی صفحه باشند، نمی‌توان با هر کدام به عنوان یک شیء بازی مستقل با جزئیات در حال محاسبه برخورد کرد.
اصول معماری رندرینگ در این پروژه عبارتند از:
- تولید تنبل: تولید محتوا فقط در لحظه نیاز.
- LOD: استفاده از مقیاس‌های مختلف جزئیات بسته به فاصله کاربر از شیء.
- بازاستفاده از منابع: اشتراک‌گذاری هندسه، متریال‌ها و بافت‌ها در سراسر صحنه.
- کنترل اشیاء: مدیریت سخت‌گیرانه تعداد اشیاء و افکت‌های فعال.
- مدیریت حافظه: آزادسازی فوری منابع هنگام جابه‌جایی بین صحنه‌ها.
او همچنین روی مه و ذرات، بافت‌های سطحی و نورپردازی آزمایش کرد. هر بهبود بصری نه تنها بر اساس کیفیت تصویر، بلکه بر اساس هزینه رندرینگ ارزیابی شد تا اطمینان حاصل شود که پروژه روی کامپیوترهای معمولی به‌طور روان اجرا می‌شود.
مهندسی با عامل‌های هوش مصنوعی
دستاورد اصلی GalaxyAtlas نه خودِ بازی، بلکه فرآیند توسعه آن است. یاروسلاو از پرامپت‌های غول‌پیکر فاصله گرفت و پروژه را به پنج حوزه مهندسی مجزا تقسیم کرد:
۱. کهکشان و تولید رویه‌ای: کار با کاتالوگ ستاره‌ها، ساختار فضایی و تولید منظومه‌ها، سیارات، بیوم‌ها و سایر محتواهای رویه‌ای.
۲. رندرینگ سه‌بعدی و عملکرد: بهینه‌سازی Three.js، شیدرها، متریال‌ها، نورپردازی، بهینه‌سازی هندسه و مدیریت حافظه.
۳. گیم‌پلی و تعامل با جهان: مدیریت پرواز فضایی، فرود، اکتشاف سیاره‌ای، تعامل با اشیاء و سناریوهای گیم‌پلی.
۴. محتوا و سفارشی‌سازی: خلق داستان‌های سیارات، پیکربندی بیوم‌ها، موجودات منحصر‌به‌فرد و صحنه‌های تماتیک.
۵. تست و کیفیت: بررسی رگرسیون‌ها، پایداری تولید، رفتار صحنه و معیارهای پذیرش عملکردی.
او «مهارت‌ها» (Skills) را تعریف کرد؛ دستورالعمل‌های رسمی که محدودیت‌های معماری را ثبت می‌کنند. به جای توضیح قوانین در هر جلسه جدید، این مهارت‌ها مانند یک پایگاه دانش عمل می‌کنند. برای مثال، «مهارت Three.js» شامل قوانین خاص برای پاک‌سازی منابع GPU، اشتراک‌گذاری متریال‌ها و بررسی عملکرد است تا هوش مصنوعی در هر ویژگی جدید، نشت حافظه ایجاد نکند.
به همین ترتیب، «مهارت تولید رویه‌ای» مشخص می‌کند که:
- چگونه تولید مبتنی بر بذر (Seed) پایدار بماند.
- کدام قراردادهای داده نباید بدون مهاجرت (Migration) تغییر کنند.
- چگونه بررسی شود که منطق تولید جدید با جهان‌های موجود سازگار باقی می‌ماند.
- کدام معیارهای عملکردی باید در نظر گرفته شوند.
بهینه‌سازی اقتصاد توکن
توسعه سیستم‌های پیچیده با هوش مصنوعی گران است. یاروسلاو اشاره کرد که هزینه‌برترین بخش، نه تولید کد نهایی، بلکه چرخه تکراری خواندن فایل‌ها، بازسازی زمینه (Context)، تحلیل لاگ‌ها و تلاش برای اصلاحات شکست‌خورده است.
او برای مقابله با این هزینه، مدل‌های مختلفی از جمله GPT-6 Astra، مدل‌های سریع‌تر و ارزان‌تر خانواده GPT، Claude و مدل‌های محلی مثل Qwen3 را مقایسه کرد و به این نتیجه رسید که استفاده از قدرتمندترین مدل برای هر وظیفه، ناکارآمد است. او قوانین بهینه‌سازی زیر را به کار گرفت:
- لایه‌بندی مدل‌ها: استفاده از مدل‌های ارزان برای کارهای کوچک و تعریف‌شده (مثل فرمت مستندات، آماده‌سازی قطعات کد ساده یا تغییرات پیکربندی محلی) و رزرو مدل‌های قدرتمند برای تحلیل‌های معماری پیچیده، تغییرات در چندین فایل و ارکستراسیون.
- محدود کردن زمینه: عامل‌های مربوط به مناظر، از خواندن کدهای بی‌ربط رابط کاربری (UI)، رشته‌های بومی‌سازی یا کنترل‌های سفینه منع شده‌اند تا توکن‌ها روی داده‌های بی‌ربط هدر نرود.
- تبادل آرتیفکت: عامل‌ها به جای ارسال هزاران پیام تاریخچه در یک گفتگو، تنها مشخصات کوتاه، Diffها یا اینترفیس‌ها را رد و بدل می‌کنند.
- سقف اجرا: تعیین حد نصاب اجباری برای تعداد تلاش‌های یک عامل جهت رفع باگ پیش از دخالت انسان، تا از کار کردن عامل بدون پیشرفت معنادار جلوگیری شود.
پشته فنی و اعتبارسنجی
کتابخانه Three.js زیربنای رندرینگ است که اجازه می‌دهد پروژه فوراً از طریق یک URL اجرا شود. برای اطمینان از ثبات جهان‌ها، از تولید دترمینستیک مبتنی بر بذر استفاده شده است؛ یعنی یک بذر خاص همیشه همان سیاره را تولید می‌کند و به کاربران اجازه می‌دهد به همان جهان بازگردند.
با این حال، این موضوع یک تضاد ایجاد می‌کند: تغییر در الگوریتم تولید می‌تواند به‌طور تصادفی جهان‌هایی را که کاربران می‌شناسند تغییر دهد. این مسئله، نسخه‌بندی تولیدکننده و پایداری بذرهای رویه‌ای را به یک چالش معماری مجزا و مستمر تبدیل کرده است.
اعتبارسنجی به جای ارزیابی توسط مدل‌های زبانی، از طریق ابزارهای خودکار انجام می‌شود. برای مثال، پایداری تولید رویه‌ای با بازتولید مجموعه‌ای از بذرهای ثابت و مقایسه نتایج بررسی می‌شود، که نیاز به یک مدل گران‌قیمت برای «حدس زدن» درست بودن کد را از بین می‌برد. این تضمین می‌کند که اگر یک ویژگی سیستم با تست قابل بررسی باشد، به مدل زبانی واگذار نمی‌شود.
این رویکرد، هوش مصنوعی را از یک تولیدکننده ساده کد به یک تیم مهندسی ساختاریافته تبدیل می‌کند. با تعریف قراردادهای مشخص برای هر عامل، یاروسلاو سیستمی را ساخت که معمولاً به یک استودیوی کامل و بودجه‌ای چند میلیون دلاری نیاز دارد. نتیجه نهایی، کهکشانی با ۱۹۰,۰۰۰ تا ۱۹۵,۰۰۰ منظومه ستاره‌ای در دسترس است که کاربران می‌توانند در آن سفینه برانند، روی سطوح فرود آیند و به دنبال یک اثر باستانی بگردند.
برای توسعه‌دهندگان، این به معنای گذار از «عصر پرامپت» به «عصر ارکستراسیون» است. ارزش دیگر در خودِ پرامپت نیست، بلکه در طراحی گردش‌کار عامل‌محور و محدودیت‌های اعمال‌شده بر آن است.
این پروژه نشان می‌دهد که آینده توسعه مستقل (Indie Development) در توانایی مدیریت عامل‌های هوش مصنوعی به عنوان یک نیروی کار نهفته است. گلوگاه دیگر توانایی نوشتن کد نیست، بلکه توانایی معماری سیستم و طراحی فرآیند ساخت آن توسط هوش مصنوعی است. یاروسلاو همچنان در حال گسترش پروژه با تمرکز بر موجودات واقع‌گرایانه‌تر، جهان‌های رویه‌ای متنوع‌تر و بهینه‌سازی اقتصاد توکن در توسعه عامل‌محور است.
اگر می‌خواهید نتیجه این گردش‌کار عامل‌محور را ببینید، می‌توانید جهان تولیدشده را در galaxyatlas.space کاوش کنید.
گفتگو