توسعه بازی Unity با AI

با قرارداد پروژه موجود شروع کنید

پیش از دادن دسترسی نوشتن به agent، editor انتخاب‌شده Unity، مسیر پروژه، پلتفرم target، packageها و setup rendering را مشخص کنید. نسخه پروژه و قفل‌های وابستگی را با رکورد آزمایش نگه دارید. تأیید کنید اپراتور editor و moduleهای target لازم را دارد؛ دسترسی مدل این پیش‌نیازها را فراهم نمی‌کند.

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

خودکارسازی editor را یک اتصال جدا بدانید

پروژه Unity MCP متعلق به CoplayDev عملیات editor را برای clientهای سازگار ارائه می‌کند. راهنمای نصب آن package editor و اتصال سرور را توضیح می‌دهد. سرویس مدل agent جداست: تغییر اعتبارنامه مدل instance در دسترس editor را درست نمی‌کند.

با بازرسی فقط‌خواندنی پروژه شروع و مشخص کنید کدام instance باز درخواست را می‌گیرد. تأییدهای mutation را به صحنه دورریختنی یا قابلیت صریحاً متعلق محدود کنید. برگشت موفق ابزار یعنی عملیات در مرز خودش تمام شده؛ صحنه حاصل ممکن است ارجاع نادرست داشته باشد یا در play شکست بخورد. راهنمای اختصاصی MCP کنترل اتصال و ثبت نسخه را پوشش می‌دهد.

تغییرهای محدود با نتیجه قابل‌مشاهده بخواهید

به‌جای بازنویسی کل صحنه پس از هر شکست، تنظیم controller، یک انتقال menu یا قابلیت persistence کوچک بخواهید. بگویید بازیکن چه باید کند، کدام state باید تغییر کند و نتیجه چگونه دیده می‌شود. پیش از قبول تغییرهای تولیدشده state سالم قبلی را حفظ کنید.

از brief نمونه زیر برای تعریف تغییر محدود و معیار بازبینی آن استفاده کنید. برای صحنه و prefab، ارجاع object و state ذخیره‌شده را علاوه بر diff script بررسی کنید؛ ممکن است فایل source به‌تنهایی configuration تعیین‌کننده گیم‌پلی را نداشته باشد. از agent بخواهید objectهای آسیب‌دیده را پیش از ویرایش مشخص کند.

Inspect the selected project and its existing input and controller code.
Add one restart transition to the owned gameplay scene.
Keep package versions and rendering settings unchanged.
Report changed scripts, scene references, and the verification performed.
Stop before package downloads, purchases, external uploads, or publishing.

پیش از تفسیر نتیجه play منتظر compilation بمانید

compilation کد، آماده‌بودن editor و گیم‌پلی را در log مشاهده جدا کنید. اگر compilation شکست خورد، نخستین خطای مرتبط و زمینه source تغییرکرده را capture کنید. وقتی editor scriptهای موردنظر را بارگذاری نمی‌کند از آن نخواهید حرکت را تنظیم کند؛ این کار ویرایش بیشتری روی baseline نامعتبر می‌سازد.

پس از compilation، پیش از ورود به play مؤلفه‌ها و ارجاع‌های مورد انتظار را بررسی کنید. پس از اصلاح همان عمل بازیکن را بازتولید کنید. console بدون خطا شواهد مفیدی است، اما بازی همچنان باید به وضعیت موردنظر برسد. تغییرهای تکراری بی‌اثر باید به بازتولید کوچک‌تر منجر شوند، نه جایگزینی بزرگ‌تر.

چارچوب test پروژه را آگاهانه به‌کار ببرید

Unity Test Framework انتخاب test از خط فرمان و خروجی نتیجه را مستند می‌کند. نمونه فرض می‌کند چارچوب از قبل پیکربندی و پوشه نتیجه موجود است. UNITY_BIN و PROJECT متغیرهای shell نمایشی هستند که به editor و پروژه موجود اشاره دارند. مستندات مرجع را با package نصب‌شده خود هماهنگ کنید.

برای منطق ایزوله مناسب کنترل‌های EditMode و برای رفتاری که اجرا لازم دارد کنترل‌های PlayMode را اجرا کنید. این دسته‌ها جای بازبینی دستی کنترل و ارائه را نمی‌گیرند. تعداد test، شکست‌ها و فایل‌های نتیجه را با revision مورد آزمون نگه دارید. اجرای بدون test کشف‌شده ثابت نمی‌کند بازی قبول شده است.

UNITY_BIN="/absolute/path/to/Unity"
PROJECT="/absolute/path/to/project"
"$UNITY_BIN" -batchmode -projectPath "$PROJECT" \
  -runTests -testPlatform EditMode \
  -testResults "/absolute/existing-results-dir/editmode.xml" \
  -logFile "/absolute/existing-results-dir/editmode.log"

پیش از ساخت player ورودی‌های build را بازبینی کنید

build باید از انتخاب صحنه بازبینی‌شده پروژه و configuration target استفاده کند. فرض نکنید صحنه باز فعلی editor همان صحنه شروع واردشده است. هویت build و logها را نگه دارید تا شکست‌های بعدی به artifact دقیق وصل شوند.

CLI Unity از فراخوانی متد static موجود editor با -executeMethod پشتیبانی می‌کند. این flag پیاده‌سازی build ایجاد نمی‌کند: پروژه به متد واقعی با رفتار build صریح و مدیریت شکست نیاز دارد. entry point موجود تیم را به method نمونه ساختگی ترجیح دهید که runnable به‌نظر می‌رسد اما در پروژه وجود ندارد.

گیم‌پلی را بیرون از editor اعتبارسنجی کنید

player تحویل‌شده را روی سیستم‌عامل اعلام‌شده با کنترل‌های مورد انتظار و state شروع پاک آزمایش کنید. از صفحه اول وارد، یک round را کامل، restart، تنظیمات را تغییر و دوباره launch کنید. persistence و انتقال‌ها را با brief پذیرش مقایسه کنید، نه فقط بازشدن پنجره.

از artifact واقعی screenshot اصیل و دنباله کوتاه مبتنی بر ورودی ثبت کنید. اگر اجرای editor موفق بود اما build شکست خورد، پیش از درخواست بازنویسی گیم‌پلی، گنجاندن صحنه، وابستگی منابع و رفتار ویژه پلتفرم را بررسی کنید. مرزی که تغییر کرده سرنخ خوبی برای علت است.

کار انسانی و وابستگی‌های حل‌نشده را پیگیری کنید

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

این walkthrough متکی بر مستندات باید با نسخه editor و package انتخابی شما اعتبارسنجی شود. کوچک‌ترین گردش‌کار کامل را در handoff نگه دارید: اتصال، تغییر، compilation، play و export. وقتی توسعه‌دهنده دیگری توانست آن را تکرار کند، همان baseline را برای قابلیت بعدی استفاده و هر بار وابستگی یا target build تغییر کرد کنترل را بازبینی کنید.

پرسش‌های پرتکرار